Thanks for the feedback!
> - I wish conditionals were lighter weight.
> Maybe cond: Q0, A0, ... else: An
I expressly want the signposts for intermediate expressions. It makes
clearer what you're looking at -- a question or an answer.
Though I'm not a fan of cond's syntax, at least we have signposts: the
thing after the anonymous open paren is the question, the thing before
the anonymous close paren is the answer. By getting rid of those
parens, all we have is a sequence of expressions. So the intermediate
keywords do what the parens did. Imagine in lab:
"Which is the question part?"
"Uh, I don't know..."
"The things after the if: and elseif: are questions."
"Oh, okay."
vs.
"Which is the question part?"
"Uh, I don't know..."
"You have to count how many expressions down you are; every odd one is
a question, and every even one is an answer."
Plus, the intermediate keywords give me something to hang an
indentation check hat on. This way the expressions can be flexibly
indented, while the keywords are kept rigid.
My understanding from Python, C, etc., is that the intermediate
keywords are not considered onerous.
> - I wish it were easier to predict names and syntax for special forms.
That's just because my docs need to be better. I haven't invested
time in the BNF because things keep changing around. Once you have a
BNF and corresponding manual, you wouldn't need to guess. BUT:
> Choices of names seem independent of surface syntax details, so why
> should they change if we change those details?
1. Because names are part of surface syntax.
2. Because I'm also expermenting with the names.
I want the overhead of testing to be as small as possible, and find
"check-expect" pretty unwieldy. In PLAI, I called it test.
Purely by coincidence, in Bootstrap, Emmanuel called it TEST [sic],
because young kids have bad typing skills so the more characters they
have to write, the longer it takes and the more mistakes they make.
If at some point Emmanuel experiments with P4P, I can be sure the
FIRST thing he'll ask for is a test: construct for testing.
> And doesn't the use of `=' and `=?' keywords violate your
> "Distinguishing Keywords" choice? I would expect `=:' and `=?:' for
> consistency.
At some point I had text, which I seem to have lost, that says I made
an exception for symbolic keywords. Put differently, I can claim it's
already in there in that the rule only applies to keyWORDS.
Take examples.rkt, rename all the = to =: and =? to =?:, and look at
it. I really believe you'll agree it looks significantly uglier.
Shriram
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
