Re: Designing Lisp from scratch

Hi Daniel,

If you're interested in experimenting with FrTime or looking at the
code that Shriram mentioned, it's all included in the "frtime"
collection of the standard PLT Scheme distribution.  There are a
number of animation demos in the frtime/demos/ directory, and the "400
lines" of GUI wrapper code are in frtime/demos/gui/.  The relevant
files are:

frtime/demos/gui/aux-mixin-macros.ss
frtime/demos/gui/mixin-macros.ss
frtime/demos/gui/fred.ss

There are a few simple demos of the GUI system, including a slightly
modified version of the timer presented in the FLOPS paper, which is
at frtime/demos/gui/demo/timer.ss.

I'm not subscribed to this list, but feel free to contact me directly
with questions or comments.

Regards,
Greg

> 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/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
>
>
>
> ________________________________
> AOL now offers free email to everyone. Find out more about what's free
> from AOL at AOL.com.
>