This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: why undefined return values?


On 21 Jan 2000, Per Bothner wrote:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
>
> > I also find it useful to regard #<unspecified> as an indicator of no  
> > return value (which is also utilized in the repl).
>
> FWIW, in Kawa I defined (set! ...) (if x y) (set-car! ...) all to
> return #!void.  I also defined #!void to be eq to (values), i.e.
> zero values.  And the repl does not print the result of an
> expression if it is #!void.
>
> I don't like #<unspecified> because in Kawa, the result *is* specified.
> It seems silly to specify that the result of set! is #<unspecified> ...

I disagree, because I like the idea to make it explicit when an
application makes use of unspecified behaviour.  However, I wonder if in  
scheme one can make a distinction between 'definitely no return value',
which means that the standard explicitly states that there is no return
value, and 'the return value is unspecified'.  To me it seems that keeping
a return value unspecified leaves an option to the implementer to add a
return value at will, while still being standard conformant.

If this distinction was possible, I would even vote to add #<no return   
value> or #<void> or something similar to guile, to make this distinction
even clearer for those who try to write portable code.

Best regards,
Dirk Herrmann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]