proj-jasper-jasperSyntaxNotes1

"Even Herb Sutter, of C++ fame agrees:

> One of the things Go does that I would love C++ to do is a complete left-to-right declaration syntax. That is a good thing because the left-to-right makes you end up in a place where you have no ambiguities, you can read your code in a more strait-forward way, which also makes it more toolable.

(6:00) http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Ques... "

--

http://en.wikipedia.org/wiki/Most_vexing_parse

C var decl syntax is (unless you know all the detailed rules) ambiguous because, since you can do initialization and declaration in the same line, sometimes it gets confusing, e.g.

  TimeKeeper time_keeper(Timer());

is that declaring an instance named time_keeper of class TimeKeeper? and calling its constructor, or is it "a function declaration for a function time_keeper which returns an object of type TimeKeeper? and takes a single (unnamed) argument which is a function returning type Timer (and taking no input). "?

--

could maybe do const/let and #ifdef/if distinction using a 'when to evaluate' sigil?

--

ambiguous precedence can be ignored if all relevant ops are marked associative with each other

--

" This points out that designing a syntax after a keyboard is a tricky business. Some national layouts make it clear that they are made with no consideration of programming needs what so ever. I definitely think there should be several layouts tuned to particular needs (but similar enough to still be somewhat usable by different users). Programmers use the national characters (such as åäö) less often than operators, so why are we forced to work on keyboards that have dedicated keys for (åäö) but squeeze up to 3 important operator-characters on other keys? For your information, here are some examples (plain, shift, altgr): 2 " @ 7 / { 8 ( [ 9 ) ] 0 = } + ? \ < >

¨ ^ ~ -all of them are normally "dead" meaning they get attached to other characters so you need to type them twice and then delete one to get a single one. "
-this sucks particularly if you work with a shell

"

    Here are the only special characters I can get with single key press without going to numpad ,.-'+§<
    It sucks to code with Finnish keyboard layout. Swedes probably use same. 3 extra vowels make it hard. Hmm.
    Hmmm. This discussion makes me think that should I configure full custom keyboard layout for coding.
    If getting rid of that shift is such a great advantage in programming."

"

    As a curiosity:
    The only characters that are available unshifted on (practically) all keyboards are letters a-z, digits 0-9 punctuation ,. and addition/subtraction +-
    For all other characters, there is a very large percentage of keyboards where some form of shifting is necessary.
    All the paragraphs that mention () being vastly superior to [] are therefore factually incorrect.
    So yeah, that's silly :-)"

--

since punctuation is hard to search for using std tools, perhaps require punctuation infix operator assignments to be imported individually rather than with an import *

--

mb prohibit defining symbolic operators without first defining an alphanumeric function to bind to them

--

consider scala's syntax for anonymous functions:

l.map( x => x*2 )

note that i think the same syntax is reused for function types, e.g.

(fun: List[T] => T)

--

i think golang has an LALR(1) grammar?

--

LL \subset LALR(1) \subset LR \subset? GLR

--

apparently if you have an LL(k) grammar you can parse it in linear time without backtracking by a recursive descent parser (a linear recursive descent parser without backtracing is also called a 'predictive parser'), which is intuitive and easy to write. this sounds like a good idea to make it easy for others to write macros by hand (otoh by that time they get the AST, right, so it doesn't really matter?). ANTLR also does LL(*).

so i guess we should make Jasper LL(k) if possible, or LALR(1) if not.

what is scheme? i bet it's LL(*). not sure tho.

golang also makes a big deal about being parsable without a symbol table. i guess that's important for efficiency.

--

http://programmers.stackexchange.com/questions/19541/what-are-the-main-advantages-and-disadvantages-of-ll-and-lr-parsing

--

an argument for block syntax that i don't quite understand:

" munificent 10/21/10 Hi, I'm the author of that post.

On Oct 21, 6:13 am, Corey Thomasson <cthom.li...@gmail.com> wrote: > block arguments for example, are just another form of closures, which go has

I'm aware of that. Wasn't that clear from the article? It was under the "syntax" section and specifically says that the parser will desugar it to a regular anonymous function. The goal here isn't to change semantics, it's to add some syntactic support so that scoped behavior doesn't look so awkward. I think a little syntax can go a long way towards encouraging something to be idiomatic.

--

"

C# pulled it off. There's nothing magical at all about operator overloading, with the exception of the assignment operation, which

--

bwk complains that Pascal http://www.lysator.liu.se/c/bwk-on-pascal.html has too few levels: " while (i <= XMAX) and (x[i] > 0) do ...

...

By the way, the parentheses in this code are mandatory - the language has only four levels of operator precedence, with relationals at the bottom. ... There is a paucity of operators (probably related to the paucity of precedence levels).

"

so maybe we need more than 4 levels but less than 10

list of a bunch of languages and their precedence:

http://rosettacode.org/wiki/Operator_precedence

Go has 6 levels, mb that's good

But i would say has at least 7 level:

Go's levels are:

Precedence Operator 6 all unary operators 5 * / % 1 & &^ 4 + -

^
    3             ==  !=  <  <=  >  >=
    2             &&
    1             ||
    0             things that in Go form statements, not expressions, e.g. ++

in Go, % is remainder, 2