Hi everyone,
I didn't know I wasn't the only one who thought that infix notation are more
natural specially for mathematic expressions. Actually I am a mathematics
student who happens to like (common) lisp very much. In the last few days
I've been learning how to use maxima and realized that infix notation are a
big deal in understanding what is being written. I also said to one of my
friends (who is learning lisp) that parentheses in lisp could be avoided if
we use indentation.
I have some ideas about it. I apologize if these ideas were already given
and discarded since I didn't yet have time to read the entire discussion, or
if they are silly.
First: I like the idea "infix non-default", but I don't like "precedence
non-default". Of course, I could implement the macro nfx for my own
programs. But if I want to include programs from other people, which also
implement a macro nfx, I could go crazy. Which means that every library
(almost everything in common lisp) could not use this feature. I agree:
default precedence isn't good since your code is distinguished from internal
code (which is the opposite of the behavior of Lisp) and dynamic precedence
is bad because of its not previsible behavior.
So, I have an idea that might be an intermediate: to implement a precedence
rule, you must implement the hole set of operators it is defined in, e.g.:
def-op-prec-list (^ (* /) (+ -) (= != <= >= < >))
which signals an error if any of the operators is already in another
precedence list. And there could be a predefined precedence rule for
mathematics (like the one above) and one for logical operators.
Off course, the macro nfx could remain as an option.
Second: About the backwards-compatibility: the sweet reader could see the
extension of the file. If the extension is not swt (or sweet or something),
apply the reading and create a file which has the same name but removing the
.swt (so e.g. main.lisp.swt would became main.lisp) and then give the file
to the default reader; otherwise, just execute the last step. Then the
indentation of top-level code could be forbidden without any further
problems.
Third: Options could be settable locally. E.g. in a file (probably in the
beginning) one could say:
local-sweet-settings
disable-parentheses-read
set-bracket-accessor(aref)
def-op-prec-list(...)
...
where possibly set-bracket-accessor accepts a symbol to be used instead of
bracketaccess.
Fourth: the use of "group" is not very comfortable in let, labels,
with-open-file,... . There could be a default behavior in indentation:
let
a 3
b 4
{a + b}
labels
f [x y]
{x + y}
f(3 4)
So, anything which has 2 levels of indentation would group the level at
right, and leave the rest intact. This, off course, would impeach someone
from writing
let a 3
{a + 1}
but, for me, it is better than using group. Maybe we can go further:
foo
bar
baz
foobar
foobaz
which translates to (foo (bar) baz (foobar) foobaz). Or even further,
allowing more that 2 levels. But there is the problem for macro do which, in
this case, would be written as
do
a 1 {a + 1}
b 0 {b - 1}
[{b = -50} {a + b}]
do-something
do-something-else
I guess it is still a problem, because indenting the bracket would change
the interpretation... maybe we could accept empty lines as an option for
creating a new group:
do
[a 1 {a + 1}]
[b 0 {b - 1}]
{b = -50} {a + b}
do-something
do-something-else
which still has some elegance, I believe... Or we could write "end" between
the declarations and the return condition / value. Or accept both. Well, I
can't cover all possibilities... This is a great matter: after all, we are
almost creating a new language!
Well, all of these are just ideas. Like every idea, they can be bad or not
the better. Fell free to improve them!
Gustavo.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
