Some problems with ELKS 
Author Message
 Some problems with ELKS

Hello,

First of all, I would like to know if there is a more recent version of
ELKS than 'vintage 95'. If not, is there a place where I could read
about all the things in work for the next vintage?

I'm trying to implement the class 'FILE' of ELKS 95 for SmallEiffel. And
there is a lot of things that I just don't understand:

1. What means the eigth rule of 'Flatshort Compatibility' ? In the way I
understand it, it means that we could redeclare the type of the
arguments of all routines by 'NONE' and still be ELKS compliant! I must
have missed something... Or may be it's about the type of features, not
of arguments!

[All the other questions are about the class 'FILE']

2. Why is there a postcondition 'exists' in the features 'open_read' and
'make_open_read'? This means that if we try to open an input file that
doesn't exist, it will be created. Should not this be a precondition
instead?

3. Why the names of 'open_read_append' and 'make_open_append' are not
coherents (in all other cases, there is just a prefix 'make_')?

4. Why is the feature 'dispose' exported to 'ANY'? The way I understand
it, it's just called by the GC when the object is garbage-collected. Am
I wrong?

5. How can we know that the reading of a number have succeded or failed?
That is, if we try to read an integer when the first character of the
input is neither a digit nor a sign (or a separator), nothing can be
read. Should not features like 'valid_integer_read' be useful
(necessary)? Is there another way, without changing ELKS?

6. What is the format of numbers that *must* be accepted? Are
underscores allowed (like in Eiffel-programs)?

7. Why isn't there a feature 'make_from_file'? It could be useful, for
example in testing a programmer-made sublass of 'FILE' by creating an
instance from 'io.input'...

8. Should 'put_real' and 'put_double' truncate their output? Whithout
truncating, these features are quite annoying... It's not possible to
use them in human-read output.

9. Should not the feature 'change_name' have a precondition
'not_new_name_empty'?

10. With a simple implementation, reading a number at the very end of a
file set 'end_of_file' to true, whereas reading a character at the end
of a file don't (it's the next call to read_xxx that will set it to
true). Is that a problem? (I think that C compilers also work that way,
but maybe they aren't the best example...)

I hope that not all of these questions have already been answered...

Thanks in advance for your help, and sorry for all the things I
certainly misunderstood!

PS : I would like to create a minimal implementation, that is, something
that would allow everything that is required, and nothing more. This is
to facilitate portability...

--

Universite de Bretagne Occidentale (Brest, France)

        Le C++ est a la programmation
        ce que les PC sont a l'informatique :
        une plaie.



Wed, 22 Sep 1999 03:00:00 GMT  
 Some problems with ELKS

Quote:

> First of all, I would like to know if there is a more recent version of
> ELKS than 'vintage 95'.

No. The latest officially-released document is the one entitled
"Eiffel Library Standard, Vintage 95" that was released at the time
of the 1995 press conference.

Quote:
> If not, is there a place where I could read
> about all the things in work for the next vintage?

No. Members of the NICE Libraries Committee are not permitted to discuss work
in progress in a public forum. However, if you join NICE you are able to
receive a copy of the committee's email discussions.

Your comments are useful, and I suggest you email them to the Chair of the

Quote:
> ... Should 'put_real' and 'put_double' truncate their output? Whithout
> truncating, these features are quite annoying... It's not possible to
> use them in human-read output.

The presentation of output is really beyond the responsibility of class
FILE. You should look towards specialised formatting classes for this.
The SIG Website (and CD-ROM) has some freeware formatting classes.

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Thu, 23 Sep 1999 04:00:00 GMT  
 Some problems with ELKS


Quote:
> 2. Why is there a postcondition 'exists' in the features 'open_read' and
> 'make_open_read'? This means that if we try to open an input file that
> doesn't exist, it will be created. Should not this be a precondition
> instead?

It can also mean that the feature will fail if the file does not
exist, but you are right; it should be a precondition.

Quote:

> 3. Why the names of 'open_read_append' and 'make_open_append' are not
> coherents (in all other cases, there is just a prefix 'make_')?

> 4. Why is the feature 'dispose' exported to 'ANY'? The way I understand
> it, it's just called by the GC when the object is garbage-collected. Am
> I wrong?

> 5. How can we know that the reading of a number have succeded or failed?
> That is, if we try to read an integer when the first character of the
> input is neither a digit nor a sign (or a separator), nothing can be
> read. Should not features like 'valid_integer_read' be useful
> (necessary)? Is there another way, without changing ELKS?

> 6. What is the format of numbers that *must* be accepted? Are
> underscores allowed (like in Eiffel-programs)?

This should be specified informally (BNF, smile) in the precondition, IMHO.

Ulrich Windl



Fri, 24 Sep 1999 03:00:00 GMT  
 Some problems with ELKS

Quote:

> No. Members of the NICE Libraries Committee are not permitted to discuss work
> in progress in a public forum. However, if you join NICE you are able to
> receive a copy of the committee's email discussions.

        Why? Should'nt it be useful to the Eiffel-programmers knowing (if not
discussing) the evolution of ELKS?

Quote:
> The presentation of output is really beyond the responsibility of class
> FILE. You should look towards specialised formatting classes for this.
> The SIG Website (and CD-ROM) has some freeware formatting classes.

        Then, what is the interest of this features (put_real, put_double) in
class FILE? Does someone use them, and what for? (I'm just curious).

--

Universite de Bretagne Occidentale (Brest, France)

        Le C++ est a la programmation
        ce que les PC sont a l'informatique :
        une plaie.



Mon, 27 Sep 1999 03:00:00 GMT  
 Some problems with ELKS

Quote:


> > 2. Why is there a postcondition 'exists' in the features 'open_read' and
> > 'make_open_read'? This means that if we try to open an input file that
> > doesn't exist, it will be created. Should not this be a precondition
> > instead?

> It can also mean that the feature will fail if the file does not
> exist

I was thinking that if preconditions are staisfied, the routine MUST
satisfy its postconditions... So, if we call 'open_read' on a closed
file-object, this file must physically exist after the call. If the call
fails, it means that there is a problem in the class FILE, not in the
programmer classes.

Anyway, we agree : it should be a precondition.

--

Universite de Bretagne Occidentale (Brest, France)

        Le C++ est a la programmation
        ce que les PC sont a l'informatique :
        une plaie.



Mon, 27 Sep 1999 03:00:00 GMT  
 Some problems with ELKS

Quote:

> ... what is the interest of this features (put_real, put_double) in
> class FILE? Does someone use them, and what for? (I'm just curious).

Personally, I think they are unnecessary. I always use
'put_string', so instead of writing "put_double(d)" I write
"put_string(d.out)". I prefer this approach because I can use it to
output any object. If 'out' has not been redefined, the default version from
class GENERAL will be used. It also works well for objects with formatted
output features. For example:

  a: ACCOUNT_NUMBER
  ...
  io.put_string(a.format("999-99"))

For similar reasons I think 'append_double' and 'append_real' are
unnecessary in class STRING.

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Mon, 27 Sep 1999 03:00:00 GMT  
 Some problems with ELKS

Quote:

> ... if preconditions are staisfied, the routine MUST
> satisfy its postconditions...

.. OR the routine may "fail" by raising an exception in which
case the "routine" must maintain the invariant but need not
satisfy the postcondition. I wrote "routine" in inverted commas
because the code responsible for maintaining the invariant
includes the routine body, the rescue clause (if any), and the
local version of ANY's feature 'default_rescue' (if there is no rescue
clause). (ETL page 258)

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Mon, 27 Sep 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Elk 2.2 on Solaris 2.3 - dlopen problems

2. Elk 2.0 problem loading xt.o (_alloca undefined)

3. Moving to ELKS

4. ELKS flat-short compliance issues

5. ELKS & flat-short compatibility paradox #1 :-)

6. ELKS bug for class ANY

7. ELKS 2001 STRING class is now an official standard

8. ELKS 2000 standard consequences?

9. Request for comments: proposed ELKS 2000 ARRAY class

10. Need debugger for Elk

11. ? Elk Scheme, Linux sigaction, SA_SIGINFO, siginfo_t ?

 

 
Powered by phpBB® Forum Software