Hey,
As a dedicated user of the 'apply' procedure, I've been wondering if
it would be possible to use another syntax for `apply', so that
instead of writing:
(apply + '(1 2 3))
one could simply write
(+ . '(1 2 3))
Such syntax and behaviour would be coherent with the syntax and
semantics of argument lists in procedure definitions.
As I see it now, the syntaxes
(+ . (1 2 3))
and
(+ . (1 . (2 . (3 . ()))))
and
(+ 1 2 . (3 . ()))
although used rather rarely, are simply equivalent to
(+ 1 2 3)
and there is no purely syntactic way to apply, as the dot itself
behaves a little like a quote operator.
Having this syntax would of course allow to define `apply' using it,
if anyone ever wanted that:
(define (apply f . args) (f . args))

Perhaps I fail to see the whole picture, but would it really be so bad
to change the behaviour of the reader slightly to suit it to the
context of procedure application?
Would there be any drastic consequences?

Cheers,
M.

godek.maciek writes:

> As a dedicated user of the 'apply' procedure, I've been wondering if
> it would be possible to use another syntax for `apply', so that
> instead of writing:
> (apply + '(1 2 3))
> one could simply write
> (+ . '(1 2 3))

At the moment, that is the same as (+ quote 1 2 3). Awkward.

You might have better luck in asking for a programmable reader.
Schemers tend to appreciate the uniformity of their syntax, but also
the ability of the user to grow the language on their own.

> Such syntax and behaviour would be coherent with the syntax and
> semantics of argument lists in procedure definitions.
> As I see it now, the syntaxes
> (+ . (1 2 3))
> and
> (+ . (1 . (2 . (3 . ()))))
> and
> (+ 1 2 . (3 . ()))
> although used rather rarely, are simply equivalent to
> (+ 1 2 3)
> and there is no purely syntactic way to apply, as the dot itself
> behaves a little like a quote operator.

Yes, those are equivalent when read, but I think Scheme syntax is
defined so that a language processor is allowed (not required) to
reject the dotted ones as expressions.

And (+ . args) is never equivalent to (+ 1 2 3).

No, the dot does not quote anything. In a program, the whole datum
needs to be quoted to be valid.

> Having this syntax would of course allow to define `apply' using it,
> if anyone ever wanted that:
> (define (apply f . args) (f . args))
>
> Perhaps I fail to see the whole picture, but would it really be so bad
> to change the behaviour of the reader slightly to suit it to the
> context of procedure application?
> Would there be any drastic consequences?

Yes, there would: requests for ever more instances of special syntax.
Not worth it.

My feeling is that defining (f . args) is one thing, and would fit
along the lines you followed, but then defining (f quote arg) begins
to be ugly, and defining (f . args) without defining (f quote arg),
well, also ugly.

On Nov 15, 4:59=A0am, "godek.maciek" <godek.mac...@gmail.com> wrote:
> Perhaps I fail to see the whole picture, but would it really be so bad
> to change the behaviour of the reader slightly to suit it to the
> context of procedure application?
> Would there be any drastic consequences?

Language is for exploration. Give it a try and report back.

People say it is easy to tweak the reader in Racket.

W dniu wtorek, 15 listopada 2011, 14:28:25 UTC+1 u=C5=BCytkownik Jussi Piit=
ulainen=20

> > As a dedicated user of the 'apply' procedure, I've been wondering if
> > it would be possible to use another syntax for `apply', so that
> > instead of writing:
> > (apply + '(1 2 3))
> > one could simply write
> > (+ . '(1 2 3))
>=20
> At the moment, that is the same as (+ quote 1 2 3). Awkward.
>
> You might have better luck in asking for a programmable reader.
> Schemers tend to appreciate the uniformity of their syntax, but also
> the ability of the user to grow the language on their own.

Well, this is the second thing I wanted to ask :)
Actually, I admit that I really like the idea of the reader that bigloo has=
.. Perhaps certain details are not solved perfectly, but I think it is a goo=
d direction.

> > Such syntax and behaviour would be coherent with the syntax and
> > semantics of argument lists in procedure definitions.
> > As I see it now, the syntaxes
> > (+ . (1 2 3))
> > and
> > (+ . (1 . (2 . (3 . ()))))
> > and
> > (+ 1 2 . (3 . ()))
> > although used rather rarely, are simply equivalent to
> > (+ 1 2 3)
> > and there is no purely syntactic way to apply, as the dot itself
> > behaves a little like a quote operator.
>=20
> Yes, those are equivalent when read, but I think Scheme syntax is
> defined so that a language processor is allowed (not required) to
> reject the dotted ones as expressions.
>=20
> And (+ . args) is never equivalent to (+ 1 2 3).
>=20
> No, the dot does not quote anything. In a program, the whole datum
> needs to be quoted to be valid.

I wrote that it behaves 'a little like a quote operator', because when I wr=
ite (+ 1 . (2 3)), the interpreter does not try to apply 3 to 2 -- and that=
's what would happen if I wrote (+ 1 (2 3)).

> > Having this syntax would of course allow to define `apply' using it,
> > if anyone ever wanted that:
> > (define (apply f . args) (f . args))
> >
> > Perhaps I fail to see the whole picture, but would it really be so bad
> > to change the behaviour of the reader slightly to suit it to the
> > context of procedure application?
> > Would there be any drastic consequences?
>=20
> Yes, there would: requests for ever more instances of special syntax.
> Not worth it.

I think your assumption is that the behaviour of the current scheme reader =
is somewhat optimal. Perhaps you're right -- I don't know much about it.

> My feeling is that defining (f . args) is one thing, and would fit
> along the lines you followed, but then defining (f quote arg) begins
> to be ugly, and defining (f . args) without defining (f quote arg),
> well, also ugly.

I don't follow. Why would (f . args) without (f quote args) be ugly? Why wo=
uld anyone have to define anything like (f quote args) [which would be, I a=
dmit, ugly indeed]?

Regards

godek.maciek@gmail.com writes:
> W dniu wtorek, 15 listopada 2011, 14:28:25 UTC+1 użytkownik Jussi
> Piitulainen
>
> > You might have better luck in asking for a programmable reader.
> > Schemers tend to appreciate the uniformity of their syntax, but also
> > the ability of the user to grow the language on their own.
> 
> Well, this is the second thing I wanted to ask :)
> Actually, I admit that I really like the idea of the reader that
> bigloo has. Perhaps certain details are not solved perfectly, but I
> think it is a good direction.

Explore it, by all means, or follow the suggestion by Grant Rettke. I
thought of mentioning Racket, too, but I was not sure of the details
and the thing having changed its name since I last looked, I wasn't
exactly sure of what I should mention.

> > No, the dot does not quote anything. In a program, the whole datum
> > needs to be quoted to be valid.
> 
> I wrote that it behaves 'a little like a quote operator', because
> when I write (+ 1 . (2 3)), the interpreter does not try to apply 3
> to 2 -- and that's what would happen if I wrote (+ 1 (2 3)).

The way it works, when it works, is such that the interpreter never
sees (+ 1 . (2 3)) as distinct from (+ 1 2 3). It is resolved by the
reader, which is a parser for Scheme data. Interpretation as code
comes after that.

> > > Perhaps I fail to see the whole picture, but would it really be
> > > so bad to change the behaviour of the reader slightly to suit it
> > > to the context of procedure application?
> > > Would there be any drastic consequences?
> > 
> > Yes, there would: requests for ever more instances of special syntax.
> > Not worth it.
> 
> I think your assumption is that the behaviour of the current scheme
> reader is somewhat optimal. Perhaps you're right -- I don't know
> much about it.

I'm not sure about that. It might be a kind of local optimum. One
change would lead to others.

> > My feeling is that defining (f . args) is one thing, and would fit
> > along the lines you followed, but then defining (f quote arg) begins
> > to be ugly, and defining (f . args) without defining (f quote arg),
> > well, also ugly.
> 
> I don't follow. Why would (f . args) without (f quote args) be ugly?
> Why would anyone have to define anything like (f quote args) [which
> would be, I admit, ugly indeed]?

Because the datum (f . 'arg) is equivalent to (f quote arg). First,
'arg is equivalent to (quote arg), and then (f . (quote arg)) is
equivalent to (f quote arg).

I'm getting confused :) Let's see. I give you the case where the dot
is followed by a variable: it's currently undefined and could be
defined. But if the dot is followed by anything else, we get either
nonsense like (f quote arg), with a keyword where a keyword cannot be,
or cases that are currently defined but not as apply: (f . (1 2 3)) is
the same as (f 1 2 3) -- if the language processor uses read, that is
-- which is all right but not new.

And currently (f . (+ 2 3)) is the same as (f + 2 3) -- if it is
anything. Ok, (apply f 5) is an error, but (f . (g 2 3)) is the same
as (f g 2 3), which cannot be generally defined to mean the same as
(apply f (g 2 3)) because it already has a meaning. The interpretation
of the dot syntax precedes the interpretation of the datum as an
expression.

That's what I mean when I say that one change would lead to others.

"godek.maciek" <godek.maciek@gmail.com> writes:
> (define (apply f . args) (f . args))
>

Back in my school days we learned scheme things like this:

(lambda (<selector> . <arguments>)
        (apply (vector-ref dispatch <selector>)
                           <arguments>))

with (define selector1 (vector 'foo 'bar 'baz))
and
        (define (func args)
                'gnuvy)

        (define (dispatch <selector>)
                (cond ((eq? <selector> 'gnuvy)
                            func)
                            (else (display "Unknown <selector>")(newline))))
and arguments a dot list.

FE

> Perhaps I fail to see the whole picture, but would it really be so bad
> to change the behaviour of the reader slightly to suit it to the
> context of procedure application?
> Would there be any drastic consequences?
>
> Cheers,
> M.