parsability (was: Choosing a parser for Mathematica input)

glen herrmannsfeldt <>
Fri, 6 Feb 2015 00:05:39 +0000 (UTC)

          From comp.compilers

Related articles
Choosing a parser for Mathematica input (David Kirkby) (2010-11-07)
Re: Choosing a parser for Mathematica input (2015-02-05)
parsability (was: Choosing a parser for Mathematica input) (glen herrmannsfeldt) (2015-02-06)
Re: parsability and human factors (Derek M. Jones) (2015-02-07)
Re: parsability and human factors (glen herrmannsfeldt) (2015-02-08)
Re: parsability (Robin Vowels) (2015-02-09)
Re: parsability (Hans-Peter Diettrich) (2015-02-08)
Re: parsability (2015-02-09)
Re: parsability and human factors (Derek M. Jones) (2015-02-10)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: Fri, 6 Feb 2015 00:05:39 +0000 (UTC)
Organization: NNTP Server
References: 10-11-017 15-02-009
Keywords: parse, design
Posted-Date: 06 Feb 2015 22:15:43 EST wrote:
> Hi, comp.compiler guys.
> I came across this thread while googling for something I wrote;
> found this thread with stuff written about me.. It's a bit stale but
> if David Kirby wants a Mathematica clone, he should look at Mathics.
> Regarding the difficult of parsing the Mathematica language, he misses
> the point, I think. By the way, after conducting a worldwide search
> for a better name for the language-minus-the-math-library, Stephen
> Wolfram chose, tada, "The Wolfram Language".

It seems that most computer languages are designed to be easy to parse
by programs, but not for ease of use by people.

When computers were smaller and slower, that might have made sense,
but for the computers we have today, making it easier for people
should come first.

I went to a talk, not so long ago, by someone actually studying people
using computer languages. It seems that many people who write papers
about how easy or hard they are to use don't actually do any tests
with real people.

> Anyway the difficulty isn't parsing x //f to get f(x). It is in the
> separation of lexical and syntactic uses of characters like "." which have
> multiple uses.

> a.3 is Dot[a,3]. a .3 is Times[0.3, a]. And the difficulty with using
> "space"
> or merely adjacency for multiplication is not resolved by asserting that
> mathematicians use it all the time.

Interesting that when we learn multiplication in 3rd grade, we learn
the x operator for it, but then when we learn algebra we expect
adjacent terms to be multiplied without any operator. Mathematicians
have been doing that for centuries.

Though there is the compilication of multiple character symbolic
names, which mathematicians seem still not to have adopted.

> I have written papers and email in which I am critical of Mathematica.
> I have also written programs that are partial implementations of that program
> but with illustrative changes showing (in my view) better design decisions.
> Some of these decisions are mathematical rather than language issues.

But did you do any tests comparing your design to others? That is,
using actual people, both experienced and not so experienced?

The person I mentioned above, though I didn't find the reference,
compared currently popular languages taught in introductory classes
against ones with random ASCII characters in place of the keywords,
and the random one did better!

-- glen
[I can believe it, but I believe there is also some evidence that once
you get beyond examples of trivial size, languages that are hard for
computers to parse are also hard for people to use. For example, with
implicit multiplication, what does this mean:

    a b c + d e f + g

Rules like APL's everything associates to the left, or languages where
you have to parenthesize everything may seem "unnatural" but also are
a lot easier to get things written correctly. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.