Re: [fonc] Reverse OMeta and Emulation
You may find the concept of semantic slicing relevant: http://www.cse.dmu.ac.uk/~mward/martin/papers/csmr2005-t.pdf There is software at: http://www.cse.dmu.ac.uk/~mward/fermat.html One possible path to explore is to take GNU C etc intermediate representation of source as the assembly language of a VM and reverse from that to a more portable VM, as in Squeak or Java. Perhaps Ometa could be combined in some way with FermaT to recognise patterns and port legacy code to a fonc VM ? Regards, Gerry Jensen 02 9713 6004 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Ometa references was Re: [fonc] Systems and artifacts
Thanks Andrey, i thought it might be useful to others (especially newbies who come here first) to post a few other Ometa related URLs/posts, with yours http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html http://www.tinlizzie.org/ometa/ http://www.vpri.org/vp_wiki/index.php/Main_Page http://tinlizzie.org/ometa/ometa2.html http://vpri.org/pipermail/ometa/2010-April/000241.html http://vpri.org/pipermail/ometa/2008-June/20.html There are some interesting related posts at LtU if one googles on Ometa pegs or packrat -- Regards, Gerry Jensen 02 9713 6004 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Systems and artifacts
At Andrey's reference (2),there was an example that TCP/IP could be modelled in less than a hundred LOC, whereas a C code version might be more than an order of magnitude larger. Is that model available? Regards, Gerry Jensen 02 9713 6004 Alan Kay wrote: It used to be more clear. The main meaning of artifact is still something made by a human being (I think it originated in Anthropology), but other meanings have crept in as the word has become more of a metaphor. I'm using the term with its original intent. So system would be a much larger word, dealing with ways of viewing all phenomena. I've used artifact a lot to point out (as Herb Simon did before me) that one way of thinking about science is: as trying to understand phenomena by making models that give rise to similar phenomena, regardless of whether the phenomena is produced by nature or human artifacts (man made objects). Cheers, Alan *From:* Andrey Fedorov anfedo...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, April 30, 2010 7:35:14 PM *Subject:* [fonc] Systems and artifacts I've noticed the word artifact used in a similar sense as system, with no overly obvious distinction [1]. One that comes to mind is an artifact being something we're considering in relation to its human origins, and system being something we are considering in terms of finding an optimal representation. For example, we could consider TCP/IP an artifact if we're talking about its design, or a system if we're talking about studying its inherent properties [2]. Or is this off? Cheers, Andrey 1. The former, mostly in Brooks' The Design of Design. The latter, mostly in writings relating to VPRI's work. 2. Kay makes a similar distinction between invention/engineering and research/science here: http://computinged.wordpress.com/2010/04/23/alan-kay-on-hoping-that-simple-is-not-too-simple/#comment-2318 ___ 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] Reading Maxwell's Equations
John, et al I am interested in what you think are the better approach alternatives to handle complexity and size (etc), what criteria should apply and why one ranks higher than another. For example, should a language support both actors and be model driven? Is a mix of type inference and explicit typing with operators (like OCAML) better than extremely late binding, and for what? Should there be a hierarchy of syntax compatible languages, with different restrictions, say extremely late binding at the top, and fully typed and OS or device driver oriented at the bottom? (ie pick the right tool in the family, size of hand held screwdriver up to exchangeable bits for a power tool). Thanks for your interesting references and insights. Regards, Gerry Jensen ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
