A threading interface would be very beneficial.
Other language support, being able to invoke a DLL/SO would be of tremendous use.
PVM/MPI is something I hadn't been thinking about.
The whole reference type discussion didn't sit well with me. It was much more than a semantics change. I think Michael hit the nail on the head with:
Michael Meehan wrote:
I think the suggestion of adding a reference type is a bad idea.With references do we somehow avoid needing to copy aggregates?
If the motivation is to create a capability for pass by reference --- if this is an efficiency consideration it doesnât make sense, as everything on the stack passed in the virtual machine is a descriptor of the same size anyway.
--- If it is so you can create a functional side effect to modify a variable local to another procedure be careful what you wish forWouldn't a class/package variable and methods be a clearer way to accomplish this?
(I recall some of the design decisions that were undone from Snobol to Icon. The gotcha's or what James Gimple called Snobol's Foibles. In particular the most dangerous and annoying were (1) variables defaulting to the null string and (2) unevaluated expressions. Tracking down errors in large programs because of variable name misspellings resulting in null strings being coerced into 0's or other forms was a huge problem that &null fixed. Create and coexpression semantics (even without their superior functionality) made far more sense than having a unary operator to prevent an expression from evaluating and cluttered the code often unnecessarily.)
Some aspects of the suggestions did seem intriguing and even useful, but I couldn't clearly see the price we'd pay for them. I am still left wondering if there is any useful middle ground here and what it might be. It is clear to me at least that this feature requires very careful evaluation. What is the real problem we're trying to solve here? Are there better ways to spend the effort?
If the motivation is not just to create pass by reference but also to be able to create aliases to non-aggregate types in Unicon I would ask why? Some language designers have gone to extreme lengths to remove this possibility from the language. (See Euclid)
Finally, it is antithetical to the nature of the Icon/Unicon languages for the programmer to âthink at this level.â Unicon variables are simply names that hold what you put into them. If we use these names in an l-value context they are still not bound to a fixed address in any traditional sense. We donât need a reference to hold the result of an allocation, as we donât do explicit allocation in the language.
If it is performance, then threads and other language support would provide huge potentials for performance improvements I'm not sure references would have the same benefit. Many serious performance problems I've seen in Icon/Unicon can be overcome by reworking the problem to use lists, records and other structures.
I for one have always treated Unicon/Icon/Snobol types as being mostly like pointers but without all the bad baggage. My understanding of them is clear and I am rarely surprised.
David
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
