We should have a general idea of a theme for each of [] () and {}.
Perhaps the on-both-sides thing is too cute. :(sad):
lambda:
[x : Num -> x + 1]
`[x : Num -> x + 1]`
\ x : Num . x + 1
^[x : Num -> x + 1]^
.[x : Num -> x + 1].
^ x : Num -> x + 1
.[x : Num . x + 1].
-[x : Num]- x + 1
->[x : Num]-> x + 1
x : Num ->[x + 1]->
quick lambda:
(Assuming we can get inference to work. Otherwise, maybe `the Num` or `_ : Num` instead)
[_ + 1]
_[_ + 1]_
-> _ + 1
type parameterization:
List @ Num
List <[Num]< ...fish X-ray!
@[List Num]@
t[List Num]t
List Num and Map (String Num)
Num List and (String Num) Map ...Englishy!
syntax quotation:
'[,[e], + 1]' and ''[,[ e ], + ,,[e],,]''
+[-[e]- + 1]+
'[ ...[ ,[e], + 1 ]... ]' ...but how do we escape it?
'[ *[ ,[e], + 1 ]* ]'
'[ ,,...[e],,... ]' '[ ,[ (dotdotdotsyntax '[e]')], ]'
(turns out we need to name our nonterminals)
'[Expr | ,[e], + 1]'
E[,[e], + 1]E
form definition:
(Gosh, there's a lot of stuff in here...)
'[(lambda ( ,{x : Name}, : ,{t : Type}, ) ,{e : Expr @ S <-- (x : t)}, )]'
'[(extend-syntax ,{f : Forms}, ,{body : T <-syn- f})]'
'[(begin-for-syntax ,{+phase e : Expr},)]'
function invocation:
(map [the Num + 1] lst) ...Schemey!
map ([the Num + 1] lst) ...Cy! (but with an extra space)
map [the Num + 1] lst ...MLy!
map [the Num + 1] over lst ...Smalltalky!
macro types:
(Is the concrete syntax part of the type? We may need it to be, for `...` to work)
∀ ...{T}... . ∀ S .
'[let ...[ ,[ var ⇑ v ], = ,[ expr<[T]< ], ]...
in ,[ expr<[S]< ↓ ...{v = T}...], ]'
-> expr<[S]<
'[letrec
...[ ( ,[ var ⇑ v], ...[ ,[ var ⇑ arg], ]... )
= ,[ expr <[T]< ↓ ...{arg}...], ]...
in ,[ expr <[S]< ], ]'
We should try to have types and expressions look different.
One tradition is for types to be capitalized and expressions to be lowercase.
Perhaps that means that types generally get "bigger" operators?
-[x : Int -> x]- : =[Int => Int]=
~[the Int]~ : =[Int => Int]=
We also need [](){} groupers for a lot of different purposes:
syntax quotation, syntax unquotation, lambda, possibly function application
forced precedence in expressions,
forced precedence for syntax operations (maybe just `...`),
forced precedence for betas (maybe just `...`),
function types, type precedence (maybe just type abstraction invocation),
enum/struct types,
literal lists/maps/sets,
...probably more kinds of quotation,
One natural allocation is [] for sequences in which order matters, {} for sets,
and () for forcing precedence.
An immediate problem with that is that {} will hardly ever get used.
We could use `[]` for "level shifts" (i.e. literals, quotation, lambdas),
`()` for precedence, and `{}` for... everything else?