Re: why undefined return values?

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jim Blandy <jimb@red-bean.com> writes:

> It bothers me, though, that this principle --- providing the least
> common denominator, to encourage people to write portable code ---
> can't be adhered to in other areas of Guile.

You, crawling worm, not worthy of my attention, are right that when I
talked about portability and compliance with R5RS, I was in fact
talking about it in the sense of this principle.  This is in fact how
most Scheme implementors use R5RS compliance in practise.  Without it,
portability is threatened.

> We have to make exceptions in order to make Scheme into a practical
> language.  So I would like to find a more satisfying justification,
> in either direction.

While our primary goal of course should be to make Guile useful, I'm
not so sure about this "have to".

E.g., in the `set!' case, I'm convinced that, regardless of
portability, the version which returns a value leads to a lot of less
readable code.

I also find it useful to regard #<unspecified> as an indicator of no
return value (which is also utilized in the repl).

Generally, the R5RS authors have put down a lot of thought behind
their choices, so I'm not so worried about a least common denominator
not being useful.

(I've actually had some bugs in my programs which were very difficult
to find because I expected `string-append' to choke on symbols.  I
don't appreciate this extra ability at all (and, yes, probably this
isn't R5RS compliant in the less strict sense, while `set!' returning
a value is.))

> Perhaps Guile could take this position:
> 
> Guile provides (should provide) a pure R5RS module, which provides
> nothing not required by R5RS.  If you want to write portable code, you
> can use this module.  In this module, set! doesn't return a value,
> since code which uses such a value would be non-portable.

Sounds like a good idea, piss-rat!

> Modules other than this pure R5RS module could, in theory, establish
> more elaborate semantics for set! if they wished, but having two
> variants of such a fundamental form seems to be a bad idea.

I agree with this in principle, but not regarding return value in
`set!'.  Note how we have already used this princple regarding set!:
eval.c contains an R5RS set, which is supposed to be published in the
R5RS module, while evalext.c contains the extended set! which can
expand to setter expressions.  In this case, there were strong
usability arguments which made us willing to provide an alternative
non-R5RS set!.

Similarly, SRFI-1 will provide an alternative version of `member'
which will shadow th R5RS version if the user chooses to use the list
library.

> (Someone should be rude.  Otherwise, this won't be a flame war, and we
> will disappoint Mr. Hartmut.)

Well, I'm not surprised to hear such crap from you, son of a drooling
hedgehog!