Andreas Rossberg wrote:
> Yes, technically you are right. But this makes a pretty weak notion of
> mutability. All stateful data structures had to stay within their
> lexical scope, and could never be passed to a function.
Not really. The way Hermes handles this is with destructive assignment.
Each variable holds a value, and you (almost) cannot have multiple
variables referring to the same value.
If you want to assign Y to X, you use
X := Y
after which Y is considered to be uninitialized. If you want X and Y to
have the same value, you use
X := copy of Y
after which X and Y have the same value but are otherwise unrelated, and
changes to one don't affect the other.
(As almost an aside, the non-scalar data structures were very similar to
SQL data tables.)
If you declare (the equivalent to) a function, you can indicate whether
the paramters matching the arguments are passed destructively, or are
read-only, or are copy-in-copy-out. So you could declare a function, for
example, that you pass a table into, and if it's marked as a read-only
parameter, the compiler ensures the callee does not modify the table and
the compiler generates code to pass a pointer. One could also mark a
variable (for example) as uninitialized on entry, intialized on return,
and uninitalized on the throw of an exception, and this could be used
(for example) for the read-a-line-from-a-socket routine.
The only value that came close to being shared is an outgoing connection
to a procedure; the equivalent of the client side of a socket. For
these, you could make copies, and each copy would point to the same
receiver. The receiving process could change over time, by passing its
end of the socket in a message to some other process (live code
upgrading, for example).
Since everything could be passed as part of a message, including code,
procedures, tables, and "inports" and "outports" (the ends of sockets),
I don't see that it had any problems with first classness.
> OK, if you prefer: it is an aspect of first-class mutability - which is
> present in almost all imperative languages I know. :-)
I disagree. It's entirely possible to make sophisticated imperitive
languages with assignment and without aliasing.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
--
http://mail.python.org/mailman/listinfo/python-list
