Jørn Inge Vestgården":
> Some comments from the sideline.
>
> - Infix can be semantically equivalent to s-expression, as the infix
> macro I have put on "http://folk.uio.no/jornv/infpre/infpre.html";.
> This means that 1 + 2 + 3 translates to (+ 1 2 3) rather than (+ (+ 1 2) 3)
Agree. In my "curly infix" approach, which is included in my
modern-expressions and
sweet-expressions, this is handled by definition. So {1 + 2 + 3} becomes (+ 1
2 3). In fact, if you WANT to force things to be separate, you have to use
another {...}, just as with s-expressions. So if you have a hideous
implementation where "-" can only take up to two parameters, you have to do
this:
{{3 - 2} - 1}
This means that curly infix is still homoiconic - you can tell, visually, where
every new list begins.
I know Gloria's macros support fungible/non-fungible, same idea.
> - Infix is mainly useful in long-winded math expressions where
> precedence is used extensively. In my opinion infix is large gain for
> the basic math operators +,-,*,/,^ but not to same extent for =, <,
> &&, || etc.
>
> For example I prefer
> if (= a b) 1 2
> over
> if (a = b) 1 2
> but
> 1 + sin 2 * 3
> over
> + 1 (* (sin 2) 3)
My preferences are quite different :-). For me, if it's normally written as
infix in math, then that's how I want to express it. So I would write (in
sweet-expressions):
if {a = b} 1 2
and
1 + sin{2 * 3}
That said, my sweet-expressions/modern-expressions approach will happily let
you write it the way you prefer, so you can also say:
if (= a b) 1 2
> - Infix makes operator overloading an issue. All infix operators
> should eventually be overloadable, since it is far more limited how
> many symbols that are suitable for infix operators compared to
> function names.
Well, that's only if you limit the symbols. I tried for a long time to do
automatic detection of infix symbols, and that turns out to be a pain.
Registration is also a pain, and though it's needed for precedence, I think
that in a _reader-based_ approach precedence is a terrible idea anyway (it
works better if you're using a macro-based approach). So instead, in my
approach, {...} _always_ means infix. So my approach would permit:
if {x string-ci>=? y} ...
I have to admit that I would normally write it this way:
if string-ci>=?(x y) ...
But that's merely a preference.
Although it's early in experimentation, I _like_ this flexibility. It means
that I don't have to remember a mapping of function name to function name
(they're just the names), I'm not limited in what functions I can use, AND I
don't have to register anything. What I give up is direct precedence handling.
But my reader then calls on "nfx", which can then decide what to do. Others
here are discussing macro-based approaches, which provide precedence support.
What I _hope_ we end up with is several useful approaches, many of which can be
used together.
> This is above all a problem for =. Should infix =
> translate to =, eq, eql, equal, or equalp?
This has been a recent topic of discussion. A big problem is that if "=" maps
to something OTHER than "=", you have a great potential for confusion and bugs.
Also, my "curly infix" BY INTENT does not allow you to rename functions - it's
really dangerous to put too many "smarts" in a reader (because you'll have
different levels of programming, etc.). Gloria's macro does allow renaming,
but that kind of flexibility can easily lead to foot-shooting.
So I think it's probably better to have NO map (i.e., map "=" to "="). Then
you can create NEW names (which doesn't risk confusion). Gloria had proposed
==, ===, ====, with the more equal signs being the more precise. I think
that's a good idea.
> - Most of the brackets in lisp do not come from arithmetic expressions
> at all, e.g.
> (let ((a 1))
> (cond ((null a) 0)
> (t 1)))
> has a lot of brackets, in my opinion too many, since it could have been
> (let (a 1)
> (cond (null a) 0
> t 1))
> which is also s-expression. However, I've got bad feelings changing
> basic forms like that.
As was previously noted, I-expressions are specially designed to handle this
(the "group" metasymbol). Which I think are a key insight in I-expressions -
you really need a way to express that.
That said, the format of "let" (in s-expressions OR I-expressions) is
inconvenient.
I prefer having a "let1" macro of the form:
let1 variable variable-value expressions+
Which you can define in many Schemes like this:
(define-macro let1
(lambda (variable value . computations)
`(let ((,variable ,value)) ,@computations)))
Someone else on-list prefers ":=" instead of let1. I can't say I care THAT
much, but I prefer to reserve punctuation-only names to names that I intend to
use as infix operations, and since I don't intend to use it that way, I prefer
"let1".
> - Using {} and [] might require changes in programming environments like
> slime.
Sure. Adding indentation-as-syntax will almost certainly require such changes
in any case.
A lot of systems seem to be happy with {...} and [...] though. [...] is
actually part of Scheme R6RS, and since it's easy in Common Lisp to commandeer
{...}, they're often used that way.
--- David A. Wheeler
