These unicon/icon questions are of a most interesting nature.
- is there a case to change the default behavior of list(n,x)
and table(x) in unicon where x is a structure?
- is a mechanism to convert/coerce a structure into a generator
(e.g., associate something like !listvalue to a variable)
desirable?
First, I'll apologize for my earlier brief post - and only to the
icon list too. I'll excuse myself in that I'd just returned from
vacation, was rushed and didn't fully consider the breadth of the
discussion.
1. On the default behavior of list(n,x) and table(x). This goes
beyond a newbie problem. I've made the mistake when both tired
and rushed. Quickly corrected but embarrassingly "simple". (I can
only assume others have made the same error). But this suggests
the behavior is somehow counter-intuitive. As an old S*BOL
retread, I've found that Icon fixed the many foibles of its'
precursors. Icon attracted me because of it's intuitive
expression of the essential S*BOL semantics.
On the issue of what should the default behavior of list(n,x)
be? IMO the proposed copying behavior *could* be desirable. But
should it be the default? My gut said yes. But knowing that
even seasoned gut reactions can on occasion be spectacularly
wrong, I wondered if the current behavior is (a) ever used (b) at
all useful and (c) are there any surprises in waiting if unicon
makes such a change?
For tables the default bucket argument works. But does anyone
have a *useful* example using a list with a structure as a
default value? I expect something can be contrived but would
wash out on a (admittedly subjective) simplicity or elegance
test.
Consider:
x := list(3,list(2,0))
+--------+ +--------+ +--------+
| x |-------------->| ----------.------>| 0 |
+--------+ +--------+ | +--------+
| ----------. | 0 |
+--------+ | +--------+
| ----------+
+--------+
Every update changes the same list. Only operations like |||,
push, pop, sectioning, etc. will change this.
The suggestion of a run-time error is also interesting. Beyond
protecting newbies (and the tired), it's somewhat backward
compatible. If the behavior was truly needed, the error can be
trapped and continued. Elegant. The existence of code to
override that error would be like a neon sign in desert saying
something unnatural is about to happen. But, assuming nobody
finds the useful list example, would it make sense to only
implement this for list?
I tool a quick at the current IPL and found 921 lines with calls
to procedures with names ending in list. Of these only the
following seem
even close to interesting with two having the most unusual calls.
- gprogs/hb.icn:259: every !board := list(height, init_value)
- procs/colmize.icn:63: width := list(cols,minwidth)
* procs/ichartp.icn:505: retval := table(obj[[]])
- procs/lists.icn:855: lmaptbl :=
table(tdefault) # new mapping table
- procs/matrix.icn:83: every !M := list(m, x)
- procs/wifisd.icn:293: if size := \data_entries[name] then
lst := list(size, value)
* progs/scramble.icn:38: index:= table([])
Given the amount of discussion, some of the implications and
potential for change; the suggestion of developing library
procedures using the Godiva's 3 tier model for copying seems a
good place to start.
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.
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.
But what would this do to the underlying architecture of
icon/unicon,
- backtracking,
- expression bounding,
- other areas?
Another question is how would this affect the strong typing
inherent in Icon's syntax? While Icon's variables aren't
strongly typed its syntax is. String, numeric and structure
operations are strongly defined by operators. And to some degree
procedures (excepting for reassignment). Backtracking is also
generally syntactically clear.
In S*BOL there were deferred expressions (e.g.., E =
*ARBNO(ANY('ABC')) ). Please bear with me on this background
and I hope my point will become clear. (Any S*BOL inaccuracies
you can attribute to my lack of use and/or failing memory).
The evaluation of these was deferred until activated either
explicitly or implicitly. The most common use of these was to
construct patterns for pattern matching operations. One of the
language foibles was that knowing for certain when expressions
deferred and when they were activated. In my experience, this
was unclear to most programmers. This lead to excessive
deferring of expressions in many programs. It also created
problems with the pattern matching heuristics and was generally
'ugly'.
Icon reversed the design decision on this (and other foibles.
Although, these may actually have happened in SL5?). When the
entire scanning architecture was changed from the S*BOL/SL5 model
to the Icon model the core semantics of pattern matching
changed. Instead of building up a pattern using dereferenced
expressions, the semantics were built into the code structure in
the startlingly elegant form that we see today.
This main use of the old dereferenced expressions essentially
amounted to a pattern data type. Although, I don't believe it
was ever formally acknowledged that way.
Now, when Icon was being designed this dereferencing mechanism
was abandoned. I suspect there were many discussions over the
nature and implication of the change. It may have been that it
simply wasn't needed? Or there may have been more complex
concerns. By considering putting this back, the architects and
implementers must consider what side effects might be introduced
into the language? Once in, backtracking the decision will be
difficult.
Such a mechanism might provide a solution for the default value
of list and table? It would create other opportunities as well.
I suspect the amount of language design and research required to
evaluate this makes it a unlikely starter for now.
3. Other things to keep in mind:
- What problem were we solving anyway?
- Documentation errors and education are often overlooked when
trying to find a 'solution'.
- An old adage about small numbers of features and increasing
complexity and size fairly dramatically.
Something like 10-20% and 50% as I recall.
4. My take right now would be to (a) do nothing with the
builtins, and (b) pursue IPL functions to implement list(n,v,i)
and table(x,i). These can easily be used with wrapper procedures
to swap values with the builtins and transparently handle the
extra argument. This could even be done inside a package but it
wouldn't be available to the wider audience of Icon users.
5. This raises another question. Has anyone developed a
framework for IPL functions that can live in both icon and
unicon? By this I mean in cases where the code could be nicely
wrapped in a package for unicon but might still be useful in an
unwrapped form in Icon such as for extending procedures.
Thanks Marc, both Steve's, Clint, Dave, Ray, Taybin, Fredrico
David Gamey
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/unicon-group
