Many years ago when I was at Arizona working on the Icon project, we
came up with the something that may be what you are suggesting. The
general idea was that we wanted a generalization of the snobol4 pattern
data type that would make full use of Icon's expression evalutation
mechanism. Coroutines were close to what we wanted but they had two
weaknesses: first, consider a code fragment like (my apologies if the
syntax is off, it's been a long time...)
p1 := create (digits := tab(any(&digits)))
p2 := create (=digits)
s ? @p1 & tab(any(~&digits)) & @p2
the intent of this code fragment is to match a single number in two
places. However what this does is cause an error when you try to match
p2 because the variable "digits" in p2 is _not_ the same as the variable
"digits" in p1, it is a new variable with the value &null.
Second, consider
p1 := create (write(tab(find("abc"))))
s ? every @p1
the intention of this is probably the same as
s ? every write(tab(find("abc")))
but it doesn't work since the @ operator only produces one result.
What we came up with was a variant of coexpressions that would share the
local environment with the procedure in which it was created and we had
a new operator that made it generate results. Ken Walker implemented it
and wrote a paper on it. I don't recall the name of the paper but the
new facility was called "c-expressions". I thought it was quite
successful but it had a weaknesses that kept it from making it into
standard Icon, basically that it requires procedure environments to be
heap-allocated. If you do this for all procedures it causes a
performance hit for all programs, not just those that use c-expressions.
I felt, and still do, that it would be practical to optimize this so
that you only heap allocate a part of the environment, only those local
variables that occur in a create statement. These variables would be
given a special class, not "global" or "local", but "heap", and would be
accessed by a special virtual machine instruction. This would have no
(or very little) effect on programs that do not use c-expressions.
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/unicon-group
