[fonc] tutorial
Dear all, there's a small tutorial I wrote on the principles applied when implementing programming languages using COLA and its PEG implementation. The language chosen for the tutorial is, rather for its simplicity than for its name, brainfuck. http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html Please let me know whether and how you like it. I shall be especially happy about suggestions for improvement and corrections. Best, Michael -- Dr.-Ing. Michael Haupt[EMAIL PROTECTED] Software Architecture Group Phone: ++49 (0) 331-5509-542 Hasso Plattner Institute for Fax:++49 (0) 331-5509-229 Software Systems Engineering http://www.swa.hpi.uni-potsdam.de/ Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Le 22 nov. 07 à 18:25, Michael Haupt a écrit : The trick is dirty because I have to bind a variable to the result of a rule evaluation and then re-bind it to something entirely different. That's not what I consider clean code. I still don't understand why you had to do that. I really like the description of the hierarchy between C < objects < functions. However, is this order the only one ? I originally thought there were no such hierarchy, so that objects can use functions, as much as functions use objects. Does it mean that ST style of programming can not be applied to COLA, if ever this question make sense ? I don't fully understand what you mean. Ok, maybe it's because your tutorial is about peg, not the entire "fonc/idst" project. The way I saw it, I thought that this project could be the base on which the next "squeak" would be built on. But if you have the order function > object > C, then you can't express "programs" as a soup of objects (the ST way). Stéphane Conversy Enseignant Chercheur en IHM - ENAC http://lii-enac.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Le 22 nov. 07 à 23:40, Michael Haupt a écrit :
Hi Stéphane,
Am 22.11.2007 um 20:13 schrieb Stéphane Conversy:
The trick is dirty because I have to bind a variable to the
result of a rule evaluation and then re-bind it to something
entirely different. That's not what I consider clean code.
I still don't understand why you had to do that.
OK. In that rule of the grammar, I need a data structure to
assemble all the AST bits that are returned from the Instruction
rule into a single AST. That data structure is an
OrderedCollection. It is not possible to declare a local variable
in a grammar rule (at least I don't know a "clean" solution). So I
do the following:
1. match the Instruction rule once and store the resulting AST in
the "instructions" variable
2. create an OrderedCollection ("coll" at first) and put
"instructions" (which is currently only the AST pertaining to *one*
instruction) in there
3. assign the OrderedCollection to "instructions"
Now the required state is reached.
Does that clarify things? The crucial problem is that I cannot
declare local variables in rules, as said above.
ok, now it's clear.
I really like the description of the hierarchy between C <
objects < functions. However, is this order the only one ? I
originally thought
there were no such hierarchy, so that objects can use functions,
as much as functions use objects. Does it mean that ST style of
programming can not be applied to COLA, if
ever this question make sense ?
I don't fully understand what you mean.
Ok, maybe it's because your tutorial is about peg, not the entire
"fonc/idst" project. The way I saw it, I thought that this project
could be the base on which the next "squeak" would be built on.
But if you have the order function > object > C, then you can't
express "programs" as a soup of objects (the ST way).
Hm... I'm still not fully sure I understand you; you really should
post this question to the list.
I try to express it differently:
For me, fonc/idst is a general project about language, run-time,
dynamic everything etc, including peg, which is a new way to
implement languages. It seems to me that your tutorial only adresses
the problem
of implementing a language using peg, not about a general use of fonc/
idst.
My concern is: is the order you mention (function > object > C) when
using PEG, still holds when doing more general thing (like
"reimplementing squeak", whatever it means) ?
if you still don't understand the question, nevermind, it's maybe
because I still don't fully understand the goal of fonc/idst (or
COLA ? or LOLA ?), which is a shame, as I usually get things quicker,
I'm getting older :-(
s.
Best,
Michael
--
Dr.-Ing. Michael Haupt[EMAIL PROTECTED]
Software Architecture Group Phone: ++49 (0) 331-5509-542
Hasso Plattner Institute for Fax:++49 (0) 331-5509-229
Software Systems Engineering http://www.swa.hpi.uni-
potsdam.de/
Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany
Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam
Amtsgericht Potsdam, HRB 12184
Geschäftsführung: Prof. Dr. Christoph Meinel
Stéphane Conversy
Enseignant Chercheur en IHM - ENAC
http://lii-enac.fr/~conversy
enac: +33 5 62 17 40 19
dgac r&d: +33 5 62 25 96 48
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Le 23 nov. 07 à 09:22, Stéphane Conversy a écrit : I try to express it differently: For me, fonc/idst is a general project about language, run-time, dynamic everything etc, including peg, which is a new way to implement languages. It seems to me that your tutorial only adresses the problem of implementing a language using peg, not about a general use of fonc/idst. My concern is: is the order you mention (function > object > C) when using PEG, still holds when doing more general thing (like "reimplementing squeak", whatever it means) ? for example, there is a lot of canvas examples in the function directory, none in the object directory. Why is that ? can't I program OO graphical stuff with LOLA ? if you still don't understand the question, nevermind, it's maybe because I still don't fully understand the goal of fonc/idst (or COLA ? or LOLA ?), which is a shame, as I usually get things quicker, I'm getting older :-( s. Best, Michael -- Dr.-Ing. Michael Haupt[EMAIL PROTECTED] potsdam.de Software Architecture Group Phone: ++49 (0) 331-5509-542 Hasso Plattner Institute for Fax:++49 (0) 331-5509-229 Software Systems Engineering http://www.swa.hpi.uni- potsdam.de/ Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel Stéphane Conversy Enseignant Chercheur en IHM - ENAC http://lii-enac.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Stéphane Conversy Enseignant Chercheur en IHM - ENAC http://lii-enac.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Nov 23, 2007 2:39 AM, Stéphane Conversy <[EMAIL PROTECTED]> wrote: > ... > for example, there is a lot of canvas examples in the function directory, > none in the object directory. > Why is that ? can't I program OO graphical stuff with LOLA ? You can. The fact that the canvas stuff was done in jolt is not a sign of what you can or can't do with the various pieces of the system. The canvas stuff was created initially to support some jolt+javascript work that needed graphical capabilities. I wouldn't try to infer anything profound from its existence/implementation. Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Nov 23, 2007, at 2:39 AM, Stéphane Conversy wrote: For example, there is a lot of canvas examples in the function directory, none in the object directory. Why is that ? can't I program OO graphical stuff with LOLA ? The object/ and function/ directories include incompatible object libraries (the biggest difference is that the one in object/st80 has 1-based arrays and the one in function/object has 0-based indexing). The object/st80 library is moribund; it's only purpose is to support the idc compiler. As the idc compiler is pulled into Jolt (to make Coke -- it's the real thing ;-) the st80 library will become irrelevant (although I am slightly tempted to keep it, make it ANSI compliant, anc call it 'Standard Smalltalk'). New code should use the function/object library. Eventually everything above function/ will be subsumed by stuff inside function/ and a 'mv function/* .; rmdir function' will be issued. Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Nov 25, 2007, at 4:18 PM, Dan Amelang wrote: The canvas stuff was created initially to support some jolt+javascript work that needed graphical capabilities. I wouldn't try to infer anything profound from its existence/implementation. Other than it's an indication of the direction in which the UI work must move. I like the Typeface stuff in there a lot. I think the Shape stuff is reasonably good, but I'd be happier if Points, Rectangles and Polygons were unified. I hate the proliferation of view types -- there should only be two kinds of view. I really hate the proliferation of instance variables -- everything should be (dynamic) properties hung off instances of one of the two general view types. I hate the special case handling of text layout -- everything should be made of relationships between and constraints acting on boxes and springs, like in TeX (and maybe we should even be using Knuth's algorithms directly). I'd love someone who is much better than me at math to think seriously about how geometric algebra might be exploited in (or even subsume) all the transform stuff in there. Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Nov 23, 2007, at 12:22 AM, Stéphane Conversy wrote: I still don't fully understand the goal of fonc/idst (or COLA ? or LOLA ?) Think of it as 'factory tooling'. If you have a lathe and a milling machine you can build lathes and milling machines easily; without them, building the same tools is much harder. *OLA is (converging on ;-) the minimal programming language tooling needed to make (very easily) new programming languages, with minimal assumptions (static, dynamic, incremental, offline, etc...), including itself (in its entirety). The properties that fall out from this make it attractive for any programming task, not just language implementation. (Interesting thing about tooling: it often ends up begin more valuable than the artefacts that it manufactured.) Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Ian Piumarta <[EMAIL PROTECTED]> wrote: [snip] > I hate the special case handling of text layout -- > everything should be made of relationships between and constraints > acting on boxes and springs, like in TeX (and maybe we should even be > using Knuth's algorithms directly). Possibly of interest: http://www.arsmathematica.net/archives/2007/11/22/tex-finally-made-functional/ > I'd love someone who is much better than me at math to think > seriously about how geometric algebra might be exploited in (or even > subsume) all the transform stuff in there. Its nice to see somone mention geometric algebra :). I had coded some GA stuff for squeak a while ago, for use with Jasmine Croquet (I think to make the transforms for 3D head-tracking + stereo projection friendlier). But the code is probably fairly crufty :). I'd be interested in looking at doing a GA implementation once things get a bit more mature (and there is a tutorial where I don't have to look at filthy language!). cheers, Daniel Faken ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Tue, Nov 27, 2007 at 10:08:04AM -0800, Ian Piumarta wrote: > On Nov 23, 2007, at 12:22 AM, St?phane Conversy wrote: > >> I still don't fully understand the goal of fonc/idst (or COLA ? or LOLA ?) > > Think of it as 'factory tooling'. If you have a lathe and a milling > machine you can build lathes and milling machines easily; without them, > building the same tools is much harder. *OLA is (converging on ;-) the > minimal programming language tooling needed to make (very easily) new > programming languages, with minimal assumptions (static, dynamic, > incremental, offline, etc...), including itself (in its entirety). The > properties that fall out from this make it attractive for any programming > task, not just language implementation. What sort of properties? It seems the same concepts applied to programming languages could be applied to computer languages too, so Cola could be used to build parsers for languages such as: PNG ZIP OGG IPv6 Disk File Systems These are languages with a completely different set of constraints than human-readable languages. Constraints here include: compactness, automatic error correction, and ease-of-decoding. Do you feel that these are some of the tools that Cola could help build? If so, how would cola help with building these, as opposed to the current practice of building a dedicated library for each? > (Interesting thing about tooling: it often ends up begin more valuable than > the artefacts that it manufactured.) I don't understand this comment -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Many thanks for taking time to answer to the previous questions. Introducing the new ones: In function/, there is jolt/, jolt-burg/, jolt-vpu/. AFAI, jolt-vpu is a first attempt, and is moribund. I don't know the relationship between jolt and jolt-burg. However, a $ find . -name Makefile | xargs grep "jolt-burg/" gives some results, though $ find . -name Makefile | xargs grep "jolt/" gives nothing interesting, so I guess jolt/ is moribund as well. can you confirm ? Now I understand that jolt contains/subsumes idc. However, I still don't understand the relationships between jolt, Coke and PEG. I guess a sentence or two would suffice. Aparte: maybe it's because of the naming. I had a hard time when exploring squeak to figure out what monticello, squeakmap, squeaksource etc were refering. I think it's the same on this one. Le 27 nov. 07 à 19:12, Ian Piumarta a écrit : On Nov 23, 2007, at 2:39 AM, Stéphane Conversy wrote: For example, there is a lot of canvas examples in the function directory, none in the object directory. Why is that ? can't I program OO graphical stuff with LOLA ? The object/ and function/ directories include incompatible object libraries (the biggest difference is that the one in object/st80 has 1-based arrays and the one in function/object has 0-based indexing). The object/st80 library is moribund; it's only purpose is to support the idc compiler. As the idc compiler is pulled into Jolt (to make Coke -- it's the real thing ;-) the st80 library will become irrelevant (although I am slightly tempted to keep it, make it ANSI compliant, anc call it 'Standard Smalltalk'). New code should use the function/object library. Eventually everything above function/ will be subsumed by stuff inside function/ and a 'mv function/* .; rmdir function' will be issued. Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Stéphane Conversy Enseignant Chercheur en IHM - ENAC http://lii-enac.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
ok. By looking at the examples, I see that all the tools are launched using a command line. Can I infer that so far, dynamic 'compiling' is still not possible, though envisionned ? Which leads to the question: is it one of the goals to make *OLA embedable someday in a squeak-like environment (which btw would not be the squeak we know, but something built with *OLA) ? btw, I vote for ZOLA for two reasons: 1. http://acronyms.thefreedictionary.com/zola. "Zola is not available in the list of acronyms." (whci hmeans it IS available) 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: "...but I affirm, with intense conviction, the Truth is on the march and nothing will stop it." — Émile Zola I still work hard to find out what the 'Z' would mean. s. Le 27 nov. 07 à 19:08, Ian Piumarta a écrit : On Nov 23, 2007, at 12:22 AM, Stéphane Conversy wrote: I still don't fully understand the goal of fonc/idst (or COLA ? or LOLA ?) Think of it as 'factory tooling'. If you have a lathe and a milling machine you can build lathes and milling machines easily; without them, building the same tools is much harder. *OLA is (converging on ;-) the minimal programming language tooling needed to make (very easily) new programming languages, with minimal assumptions (static, dynamic, incremental, offline, etc...), including itself (in its entirety). The properties that fall out from this make it attractive for any programming task, not just language implementation. (Interesting thing about tooling: it often ends up begin more valuable than the artefacts that it manufactured.) Cheers, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Stéphane Conversy Enseignant Chercheur en IHM - ENAC http://lii-enac.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
Stéphane Conversy wrote: btw, I vote for ZOLA for two reasons: 1. http://acronyms.thefreedictionary.com/zola. "Zola is not available in the list of acronyms." (whci hmeans it IS available) 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: "...but I affirm, with intense conviction, the Truth is on the march and nothing will stop it." — Émile Zola I still work hard to find out what the 'Z' would mean. How about Zen Object Lambda Architecture? # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
ZEN meaning Zero Engine Noise? .. Zitat von "Steven H. Rogers" <[EMAIL PROTECTED]>: > Stéphane Conversy wrote: > > btw, I vote for ZOLA for two reasons: > > 1. http://acronyms.thefreedictionary.com/zola. "Zola is not available > > in the list of acronyms." (whci hmeans it IS available) > > 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: "...but I affirm, > > with intense conviction, the Truth is on the march and nothing will > > stop it." Émile Zola > > > > I still work hard to find out what the 'Z' would mean. > > > How about Zen Object Lambda Architecture? > > # Steve > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
On Wed, November 28, 2007 06:50, [EMAIL PROTECTED] wrote: > ZEN meaning Zero Engine Noise? > That might work ;), but this definition from the Jargon File is more what I had in mind: zen vt. To figure out something by meditation or by a sudden flash of enlightenment. Originally applied to bugs, but occasionally applied to problems of life in general. "How'd you figure out the buffer allocation problem?" "Oh, I zenned it." Contrast grok, which connotes a time-extended version of zenning a system. It seems to fit the FONC goal of discoverable systems. # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
That's not bad. How about simply OLA, since minimalism is such a big part of the whole adventure? Josh On Nov 28, 2007, at 5:30 AM, Steven H. Rogers wrote: Stéphane Conversy wrote: btw, I vote for ZOLA for two reasons: 1. http://acronyms.thefreedictionary.com/zola . "Zola is not available in the list of acronyms." (whci hmeans it IS available) 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: "...but I affirm, with intense conviction, the Truth is on the march and nothing will stop it." — Émile Zola I still work hard to find out what the 'Z' would mean. How about Zen Object Lambda Architecture? # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
That's got my vote for the time being... -- Kim On Nov 28, 2007, at 9:41 AM, Joshua Gargus wrote: That's not bad. How about simply OLA, since minimalism is such a big part of the whole adventure? Josh On Nov 28, 2007, at 5:30 AM, Steven H. Rogers wrote: Stéphane Conversy wrote: btw, I vote for ZOLA for two reasons: 1. http:// acronyms.thefreedictionary.com/zola. "Zola is not available in the list of acronyms." (whci hmeans it IS available) 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: "...but I affirm, with intense conviction, the Truth is on the march and nothing will stop it." — Émile Zola I still work hard to find out what the 'Z' would mean. How about Zen Object Lambda Architecture? # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
The community may find it of interest to know we toyed with this word/ idea some time ago Kim On Nov 28, 2007, at 7:12 AM, Steven H. Rogers wrote: On Wed, November 28, 2007 06:50, [EMAIL PROTECTED] wrote: ZEN meaning Zero Engine Noise? That might work ;), but this definition from the Jargon File is more what I had in mind: zen vt. To figure out something by meditation or by a sudden flash of enlightenment. Originally applied to bugs, but occasionally applied to problems of life in general. "How'd you figure out the buffer allocation problem?" "Oh, I zenned it." Contrast grok, which connotes a time-extended version of zenning a system. It seems to fit the FONC goal of discoverable systems. # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] tutorial update
Dear all,
just a brief notice that my COLA tutorial ("Implementing Brainfuck in
COLA") is available in an updated version. The update does not bring
anything fundamentally new, just enhancements, mostly in terms of
accuracy.
http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html
Best,
Michael
--
Dr.-Ing. Michael Haupt[EMAIL PROTECTED]
Software Architecture Group Phone: ++49 (0) 331-5509-542
Hasso Plattner Institute for Fax:++49 (0) 331-5509-229
Software Systems Engineering http://www.swa.hpi.uni-potsdam.de/
Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany
Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam
Amtsgericht Potsdam, HRB 12184
Geschäftsführung: Prof. Dr. Christoph Meinel
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial update
Hi,
Michael Haupt <[EMAIL PROTECTED]> writes:
> just a brief notice that my COLA tutorial ("Implementing Brainfuck in
> COLA") is available in an updated version. The update does not bring
> anything fundamentally new, just enhancements, mostly in terms of
> accuracy.
Would you be able to share something like a diff or wdiff of the paper
so that we could see what has changed?
Thanks,
--
Michael FIG <[EMAIL PROTECTED]> //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial update
Hi Michael, Am 01.05.2008 um 05:11 schrieb Michael FIG: Would you be able to share something like a diff or wdiff of the paper so that we could see what has changed? it's really what you'd call a maintenance update. If you have read the first version, this one won't give you anything new; it just gets some things a bit more right: - the text on syntax definitions in Sec. 2.1 has been extended to make clear that they are macros only at first sight, - the text on action parts in Sec. 2.2.2 has been corrected - there was a wrong detail in the description of when they are actually executed, - the implementation has been slightly augmented according to a suggestion from Ian (lines 60-63; Sec. 2.2.3) - it's a bit simpler now but semantically equivalent. That's all. :-) With Jolt2 becoming more stable, there will be future versions based on that, and the update to a Jolt2 implementation will inevitably bring more changes in the text, as the philosophy behind things is changing. Best, Michael -- Dr.-Ing. Michael Haupt[EMAIL PROTECTED] Software Architecture Group Phone: ++49 (0) 331-5509-542 Hasso Plattner Institute for Fax:++49 (0) 331-5509-229 Software Systems Engineering http://www.swa.hpi.uni-potsdam.de/ Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
