On Dec 2, 2007 12:58 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> Alan Manuel Gloria:
> > Declaring a "pattern" to match a string from an input stream just feels so
> > Perlish, to me.... the infix pattern [should be changeable]... I (or
> > someone) might make a "convoke" (or something) infix operator...
>
> My explanation may be too Perlish. The rule is actually simple, it's
> basically "1 to 5 of these punctuation characters..." plus a few special
> cases. Perhaps I should rewrite the pattern rule without using a regex.
Actually, my objection is that it makes punctuation a little too
special. If only punctuation is allowed in infix... comrade
nonpunctuation characters, you must fight for your right to be
included!
Still, I suppose that if infix is limited to that, perhaps it would be
better to exactly define what the operators are, instead of allowing 1
to 5 punctuation characters and adding special cases; that is, make
them all special cases.
>
> I think allowing developers to declare operators is a good thing for a
> _macro_. But if you do infix processing at _READ_ time, I think requiring it
> is a bad idea. That would create nasty read-ordering dependencies; if you
> read an expression, and THEN read the command that defined a new operator, it
> wouldn't work as expected.
I wouldn't expect previous expressions to follow the newly declared
operator, in much the same way that I don't expect macros or
reader-macros to magically redefine previous expressions.
>
> Many languages seem to intentionally devise their infix operators so that
> they are only punctuation anyway (with possible exceptions for "and' and
> "or"). That way, all infix operators are visually distinct, and being
> visually distinct is a good thing anyway. So I don't think the limitation is
> a big deal. You can have a convoke operator, you just can't spell it as
> "convoke" :-).
Hmm. Alternative convoke spellings:
*<=>*
<<*>>
!<->!
><+><
@<=>@
<=+=>
Incidentally, Haskell supports using function names as infix operators
by using `` to escape the function:
foob:: Proc a -> Proc a -> Proc a
foob a b = a `convoke` b -- equivalent to convoke a b
>
>
>
> > > But if (...) will only be used to surround "strict s-expressions", and
> > > [...] force "no infix" interpretation, then this is no longer a problem.
> > Hmm, I thought {} for "infix interpretation", everything else being no
> > infix? It seems in most of your later samples, {} is used around infixes.
>
> No, the default in sweet-expression is "infix everywhere", and I was thinking
> about specific ways to turn it off. You can even see this in my first
> example (the factorial) at http://www.dwheeler.com/readable/ :
>
> defun factorial (n)
> if (n <= 1)
> 1
> n * factorial(n - 1)
>
>
> Note that the "n * factorial..." didn't get surrounded by {...}. Note also
> that factorial(n - 1) isn't surrounded by {...}, but name-prefixing ITSELF
> also permits inside it.
>
> The rationale for this is pretty straightforward: In nearly all other
> languages, infix is the DEFAULT. So, I set up infix to be the default
> everywhere too. Sometimes you don't WANT it to be the default, so I used
> as(+) to escape it.
>
> But if I'm going to switch to using {...} instead of (..) for grouping infix
> anyway, then it's certainly plausible to say something like "for infix, must
> surround with {...} or name-prefixed function name". This would mean that
> where indentation is relevant, infix is NOT enabled; you'd have to use {...}
> or name(...) to have an infix use.
>
> The example would become:
> defun factorial (n)
> if {n <= 1}
> 1
> {n * factorial(n - 1)}
>
> The {...} would a good idea if the reader inserted a macro call here. But if
> not, I'm not sure what the advantage would be. Anyone think this is a big
> boon (e.g., to warn that infix processing might happen here)? I guess it
> would eliminate the need for a "no prefix" operator, but other than that, is
> there any reason to do so?
Yes, to warn a human reader that infix processing might happen here.
defvar !!! ;debugging variable that will get logged somewhere
define something(f)
;for debugging
setf !!! f
if {f > 42}
something-else f
something-else-entirely {f + 1}
define something-else(f)
;for debugging
log f !!!
do-some-event f
This also fixes the problem of offloading the infix fixing to a macro.
Just define {} as meaning "must completely, totally, importantly mean
infix", so that:
{a convoke b}
requires that convoke be predeclared as an infix; otherwise error (so
that you force the predeclaration of all used infixes).
You might even want to transform:
{a convoke {b convoke c}}
to:
(infix-fix a convoke (infix-fix b convoke c))
so that you can safely use:
{a convoke new-proc(b c)}
Which would transform to:
(infix-fix a convoke (new-proc b c)) ;infix-fix doesn't recurse, so it
won't complain about b,
Of course this rejects the possibility of using infix in f(...) forms,
except if boxed in a {}. And non-Lispers will then object about all
those {}'s instead.... oof.
Alternatively, implement a different macro for function infixes. Hmm.
Sincerely,
AmkG
