[racket-dev] P4P: A Syntax Proposal
I will definitely use p4p next time I teach racket to beginners.
* My only qualms are about "do:" and "if:" as keywords, instead of more
function-like syntax. Looking back at what I found beautiful and elegant
and liberating about scheme the very first time I saw it:
- The whole distinction between operators and functions is a lie!
- The whole distinction between control-flow and functions is a lie!
Well, I¹m exaggerating on that second one; at the time I only realized that
viewing "if" as a function was way cool. (The fact that it's not exactly a
function never bothered me.)
The difference between "do: { a b c }" and "do(a, b, c)" doesn't seem worth
a new keyword to me. (But if it is, it should definitely use curly-brackets
as you mention.) I concede that the keyword might do better at gaining
acceptance from people who balk at scheme's apparent lack of control-flow.
I appreciate the reasons you mention for introducing if:,elif: (about
counting parity, and less parens-for-nesting); I'm just personally reluctant
to give up if-as-function. A friendly amendment/proposal (feel free to
reject it out-of-hand):
if( a,b, elif: c,d, else: e)
where students would realize the keywords `elif:` and `else:` are
meaningless except for indenting/human-readability. Perhaps the keywords
would even be optional -- either they're all there, or none of them are;
beginner-level could require them. (I suppose if I really wanted this I
could write my own macro versions, though I'm guessing that wouldn't play
nice with p4p's auto-indenter.) ...hmm, my proposed asymmetry between the
words "if" and "elif:" is confusing though.
* Any p4p equivalents for the other racket constructs which use extra-parens
(mostly: let and named-let)?
* Are the brackets around expressions-in-function-position required, or
optional? I¹d prefer optional, again just for pedagogical elegance when
introducing anonymous functions, and when using the stepper to replace an
identifier with it's `fun:` value.
(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??)
I look forward to trying out p4p. I've always felt a wee bit hypocritical
saying "scheme emphasizes the connections between programming and math", and
then turning around and correcting the all the years of K-12 notation
"f(x,y)".
--Ian
(who perhaps should have been using honu for quite a while now?)