

Math Envy and CoffeeScript's Foibles - johnbender
http://johnbender.us/2012/11/27/math-envy-and-coffeescripts-foibles/

======
jashkenas
Very cool post -- looking forward to part 2.

For what it's worth, the syntax foible up for discussion here is intentional.
Because CoffeeScript allows you to pass an argument on the right hand side
into a function on the left hand side without having to use parentheses, there
are several cases where we need to disambiguate:

    
    
        f / a /i
    

Repeated division, or a function being passed a regex with space in it?
CoffeeScript treats it as:

    
    
        f / a / i
    

The example in the post is:

    
    
        func (arg1, arg2) ->
    

We disambiguate by saying that if the parentheses are attached to the
identifier on the left, then they're part of the function call, otherwise
they're part of the argument list as usual. It seems fiddly, but is useful for
writing code like this:

    
    
        load(url).then (response) ->
          handle response
    

... as well as code like this:

    
    
        reduce(list, {}) ->
          for arg in arguments
            ...

~~~
johnbender
This is an important point, and I'm glad I can expand a bit on it here.

Considered as purely a syntactic issue there's not much for discussion. Fix
the parser. But! Conceding that method/function application is useful along
side the invocation operator `()` (which it certainly seems to be) makes this
an interesting semantic issue. That is can two terms mean different things but
look "similar"

I have no interest in telling anyone how to build a programming language or
that one approach is subjectively "wrong", but knowing that certain term pairs
in a language could be ambiguous with respect to each other seems like
valuable information. Provided to the creator at the right time it might help
with language design.

~~~
jashkenas
Eh? This is where I don't follow. What exactly are you recommending should be
changed when you say "fix the parser"? Choose the other disambiguation, or
simply use an entirely different function literal in the first place?

For what it's worth, this particular ambiguity was discussed as part of the
original language design. It was decided that having parentheses for both
argument definitions and argument application was useful parallelism, and that
function literals shouldn't have to have a "def", "func", "function", or other
prefix. From those two ideas:

    
    
        # Definition
        (input) -> output
    
        # Application
        function(input)
    

... the rest of it falls out naturally.

~~~
johnbender
s/fix the parser/change the parser/, meaning choose not to support both types
of invocation.

------
Rickasaurus
This post left me feeling pretty bad about Coffeescript. Those semantics
weren't well thought out at all.

~~~
johnbender
In defense of CoffeeScript, I'm not convinced that semantic issues like this
are at all obvious during the creation of a programming language. Honestly
it'd be dumb luck landing on this one in particular since you can imagine that
the grammar definition for lambdas and invocation/application aren't sitting
right next to each other. That's what got me thinking about how you could
explore the term space automatically.

~~~
rayiner
Flaws like this arise from trying to be too clever with syntax. Function
application with parentheses, literal regular expressions without clear
delimiters, etc. Syntax should be describable in a handful of universal rules.
Lisp is the extreme in this regard, the rule is simply: parentheses nest
properly. But you can build surprisingly rich syntax with a simple set of
rules so long as you lay out those rules first and conform the syntax to them
as you go.

~~~
chadzawistowski
Io language is another great example of a language with a minimal set of
universal rules yet incredibly rich metaprogramming.

<http://iolanguage.org/>

------
dnr
Commenting a little late, but I just got around to reading this. One question,
if anyone is still reading:

How is looking at distance between derivation trees any more useful than just
looking at distance between whatever ASTs the coffeescript parser makes? In
other words, why involve operational semantics if you can just talk about the
trees produced by a BNF grammar for your language?

------
tjholowaychuk
dear god, please do not ever do any of that

------
Evbn
Why a long essay on semantics to argue a point about coffeescripts choice of
whitespace syntax?

~~~
johnbender
Totally fair question, which I'm reading as, "why did you take the time to
write this?"

1\. I've been reading through Types and Programming Languages in fits and
starts over the last year or so. Operational Semantics is one of the topics
covered in the book and I wanted to test my knowledge of it. I did the same
thing with Category Theory and jQuery

2\. I get a kick out of "teaching" (that's an overestimation of what I'm
doing) things like Operational Semantics using examples that developers can
relate to out of their own experience. This is also part vanity. I like people
to read/enjoy/approve of my ideas, but that requires that they be able to
understand them.

3\. Writing is a difficult but rewarding exercise. It makes you better at
thinking through and conveying your ideas in all mediums.

Hopefully that answers your question.

------
ilaksh
This is probably just going to be buried, but I think someone needs to tell
you, Mr. Bender, that you are failing to see the forest through the trees.

In this work and in other projects of yours that I see on github, I see an
incredible amount of effort wasted on semantics, formal theory, notation and
attempted minor refinements to syntax.

Maybe your obvious intelligence would serve us all better if you focused more
on creating new programming languages or software development tools rather
than refining existing systems that are quite functional.

Have you ever created a tool that has anything approaching the utility of
CoffeeScript? Because I think that unfortunately in your blog post you've
proven that your study of mathematics was actually wasted.

Math is just obfuscated code that doesn't compile or run.

~~~
mitchellh
John Bender created Vagrant[1] with me back in 2010. I don't consider it even
close to the caliber of CoffeeScript, but I'd say that is a pretty solid
contribution to the world.

I should also note that basically the only part of Vagrant that hasn't changed
in the past 3 years are the parts John came up with based on some pretty
impressive mathematical underpinnings.

Research almost always appears useless on the surface, but it is what makes
all of what we do on these clicky-clacky machines possible today.

[1]: <http://vagrantup.com>

~~~
Evbn
How is vagrant not close to the caliber of coffee script? Vagrant solves an
actual problem.

