On 3/14/13, Alan Manuel Gloria <xxxxxx@gmail.com> wrote:
> On 3/14/13, David A. Wheeler <xxxxxx@dwheeler.com> 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 <xxxxxx@gmail.com> 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