On Thu, May 19, 2011 at 8:50 PM, Jim Rees <[email protected]> wrote:
> On Thu, May 19, 2011 at 1:10 PM, Andy Wingo <[email protected]> wrote: > >> I do not agree with the note that permitting any number of values to be >> returned from `set!' et al is incompatible. It is not incompatible with >> implementations, as it widens the scope of what they may do..... > > > Requiring a single unspecified value means that: > > (let ((x (if #f 'never))) <stuff that does not depend on x>) > > is legal Scheme code (based on the interpretation that initializers *must* > return a single value, unspecified or not). > > So, allowing implementations to return multiple or zero unspecified values > would actually shrink the language from what it used to be. This is what I > observe the WG tries very hard to avoid, especially if "lots of existing > code" depends on the status quo. > > I know nothing about the existing code that depends on this particular > feature. I would personally have preferred "any number", as it's handy for > detecting buggy code. > > "In the land of the one-armed IF, the people go blind from squinting" -- Shriram Krishnamurthi Relying on a value from an expression which could have none is potentially buggy. I would not go and standardize such "status quo". In Dr Racket they enforced to always have an 'else' clause. I would suggest that one armed "if" should return no values. PS: For me the real problem is elsewhere: I really dislike to have a value which is an unspecified one, I prefer instead that implementations return nothing - as in (values) - and to let the standard legitimates some implementation which wants to return something (as with MIT-Scheme with set! to have a kind of test-and-set instruction, however I don't know of other examples) Best regards, -- Emmanuel Medernach
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
