Alan Manuel Gloria:
> 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 _really_ don't want to do THAT, for 2 reasons:
1. I _want_ people to be able to define their own infix operators.
2. I want this to work with any Lisp-based language, and languages differ.
Indeed, even in the same language, you might add a new operator, see reason #1.
> > 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.
It's a good thing to have that expectation, since it'd be true. :-)
That kind of ordering dependency obviously happens in many languages (e.g., C's
#define can change what comes after). But it's also a source of nasty,
hard-to-find errors. It also makes it harder to exchange files, because of all
these weird dependencies you have to master.
I'd rather have something that is NOT so ordering-dependent.
> 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
Ah, and you're suggesting having a syntax marker saying "what's inside is the
infix operator"? Hm, that's actually a pretty good idea. I don't think the
two approaches are inconsistent, either. You can have punctuation-only be
automatically interpreted as infix operators, and some sort of marking for any
other function used as infix.
Any suggestions for that syntax? It can't use the `...` syntax exactly, because
` is the quasiquote character in pretty much ALL Lisp-derived languages. It
needs to be unlikely to use otherwise, yet not too complicated. One idea is to
surround it with colons; colons are already special in most Lisps (keyword
markers, namespace separators, etc.), but a colon at the beginning AND end is
(I believe) pretty unlikely. The colons would be stripped off, and the whole
thing re-interpreted. One trouble is that means that their use would look a LOT
like using a named parameter or a Common Lisp namespace.
I like this overall idea, if a reasonable syntax can be found. (I think the
colon-punning will work with Common Lisp and Scheme, but I don't know about
others.) Would surrounding it with "+" or "/" be any better? E.G., a
/convoke/ b?
> > 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
... I'm not sure the EXAMPLE is convincing. Anybody who names their variable
!!! deserves what they get anyway :-).
But obviously you DO think it's important to give a syntactical warning,
instead of making it simply the default. Anyone else?
> 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).
If infix is relatively rare, then exclusively using {...} for infix operations
has lots of advantages. Certainly it's a smaller change to the surface syntax.
But you note the big downside of it too:
> 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.
E.G., f(...) for non-infix and f{...} for infix, right? Problem is, then people
will constantly use the wrong marking. Sigh.
You're better off just using {...} everywhere for infix, I think. So it'd
become:
{n * factorial({n - 1})}
But it's hard to argue that this is better than:
n * factorial(n - 1)
Constantly having to specially mark what should be the default seems (to me) to
be a sign of a bad user interface. "Normal case" should be the default. And I
think that infix IS the default for the world at large. Having to mark infix
operators if they're alphabetic doesn't bother me, because the typical infix
operators ARE punctuation anyway.
--- David A. Wheeler
