[plt-scheme] Scheme and R

On Mar 26, Neil Toronto wrote:
> 
> As a language it's rather weak and inconsistent. Sungwoo Park's
> analysis is good, so I'll defer to him:
> 
>      http://www.postech.ac.kr/~gla/paper/R-ism-dec-8.ppt

If anything, reading this made me appreciate R more than my previous
vague impression.  Specifically, that criticism reads very obviously
as an ML advocate criticising (PLT) Scheme.

Even more specifically:

* We have a `void' value that is the common result of side-effect
  functions[1] -- we even have (surprise) a `when' expression, and
  one-sided `if's.  (It's not clear to me whether R implements this
  using a void value or using something like (values) -- but the
  choice between the two is irrelevant.)

* We have implicit boxing that allows `set!'.  It's debatable whether
  this is better than forcing an explicit `box' in the code (as ML
  does), but again, with modules turning these into local boxes, the
  difference is almost cosmetic[2].

* Note that the "No Lexical Scoping" criticises the R repl in a way
  that applies to any Scheme repl.  The only difference is the `set!'
  implying a definition (which is not a good idea in any case).  Even
  more importantly, it highlights the `let*' semantics of the OCaml
  repl -- which is very problematic in itself (up to the point where I
  just gave up on using the OCaml repl for anything more than simple
  testing)[3].  The "Special Top Level?" slide is bogus for the same
  reason.

* He also labels "otherwise the user could not define new functions"
  as "Wrong!" -- but neglects to show the need for `let rec' binders
  in OCaml *and* the fact that this makes certain kind of programs
  nearly impossible to write in a repl[4].

* The "R*Type" slides criticises what looks like doing the same thing
  that Scheme does.  Therefore, the conclusion that dynamic types
  are good for "quick, small programming tasks" and that static types
  are good for "large programming tasks" is something that PLT Scheme
  disproves very effectively (both in code size, and in features like
  contracts and typed Scheme).

* The criticism of "Lazy Evaluation" is very exaggerated: promises in
  Scheme can be useful with side-effects too.  Yes, you can get into a
  "total complete mess" if you're not careful in side-effects that you
  expect to happen multiple times -- but I didn't see anyone
  advocating the removal of promises in Scheme on that ground.  He
  even mentions monads as "the solution" from programming language
  theory -- not mentioning that a state/io monad is just not needed if
  you have state/io in your language.  (And if you don't have them,
  and you use a monad, that still wouldn't magically make your code
  less prone to bugs in a significant way[5].)

* In "Meta-programming in R" his (implied) conclusion is that meta
  programming is just not useful for statistical computing.  But
  that's completely ridiculous when his final conclusion is to rebuild
  R on top of a generic language.

* Also, in this slide you can already see what his opinion on macros
  is going to be -- and the next slide this is verified: equating
  macros with "stuff that could be done with thunks" is a common
  misconception that, uh, "people who don't like macros" use
  frequently.  Instead, his point in this slide should be about the
  lack of hygiene in R's quotes.

* There are also, btw, many slides that are just silly, like quoting
  random blurbs.


[1] Just like in ML, BTW.  Looks like the author was trying to sweep
    it under the rug with some really hard to see light gray color for
    the "val it = () : unit" result...  (Light enough that I couldn't
    see it first due to the laptop's angle...)

[2] By "cosmetic" I mean that if MzScheme were to drop `set!' from the
    language, it probably wouldn't be too hard to re-implement it as a
    module language that finds assigned identifiers.

[3] And yes, you can mention DrScheme interaction being used in a
    similar way, and the inherent problems in any repl -- but if
    anything, all of this means that R is not worse in any significant
    way.

[4] For example, almost any kind of CamlP4 code that I've seen
    required most of the module to be defined in a giant `let rec'.
    Using the repl with such expressions is impractical.

[5] The main benefit I see from the whole monad thing is in using the
    type system to ensure that you don't have side effects in random
    places, but I've seen some haskell code examples with the IO monad
    chained through the whole code making it no better to debug than
    any impertaive language.  (At least that was my (shallow)
    impression.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!