Re: [fonc] quasiquoting in maru
On Wed, Nov 27, 2013 at 11:07 AM, Andre van Delft andre.vande...@gmail.com wrote: Quasiquotes and string interpolation are being added to Scala; these don't seem to have the two drawbacks that you mentioned for E's design. [...] http://infoscience.epfl.ch/record/185242/files/QuasiquotesForScala.pdf Thanks Andre for your many links of which I copied but one. Scala quasiquotes look nice indeed, and seem to handle the common and simple cases very well, but they are not a general mechanism for arbitrary grammatical non-terminals, and they are not designed to nest without a lot of clumsy escaping. It seems to me they are not implicitly hygienic, either, but that's asking a lot. A more general approach for a language with a rich grammar with arbitrary many (and extensible) non-terminal types might be that of Racket's syntax-parse by Ryan Culpepper which has #`quasiquotations, or Jon Rafkind's honu syntax for Racket, which I believe has the same. I believe Dave Moon's PLOT may have something, too. In any case, it's possible to have better macros and quasiquotations in an infix language than E or Scala provides. I can't say at this point how to make it work in the context of maru and its extensible parsers, but the idea would probably be to add extra parametrization to the parsers, to allow for an optional escape up. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one. — Mark Twain ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] quasiquoting in maru
On Mon, Nov 25, 2013 at 10:27 AM, Aaron Burrow burrows.l...@gmail.com wrote: a few remarks on the semantics of quasiquoting, [...] High level design intent of maru's quasiquote would also be interesting. My guess would be that maru's quasiquote is somewhat buggy. Quasiquote is really difficult to implement right. I tried once, and failed to optimize the expansion in a way that handles ,@,@ then eventually fell back to closely following the reference implementation http://cliki.net/fare-quasiquote Also note that the semantics of quasiquote is underspecified in Common Lisp, as to how it interacts with the special syntaxes of various other data structure constructors (e.g. what is `#3(1 ,@'(2 3)) ? If you have other builtin or user-defined structure constructor syntaxes, how does it interact with quasiquoting?). I am not sure how Scheme or Clojure resolve the issue... probably not in a well-designed way. That's an area where indeed maru could improve on CL, by e.g. specifying a meta-quasiquote protocol for how quoting interacts with user-defined syntax. If you're interested, there's experimentation and design to do, and probably a paper to publish. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Computer programming is omnipotence without omniscience. — Prospero, as cited by Eliezer Yudkowsky ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] quasiquoting in maru
On Wed, Nov 27, 2013 at 12:10 AM, Darius Bacon wit...@gmail.com wrote:
For a quasiquote in Scheme that works like the Common Lisp one:
https://github.com/darius/sketchbook/blob/master/misc/quasiquote.scm
Alan Bawden's paper referenced from there gives the rationale.
Your implementation is so simple that I'd be happily surprised
if it got things like ,@, and ,@,@ processed correctly.
And it obviously doesn't handle #() and such.
Once again, see my http://cliki.net/fare-quasiquote
for a complete CL implementation.
Faré wrote:
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.
It might be worth looking at E's quasiliterals design for ideas there.
http://erights.org/elang/grammar/quasi-overview.html
It has some good ideas, but plenty of bad ideas too.
It makes ${0} ${1}, etc., without providing hygiene for cases where
users would like ${0} as an actual literal in the text (e.g. because
of recursive patterns). A kludgy solution along those lines would at
least use a cryptographic gensym to prevent collisions, and pass that
as argument in the expansion, and/or somehow escape the dollars in the
text. A real solution would have a notion of parametrized extensible
grammars, so that the escaping happens properly at all levels. A
formalization of this extension mechanism is what I'm seeking.
E also falls short by distinguishing quasiquoting for expressions and
patterns ${x} and @{x}. The two should be dual and disambiguation
should happen from context, and to get the equivalent of E's ${x} in a
pattern context should just be @{kwote(x)}, where (kwote x) is as in
traditional Lisp: (defun kwote (x) (list 'quote x)).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
There are three types of people in the world;
those who can count, and those who can't.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] Hacking Maru
Dear Ian, having exhausted my sources of procrastination in Common Lisp, I'm now just starting to look at maru seriously. Is there a mailing list specifically about technical details of maru, or is FoNC the thing? Stupid questions: * I see the gc reserves 8 bits for flags, but uses only 3. Is that a typo? Is that done with the intent of addressing that byte directly? On the other hand, given the opportunity for 5 extra bits, I'd gladly grab one for a one-bit reference count (i.e. is the object linear so far or not), and another one for a can-we-duplicate capability, if/when implementing a linear lisp on top of it. * The source could use comments and documentation. Would you merge in patches that provide some? * Speaking of documentation, could you produce an initial README, with a roadmap of which files are which and depend on which, and how to run the various tests, etc.? Maybe separating things in subdirectories could help. Or not. Many Makefile targets are obsolete. A working test-suite could help. * Is the idea that everyone should be doing/forking his own, CipherSaber style, or is there an intent to share and build common platform? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If it's not worth doing, it's not worth doing well — Donald Hebb If it's not worth doing right, it's not worth doing. — Scott McKay ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Simulator of Linear Lisp Machine written in Maru language
Dear Ilya, I've been wanting to experiment with a Linear Lisp in Maru for a long time. Do you have a mailing-list to discuss and/or public repository to work with? Regarding practical programming with Linear Types, see Jesse Tov's thesis at http://www.eecs.harvard.edu/~tov/pubs/dissertation/ Jesse also recommends reading about Nikhil Swamy's work on Fine and Fstar. http://research.microsoft.com/en-us/um/people/nswamy/papers/ And if you are into foundational theories, you could give a look at Computability Logic. PS: Sorry for a reply long in the making — I'm just out of a long procrastination period and ran out of excuses (having nailed the coffin on ASDF, a quick-build extension for it, and the Lisp-Interface-Library using that). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If you argue and rankle and contradict, you may achieve a victory sometimes; but it will be an empty victory because you will never get your opponent's good will. — Benjamin Franklin On Wed, Sep 18, 2013 at 4:46 AM, Iliya Georgiev ikgeorg...@gmail.com wrote: I would like to make a simulator of a Lisp Machine. If it is successful, then I will program a FPGA with Linear Lisp and use Lisp-like interpreter to execute programs over it. My main motivation is to be able to understand and change the system as I want. The system should be as simple as possible. The history of the ideas in computer science is used as a method of the research. The ideas of different LISP Machine theoretic models were found. They differentiate in the type of register or type of structure and the instructions. The Linear Lisp model seems encouraging for the purposes. It uses finite state machine with pointer register, data structure with unity reference counts (tree?) and omits the usage of garbage collector. [1] Also the interpreter for Linear Lisp is already created. So efforts in this direction will be saved. Maru language is proposed for the implementation of the simulator, because it is not bounded to its own structure. After this lengthy introduction I have two questions: 1. Is it possible to make data structure with unity reference counts in Maru? This is crucial for such a simulator. 2. Do you know of example that describes real finite state machine with pointer register? Most papers in this topic seems to be just theory. [2] References: 1. Publication on Linear Lisp theoretic model - http://home.pipeline.com/~hbaker1/LinearLisp.html 2. Pointer machine - http://en.wikipedia.org/wiki/Pointer_machine ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] LIL: CLOS reaches higher-order, sheds identity, and has a transformative experience
Dear FoNC addicts, I thought some of you might like this article I've sent to the International Lisp Conference 2012: LIL: CLOS reaches higher-order, sheds identity, and has a transformative experience http://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.html http://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.pdf The paper got accepted, and I'm looking for comments before sending the final version. I'm sure some of you have at least something to say about related work. The paper is about a data structure library I wrote in Common Lisp, Lisp-Interface-Library, using an Interface Passing-Style, where these interfaces could be described as objects without identity or state, manual type-classes, or detached class information. They combine parametric and ad-hoc polymorphism, and were used to develop both stateful and pure data structures, in a way that allows for automatic conversion from one style to the other. I believe that whichever language any of you is hacking right now might benefit from this style of library. PS: In case you happen to be around Boston, MA, I'll present the paper at the local Boston Lisp Meeting on October 4. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Gauss, when asked how soon he expected to reach certain mathematical conclusions, replied that he had reached them long ago, all he was worrying about was how to reach them! [Karl F. Gauss (1777-1855), German mathematician] ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Growing Objects?
On 14 October 2010 21:20, Casey Ransberger casey.obrie...@gmail.com wrote: The previous thread about testing got me thinking about this again. One of the biggest problems I have in the large with getting developers to write tests is the burden of maintaining the tests when the code changes. I have this wacky idea that we need the tests more than the dev code; it makes me wish I had some time to study prolog. I wonder: what if all we did was write the tests? What if we threw some kind of genetic algorithm or neural network at the task of making the tests pass? I realize that there are some challenges with the idea: what's the DNA of a computer program look like? Compiled methods? Pure functions? Abstract syntax trees? Objects? Classes? Prototypes? Source code fragments? How are these things composed, inherited, and mutated? I've pitched the idea over beer before; the only objections I've heard have been of the form that's computationally expensive and no one knows how to do that. Computational expense is usually less expensive than developer time these days, so without knowing exactly *how* expensive, it's hard to buy that. And if no one knows how to do it, it could be that there aren't enough of us trying:) Does anyone know of any cool research in this area? For the low-hanging fruits, see Programming by example. For the general case, search for (Solomonoff) Induction, and see notably recent work by Noah Goodman. If you're going to explore this area, be sure to come back to tell your experiences. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] I discovered a few years ago that happiness was something you put into life, not something you get out of it — and I was transformed. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Flight Data Recorders, etc. (was: [fonc] my two cents)
On 2 March 2010 10:18, John Zabroski johnzabro...@gmail.com wrote: 1. I am simultaneously interested in open, reflective, dynamically distributed and dynamically federated systems Nice way to put it. Welcome to the club! 3. Flight Data Recorders is a fancy way to say all software is a living system, and computer scientists suck at studying living systems, and programmers lack sufficient tools for repairing living systems 4. Flight Data Recorders biggest disadvantage is not mentioned: dealing with purity No purity needed. See Omniscient Debugging... http://www.lambdacs.com/debugger/ Note that the idea is old, and has been done in the 1980's in expert systems that could explain their decisions. ODB shows that the idea is applicable to JVM languages. 8. Compiler optimization vs. algorithms in general is a false dichotomy in a maximally open, maximally reflective system, and I'll claim anyone who thinks this dichotomy is real will not push themselves into an *extreme position* necessary to radically innovate So you have the ambition of writing a SSC that can transform bogosort into quicksort? Typed data access has never been a real problem, Talk to the millions of people who've seen their credit card or other data stolen because of a bug in a PHP site. http://xkcd.com/327/ I'm going to conclude by saying the three stumbling blocks are size, complexity and trustworthiness. Paying attention to all of Todd P's big problems just puts your focus on solutions-oriented thinking, rather than fundamentals-oriented thinking. Solutions are how you sell fundamentals. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] No matter what language you use, a Sufficiently Smart Compiler(TM) will be able to find an efficient implementation for whatever apparently difficult problem you specify. However, a Sufficiently Smart Compiler(TM) for arbitrary problems is itself an AI-complete problem. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: [Ometa] FPGA targets?
: Jecel Assumpcao Jr je...@merlintec.com The key thing is to have some model of parallelism which is used by the source code. If you try to extract automatically parallelism from normal application code you will just make things needlessly complicated for yourself. : Nathan Cain n...@inverse-engineering.com Precisely. You've hit the nail on the head. Most of the world is trying to shoehorn imperative specification into a mixed imperative/combinatorial environment, usually a heterogeneous one at that (cpu+fpga or cpu+gpu or even cpu+OtherArchCpu), and wondering why they are running into a semantics mismatch. AFAIK, the paradigms that fit are reactive and synchronous programming. In the last few decades, there have been plenty of successful reactive and/or synchronous programming systems with backends to C, VHDL, model checkers and theorem provers. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] A cuddle a day keeps the shrink away ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
