Sunday, May 28, 2006


ECMA 367 is not a standard

You can't call this a standard, because it does not contain sufficient information for implementors to know if they conform to it or not.

Specifically, the semantics of some parts of the language are defined in terms of kernel classes, but these classes are not defined within the standard, nor is there a reference to their standard definition.

This would be bad enough for classes like BOOLEAN, which have been defined before, but for classes like STRING_32 and ASSERTION_EXCEPTION, it is unforgivable.

Anyway, the standard ought to define the interfaces for the entire kernel library. And this ought to include container classes. How else can we hope to write portable code?

Interesting, didn't know that!
It's a language standard. It doesn't claim to be a standard for libraries, Lace, etc. Accusing it of not being a standard, just because it doesn't describe something outside its scope, is ... ummm ... provocative.

Of course, you're not alone in needing to see the standard for the kernel classes. You say that ECMA 367 has no reference to their standard definition. How about page 2? It refers to ELKS 2001, and it mentions 19 classes that it assumes to be present in ELKS. As far as I can tell, though, many of those 19 classes are missing from ELKS 2001: e.g., TYPE [G] and the sized strings and numerics.

The ETL3 draft describes a lot of these classes, but it hasn't been updated for almost a year and is not authoritative.
ECMA 367 refers to the ELKS standard as an external reference. You could argue that the library definition be included in ECMA 367, since the language is so heavily dependent on them. But to say it's "not a standard" is to look at it in black and white. It's like you're saying, "it doesn't define ELKS classes so the whole thing is garbage!"

Here is the reference

3.2 Eiffel Kernel Library
The terms “ELKS” and “Kernel Library”, as used in this Standard, refer to the latest version of the Eiffel Library Kernel Standard. A preliminary version is available from the NICE consortium:

NICE consortium: The Eiffel Library Kernel Standard, 2001 Vintage.

Maybe the ECMA committee wanted NICE to continue their efforts and release a new ELKS standard? Time to go to work?
You haven't been reading what I said.

STRING_32 and ASSERTION_EXCEPTION hasn't been defined anywhere, yet the semantics of the language depend upon their definition.

So the language is not defined.
It's pretty clear that Bertrand doesn't plan to endorse any future NICE standard as the standard kernel to support ECMA Eiffel.

Nor could NICE specify such a thing anyway, given that ECMA 367 is an unimplemented fiction.

Nor does there seem to be any point for NICE to update ELKS. ISE Eiffel and SmartEiffel are diverging from ELKS and from each other. Visual Eiffel is stagnant, and Gobo Eiffel has a stated aim of compatibility with ISE Eiffel.

Therefore, I can't see any scenario in which a NICE ELKS standard can help with interoperability - and what other purpose could a NICE standard have?
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?