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

The ". $" notation (was: Re: how useful are collecting lists?)

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 are here. Eventually, the entire history will be moved there, including any new messages.



On 3/14/13, Alan Manuel Gloria <almkglor@xxxxxxxxx> wrote:
> On 3/14/13, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote:
>> I said:
>>> > Hmm. If that's a *problem*, one solution without significantly
>>> > changing
>>> > the existing semantics might be to allow <*...*> after ".".
>>
>> Alan Manuel Gloria <almkglor@xxxxxxxxx> wrote:
>>
>>> Ara ara, I thought this was *already* allowed...
>>
>> Actually, they weren't.  I was trying to be picky about what's allowed
>> after
>> "." (e.g., I don't think "$" and "\\" are sensible),
>
> EEeeeeeh??
>
> Well, \\ isn't sensible because it ends the current expression so it
> comes out as something like (. ), which doesn't make sense), but why
> not "$"?
>
> Say:
>
> foo $ a b
> ===>
> (foo (a b))
>
> foo . $ a b
> ===>
> (foo . (a b))
> ===>
> (foo a b)
>
> ....hmmm.
>
> Okay, so there's really no use for $ after . LOL.  I can't think of a
> use case for when you'd rather have a ". $" instead of just writing
> the next datum directly.
>

Okay, here's something we can use ". $" for:

SRFI-26 provides a "cut" operator that, in s-expressions, looks likes this:

(cut proc arg arg <> arg arg <...>)
==macro-expansion==>
(lambda (x1 . x2)
  (apply proc arg arg x1 arg arg x2))

By s-expression rules, we can re-express it as:

(cut . (proc arg arg <> arg arg <...>))

By t-expression rules:

cut . (proc arg arg <> arg arg <...>)

To reduce the parentheses, we could (I propose!!) do:

cut .
  proc arg arg <> arg arg <...>

Or alternatively:

cut . $ proc arg arg <> arg arg <...>

--

Basically, in the case of cut, while ". $" is effectively a no-op, it
separates, syntactically, the procedure call from the form that
provides a limited extension of the procedure call's semantics (in the
case of cut, it adds <> and <...> syntaxes).  A user might, in the
future, be able to think of other extended formulations which ". $"
could then support.

For another example:

map f as bs ; where f is a two-argument function.

We might want to express it as:

map . $ f as bs

Where we might conceptually think "The syntax 'map . $' makes the
syntactically-subsequent call 'map' a function over lists of its
arguments, instead of just applying a function to its arguments
directly."

This riffs off my insight in SRFI-105:

(cut . { <> + b }) ==> (cut . (+ <> b)) ==> (cut + <> b)
(map . { as + bs }) ==> (map . (+ as bs)) ==> (map + as bs)

--

So my proposal is:

1.  Allow "foo . EOL INDENT x ..." ==> "(foo . (x ...))"
2.  Allow "foo . $ x ..." ==> "(foo x ...)"

What does everyone think??

Sincerely,
AmkG