From: Kostas O. <ko...@re...> - 2004-12-22 23:08:48
|
On Wed, 22 Dec 2004 23:26:17 +0100, <pet...@xs...> wrote: > > I think C must remain a strong backend for Unicon. Of course, > embedded applications and apps that are otherwise resource-constrained > will benefit from this one the most. Optimisations in this area are > certainly welcome... I agree. The applications I have in mind are indeed the ones that are resource (speed-) constrained. However, I want to clarify that we are no= t simply talking about optimizations here. To the best of my knowledge, the (Un)I= con-C interface is, at this point, very rudimentary. One can only pass integer= s, reals, and strings as parameters of routines between Icon and C. I've written an extension = that allows passing arrays of integers and reals back and forth, and which seems to w= ork :-) but is not pretty. But there's much more work to be done. > However, it terms of usefulness to a more broad range of people, > having a Unicon.Net implementation will guarantee full compatibility > with other languages supported under .Net, as well as improved Windos > interface, since that OS is slowly shifting towards .Net-only upper > layers. Clearly, we don't want having multiple VMs that can not > interoperate (JVM, iconx, .Net). I don't really know that much about .net, but can't the same advantages b= e claimed about the Java platform? (Which I consider to be much more open than .net, by the way.) Also, on the subject of usefulness and compatibi= lity, there are a lot of C libraries out there that Unicon could use with some = work on the C interface. Same goes for Java, if that route were adopted. A different issue is the amount of work that would be involved in a .net = implementation. Again, I know very little about .net, but it seems to me that the necessa= ry work would be quite a bit more than what would be required for C. Finally, there is, at least for me, the whole issue about Windows and its= philosophy ... Kostas |