guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nested define syntax


From: Matthias Koeppe
Subject: Re: nested define syntax
Date: Wed, 07 Nov 2001 18:15:51 +0100
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (sparc-sun-solaris2.7)

Dirk Herrmann <address@hidden> writes:

> On Thu, 1 Nov 2001, Matthias Koeppe wrote:
>
>> Dirk Herrmann <address@hidden> writes:
>> 
>> > currently, guile allows the following:
>> >
>> > guile> (define (((foo a b) c) d) #f)
>> > guile> foo
>> > #<procedure foo (a b)>
>> > guile> (procedure-source foo)
>> > (lambda (a b) (lambda (c) (lambda (d) #f)))
>> >
>> > This is non-R5RS conformant, and I wonder if anybody uses this style of
>> > declaration?  Shouldn't we rather remove it?
>> 
>> This syntax is *not defined* in R5RS.  Guile provides a convenient
>> *extension* to R5RS here.  Why do you claim that supporting this
>> extension violates R5RS?
>
> R5RS says ('*' characters added by me):
>
>   5.2 Definitions
> [...]
>
> Obviously, the (define ((foo x y ...) r s ...) ...) form is none of the
> forms a definition _should_ have according to R5RS, although I admittedly
> don't know if this means that is strictly correct to speak of 'violation'
> or 'being non-conformant'.

Please see R5RS "Notation and terminology" -- "Primitive; library; and
optional features", where this is explained:

| Implementations are free to omit optional features of Scheme or to add
| extensions, provided the extensions are not in conflict with the
| language reported here.  In particular, implementations must support
| portable code by providing a syntactic mode that preempts no lexical
| conventions of this report.

Guile's extended DEFINE form clearly is not in conflict with the R5RS
language (because, as you pointed out, the extended syntax is not
defined by R5RS), so Guile *is* R5RS-conformant in this respect.

> That is, the syntactic extension does not provide too much of a
> convenience, but leads to an incompatibility.  

Incompatibility with what.  Do you mean non-portability of code using
this Guile extension?

> I question that this is a good idea.  For those who like to use such
> a feature, it would IMO be better to provide it as a loadable
> extension, or to use 'define*' instead.
>
> However, I wonder how people get to know about this feature at all, since
> there does not seem to be any documentation about it.  The only faint
> reference to it I could find was in the documentation for 'define*':
>
>   "`define*' and `define*-public' support optional arguments with a
>    similar syntax to `lambda*'. They also support arbitrary-depth
>    currying, just like Guile's define."
>
> I would not consider this a documented feature.  Thus, we should decide
> whether we want to keep this extension.  IMO, we should not support it by
> default.  Who likes it, can use 'define*'.  If it is still decided to keep
> it as an official feature (and thus as a source for incompatibilities),

Again, only *removing* the feature would be a source for
incompatibilities (that is, with code written for older versions of
Guile).

> then it should a) be documented in the manual and b) this should also be
> documented in the implementation.

I would suggest to keep this feature and to document it.  It was
present in Guile for a long time, and it was only forgotten in the
documentation.

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]