[racket-dev] P4P: A Syntax Proposal

From: Barland, Ian (ibarland at RADFORD.EDU)
Date: Wed Jul 28 19:23:38 EDT 2010

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?)



Posted on the dev mailing list.