[plt-scheme] MrMathematica

>>>>> "Eli" == Eli Barzilay <eli at barzilay.org> writes:

Eli> On Jun 11, Michael Sperber wrote:
>> I strongly encourage you to take a combinator-based approach.  This
>> macrology in scsh is a recurring nightmare (it isn't compositional,
>> for one), and we'll get rid of it in the long run.

Eli> Any quick examples why this is so bad?

Well, it's mainly *not good* is why.

2 things, mainly:

- You quickly add custom syntax that's hard to remember---when you're
  doing Scheme, where syntax should be easy to remember.  Try teaching
  the funky scsh syntax to people who've only had a little bit of
  exposure to Scheme---they go all googly-eyed.  (This is
  fundamentally because the stuff wasn't devised using a systematic,
  recipe-based design approach, but really using 70s Lisp lore.)

- It's not compositional---since everything is syntax, you can't just
  return the value of one of these forms, and use them as a subform in
  another.  (Or, rather, you can, but using completely different
  forms, which adds to the confusion.)

Also, there usually isn't any real gain.  For sure, scsh's idea of
what "process forms" and "extended process forms" are is at least
confusing and really nonsensical, which is a result of the design
approach taken.  (I made very similar observations with SchemeQL---the
combinator-based version is much more regular and nicer.)

Eli> Any other ideas how to deal with `easy' syntax without this, or will
Eli> you switch to normal no-discount syntax?

Design a combinator library first.  Then, only when that's done, start
thinking about funky syntax, and only when there's significant and
obvious benefit.  Otherwise, don't.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla