Re: nested define syntax

[Matthias Koeppe]

Marius Vollmer <address@hidden> writes:

> Matthias Koeppe <address@hidden> writes:
>
>> Dirk Herrmann <address@hidden> writes:
>> 
>> > currently, guile allows the following:
>> >
>> > guile> (define (((foo a b) c) d) #f)
>> [...]
>> BTW, this technique is called "currying"; I use it extensively in my
>> code.
>
> But is the technique closely linked to the syntax?  What we currently
> have is certainly very elegant, and for a long time I thought it was
> standard Scheme because it felt so much in line with Scheme in
> general.  

Of course the technique is not limited to this syntax, as the
technique is used in other functional languages as well.  But as you
point out, the syntax is a very natural since it generalizes the
standard Scheme syntax

    (define (foo a) BODY...)   ==   (define foo (lambda (a) BODY...))

> But I could also image that we might want that syntax for
> some other extension that is less elegant but more practical.  Common
> Lisp has function names that are lists of symbols, for example.  The
> setter of FOO is called (SETTER FOO).  That's certainly an elegant
> concept as well, and it is extensible.  Just one half of a thought.

That's fine for Comon Lisp, where functions are defined with (defun
FUNCTION-NAME LAMBDA-LIST BODY...).  It does not fit at all into the
Scheme define syntax, though.  

Maybe this wasn't your actual point, but I don't see why one should
want to introduce a new syntax for defining setters or other
SRFI-17-style "properties" of a procedure.  For setters, just stick to
Guile's MAKE-PROCEDURE-WITH-SETTER (or SRFI-17's GETTER-WITH-SETTER)
to build procedures with setters (that is, build a value that is both
applicable as a procedure and can deliver a "setter" procedure).
That's a much more Schemy way than attaching extra properties (SETTER)
to a symbol (FOO) or the procedure.  If one really wants to deal with
properties, setting a property should be regarded as a mutation rather
than a definition, so the generalized SET! syntax is appropriate.

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