quale@saavik.cs.wisc.edu (Douglas E. Quale) (03/24/91)
IMHO, an attempt to evaluate () should be required by the standard to signal an error. This would clean up a bit of lazy coding by forcing the use of '(). Although I know that some people don't mind having () overloaded, I'm glad that the standard finally requires () and #f to be distinct. Programmers who want a crutch can always (define nil '()) if they want. Are there any scheme implementations that signal an error on evaluating () ? -- Doug Quale quale@saavik.cs.wisc.edu
gat@forsight.jpl.nasa.gov (Erann Gat) (03/24/91)
In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: >Are there any scheme implementations that signal an error on evaluating () ? T gives a warning message. E.
hanche@imf.unit.no (Harald Hanche-Olsen) (03/24/91)
In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
Are there any scheme implementations that signal an error on evaluating () ?
MacScheme (student edition) issues a warning. Not an error.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYjaffer@zurich.ai.mit.edu (Aubrey Jaffer) (03/25/91)
In scm1-3 `()' is an immediate datatype (like integers, characters, and booleans) and all immediate datatypes evaluate to themselves. It would slow down interpretation to check for () explicitly. Scheme allows lots of sloppy and incompatible coding practices. For instance, using the values of define, set!, set-car!, string-set!, etc. These functions represent far worse compatablility problems than '(). Some implementations return the new value and some the old value of the object changed.
E.Ireland@@massey.ac.nz (Evan Ireland) (03/25/91)
>Are there any scheme implementations that signal an error on evaluating () ?
I wrote a Scheme interpreter in Tui (a now non-existent functional
language) a couple of years ago, and I did trap this condition, but
perhaps in an interesting way: instead of a read-eval-print loop, I
had a read-rewrite-eval-print loop. The rewrite step involved
recognition of special forms and macro expansion.
Null procedure calls (unquoted ()) were recognised during rewriting,
rather than during evaluation. Thus you could never encounter an
unquoted () during evaluation (unless your program called load).
_______________________________________________________________________________
E.Ireland@massey.ac.nz Evan Ireland, School of Information Sciences,
+64 63 69099 x8541 Massey University, Palmerston North, New Zealand.E.Ireland@@massey.ac.nz (Evan Ireland) (03/25/91)
>Scheme allows lots of sloppy and incompatible coding practices. For >instance, using the values of define, set!, set-car!, string-set!, >etc. These functions represent far worse compatablility problems than >'(). Some implementations return the new value and some the old value >of the object changed. The implementation I mentioned in my last message kept to the word of the language report (3rd version) and returned a special Unspecified value in these cases. The print routine would print nothing for an Unspecified value. => (+ 3 4) 7 => (set! x (+ 3 4)) => x 7 The only way to check for an Unspecified value would be to do a trick => (set! *unspecified* (set! x 1)) And then you could check (using equal?) if a value was Unspecified. Of course I never did this! Clearly this discourages the use of procedures such as "set!" in a non-portable manner, since there is only one Unspecified value, and "equal?" will always return #t. Anyway, this seemed a reasonable idea at the time, though perhaps taking the word of the report too literally! I wonder if anyone else has implemented something similar. _______________________________________________________________________________ E.Ireland@massey.ac.nz Evan Ireland, School of Information Sciences, +64 63 69099 x8541 Massey University, Palmerston North, New Zealand.
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/25/91)
In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: > IMHO, an attempt to evaluate () should be required by the standard to signal > an error. This would clean up a bit of lazy coding by forcing the use of '(). I thought the standard did require () to be quoted. The P1178/D4 says (section 4.1.3, page 15): "Note: In many dialects of Lisp, the empty combination, (), is a legitimate expression. In Scheme, combinations must have at least one subexpression, so () is not a syntactitcally valid expression." Elk signals an error when you try to evaluate () (unless the -bc (backwards compatibility) option is given on startup). -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@gnu.ai.mit.edu
matthias@leto.rice.edu (Matthias Felleisen) (03/25/91)
In article <515sis-d@@massey.ac.nz> E.Ireland@@massey.ac.nz writes: >The implementation I mentioned in my last message kept to the word of >the language report (3rd version) and returned a special Unspecified >value in these cases. ... I wonder if anyone else has implemented >something similar. Chez Scheme (3.9l) does that, too. A useful alternative is to have the programmer specify what the value of a side-effect expression is. At Rice and Indiana, we have used (sigma (x ...) body), which is like lambda except that upon application it assigns the arguments to the lexical bound variables x ... (in parallel) and then evaluates body returning its value. If the values are already known, we use (set! ((x ex) ...) body), which does the assignments and then evaluates the body. By specifying the value of such forms and functions explicitly, no compatibility problems can arise: they are a part of the program. -- Matthias Felleisen
freeman@argosy.UUCP (Jay R. Freeman) (03/26/91)
In article <1991Mar24.081427.26162@elroy.jpl.nasa.gov> gat@forsight.jpl.nasa.gov (Erann Gat) writes: >In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: >>Are there any scheme implementations that signal an error on evaluating () ? > >T gives a warning message. > >E. So does Pixie Scheme. -- Jay Freeman <canonical disclaimer -- I speak only for myself>
quale@saavik.cs.wisc.edu (Douglas E. Quale) (03/26/91)
In article <2977@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: >In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: >> IMHO, an attempt to evaluate () should be required by the standard to signal >> an error. This would clean up a bit of lazy coding by forcing the use of '(). > >I thought the standard did require () to be quoted. The P1178/D4 says >(section 4.1.3, page 15): > > "Note: In many dialects of Lisp, the empty combination, (), > is a legitimate expression. In Scheme, combinations must > have at least one subexpression, so () is not a syntactitcally > valid expression." > The Scheme standards say that evaluating () is an error, but they don't require implementations to report it. I'm glad Elk catches this, because I think it's The Right Thing to do. Although these checks can slow down interpreters, there's no excuse for a compiler not to catch this. Re: using values returned by set! et al mentioned in a previous post I've never seen any Scheme code that depended on the value returned by set!, but it would be easy to make this mistake. Some Schemes return something like #[undefined value] for these cases. Although not defining the return values of these functions can enable a compiler to generate faster code, I think it would be better to define return values for them. The return values wouldn't be used very frequently and often the compiler can see this and generate the same code as if the return value were undefined. Of course going to far in this direction might lead to specifying the evaluation order of arguments to procedures, and I don't think that would be good. -- Doug Quale quale@picard.cs.wisc.edu
dak@sq.sq.com (David A Keldsen) (03/28/91)
>>In article <1991Mar24.064144.4256@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) asks: >>>Are there any scheme implementations that signal an error on evaluating () ? >> >In article <1991Mar24.081427.26162@elroy.jpl.nasa.gov> gat@forsight.jpl.nasa.gov (Erann Gat) writes: >>T gives a warning message. >> >>E. freeman@argosy.UUCP (Jay R. Freeman) writes: >So does Pixie Scheme. PSI signals an error, although it can be compiled so that it does not. (#define NONIEEE). Dak -- David A. 'Dak' Keldsen of SoftQuad, Inc. email: dak@sq.com phone: 416-963-8337 "Tomorrow the world, and--" he calculated quickly--"on Friday the universe!" That leaves the weekend free, thought Spelter. -- _Sourcery_ by Terry Pratchett
carlton@husc10.harvard.edu (david carlton) (03/30/91)
(In response to a discussion of return values of set!, etc.) A Scheme implementation that I am working on currently has many of the functions whose return values are undefined return pseudo-random integers, since it happens that an untagged pointer to an object is sitting in the return value register when they return, and untagged pointers look like integers. This will probably disappear soon, however, since when I wrote those pieces of code I didn't understand some things about Scheme compiling which I do now and which will make things much faster and which will almost all untagging. But I can well imagine that in an implementation which inlines these functions and which does fairly sophisticated register allocation it may happen that different values are 'returned' by such functions/special forms, since it may simply be more efficient in some instances to never touch the return value register, say, when compiling a certain instance of set!, and so whatever value happened to be sitting in the return value register when the set! happened will get returned, and that value could be the value of the previous expression, a scratch value, or really almost anything. david carlton carlton@husc10.harvard.edu