

Syntax across languages - catern
http://rigaux.org/language-study/syntax-across-languages/

======
cstuder
Something that recently caused an interesting amount of problems for me was
the simple fact that the modulo operation with negative numbers changes its
behaviour depending on the programming language: [http://rigaux.org/language-
study/syntax-across-languages/Mth...](http://rigaux.org/language-study/syntax-
across-languages/Mthmt.html#MthmtMdl)

For a more complete list:
[http://en.wikipedia.org/wiki/Modulo_operation#Remainder_calc...](http://en.wikipedia.org/wiki/Modulo_operation#Remainder_calculation_for_the_modulo_operation)

~~~
jarcane
This is why Racket has both.

~~~
aidenn0
And Common Lisp, despite this page not having it listed.

------
jarcane
There's a great guide like this for Lisp dialects that I often refer to here:
[http://hyperpolyglot.org/lisp](http://hyperpolyglot.org/lisp)

They also have a number of similar comparative guides on their main page now:
[http://hyperpolyglot.org/](http://hyperpolyglot.org/)

~~~
fnordsensei
Interesting, but it seems to be unaware of some Clojure libs. It suggests,

    
    
      (.trim " foo ") ;; Java interop
    

instead of,

    
    
      (trim " foo ") ;; With clojure.string
    

Clojure.string is available from Clojure 1.2, which is ostensibly the version
used in the comparison, yet is for some reason not actually utilized. (By the
way, we're approaching Clojure 1.7 at the moment)

~~~
jarcane
I did notice it seemed to use the Java fallbacks a lot, yeah, but I don't use
Clojure much so didn't realize it was that out of date on the CLJ side.

------
aidenn0
I just skimmed this, but a large fraction of their information was just wrong
for common-lisp, even if you assume a standard readtable.

One example: they state "anything without a space and is not a number" for
identifiers; it's hard for that to be more wrong.

The actual rule is: a single token that could either be a symbol or a number
should start with any non-macro character, and can be made up of any
combination of non-macro and non-terminating macro characters, as well as any
escaped characters. For example:

    
    
        a\ b
    

Is a valid symbol.

Now that we have a token that is either a symbol or a number, we need to
distinguish which; that's slightly more complicated, so I'll link the spec
(which includes an EBNF):
[http://www.lispworks.com/documentation/HyperSpec/Body/02_ca....](http://www.lispworks.com/documentation/HyperSpec/Body/02_ca.htm)

------
rx4g
Now I kind of want to cross-reference this with the TIBOE index and make a
frankenlanguage with the most popular syntax.

~~~
michaelcampbell
Didn't PL/1 try that? (Or maybe they made the classic error of "worst syntax"
instead... not sure. Been a few years since I looked at it =)

------
TazeTSchnitzel
Disappointed there's no integer division, or explanation of the different
division operator behaviours (some languages have separate integer and float
operators, some use floats if indivisible but otherwise integers, some do
integer or float depending on the operand types, etc.)

------
TheDong
I personally find the site "Rosetta Code" [0] much more useful for this sort
of thing.

[0]:
[http://rosettacode.org/wiki/Rosetta_Code](http://rosettacode.org/wiki/Rosetta_Code)

------
mwsherman
Fun read. A nit, if the author is reading:

C# allows Unicode letters as identifiers, so the variable regexp should
reflect that. This might be handy: [http://www.regular-
expressions.info/unicode.html#category](http://www.regular-
expressions.info/unicode.html#category)

Also, would love to see Go in there. Similar identifier regex.

~~~
comex
So does C, although compiler support is limited.

------
mdcox
A cursory skim leaves the impression of just how alone Haskell is on many
syntactic choices (though supposedly with alot in common with "Merd".) I never
took the time to learn Haskell, but it always looks beautiful on an aesthetic
level, which differentiates it from the other loners in the list.

Can anyone point me to any papers/documentation/discussion on WHY certain
syntax decisions were made? Many could have been arbitrary choices to match
the constructs, but the way the community presents itself makes me think
there's more to it.

~~~
Retra
The best part of Haskell is that function application is just whitespace.

    
    
        f x = f(x)
    

I would attribute almost 90% of it's elegance to that idea alone. (This is not
an exact number or measured estimate.)

I also have a major thing for pattern-matching, and it always seems nice when
you know that's what you're looking at. For instance, it is far easier to
understand what `int * * var` is in C if you see it as a kind of pattern de-
structuring.

~~~
tormeh
>The best part of Haskell is that function application is just whitespace.

It's the worst part, in my opinion. Is A B C D equal to A(B(C(D))), A(B,C,D),
A(B,C(D)), A(B(C),D) or A(B(C,D))? Often you need to disambiguate with
parentheses, so I guess there is some default interpretation that you can
assume when reading code, but in the end it just looks like an unnecessary
mental translation step.

Lisp has weird syntax, but lisp has a reason to have that syntax. Haskell has
a weird syntax because it wants to either be different for different's sake or
to just be plain inaccessible.

~~~
epidemian
Consider that, in Haskell:

1\. all functions take a single argument (i.e., are curried)

2\. function application is left-associative

So "a b c d" is just applying the function "a b c" with the argument "d", the
same as "(a b c) d". "a b c" is the application of "c" to the function "a b",
which, in turn, is the application of "b" to "a". So "a b c d" is the same as
"((a b) c) d".

I personally find using the space symbol for a core concept of the language
(function application) very elegant, and not dissimilar to other languages
that strive to have simple and consistent syntax, like Smalltalk, where "obj
meth1 meth2 meth3" is the same as "((obj meth1) meth2) meth3", even though
Haskell and Smalltalk might be as different as programming languages can get
:)

~~~
tormeh
How does currying help? You still have to figure out which argument belongs to
which function. GHC demands parentheses if you try to write A(B(C(D))) as A B
C D, so I'm pretty sure I'm right.

~~~
tomp
No, you're wrong. `A(B(C(D)))` is different from `(((A B) C) D)` (which is the
parenthesized version of `A B C D`).

Currying allows simple partial application; if A is a function that "takes 3
arguments" (i.e. it has type `w -> x -> y -> z`, which means that it takes an
argument of type `w` and returns a function with type `x -> y -> z`, which
takes an argument ...), you can say e.g.

    
    
      A_ = A B C
      E1 = A_ D1
      E2 = A_ D2
    

where `A_` is the partially applied function `A`.

~~~
michaelcampbell
> No, you're wrong.

And you and he both gave evidence to the initial assertion that "it's
confusing".

~~~
gamegoblin
I'm not sure if "confusing" is fair -- just different than C-family languages.

The rule is simply "The first expression is a function, all following
expressions are arguments to that function"

It's no different than "The first symbol is a function, all comma-separated,
parentheses-bound expressions are arguments to that function"

Both are pretty easy syntactic rules, I think.

~~~
JoeAltmaier
Its arguably confusing, due to the lack of parentheses factoring a list of
functions into one or more invocations. How is the nesting done here?
Something more subtle. A lifetime of reading parenthesized functions is going
to be confounded by changing the convention - which equals 'confusing'

~~~
gamegoblin
I think you're probably overestimating the difference. Here is an algorithm
for mechanically transforming a C function call to a Haskell function call:

    
    
        for all arguments in the function
            if the argument is not a symbol surround it with parentheses
        delete all commas
        delete the two initial parentheses 
    

And an algorithm for converting Haskell calls to C calls:

    
    
        put an open parenthesis between the first expression and second expression
        put a close parenthesis at the end of the expression
        put commas between all expressions between these two parentheses
    

The fact that it's so easy to convert between them highlights to me that they
are both pretty easy.

------
blt
"NB." for comments in J made me laugh.

------
CmonDev
To me it makes it more obvious that succinct != more readable: (top two)
[http://rigaux.org/language-study/syntax-across-
languages/Fnc...](http://rigaux.org/language-study/syntax-across-
languages/Fnctn.html#FnctnFnctCall)

------
AustrianSausage
I'm really missing TeX. Could someone add it?

------
towardsCL21
the seed for random number in CL: (make-random-state &optional state)

