Le 27/02/12 12:09, Raphael Collet a écrit :
Hi,
On Fri, Feb 24, 2012 at 4:26 PM, Yves Jaradin <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
_________________________________________________________________________________
mozart-hackers mailing list [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
