proj-oot-ootSyntax

The lexical syntax is defined by regular expressions. The parse syntax is LL(1).

Almost everything which affects parsing or grouping is punctuation.

Almost all punctuation defined in Oot the language (e.g. not counting punctuation operators in the std library) is either:

• something which affects parsing or grouping, or
• something which must be defined in a meta-programmy way, or
• a particularly core operation (e.g. arithmetic)

Arithmetic operators are doubled, e.g. ++ is +, is /, etc; single character ops are reserved for other stuff

Punctuation operators may only be defined by first defining an alphanumeric function or macro to bind to them, and then setting the punctuation operator equal to that.

More than one letter, all uppercase, is a label.

Differences in capitalization after the first letter have no effect (and are removed by jfmt).

Oot syntax design todos

• how can we make it so that you don't have to triple-quote strings while building regexs, etc? i forgot when i had to do this in the past in other languages but it keeps popping up. surely there's a solution. i hear that in Inferno's shell, you only have to quote once, how do they manage that?
• how/whether to have multiple return args with prefix defaults, e.g. 'max' returns both the location of and the value at the maximum if the caller asks for two return arguments, but only returns the value of the maximum if the caller only asks for one return argument? the usual way to do multiple return arguments, e.g. return a tuple and allow the caller to destructuring bind it to variables in the lvalue, is insufficient here because with tuples, a single variable in the l-value would just be bound to the tuple, whereas we actually want it to just be bound to the first member of the tuple.
• how/whether to have partial fn application, but also have default arguments to functions? Because at any time when the mandatory arguments are bound, you will be wondering if the function should execute, using defaults for all optional arguments, or if it should wait for the optional arguments to be given.
  • mb ask the haskell mailing list for syntax ideas about combining default params with partial application
• is the only difference between () and {} whether or not it is auto-terminated, and also priority, e.g. {} is just 'big ()'? or does () mean grouping, where {} means "block", which is something like quoting, e.g. "the value of this is the function itself, rather than the result of executing it within the current context"
• are capitalized but not uppercase words labels or identifiers? leaning towards macro-distinguishable identifiers.

use of {}s? kernel if? dict as switch with closure incld. mutate in outer scope? how to indicate which builtins might be overridden in a module? to separate modular compilation step and whole program analysis? ruby-style blocks that can inject e.g. 'return' into caller?

todo move much of ootSyntaxThoughts here.

• This page has some readable practical examples on what could keep programming langugages from being LL(1): http://hypertextbookshop.com/transPL/Contents/01_Topics/03_Chapter_3/05_Section_5/02_page_2_-_LL%281%29_Table_Conflicts.html

heed Pratt's advice for precedence levels:

• Pratt's Top Down Operator Precedence paper introducing Pratt parsing. It also has a discussion on how to set operator precedence levels in a reasonable way (on page 44, pdf page 4): http://mauke.hopto.org/stuff/papers/p41-pratt.pdf

---

lowercase and capitalized names (which includes uppercase single letters) are almost identical, except:

capitalized names can optionally break through hygenicity of macros. But how to encourage ppl not to use metaprogramming tricks like ruby's method_missing to do the same thing for lowercase names? perhaps a version of method_missing that only works on capitalized names should be provided, and use of the full (original) method_missing that works on all names should be discouraged (at a higher level of the metaprogramming hierarchy).

however, excepting all caps, differences in capitalization after the first letter have no effect; e.g.

xoXo and xoxo are the same

XoXo? and Xoxo are the same

hmm, potential problem though: if you replace and API implementation with another one using methodMissing, you make the client change to capitalized method names. so would have to provide a way to 'break thru' this. Just using the unsafeMethodMissing is dirty. Perhaps provide a way to use normal methodMissing but for the implementor (not the client) to statically assert that certain methods are provided? Or, even better, to allow macros to generate these assertions at compile-time? The latter would allow the implementation of generic methodMissings that can target multiple APIs at compile-time, and which still generate the appropriate assertions so that the client can use lower-case method names. It would not allow you to replace compile-time genericity with run-time, though.

But if we also allow the required assertions to be added by a third-party, then since someone has to give the generic module the necessary parameters to choose or specify the particular API that is being generated in this case, that same party can also attach the required assertions.

So i think the problem is/must be solved in this way, unless we change the capitalization.

And if we do do that, then as a bonus we could simply not require typechecking the method names for capitalized names, on the assumption that if the API was going to prove that it serves these names, it would allow lowercase ones anyhow.

---