I wish all languages had the : operator that Wisp has. It's $ in Haskell. It simply says that what follows to the end of line is wrapped in brackets. So:
putStrLn $ somefunc $ process val = putStrLn (somefunc (process val))
Other languages in former Warsaw Pact tend to have "Programmers" layout available as well, because the national standard layouts tended to be designed for typewriters not programming and lack all kinds of characters people need - unless you go trigram route in C/C++.
For what its worth, Common Lisp at least does let you remap ` and such :)
define
pos>? p1
p2
Right, and this is what's meant by the oft-repeated statement "LISP has no syntax." Of course it has syntax in the sense that if you were to go in and delete one of those parens, the whole thing wouldn't compile, but the syntax it does have is 100% regular.
12
1/3
rome
(rome is a city in italy)
(rome (city . italy) (capital-of italy))
(rome local-name "Roma")
Lisp programs then are made out of s-expressions and there is a syntax for Lisp. Additionally the Lisp syntax is extensible via macros.
Example:
(let ((a 10)
(b 10))
(declare (integer a b))
(+ a b))
The syntax for LET would be (in some kind of EBNF notation):
let ({var | (var [init-form])}*)
declaration*
form*
You don't need regularity or simplicity, you need automation. Programming Languages are tools to under-specify a problem\process\pattern\solution\structure and still get an executable that does something useful, meaning the parts that weren't specified were filled in by the machine (in any way necessary), meaning automation. In other words, "A low level programming language is that which requires attention to the irrelevant", per Alan Perlis.
In that light, lisp's syntax is awful, you're laying down the AST yourself instead of making a parser figuring it out from program text. You're paying precious attention to the extremely irrelevant, the fact that a function's body is nested under its name, the fact that a control construct wraps its code, instead of letting those trivial facts fade into the background of a nicely-designed grammar and actually focus on the code itself.
There is literally 0 need for making code-as-text reflects code-as-tree, Mathematica represents every single language construct as a nested list underneath, and yet it has an extremely rich and pleasant syntax, full of sugar and shortcuts and alternate forms. It can do this because it understands a very fundamental point that lisp syntax fans too often miss : text is irrelevant.
The string "(+ (* 4 10) 2)" is not an S expression, its the textual form of an S expression, the serialized form. You can't do anything useful with it without parsing, the actual S expression is a hierarchical object graph in memory, you can either get it from the text by quoting the text, or immediately evaluate it by entering the text directly into an interpreter (which gets the tree first). In all cases, there is no reason why quoting `while (cond) {exprs}` can't evaluate to the list (while cond (exprs)). You are already parsing the text anyway, quote is nothing but invoking the parser from within a program, so make the textual form convenient to humans while you're at it, a simplistic form benefits no one but the parser (a machine, the very thing that needs to work hard).
Lisp's big idea is just making the compiler's services available through an easy API, this has absolutely nothing to do with its crippled syntax, it can be done by any language of any syntax whatsoever, much better than the 1960s hack lisp fans has stockholm-ed themselves into loving. To the extent it's rarely done in mainstream languages, it reflects the designers' choice.
* : I'm assuming a remotely sane ISA, not the excrement known as x86.
You could stack them like this in every language but only in Lisp do people actually do it. Lisps bad habbit of stacking all the parentheses like that is what makes it so hard to read. It is easier to write that way, but it is very hard to understand how many contexts up you just moved.
How much Lisp have you written/read? Closing parens on separate lines would be a nightmare to read in any real-world code.
Also, what makes Lisp hard to read is lack of familiarity. It's not like C is easy to read for someone who's only ever written Lisp. Lispers don't find Lisp hard to read.
You’re not alone though. Many nascent Lispers go through the use reader macros to make Lisp look more like what they’re used to phase.
#define BEGIN {
#define END }
#define INTEGER int
...
Moral of the story: If you can't be bothered to learn a language and its conventions, be honest and get another job.
From the source to the original Bourne shell:
BEGIN
REG BOOL slash; slash=0;
WHILE !fngchar(*cs)
DO IF *cs++==0
THEN IF rflg ANDF slash THEN break; ELSE return(0) FI
ELIF *cs=='/'
THEN slash++;
FI
OD
END
What a horrible thing to do. I've never liked macros, and things like this are part of the reason why.
for (var i = 1; i < 101; i++) {
if (i % 15 == 0) {
console.log("FizzBuzz");}
else if (i % 3 == 0) {
console.log("Fizz");}
else if (i % 5 == 0) {
console.log("Buzz");}
else {
console.log(i);}}
I'm sure a big reason people call lisp a "write only language" is because of this strange convention of stacking all parentheses in a big clump instead of formatting like normal.
for i in range(1, 101):
if i % 15 == 0:
print("FizzBuzz")
elif i % 3 == 0:
print("Fizz")
elif i % 5 == 0:
print("Buzz")
else:
print(i)
In Lisp you need to learn to apply the same idea of indentation being significant:
(loop for i from 1 upto 100 do
(cond ((zerop (mod i 15))
(write-line "FizzBuzz"))
((zerop (mod i 3))
(write-line "Fizz"))
((zerop (mod i 5))
(write-line "Buzz"))
(t
(write-line (princ-to-string i)))))
The disadvantages of Lisps are basically two:
a) there are more parentheses because of the nested lists being used to write code
b) one now needs to understand when (sin a) is actually code and when it is data.
The advantage of Lisp syntax:
a) code is already a simple nested data structure
b) the indentation&layout of code can be (and often is) computed from the data, while usually in Python the lines and indentation are significant
Joke aside, this is why I never understood this problem. With proper indentation it looks essentially like Python with a generous helping of your-father's-parentheses.
Your result should be unsurprising. Lisps have a minimal syntax that naturally entails high levels of nesting: (s-)expressions being used to represent functions, control structures, data, etc.
Why should a particular style convention appropriate for that kind of language necessarily transplant well to JavaScript-- a brace-delimited, Algol-inspired language with a lot of syntax?
“Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.”
> you will at a glance see which contexts you just closed
the text editor does that for me
> how people format code in every mainstream language
Python code formatting looks different from Java code formatting.
Python code:
for h in range(0, height):
for w in range(0, width):
v = bw_image.getpixel((w, h))
if v >= avg:
bm_image.putpixel((w, h), white)
else:
bm_image.putpixel((w, h), black)
(dotimes (h height)
(dotimes (w width)
(setf v (get-pixel bw-image w h))
(if (>= v avg)
(put-pixel bm-image w h while)
(put-pixel bm-image w h black)))) data = [
[1, 2, 3],
[4, 5, 6],
[7, 8, 9, [10, 11, 12]]
]
I see also lots of Python code where data isn't written like you claim...
As you barf and slurp, you’re interested in the “shape” of code but you ignore the parens.
That is false. Do yourself a favor and run "git grep -F ')))))' in, oh, the root of the Linux kernel tree.
Just mentally collapse any number of consecutive close parens into a thing that reads like "END."
(a (b c (d ]
(z (a [b c (d]
[e f (g]]Lisp lists are a data structure. One for example types code&data and computes with an interactive Read Eval Print Loop.
That's what one would write:
CL-USER 35 > (+ (expt 23 2.4) (sin (* 44 0.23 22)))
1854.5603
CL-USER 36 > (+ (expt 23 2.4) (sin (* 44 0.23 22
)
)
)
CL-USER 46 > (let ((*PRINT-RIGHT-MARGIN* 30))
(pprint '(+ (EXPT 23 2.4) (SIN (* 44 0.23 22)) (COS (+ 12 0.43 19.0)) (TAN (/ 1.4 0.77 3/4)))))
(+ (EXPT 23 2.4)
(SIN (* 44 0.23 22))
(COS (+ 12 0.43 19.0))
(TAN (/ 1.4 0.77 3/4)))
(+ (EXPT 23 2.4
)
(SIN (* 44 0.23 22
)
)
(COS (+ 12 0.43 19.0
)
)
(TAN (/ 1.4 0.77 3/4
)
)
)
The main difference between Lisp and most other programming languages is that programs are written as a data structure: nested lists. Not only that: they are not static lists, but we can compute with them - that's the main appeal. It's a programming language, where it's easy and common to manipulate lists, even programs as lists. Thus the notation has not only be useful for reading code, but also for input/output by humans and programs. There a compact notation is much more useful, since tools will often create huge amounts of nested lists. For example imagine a macro for some Lisp functionality, like a complex loop expression. The macro expanded code can often be ten times larger as the input expression, yet we may want to see it in a debugger -> write that expression in a compact way.
I let Lisp indent my code and the system-wide standard indentation makes it easier to spot parentheses errors, since all code has the same shape rules.
(progn
(case foo
(var (eval foo)))
(fn (apply foo args)))
I wouldn't care to see the parentheses aligned and it makes the problem often more difficult to spot:
(progn
(case foo
(var (eval foo
)
)
)
(fn (apply foo args
)
)
)
Like this:
(+ (EXPT 23 2.4)
(SIN (* 44 0.23 22))
(COS (+ 12 0.43 19.0))
(TAN (/ 1.4 0.77 3/4))
)
(+ (EXPT 23 2.4)
(SIN (* 44 0.23 22))
(COS (+ 12 0.43 19.0))
(TAN (/ 1.4 0.77 3/4))) ((paris (french))
(los-angeles (english spanish))
)
Also when there are comments on the last line, then sometimes the expression might be closed on the following like:
((paris (french)) ; city 1
(los-angeles (english spanish)) ; city 2
)If the opening bracket is on the same line as content, then so is the closing bracket.
By this rule, we have two options:
(+
(EXPT 23 2.4)
(SIN (\* 44 0.23 22))
(COS (+ 12 0.43 19.0))
(TAN (/ 1.4 0.77 3/4))
)
(+ (EXPT 23 2.4)
(SIN (\* 44 0.23 22))
(COS (+ 12 0.43 19.0))
(TAN (/ 1.4 0.77 3/4)))
This is consistent with other languages:
[1, 2, 3]
f(x, y, z)
[
1,
2,
3,
]
f(
x,
y,
z
)
[1,
2,
3,
]
f(x,
y,
z,
) [ x
, y
, z
]
That the expression is ended I can see in the typical Lisp expression because of the block structure. The single parentheses does make the layout very cluttered and visually ugly. It gets even worse in typically larger Lisp code or data.