Standardness of the (define ((proc arg) anotherarg) definition) syntax.
Štěpán Němec
described as follows:
==STARTQUOTE==
In Scheme mode, Emacs font locks the form:
(define (in-vicinity-proc dir)
(lambda (filename)
(in-vicinity dir filename)))
with ‘define’ as a keyword and ‘in-vicinity-proc’ as a function name,
using font-lock-{keyword,function-name}-face, respectively. That's fine.
However, for this form:
(define ((in-vicinity-proc dir) filename)
(in-vicinity dir filename))
then Emacs font locks only ‘define’. I have locally modified
‘scheme-font-lock-keywords-1’ to change "zero or one parens"
to "zero or more parens" and that change seems to DTRT.
Could someone please review the patch below and apply it?
==ENDQUOTE==
That made me wondering how standard this kind of definition is -- I
don't remember ever seeing it before. I asked Thien-Thi, who replied
that Guile supports it and that he believed other Scheme implementations
do, too. Can someone provide more insight?
Thanks,
Štěpán
Ian
I have 4 Schemes on my computer and 3 of them support it.
Guile 1.8.7, Larceny 0.9.7 and PLT Racket v5.0 do
Ikarus 0.04rc does not
Jose A. Ortega Ruiz
[...]
>> That made me wondering how standard this kind of definition is -- I
>> don't remember ever seeing it before. I asked Thien-Thi, who replied
>> that Guile supports it and that he believed other Scheme implementations
>> do, too. Can someone provide more insight?
>>
>> Thanks,
>>
>> Štěpán
>>
>> [1] <http://article.gmane.org/gmane.emacs.devel/126948>
>
> I have 4 Schemes on my computer and 3 of them support it.
> Guile 1.8.7, Larceny 0.9.7 and PLT Racket v5.0 do
> Ikarus 0.04rc does not
MIT-Scheme, Gauche and Chicken do support these 'curried definitions'
too.
jao
Vitaly Magerya
> [...]
> (define ((in-vicinity-proc dir) filename)
> (in-vicinity dir filename))
> That made me wondering how standard this kind of definition is -- I
> don't remember ever seeing it before. I asked Thien-Thi, who replied
> that Guile supports it and that he believed other Scheme implementations
> do, too. Can someone provide more insight?
In some implementations "define" is implemented like this:
(define-syntax define
(syntax-rules ()
((_ (fun . args) . body) (define fun (lambda args . body)))
((_ name value) (#internal-define name value))))
With this implementation, your definition:
(define ((in-vicinity-proc dir) filename) ...)
... is first rewritten to:
(define (in-vicinity-proc dir) (lambda (filename) ...))
... and then to:
(#internal-define in-vicinity-proc
(lambda (dir) (lambda (filename) ...)))
That's why some implementations support such a feature.
William D Clinger
> That made me wondering how standard this kind of definition is -- I
> don't remember ever seeing it before. I asked Thien-Thi, who replied
> that Guile supports it and that he believed other Scheme implementations
> do, too. Can someone provide more insight?
It originated at MIT, to simplify the definition of curried
procedures.
It isn't mentioned by any of the Scheme standards, official (IEEE/
ANSI)
or unofficial (e.g. R5RS, R6RS). The R6RS forbids extensions of that
kind to the define syntax exported by (rnrs base) and (rnrs), but you
can define your own define syntax and use it instead of the standard
syntax.
Will
Štěpán Němec
William D Clinger <cesu...@yahoo.com> writes:
> It originated at MIT, to simplify the definition of curried
> procedures.
>
> It isn't mentioned by any of the Scheme standards, official (IEEE/
> ANSI)
> or unofficial (e.g. R5RS, R6RS). The R6RS forbids extensions of that
> kind to the define syntax exported by (rnrs base) and (rnrs), but you
> can define your own define syntax and use it instead of the standard
> syntax.
I don't think I understand this. Could you point me to the section of
R6RS where such prohibition is made? All I could find is the
specification of the "conventional" `define' variants without explicitly
stating that those are the only possibilities. Also, as Vitaly shows in
a previous reply, what looks like a perfectly compliant definition of
`define' provides for the curried procedure definition as well, so it
seems that if r6rs really strictly required that this kind of definition
should not be honored, the implementations striving for r6rs compliance
would possibly have to jump through some hoops to somehow make it "not
work"...?
Thanks,
Štěpán
William D Clinger
> I don't think I understand this. Could you point me to the section of
> R6RS where such prohibition is made?
R6RS section 5.5 says:
When macro expansion terminates, however, implementations
must detect violations of the syntax. A syntax violation
is an error with respect to the syntax of library bodies,
top-level bodies, or the “syntax” entries in the
specification of the base library or the standard
libraries....
If a top-level or library form in a program is not
syntactically correct, then the implementation must raise
an exception with condition type &syntax, and execution
of that top-level program or library must not be allowed
to begin.
According to R6RS chapter 2, the word "must" in the above
implies that these are absolute requirements.
> All I could find is the
> specification of the "conventional" `define' variants without explicitly
> stating that those are the only possibilities.
Note the language in section 5.5: "A syntax violation is an
error with respect to...the “syntax” entries in the
specification of the base library or the standard
libraries...."
> Also, as Vitaly shows in
> a previous reply, what looks like a perfectly compliant definition of
> `define' provides for the curried procedure definition as well, so it
> seems that if r6rs really strictly required that this kind of definition
> should not be honored, the implementations striving for r6rs compliance
> would possibly have to jump through some hoops to somehow make it "not
> work"...?
Yes, implementations of the R6RS are required to jump
through hoops to make things not work.
Will
Štěpán Němec
Yes, I see that now, thank you for the explanation.
>> Also, as Vitaly shows in
>> a previous reply, what looks like a perfectly compliant definition of
>> `define' provides for the curried procedure definition as well, so it
>> seems that if r6rs really strictly required that this kind of definition
>> should not be honored, the implementations striving for r6rs compliance
>> would possibly have to jump through some hoops to somehow make it "not
>> work"...?
>
> Yes, implementations of the R6RS are required to jump
> through hoops to make things not work.
Interesting. Do you (or anyone reading this) also know if this
particular case (i.e. not permitting the "curried definition" variant)
was an intention on the R6RS authors' part (and the rationale for it) or
just an omission?
Štěpán
Alan Bawden
> ...
> Interesting. Do you (or anyone reading this) also know if this
> particular case (i.e. not permitting the "curried definition" variant)
> was an intention on the R6RS authors' part (and the rationale for it) or
> just an omission?
I have no idea whether the R6 authors thought about it, but I do recall the
idea of including this common extension in the standard was discussed many
years ago. The extension was rejected at the time. My memory is that the
people wo were opposed to it wanted a syntax like (define ((foo bar) ...)
...) to mean something -else-.
marcomaggi
> Interesting. Do you (or anyone reading this) also know if this
> part (and the rationale for it) or just an omission?
I do not know what the authors were thinking, but why would you
want it? Every non-standard extension allowed makes it more
difficult to port code, no? (In the past I asked for some
extensions, too, but for most of them I changed my mind after
more thinking.)
If I see (import (rnrs)) and #!r6rs at the top of a file, I know what
to expect in it. Personally, I do not want other things
there.
I am using my own "language" in which DEFINE is redefined, and...
it can be done. If you see (import (nausicaa)) you know that
something is different, and you also know that (probably)
the difference in the language can be deconstructed into some
layer on top of (rnrs).
My 0.02EUR.
--
Marco Maggi
John Cowan
> Can someone provide more insight?
(define-syntax cdefine
(syntax-rules ()
((_ (head . rest) body body* ...)
(cdefine head
(lambda rest body body* ...)))
((_ name val)
(define name val))))
Guile then exports this as define, but that's neither portable nor necessary to use it.
--
John Cowan http://vrici.lojban.org/~cowan co...@ccil.org
By naming the names they rejoiced in the complexity and specificity,
the wealth and beauty of the world, they participated in the fullness of
being. They described, they named, they told all about everything. But
they did not pray for anything. --Le Guin, The Telling