--------------------------------------------
Concerning the suggestion for adding a reference type:
I think the suggestion of adding a reference type is a bad idea.
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 for
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.
At any rate if you want to see how to add a new type see Appendix F of
http://www.cs.arizona.edu/icon/ftp/doc/ipd261.pdf
<http://www.cs.arizona.edu/icon/ftp/doc/ipd261.pdf>
Concerning the discussion about adding threads --- this is something I am
working on âoff-lineâ from the group. I will get a trial balloon implementation
put together an then bring it to the group to look over at which point it could be
incorporated/modified or just remain a dialectic variant.
Concerning adding PVM support (and/or MPI)--- this is something I have been
thinking about doing for quite some time. Yes, it would be far easier than adding
threads to the language but it is a totally different resulting capability. Both
would ultimately be where we need to be.
Concerning Uniconâs interactions with other languages --- Good point. This
is a somewhat weak area relying on loadfunc to accomplish this. I would point out that
we do have XML-RPC working so that is another way you can have a Unicon program call
functions written in other languages. Would be neat if we had an Interfaces class the
sole purpose of which would be to provide standardized internal type representation
translations between Unicon and other languages to make it easier to marshal
parameters for a foreign language call.
jmm
׊Ë)¢{(ç[É*^yÔj»X¢êË{±šl6Œº)]jw]z™hÉi±g›±êï‰Ç~ŠË{±Â+aiúÞx5C²‡íÁÞ+_®‰ˆÀ‰É
£m¶ŸÿiÛ(±ÙÜoÚv'ußš–Z ‰ÝøßÊ)rXœ‘Iâr‰à©™¨¥Šx%ŠËTž'(ž
èb²Û,¢êÜyú+éÞm¦Ïÿ–+-²Ê.Ç¢¸ ë–+-³ùb²Ø~îž'(ž
èº
