This breaks down when you want to use it in a language that has constructs that aren’t possible to model in the primary implementation language.
In other words, what do you do with the dynamic types / static types problem? The entire model code needs to be able to be represented in its own data format, a la LISP, but also able to be statically type-checked, how do you do this, if it’s meta-recursive? If so, the problem of “how do you represent code in data” arises. Code is not data, yet it is. One could say code is data that the computer decided to execute. This forms a problem because of the semantics of the data. The bulk of the FoNC project was created as a set of mini-languages described in OMeta as the meta-language. This *has* to be a better way than spending hundreds of thousands of lines of code just to describe an editor, no? Wasn’t structural editing implicit in the FoNC project? Structural editing is simply semantic editing. The trouble with representing this stuff is that you generally get tied to a particular implementation at some point if you want to do anything useful, I think. OMeta “solves” this by being a symbiotic/hybrid language with a host language that you express functionality in. In my explorations of doing similar things I’ve had to use a data-named “bottom” point for all of the functionality that I’ve wanted to include, (a transfer point between built-in functionality and functionality constructed by composition of these base elements), which is less than ideal I suppose, though the alternative seems to be not type-checking your code, which is worse. All of this stuff seems to be circling around how we can integrate these two worlds: type safety, and dynamic types. I think most runtime and syntax errors should be a thing of the past, and yes, structural editing would solve all syntax errors. As to semantic errors (type errors), I’m not sure. Julian > On 23 Jan 2016, at 8:36 AM, Aaron Gray <aaronngray.li...@gmail.com> wrote: > > Hi, > > To me model is core whether be represented in text, XML, or binary, > but preferably binary. It might even be accessed over a network via > sockets from a model server allowing multiple users and processes to > access the model. > > The model can contain different information types, be viewed in > different forms using different techniques and programs. > > The model should be described by a meta model, this allows the model > to be bounded and able to be more that just random data formats. This > makes it easier for different programs to interact with the data over > a socket via an API. > > The meta model itself should be meta and described in itself, and > possibly lifted by another lower level model used for its > implementation and API access. > > Yes text files suck ! > > > On 19 January 2016 at 11:50, Attila Lendvai <att...@lendvai.name> wrote: >> FYI, there's a new demo video: >> >> https://www.youtube.com/watch?v=s05SlmZ7ZPc >> >> it's basically demoing the editing of the source code of a website >> (all kinds of domains mixed into one document), that at the end gets >> rendered into valid CL code, and into a working website. >> >> there have also been some cleanups and code reorg, so running the code >> is reasonably simple now (using quicklisp). >> >> https://github.com/projectured/projectured >> >> -- >> • attila lendvai >> • PGP: 963F 5D5F 45C7 DFCD 0A39 >> -- >> “The direct use of physical force is so poor a solution to the problem >> of limited resources that it is commonly employed only by small >> children and great nations.” >> — David D. Friedman (1945–), 'The Machinery of Freedom' (1973) >> >> _______________________________________________ >> Fonc mailing list >> Fonc@mailman.vpri.org >> http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org > > _______________________________________________ > Fonc mailing list > Fonc@mailman.vpri.org > http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org
_______________________________________________ Fonc mailing list Fonc@mailman.vpri.org http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org
