David Gamey wrote:
>
> These unicon/icon questions are of a most interesting nature.
> ...
> - is a mechanism to convert/coerce a structure into a generator
> (e.g., associate something like !listvalue to a variable)
> desirable?
Isn't that exactly what co-expressions do?
> 2. On the question of being able to assign a generator to a value
> (or similar behavior). This would be a light weight version of a
> coexpression. I believe the proposition is far more complex.
co-expressions are pretty light weight, I think. it's only when one
starts using them as coroutines that they start getting "heavy"...
Of course, the word "create" isn't light and could be aliased to
a symbol.
> While many (most?) cases where I have used coexpressions fit this
> classification how truly valuable would this be? It could be
> - syntactically simpler,
> - more intuitive
> - optimized
I'd love to see examples of this. In some ways it sounds as
though what you're asking for is more of a macro facility, where
the meaning of the syntax is determined at the point of use
rather than the point of definition as it is with co-expressions.
I'm not sure anything beyond this wouldn't lead you right back
to co-expressions, given the constraints involved with backtracking,
expression bounds, scope, etc.
So I'm inferring (correct me if I'm wrong!) that this mechanism
could be thought of code-without-context (or "code-missing-some-
of-its-context") where the context is determined where the code is
evaluated. That would certainly be lighter than co-expressions, which
do carry context along with them.
Hmmm, would co-expressions do what you'd like if they were implemented
better? - they do carry more context than they need simply because there's
a simple implementation that way, but there's no inherent reason why that
context couldn't be reduced [in fact, that would be a generally good thing,
independent of the rest of this discussion!]
I'm guessing that they wouldn't because the "code-missing-some-of-its-context"
is the key - S4 deferred expressions take some of their context from their
point of evaluation - co-expressions don't.
> But what would this do to the underlying architecture of
> icon/unicon,
> - backtracking,
> - expression bounding,
> - other areas?
variable scope is another - if the expression uses a local variable,
what is its value outside that procedure? what if there is a global
variable with the same name, should that become part of the context
of the deferred expression? How does the translater decide what parts
of the expression should defer their context and which shouldn't?
(In the S4 deferred expression analogy, the pattern-matching context
was deferred - would that work with Icon's string scanning contexts?
How would that be made clear?
I think this could be useful, but will probably entail some restrictions
on what can be used in the "deferred" expression and definitely involve
some *careful* thought or you'll end up duplicating co-expressions..
Another, lesser, question might be: Are there situations where the use
of co-expressions allows their optimization? (That is, instead of a
new mechanism, might the context information available to the translator
allow co-expressions to provide more of what you want?)
The original intent of co-expressions was to provide a replacement for
S4's deferred evaluation mechanism. They "grew" because of issues with
backtracking, scope, etc. - at which point their ability to function as
coroutines became just a small step.
--
Steve Wampler- SOLIS Project, National Solar Observatory
[EMAIL PROTECTED]
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/unicon-group
