[racket-dev] P4P: A Syntax Proposal

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