Qi reborn for mobile devices
in [Lisp]
|
From: Raffael Cavallaro on 20 Jan 2010 11:13 On 2010-01-20 11:11:59 -0500, Raffael Cavallaro <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> said: > With respect, Hans Boenm would beg to differ: <sigh> that's Hans Boehm of course... -- Raffael Cavallaro
From: Mark Tarver on 20 Jan 2010 13:21 On 20 Jan, 16:13, Raffael Cavallaro <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: > On 2010-01-20 11:11:59 -0500, Raffael Cavallaro > <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> said: > > > With respect, Hans Boenm would beg to differ: > > <sigh> that's Hans Boehm of course... > -- > Raffael Cavallaro I skimmed this paper while cooking. Thankyou for this. What Hans Boehm says is 1. Concurrency, threads and multicore must be designed into the compiler from the beginning. They cannot be added in a library. 2. That in a language like C, layering these things onto a language designed for serial execution can result in programs with unpredictable behaviour. I'd agree with both of these things. Most of Boehm's toxic examples come from mixing concurrency with destructive operations, which, IMO, is a recipe for real trouble. I think that 1. is more relevant to Carl (so I copied the paper to him) because what I am doing is specifying a virtual language that is mapped onto existing ones. I am not writing the compiler myself. So the question I face is not 'How should K-Lambda implement threads?' but rather 'In view of the existing state of leading platforms wrt threads and multicore, what is the most sensible instruction set to choose (if any) which allows K-lambda to be easily mapped to a multicore, multithread language?" Now it may be, and I have to establish by examination, that there is no obvious instruction set or that the current state of play is one of confusion. Certainly CL is itself in a process of transition with various platforms offering threads and some not (as of 1 year ago). This will take time to assess. So pragmatically, in terms of priorities, it makes sense to begin with aspects that are less contentious. This is not to say that threads and multicore are unimportant of course. This is just a methodological point. Mark
From: D Herring on 20 Jan 2010 16:06 Mark Tarver wrote: > On 20 Jan, 16:13, Raffael Cavallaro > <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: >> On 2010-01-20 11:11:59 -0500, Raffael Cavallaro >> <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> said: >> >>> With respect, Hans Boenm would beg to differ: >> <sigh> that's Hans Boehm of course... >> -- >> Raffael Cavallaro > > I skimmed this paper while cooking. Thankyou for this. > > What Hans Boehm says is > > 1. Concurrency, threads and multicore must be designed into the > compiler from the beginning. They cannot be added in a library. > > 2. That in a language like C, layering these things onto a language > designed for serial execution can result in programs with > unpredictable behaviour. > > I'd agree with both of these things. Most of Boehm's toxic examples > come from mixing concurrency with destructive operations, which, IMO, > is a recipe for real trouble. (Un?)fortunately, the physical world is built on destructive reuse of materials. Have you considered PCLSRing? http://fare.tunes.org/tmp/emergent/pclsr.htm - Daniel
From: Mark Tarver on 20 Jan 2010 17:42 On 20 Jan, 21:06, D Herring <dherr...(a)at.tentpost.dot.com> wrote: > Mark Tarver wrote: > > On 20 Jan, 16:13, Raffael Cavallaro > > <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: > >> On 2010-01-20 11:11:59 -0500, Raffael Cavallaro > >> <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> said: > > >>> With respect, Hans Boenm would beg to differ: > >> <sigh> that's Hans Boehm of course... > >> -- > >> Raffael Cavallaro > > > I skimmed this paper while cooking. Thankyou for this. > > > What Hans Boehm says is > > > 1. Concurrency, threads and multicore must be designed into the > > compiler from the beginning. They cannot be added in a library. > > > 2. That in a language like C, layering these things onto a language > > designed for serial execution can result in programs with > > unpredictable behaviour. > > > I'd agree with both of these things. Most of Boehm's toxic examples > > come from mixing concurrency with destructive operations, which, IMO, > > is a recipe for real trouble. > > (Un?)fortunately, the physical world is built on destructive reuse of > materials. > > Have you considered PCLSRing?http://fare.tunes.org/tmp/emergent/pclsr.htm > > - Daniel- Hide quoted text - > > - Show quoted text - I will pass this on to Carl. I did think of OSes as a model in this context. I have looked at threads in Python (not so keen) and LispWorks and the latter have done a very nice job; very much the way I would expect it it be done. However at this point I must call a close, because I need to retire into my cave and make good on my commitment to my end of the project. I will return at the end of next month with a self-compiling Qi generating proto-K-lambda and a canonical procedure for porting Qi to Python/Clojure/NewLisp/Scheme etc. Mark
From: raould on 28 Jan 2010 19:46
On Jan 20, 8:13 am, Raffael Cavallaro <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: > On 2010-01-20 11:11:59 -0500, Raffael Cavallaro > <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> said: > > > With respect, Hans Boenm would beg to differ: > > <sigh> that's Hans Boehm of course... > -- > Raffael Cavallaro oh, here i thought it was his shorter double-ganger. :-) |