This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.
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