Dear Peter, Thanks for this feedback concerning your goals. I really appreciate that you keep the community in the loop.
> - Simple and elegant VM, as easy to maintain as possible > - No target to JVM. We don't want to be limited by JVM limitations such as > expensive threads. > We should not try to compete with Java or Scala. Our role as researchers is > to try new ideas, not to copy other systems. I think I understand you rationale for saying this. Also, I am not really in the position to disagree, because I am only a user and not a developer of this system. Nevertheless, I am perhaps allowed to say that I regret this decision. I use Oz a lot because the combination of programming paradigms available in Oz meets very well my purposes. (I cannot see why anyone should think that Oz can look like a copy of any other system, even if based on the JVM or some similar effort.) Are you implicitly saying that considering the limited resources available you primarily aim at developing a system interesting for computer science researchers, while actual users, i.e., programmers developing with this system, are a secondary concern at best? Will we get more community support if that road is taken? > After the discussion on Lambda the Ultimate on the new Mozart VM At the discussion on LtU, many also defended the idea of using the JVM, or tried to see both sides. For example, Matt Hellige pointed out (snippet from a longer statement). > The JVM is a very impressive system, to be sure, and has lots of advantages. > [...] I suppose it may depend on the personal inclination of those involved: > if you want something minimal, self-contained and focused, and you want to > understand it all the way down, the JVM is almost certainly not for you. If > you care most about portability and industrial strength and you'd rather > invest time in the compiler than in the VM, the JVM may be a good fit. I am simply afraid that after the development of the new VM I will have a Mozart/Oz which is finally running on a 64-bit architecture (great!), but which is also severely cut down in terms of its programming environment. Mozart is a big system with a rich programming environment, which grew from an effort of many contributors. For example, what about the Tk interface and QTk, what about all the GUI tools (browser, inspector, explorer, system panel, debugger, profiler), what about the OS support (e.g., files, sockets, process control), what about Gump, what about ozmake etc. etc. etc. I assume that some elements of this environment must either be rewritten anyway or are lost by replacing the Mozart VM, regardless what road is taken for the VM. I only wonder, which road will help the Oz programming environment -- and thus users like myself -- more in the long run. > - Attach Gecode to this VM with glue layer (as were the plans for Mozart > 1.5.0 and started in Colombia) I very much hope this means that distribution/branching strategies can still be defined in Mozart. > - The original constraint system of Mozart is now outdated, we have to > step to a new one. > (nested computation spaces will disappear, but maybe we can replace > them by spaces "next to each other") Just to confirm: this means the end of constraint combinators as documented at http://www.mozart-oz.org/documentation/system/node44.html. I really liked using them for flexibility at times, but I could work around that in my applications by reducing flexibility. To conclude, I really really appreciate the work you plan to do in replacing the Mozart VM. I am only concerned about the implications for actual users of the resulting system. However, I guess I can always just keep using the old version (I am still using Mozart 1.3.2 at times, because parallel search was broken in Mozart 1.4.0). Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de On 10 Oct 2011, at 13:18, Peter Van Roy wrote: > Dear Mozart hackers, > > After the discussion on Lambda the Ultimate on the new Mozart VM, > I think we should go for the following: > > - Simple and elegant VM, as easy to maintain as possible > (Yves' original idea of no more tagged pointers) > - Attach Distribution Subsystem to this VM with glue layer (as it is > currently to the current VM) > - Attach Gecode to this VM with glue layer (as were the plans for Mozart > 1.5.0 and started in Colombia) > > With the following reflections: > > - Multicore execution will be done through the Distribution Subsystem. > (only coarse-grained parallelism, but this is ok since data-intensive > calculations are parallel) > - The original constraint system of Mozart is now outdated, we have to > step to a new one. > (nested computation spaces will disappear, but maybe we can replace > them by spaces "next to each other") > - No target to JVM. We don't want to be limited by JVM limitations such > as expensive threads. > We should not try to compete with Java or Scala. Our role as > researchers is to try new ideas, not to copy > other systems. So far, Mozart has played this role well, and we > should continue this role. > > If you all agree, we should get this show on the road as quickly as > possible. > > Peter > > _________________________________________________________________________________ > 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
