Re: New Efforts
- Now I have done it...
On Tue, Jul 23, 2002 at 04:36:12PM -0700, Greg C wrote:
> Hello, Arno. Actually, after Roger Browne took a break, it appears no one
> wanted to step into his large shoes and stand up with an agenda.
It seems I now kind of volunteered to do this....
> So while you're standing in them, can I help you with the knots? :-)
That would be nice.
Roger's shoes definitely do not fit me at the moment, but I can give
it a try. Maybe in time I can become an acceptable substitute....
(Unless someone else wants to???)
About the further direction
> > One thing we should think about is what is most needed and
> > should be done next.
I am going to compile a list what currently open things we have.
This is not it yet, just some intermediate version.
1. I remember that we had some open issues when working on STRING. If
memory serves that was mostly in CHARACTER and COMPARABLE. But I
will have to go through the archives to find out.
2. Franck suggested
> Go on working on ANY, COMPARABLE, then NUMERIC and the concrete
> I'd like to very much see tackled is file I/O.
While Berend thinks
> Gobo already has classes for the most common IO operations,
> and its more than a lowest common denominator. Works with all
> Eiffel compilers across all platforms.
I am only working with Gobo for a short time now, and I did
not notice these classes. Is this in the KL_... classes?
If Eric already has working solutions here, we could take
them as an inspiration (if Eric agrees) and specify a subset.
While having this classes in Gobo is nice, having their basic
mechanism in ELKS should be the long-term goal. That would also
make Eric's life easier.
4. Berend wants to have a work-over on POINTER, INTEGER and related
Personally I would like to see INTEGER to be supplemented by
positives and variants that have specific bit size (see below), so
things like overflow can be handled and modern algebraic algorithms
become feasible (think e.g. crypto, PRNGs, compression,...).
Before anybody says that is what C code is for, I implemented
the mersenne twister (http://www.math.keio.ac.jp/~matumoto/emt.html)
in SE without using C code and got reasonable performance. With
known-size ints and uints I could have done this in a portable
5. Somewhat related to the last point is random number
generation and (related because of PRNG initialization)
time. I would like to have ELKS provide basic classes
here, and maybe even specify a good PRNG as default,
like the mentioned mersenne twister. This question is
not easy. E.g. current PRNGs in SE have broken contracts.
For time, I would not want to do full, international
time classes, just basic mechanisms for getting a
primitive representation, like "seconds since the epoch,
may be negative and is stored in signed 64 bit integer".
Gobo seems to do a good job of providing more, but basic
functionality should be ELKS.
Anything else? I propose we collect items for a week or two
and then I'll try to come up with an agenda.
In addition Ulrich would like to have some discussion about whether to
specify the complete set of ancestors an ELKS class might have. It
seems this discussion already is in progress.
My personal view is that it is more of a sideshow, as it implies a
complete work-over of all ELKS classes, which I think we cannot do at
the moment (be it merited or not). Of course we still have to specify
required conformance, like that INTEGER is COMPARABLE.
Incidentally, as the question will come up: Does anybody here knows
how to start a poll? Seems the interface does not allow me to. Do
I need some kind of moderator permissions?
> Is ECMA involved in just standardizing the language, or are they also
> concerned with library issues? Is ECMA getting buy-in from all the Eiffel
> compiler vendors? I for one would think it acceptable if we divided the
> standards works between ECMA on language and NICE on libraries.
> Seems pretty straightforward: ECMA does language and we can
> continue work on the kernel library. As long as we have the
> vendor's representative taking part we're safe that our efforts
> should not be wasted.
I am pretty sure ECMA will get support from all the vendors.
As far as I understood only language issues are addressed in
the upcoming standard. But while I was at the public talks
in the morning, I am not a member of the standardization group.
Anybody here that is and can keep us updated about what is going
on and warn us (and them) when we encounter possible conflicts?
Even if ECMA only does language, there are grey areas. One thing
I wanted for a long time is classes for signed/unsigned integers
with specific size (a la int8,int16,int32,int64,int128,uint16,
uint32,uint64,uint128). While a library question, this is quite
near to the compiler. So is this us, ECMA or both?
(Side note: _Can_ we expand ELKS here, to include e.g. things
like INT8? What would be the procedure? The same as a discussion
that proposes changes to an existing class?)
That about seems to sum it up for the moment.
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken
- Arno Wagner wrote:
> 3.Greg wants
> > I'd like to very much see tackled is file I/O.
> While Berend thinks
> > Gobo already has classes for the most common IO operations,
> > and its more than a lowest common denominator. Works with all
> > Eiffel compilers across all platforms.
> I am only working with Gobo for a short time now, and I did
> not notice these classes. Is this in the KL_... classes?
> If Eric already has working solutions here, we could takeNo problem with me. However note that although I'm quite happy
> them as an inspiration (if Eric agrees) and specify a subset.
with the design, it contains many classes in the inheritance
hierarchy (in order to allow not only the class interface specifiation
of files, but also of other kinds of input/output classes, even
those not necessarily based on CHARACTERs and STRINGs), and some
people might think that they are too many for kernel classes.
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> It seems I now kind of volunteered to do this....Good news!
> I am only working with Gobo for a short time now, and I didYes, but this is new to Gobo CVS/3.0, not in 2.0 (well the
> not notice these classes. Is this in the KL_... classes?
functionality was there in helper routines only).
> While having this classes in Gobo is nice, having their basicYes. (Although arguably it would make Eric's life easier only in
> mechanism in ELKS should be the long-term goal. That would also
> make Eric's life easier.
the medium term. In the short term after the agreement of a standard,
there's a risk some compilers and not others are implementing the
ELKS interface, that you need to track until everybody does it
> 4. Berend wants to have a work-over on POINTER, INTEGER and relatedI think it makes sense to do NUMERIC and COMPARABLE first, at least
for INTEGER which gets most of its interface from parents.
> Personally I would like to see INTEGER to be supplemented byBefore adding things we need to specify what is there rigorously.
Actually I think the numbers should be easier than STRING/ARRAY
(the main portability problems I can think of the top of my head
is the power operator and negative modulo semantics).
When that's done I agree fixed size arithmetic could be useful,
and it's certainly a common request.
> 5. Somewhat related to the last point is random numberI'm not sure it's wise to put that in the kernel. A trivial
> generation and (related because of PRNG initialization)
(time seeded) RNG is pure library and has nothing to do in
the kernel (as long as you have a way to get the time). A
(new) kernel facility should pass the test that it should
be hard or impossible to implement efficiently in terms
of existing kernel facilities.
A say crypto quality RNG could maybe pass that test, but
it is difficult to specify and verify (it's far too easy to
pretend) so I'd be inclined to leave it to entropy generation
libraries or operating system facilities (like /dev/[u]random
on Linux, which can be used from a kernel that includes file
Also the number of applications that need real randomness
is tiny, so another reason not to put in the kernel.
> "seconds since the epoch,That's very ugly. I can't think on any excuse to return
something other then year/month/day for the date. Time
within the day may have several equally acceptable
Without getting into full internationalisation, you still
get at least the GMT vs. local time issue to deal with in
the kernel (if only to choose one or the other).
> My personal view is that it is more of a sideshow, as it implies aAgreed.
> complete work-over of all ELKS classes, which I think we cannot do at
> the moment (be it merited or not). Of course we still have to specify
> required conformance, like that INTEGER is COMPARABLE.
> (Side note: _Can_ we expand ELKS here, to include e.g. thingsI think we basically should look at what vendors currently offer,
> like INT8? What would be the procedure? The same as a discussion
> that proposes changes to an existing class?)
and if they:
- all do the same thing, or something very similar,
- 1 or more do something similar, the others nothing
see if others agree doing like the first group,
- nobody does anything, we can design something new.
- the difficult bit is if they all do it differently ...
For signed INTEGERs I think ISE has something which could be
a starting point (I believe others have nothing but I have
On INTEGERs another thing that may be needed is variable
size integers (integers that cannot overflow), although
it is a bit at the limit of something which may belong
more to Gobo than the kernel as you can implement it
from well defined fixed size integers.
- On 25 Jul 2002, at 23:24, Franck Arnaud wrote:
> I think it makes sense to do NUMERIC and COMPARABLE first, at leastInteresting statement: We heard before that base classes (kernel
> for INTEGER which gets most of its interface from parents.
classes) to not specify what they inherit (i.e. I thought we'd see the
flat-short form of the standard specification).
Are we now claiming that INTEGER _is_ COMPARABLE in the sense of
I would very much agree with that. (Just as ARRAY _is_ some kind of
collection, but which one exactly)
> Are we now claiming that INTEGER _is_ COMPARABLE in the sense ofI think the question is not whether we can specify inheritance
> "inherit" ;-)
or not, but if we can specify a hierarchy that vendors can
agree on. In the case of ARRAY and STRING, it's very unlikely.
In the case of NUMERIC/COMPARABLE (and ANY) we start from a
point where everybody does the same thing. Arguably it's a
bit ironic given that using polymorphism on expanded types
like INTEGER and friends is not really usable, while
ancestors of STRING/ARRAY would be directly usable.
- First, I want to apologize for slipping up and sending out a copy of a
digest. Yahoo mail and I don't always get along.
Second, Arno is off to a good start here in leading discussion and
summarizing what's gone before. I'm will back off on the file I/O
standardization if there's consensus about picking up the base classes
mentioned by Berend and others, esp. INTEGER and its precursors.
It seems that COMPARABLE and NUMERIC are common base classes for INTEGER
among all compilers, and reasonable places to start discussion. And since
both classes affect other classes, having them standardized sounds good.
One of the disciplines Roger enforced was to avoid doing design on the
fly, or adding extensions, and instead focus on standardizing common
functionality already available among the various compilers. I think this
was a very successful approach that we should continue to apply.
So can we begin with a comparison of the short forms of COMPARABLE?
Apologies for the stupid Yahoo ad below.
Do You Yahoo!?
Yahoo! Health - Feel better, live better
- Hi everyone,
It seems that Arno is keen to "take the bull by the horns", and steer this
group forwards. Arno courteously emailed me to seek my approval.
Arno's move is fine by me - although it is not my OK that is needed. What is
important is the support of the Eiffel vendors and the Eiffel community. As
long as Arno captures the confidence and support of the vendors and the
community, he should proceed. If at any time that is no longer the case,
someone else should step in.
I've set Arno up with "moderator" privileges for this list - although I
never needed to use them for this very civilized group.
It was enormously satisfying to me that from 1999 to 2002 I was able to tread
a tightrope between the various Eiffel "schools of thought", and to work with
this group to achieve some very worthwhile improvements to the
interoperability of the ARRAY and STRING classes.
Thanks to everyone who made this possible, and especially to the vendors
without whose cooperation all of the work would have been fruitless.
Standards, no matter how worthwhile, are useless unless they get implemented.
Although I will continue to monitor this group, and will probably chip in
with the occasional comment, I doubt that I will devote the
time and energy to it that I did in the past. One reason is that, in my
opinion, the goalposts have shifted.
Since the beginning of my involvement with Eiffel in 1989, I have dreamed
of a vibrant multi-vendor Eiffel world that, through library
interoperability, would support the development of enough Eiffel libraries to
enable us to develop just about any kind of software system purely in Eiffel.
But it seems to me now that this dream will never be achieved. Instead, we
are almost certainly leading towards a world where software systems of all
kinds will interoperate using what Bertrand Meyer refers to as the "software
bus" - specifically the bus provided by the .NET Common Language
This is both disappointing and exciting. It's (slightly) disappointing
because the CLS falls slightly short of Eiffel's high aspirations in a few
ways. It's enormously exciting because, after decades of talk, the revolution
of software development through reusable components is finally being achieved
- and I'd like to see Eiffel (or something Eiffel-like) have a chunk of that
Not everyone sees the future that way - but for those who do, the pressing
need is not for Eiffel compilers to interoperate with each other 'per se',
but for Eiffel compilers to be compatible with the CLS. Interoperability
between Eiffel vendors then comes "for free".
Best wishes for the future work of this group - and thanks again to all those
who have contributed over the past few years!