Many people complain that LISP braces too, because the formatted LISP code itself is a hierarchical structure, then we can learn about the format of the python, use indentation to indicate the level, remove the bracket. For example:
[attachment=0]QQ截图20140805125316.png[/attachment]
In this way, both for the convenience of reading, but also reduces the number of characters,
You mean like Lispin? The website is offline, but I suppose it could be fairly easily implemented as a front end filter for newLISP. Be a neat thing to do. I'll put it on my todo list; perhaps by the end of August I'll have a spare couple hours and hack it up; looks easy to implement.
http://wayback.archive.org/web/20080517144913id_/http://www.lispin.org/wiki?page=default/introductiontolispin
Ha ha, very glad you approve of my idea！
Quote from: "LoveVirus"
It is a very old idea in LISP circles. Here, read this: http://sourceforge.net/p/readable/wiki/Solution/
"sweet expressions" have been in development for a very long time. A stripped down version of them could be easily turned into newLISP. But I'd want to also have it go the other way, turning newLISP code into sweet expressions, so people could edit in one or the other, and have it convert back to where it belongs.
http://srfi.schemers.org/srfi-110/srfi-110.html
Actually, newLISP probably makes sweet expressions easier to implement than scheme or Common Lisp. However, the [] and {} syntax wouldn't make the transfer.
Too bad there is no EBNF grammar for newLISP; I'd dearly love to run it through the railway diagram generator. (Found here: http://bottlecaps.de/rr/ui)
In the past there were often discussion about Lisp-style and indention.
For my taste it is not a good idea to remove any braces.
I find Python's use of indention for programm flow a very bad idea, especially for longer code blocks.
My prefered indention style:
(+ 1
2
(* 2
3
)
)
My used Editor automaticly highlights any matching braces and draw a thin vertical line from start-brace to end brace.
For released production code I use a tool to remove unneeded whitespace and linebreaks to get a compact Lisp stream for optimum load-performance resulting in a one-liner:
Regards
I tried it, and soon started to miss the parentheses.
define D:D
map
fn
x
D x
inc
D x
explode
read-file
main-args 2
map
fn
p
println
p 0 "t:t"
p 1
D
exit
or
(define D:D)
(map (fn (x)
(D x (inc (D x))))
(explode (read-file ((main-args) 2))))
(map (fn (p)
(println (p 0) "t:t" (p 1)))
(D))
(exit)
The script I used:
(set 'level 0)
(define (start-list)
(print "n" (dup "t" level))
(inc level))
(define (close-list)
(dec level))
(dolist (c the-data)
(cond
((= c "(")
(start-list)
)
((= c ")")
(close-list))
(true
(print (trim c "n")))))
(exit)
Of course, it breaks if the strings contains parentheses, so it doesn't run on itself... :)
Hi cormullion. Yes, the lispin and sweet-expression guys thought of that, their solutions avoid the type of problem you showed in your example.
With a tool to convert to and from newlisp, you could play with pythonesque syntax without losing anything. Linecount would increase marginally.
Quote from: "TedWalther"
... "sweet expressions" ...
http://srfi.schemers.org/srfi-110/srfi-110.html
Good Lord, is that bloody awful.[1] I'm with cormullion.
People who like the sort of things as "sweet expressions" may not yet perceive the beauty in s-expressions. The beauty comes from the s-expression's regularity and generality, and the way I see it, combined with the standard indentation, they are
Let's keep the "syntax" simple. We don't need to tax our minds remembering the vagaries of syntax born from
___________
[1] Especially, check out the examples in SRFI 110 in the "Tutorial" after the "Basics" section.
[2] Indeed, that's the very purpose of the standard indentation. And as HPW noted, a good editor can make writing s-expressions very easy.
Cormullion, is your newlisp parser up to date with the latest 10.6 release of newlisp? I'd like to use it as the basis for my experiments with what I am tentatively calling "newlispy" Or maybe "newlis.py" :)
Well I don't test my code very thoroughly .. :) but I remember adding something for bigints earlier, so it kind of works, and it's not too far behind. Pull requests accepted!
Does Lutz have a handrolled parser, or does he use lex/yacc? An EBNF grammar would make this so much easier. Is there one?