On Wed, 2003-10-08 at 10:19, Louis Kruger wrote:
> It seems to me that a new feature like this ought to be introduced in a
> way thats both flexible and backwards compatible. Here's one way to do it:
>
> Have all undefined variables default to a value specified by &undef. By
> default, &undef = &null, so existing code works as expected. However,
> &undef can be reassigned by the programmer. In addition, the semantics
> of &null are left alone.
>
> Introduce a new constant &bottom (the term is taken from ordered set
> theory) which compares "below" every value of every other type, so that
>
> &undef := &bottom
> every (!x>:=0) +:= 1
>
> would increment every positive value by 1, and also set undefined values
> to 1
>
> For completeless, a &top constant could be introduced as well (someone
> else suggested &omega)
>
> Yet another behavior could be achieved by introducing another form of
> &null, say for example, &nil, where &nil automatically converts to 0, or
> "", or [], or whatever the empty value is for the type expected by the
> given operator. Then, default behavior for undefined variables would
> work like in other languages such as Perl,
>
> &undef := &nil
> every !x :+= 1 increments every value by 1, whether it is previously
> defined or not.
>
> I'm sure someone could think of uses for other values &undef in some
> circumstances.
>
This worries me, I think it opens all sorts of issues that need to
be considered. In particular, there are scope issues. Consider,
for example:
&undef := &nil
every !x +:= f(a)
...
procedure f(a)
&undef := 1
...
return 1
end
If procedure f() is in a different package or library, it can be very
tricky figuring out what went wrong (and if f() calls g(), which calls
h(),..., which calls z() which sets &undef...).
I don't think I'm happy with the idea of 'globally-scoped' keywords
being used to implicitly alter the values of variables during
evaluation.
In fact, if the original problem (null lvalues in a generated sequence
of rvalues) is really a big problem [I haven't cursed that lack very
often, personally], I think I'd argue that adding a reference type (as
Charles wants) is a cleaner solution. Then (ignoring the syntax, which
I'm inventing out of whole cloth here), the problem can be handled as
in:
every validate(&!x) +:= 1
...
procedure validate(xref)
/@xref := 1
return xref
end
This puts a lot of flexibility in the hands of the programmer - for
example, the /@xref := 1 could just as easily be:
/@xref := big_complex_calculation_that_changes_with_time()
-Steve
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
