Dave Gudeman wrote:
>
> 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.
Yep, that pretty well rules out using co-expressions for this and is probably
close to what David Gamey also wants.
> 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.
Yep, another killer. Sometimes I wonder if it would have been
better (too late now!) to have a co-expression generate its results
and rely on limitation to control how those results are used. I think
(very fuzzily, though) that co-expressions actually preceded limitation
into the language, however.
> 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.
I had forgotten aobut c-expressions! Thanks for reminding me. The
behavior of c-expressions is very close to being a superior replacement
for co-expressions (a few programs might break, but I bet it would be
surprisingly few...)
I think Dave is right - this would be (have been?) a nice language feature,
especially if implemented as he suggests (if I had thought of it, I
probably would have implemented co-expressions that way to begin with).
Replacing co-expressions with c-expressions would likely be a net win, but I
suspect is more of a change than anyone is willing to do at this time...
I imagine c-expressions come *very close* to matching what David Gamely
is interested in.
--
Steve Wampler- SOLIS Project, National Solar Observatory
[EMAIL PROTECTED]
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/unicon-group
