This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: why undefined return values?
- To: Per Bothner <per at bothner dot com>
- Subject: Re: why undefined return values?
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Mon, 24 Jan 2000 16:38:20 +0100 (MET)
- cc: Guile Mailing List <guile at sourceware dot cygnus dot com>
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