On 22 Oct 2003 at 14:05, Steve Wampler wrote: > On Wed, 2003-10-22 at 10:54, Louis Kruger wrote: > > This problem seems like another example of why Unicon could benefit from > > references types. (seems like there have been a lot of these examples > > recently)
for a proc that returns a list, l := f(x) every x | y | z := pop(l) > Careful! Icon and Unicon have gotten along pretty well for years > without reference types. While I think it deserves more discussion, > it's not clear that most of the examples aren't self-fulfilling - > there may well be equally clean ways of addressing the same issues > using other approaches. Also note, as Clint said, that there are > any number of functional languages that are also successful w/o > reference types. True, but often oddly or slowly. After pondering the situation, I would prefer to do as much as possible to avoid the need for most references. Kazimir Majorinc's brilliant every (!L:=:x):=(if x=0 then 1 else 1.0/x) (which must NEVER FAIL after !L) could be done as (x := ` !L) := 1.0 / (x ` ~= 0) | 1 if x := ` y returned (the variable in this case) y. It could safely fail anytime, anywhere. > > Any suggestions for what actual syntax is possible for this? > > Perhaps the semantics should be discussed. > What should the behavior of the following be (also ignoring syntax > issues): <snip> > procedure g() > yref := &xref > *yref := &yref > write(*xref) this would be an error, but write(image(*xref)) should ideally give "ref(var xref)" > end > > There are reasons why functional languages don't like reference > types - they can be addressed, but it needs careful thought. > Languages like C and FORTRAN operate under a 'caveat emptor' > philosophy that isn't appropriate for languages like Unicon. Agreed. I recommend a very careful start, testing a very strict model; perhaps limiting references so they: can only reside in a variable can only point to an older or = variable in the same coexpression (usually &main) or (in)to a struct. (globals & statics are older than main's locals & etc.) => no way to point to a phantom. Will this be reasonable? Is this rule sufficient to make it safe? I like the implicit-ref type as in C++, but it has immutable ref's, created by declaration. IMHO this is not suitable for a language with generators. every x := ref(!L) do @x +:= 1 is at least of Icon's flavor. Using .x would imply auto-deref, unknown depth, because the Unicon runtime does .x willy-nilly. A reserved word ref would be much better, but may break old code (without any error message! x := ref ! L is already legal!). If y is a reference, x === y succeeds only if x := y @x === @y succeeds if x := y or x := copy(y) or x := ref(@y) I am still undecided about procedures with reference args. If not, procedure f(a:isref, b) would check calls. To avoid the need to call f(ref(x), y), we would need a 'procedure' that did not dereference its args; Icon calls this a function. function f( ` a,b); return @a +:= b ; end could generate an implicit a := ref(a) to begin f. We may need an implicit b := .b to prevent unintended side effects. I hope that users would use names that make it clear which ones are functions. ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
