Re: Designing Lisp from scratch

On 3/18/07, [email protected] <[email protected]> wrote:

> >- functional reactive programming
>
> I looked at a paper by Ignatoff, Cooper, and Krishnamurthi,
> regarding Functional Reactive languages, which also talks about
> FrTime.  I got a sense that it was a great challenge to expand a
> language like Scheme beyond its normal syntactic boundaries to make
> it support abstractions for dealing with values that change over
> time.

You read a paper about X to make an argument about Y, where X is very
distinctly not equal to Y.  Look at

http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/
Embedding Dynamic Dataflow in a Call-by-Value Language
Gregory H. Cooper, Shriram Krishnamurthi
European Symposium on Programming, 2006

which shows how relatively easy it is.  The neat thing about Greg
Cooper's embedding scheme is that you let the existing call-by-value
evaluator do the hard work for you of building the dataflow graph.
Then you hand off the graph to the dataflow engine.

> I may completely be missing the boat, but from examples like the
> ones dealing with seconds, it looked like it would not require any
> special effort at all to implement this in uCalc.

Don't look at examples: look at the semantics!  That's why we provide
one!  Are you sure you got it right?  Can you, for instance, avoid
glitches in your dataflow evaluator?

> That's because uCalc does not start with a Scheme syntax, or
> imperative style, or any particular paradigm.  It does not favor one
> style over another.

I have no idea what this means.  I think I would recognize this if it
addressed a real issue that arose in the construction of either FrTime
or Flapjax (flapjax-lang.org), but I'm afraid I don't, so quite
possibly it does not.

If anything, the Scheme syntax made building Flapjax a bit easier,
because we were able to exploit not only the macro system but --
crucially -- the richer language definition system ("macros on
steriods") built into PLT Scheme; Flapjax had to do the same work the
hard way.  But the syntax is totally irrelevant.  I don't know what
"paradigm" means.

In short, while I could be wrong, your quoted text does not pass my
smell-test.

> The result is that it's very easy to mix-and-match various paradigms
> that normally wouldn't be found in the same language.

Now I'm *really* suspicious.  Did you read the Ignatoff, et al paper
carefully?  For the benefit of others, I provide the URL below:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/ick-adapt-oo-fwk-frp/
Crossing State Lines: Adapting Object-Oriented Frameworks to
  Functional Reactive Languages
Daniel Ignatoff, Gregory H. Cooper, Shriram Krishnamurthi
Functional and Logic Programming Symposium, 2006

My opinion is that:

(1) The issues that paper talk about might be called "irreducible
complexity": it can't disappear, it has to be somewhere.  Perhaps
uCalc happens to be constructed just right so this particular
complexity disappears.  If so, I'm sure I can perform a kind of
diagonalization that shows that something else becomes awfully
hard. (-:

(2) I'm not sure why you think our solution is especially complex
(which is what I infer from "great challenge").  We brought the task
of interfacing a large, legacy library to FrTime down to about 400
lines of code, consisting of some very elegant, composable macros and
mixins.  I'm biased, of course, but that sounds pretty good to me!
You're welcome to disagree, but you're going to have to do much better
than engage in an Argument by Shock and Awe.

Shriram