Hello, Yves - may we do a non-backwards compatible release with Mozart2? ie fix all the 'broken' bits in this fresh start. - how does one get oz to run on ARM etc? would we not use gcc just after scala bootstrap stage, instead use llvm and target ARM, then repeat compilation cycle till we get *.ozf compiler to run on ARM?
Sebastien and Yves - Thanks for the bytecode insight I really appreciate it. Kind regards Stewart On Mon, Feb 27, 2012 at 8:55 PM, Yves Jaradin <yves.jara...@uclouvain.be> wrote: > Le 27/02/12 12:09, Raphael Collet a écrit : >> >> Hi, >> >> On Fri, Feb 24, 2012 at 4:26 PM, Yves Jaradin <yves.jara...@uclouvain.be >> <mailto:yves.jara...@uclouvain.be>> wrote: >> >> If you did read this far, you are probably quite interested in the >> new VM and I have more good news. There is plenty of >> low-hanging-fruit tasks : >> - Basic arithmetic operations on small integers (we have addition >> but no others) >> - unit type (we have booleans but not unit) >> - Comparison of integers and atoms >> - Floating points (Stewart might have started something there) >> - Arrays >> - ... >> >> >> What about strings? I hope we will finally switch to unicode and give >> up the list of integers representation. I suggest to define an explicit >> type for (unicode) characters, and a specific (compact) implementation >> for strings. Using atoms might also be a good option for representing >> characters. Converting (implicitly or explicitly) between strings and >> list of characters should be the way to go, in my opinion. >> > Yes, the new implementation of atoms is already unicode. We will have to > keep the list of integers representation for backward compatibility but it > should be deprecated. Characters can be represented very efficiently (the > number of types isn't limited by tags anymore) in a similar way to small > integers (unicode needs 21 bits) and compact strings will be there (byte > strings were available before too). > I'm not very fond of implicit conversions but without them we'll have Oz > language visible changes which will need to be discussed and on which > everyone will have strong positions. (uniform state again, anyone?) > > >> The following things are probably not good to start with (but I hope >> you'll all become new VM gurus soon): >> - Records (because of arities) >> - Unification >> - Spaces and Logic/Constraint Programming >> - Distribution >> >> >> My advice: avoid early optimizations of variables. This was the major >> source of bugs in the former VM, and it made maintenance and evolution >> extremely difficult. > > > This time, it's my turn to ask questions ;-) > What kind of optimizations should we avoid? Things such as optimizing > variables without suspensions? or kinded CP variables? the new VM is > designed such that access to nodes are quite insulated from the actual > representation but you probably have something specific in mind. > > >> >> For the latter, it would be nice to have Oz ports as the only entity >> with native distribution support. One could have a mechanism to >> "delegate" any entity operation to another entity (an Oz procedure or >> object, for instance), and the latter would implement all necessary >> protocols for full distribution. Distributed operations are few: read, >> write, send, bind, update. The remaining bit is the marshaling and >> distributed garbage collection. This could leverage existing work on >> distribution: one could implement a DHT system only with ports only, and >> define the distribution layer on top of it, all in Oz! >> > > Where did you find that mind-reader? How did you tune it to my brain? That's > exactly how I intend to do it in the first place!, moving things to C++ > later and only when needed for performance. > >> Cheers, >> Raphael >> >> > Yves >> >> >> >> _________________________________________________________________________________ >> mozart-hackers mailing list >> mozart-hackers@mozart-oz.org >> http://www.mozart-oz.org/mailman/listinfo/mozart-hackers > > > _________________________________________________________________________________ > mozart-hackers mailing list > mozart-hackers@mozart-oz.org > http://www.mozart-oz.org/mailman/listinfo/mozart-hackers _________________________________________________________________________________ mozart-hackers mailing list mozart-hackers@mozart-oz.org http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
