Re: Designing Lisp from scratch

 
 
 
I mentioned that maybe I had completely missed the boat.  As it turns  out I 
did.  It's only today after I looked at the FrTime presentation in  the LL3 
online video at ll3.ai.mit.edu that I got a better understanding of what  FrTime 
and functional reactive program is about.  (I had seen the  presentation long 
ago as well but had completely forgotten about it).  I  wasn't able to 
visualize the concept by only reading a static paper description  of it.  So my 
earlier response was based on a misunderstanding of the  concept.
 
I have not yet investigated whether FrTime, now that I understand it  better, 
can be implemented in uCalc.  However, I implemented a spreadsheet  for UCalc 
Fast Math Parser, the predecessor of uCalc Language Builder, using  something 
like the push-driven update mechanism that you mention in the  paper.  I 
assume that it should be possible to expand this further unto  something like 
FrTime for uCalc.  (FrTime also reminds me of an interactive  3D animation 
language that I had worked on, way back in the DOS days but  eventually discontinued. 
 It was pretty crude, but had an interesting demo  nonetheless.)
 
In any event my interest is just as much in syntax as it is in  semantics.  
This, I guess, brings the discussion to something else.   My response here was 
partly a reflection of a separate private discussion I held  concurrently with 
another reader who pointed me towards the PLT-Scheme redex  tool, perhaps as 
something that already did what I was trying to do with  uCalc.  But looking 
at the paper entitled "A Visual Environment for  Developing Context-Sensitive 
Term Rewriting Systems" by Matthews, Findler,  Flatt, and Felleisen, I came out 
with the impression that the redex tool could  only do Scheme or Lambda-like 
languages.  At least, I thought, it could  also do a version of Java.  But 
when I looked further into it, I noticed  that the ClassicJava in question (which 
I think you described in a paper),  appears to have the semantics of Java, 
but with a Scheme-like syntax.   That's fine.  Though what I'm trying to do is 
to let programmers have not  just the semantics, but also the syntax of their 
choice.
 
By the way, I'd be interested in looking at the 400 or so lines of  code 
related to FrTime that you mentioned.  Is that something that is  publicly 
available for download?

Daniel  Corbier
uCalc Language Builder
www.ucalc.com

 
In a message dated 3/18/07 10:18:51 PM Eastern Standard Time,  
[email protected] writes:

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/P
apers/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






************************************** AOL now offers free email to everyone. 
 Find out more about what's free from AOL at http://www.aol.com.