On Thu, 10 Nov 2011, Heinrich Apfelmus wrote: > Henning Thielemann wrote: >> >> I am afraid from the point of view of formal languages this is an ugly >> hack. You have no referential transparency. E.g. as noted above at time >> point zero the term 'loop' may refer to 'NoteOn 23' and two seconds later >> it may refer to 'PgmChange 42'. The whole matter of sharing and buffering >> of reduced terms is no longer an issue of performance but an issue of the >> semantics. As I said above, >> >> loop1 = append melody loop1 >> >> allows you to continue with 'loop2' after 'loop1' by changing it to >> >> loop1 = append melody loop2 >> >> on the fly, but if you would have written >> >> loop1 = cycle melody >> >> in the first place, this would not be possible. (Only by changing the >> definition of 'cycle'.) > > Ah, so if I understand that correctly, the procedure works as follows: > some terms are referred to by names and updating the program means > changing the terms associated to these names, even while the program is > being evaluated.
yes > As soon as graph reduction begins to evaluate one of > the named terms, the "connection" to the name will be broken and an > update to the name will no longer affect the term being evaluated. yes > (So, updating a program would behave a bit like "switching pointers".) > > Is this an adequate representation of what you have implemented? I think so > (That's why I'm looking for something "formal", i.e. a precise > description of what happens.) I think a formal description would have to tag rules and terms with time stamps or step numbers. The step number must be increased after every list element in the top-level list. However these step numbers would have to be automatically attached when you update the interpreted program with modified content from the editor and they are neither shown in the highlighting text area nor in the text area for the current term. > Probably not, because my description would imply that the > cycle melody example should work. After all, the name "melody" is > being duplicated and the later instances could easily be updated on the > fly. Yes, this is possible. You can alter the meaning of 'melody' and cycle will incorporate changes in the definition of 'melody'. However you can break out from cycle only by altering the definition of 'cycle' (and thus every call to cycle is affected, not only the melody-cycle). And if you would have written cycle (concat [note qn (c 4), note qn (e 4)] ) you could even not alter the looped sequence of notes. > Also, my description doesn't seem to rely on the fact the engine > only accepts changes after each MIDI note / wait item. The expected top-level data structure is a list, and the interpreter evaluates this list element by element, asking for program changes before every element. We think about a single step mode for educational purposes that shows reduction steps with certain degrees of granularities. Thus the number of break points might be increased in future. Currently the easiest way to answer questions about the semantics is to run the program (not a good answer, I know :-) Do you plan to attend our after-HaL meeting next thursday? I could also try to add a JACK back-end. I hope this would allow to run the program on Mac, too? > I'm just wondering if there's a way to get this kind of behavior from > plain GHCi by using really dirty tricks. For instance, I'm thinking that > observable sharing (to get names) and hash-consing (to get equal names > after reloading a file) might make it possible to implement the "switch > pointers" method I described. Somehow, it seems to me that the only > thing you need is access the names of variables from a Haskell source file. Update of the program could be done by calling :load in GHCi. But then you have to store the current program content in a way that survives :load. Best, Henning _______________________________________________ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
