Hi Ian, > - The whole distinction between operators and functions is a lie!
Except it's not. I've run into educators who taught Scheme who thought this way, and the accounts of Scheme they gave were nonsense. I'm not saying this (nonsensical semantics) is a necessary consequence of thinking like this, but keeping them distinct is wise. As the manifesto says, ":" means, "Look out! Not a function call!" > A friendly amendment/proposal (feel free to > reject it out-of-hand): > if( a,b, elif: c,d, else: e) Consider it rejected out-of-hand. (-: > * Any p4p equivalents for the other racket constructs which use extra-parens > (mostly: let and named-let)? Sure. I can add let:. > * Are the brackets around expressions-in-function-position required, or > optional? Essential. That's how parsing stays unambiguous. (That's why I have a do: keyword, not just {...}, as Everett proposed.) > I ¹d prefer optional, again just for pedagogical elegance when > introducing anonymous functions Not true at all. Here are two examples: ===== deffun: d/dx(f) = defvar: delta = 0.001 fun: (x) in /(-(f(+(x, delta)), f(x)), delta) defvar: d/dx-of-square = d/dx(fun: (x) in *(x,x)) =(round(d/dx-of-square(10)), 20.0) =(round(d/dx-of-square(25)), 50.0) ===== deffun: mymap(f, l) = if: empty?(l) empty else: cons(f(first(l)), mymap(f, rest(l))) mymap(add1, list(1, 2, 3)) ===== No braces anywhere. You need them ONLY when the function position is a non-identifier expression. > (I might be missing something, but I think now that you ¹re using > curly-brackets, you not only get back non-ambiguity but you also regain > predictable parsing even if curly-brackets are optional??) The former is true. I believe the latter is false. If I see something bracketed, is it the optional bracket being made manifest, or is it the function position expression? Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev