Anonymous user
Icon+Unicon/Intro: Difference between revisions
m
→General Language References
m (→Contractions) |
|||
| (80 intermediate revisions by 4 users not shown) | |||
Line 4:
Some of the sections should be referenceable from code tasks.
=== Books, Technical Reports, Newsletters, and Other Documentation ===
==== General Language References ====
These are general language references.
===== Unicon =====
* [http://unicon.org/book/ub.pdf Book: Programming with Unicon 2nd edition; Jeffrey, Mohamed, Gharaibeh, Pereda, Parlett - note also documents details of the Icon Programming Library]
* [http://unicon.org/utr/utr8.pdf Unicon Language Reference]
===== Icon =====
* [http://www.cs.arizona.edu/icon/ftp/doc/lb1up.pdf Book: The Icon Programming Language, 3rd Edition; Griswold and Griswold]
* [http://www2.cs.uidaho.edu/~jeffery/icon/humanists/humanist.pdf Book: Icon Programming for Humanists; Corré]
* [http://www.tools-of-computing.com/tc/CS/iconprog.pdf Book: Icon Programming Language Handbook by T.W. Christopher]
* [http://www.mitchellsoftwareengineering.com/icon/icon.sli.pdf Presentation: Fundamentals of Icon Programming; Mitchell]
==== Articles, Newsletters ====
Excellent sources of programming insight.
* [http://www.cs.arizona.edu/icon/analyst/contents.htm Newsletter: Table of Contents for the Icon Analyst from 1990-2001] discussing advanced Icon programming and [http://www.cs.arizona.edu/icon/analyst/ia.htm Archived issues]
* [http://www.cs.arizona.edu/icon/inl/inlx.txt Newsletter: Table of Contents for the Icon Newsletter from 1979-2000] discussing Icon programming and [http://www.cs.arizona.edu/icon/inl/inl.htm Archived issues]
* [http://unicon.org/generator/ Newsletter: Archived issues of the Generator from 2004-2005] discussing Unicon programming
==== Programming Libraries ====
* [http://www.cs.arizona.edu/icon/library/ipl.htm Code: The Icon Programming Library and index]
* [https://tapestry.tucson.az.us/twiki/bin/view/UniLib/WebHome Code: The Unicon Library]
* [https://tapestry.tucson.az.us/twiki/bin/view/Main/WebHome Code: The Tapestry TWiki examples of Icon and Unicon programs]
==== Graphics, Network Messaging, Threads, Patterns, etc. ====
These represent extensions that have been integrated into the core langauge(s).
* [http://www.cs.arizona.edu/icon/ftp/doc/gb1up.pdf Book: Graphics Programming in Icon; Griswold,Jeffery, and Townsend]
* [http://unicon.org/utr/utr6b.pdf An IVIB Primer (Visual Interface Builder, UTR6b)]
* [http://unicon.org/utr/utr9b.pdf Unicon 3D Graphics User's Guide and Reference Manual (UTR9b superseding UTR9a)]
* [http://unicon.org/utr/utr10.pdf Debugging with UDB (UTR10)]
* [http://unicon.org/utr/utr12.pdf Ui: a Unicon Development Environment (UTR12)]
* [http://unicon.org/utr/utr13.pdf The Unicon Messaging Facilities (UTR13)]
* [http://unicon.org/utr/utr14.pdf Unicon Threads User's Guide and Reference Manual (UTR14)]
* [http://unicon.org/utr/utr18.pdf Pattern Matching in Unicon (UTR18)]
==== Implementation ====
* [http://www.cs.arizona.edu/icon/ftp/doc/ib1up.pdf The Implementation of the Icon Programming Language; Griswold and Griswold]
** [http://www.cs.arizona.edu/icon/docs/ipd112.htm Report: IPD112, Supplementary Information for Version 8]
** [http://www.cs.arizona.edu/icon/docs/ipd239.htm Report: IPD239, Supplementary Information for Version 9]
** [http://www.cs.arizona.edu/icon/ftp/doc/ipd261.pdf Report: IPD261 Icon's run-time implementation language]
* [http://unicon.org/book/ib.pdf Book: The Implementation of Icon and Unicon: a Compendium; Jeffery]
* [http://unicon.org/utr/utr5b.pdf The Implementation of Graphics in Unicon Version 12 (UTR5b)]
== Icon and Unicon Differences ==
[[Icon|The Icon Programming Language]] was the successor of a series of non-numeric languages including
Over the years various improvements, extensions, and experimental variants were added including a platform independent graphics interface, IDOL (an object oriented pre-processor), MT Icon (a Multi-Threaded variant), Jcon (an implementation in Java), and others. And while the graphics interface was integrated into Icon, many of these variants were not.
[[Unicon|The Unicon Programming Language]] integrated a number of these extensions into a single variant of Icon. Unicon includes object-oriented support, improved system interfaces, messaging and data base interfaces. Additionally, a number of syntactic improvements to the language and semantic extensions to some functions have been implemented. Because of this Unicon isn't completely a superset of Icon.
The differences between these language dialects are elaborated on later in this document (see [[Icon%2BUnicon/Intro#Appendix_A_-_Icon_and_Unicon_Differences_.28Details.29|Appendix A]]).
== Variables, Data Types, and Structures ==
Line 148 ⟶ 197:
Files and windows (mutable) allow Icon/Unicon to interface with the operating system. Operations on files and windows have side effects and they are considered mutable. Sockets and pipes are also implemented as "files".
=== Keywords ===
Icon and Unicon has a list of special variables known as keywords. Syntactically, keywords are variable names preceded by an &.
Keywords can be used to inquire about the current state of the program, as constants, and to modify the operation (tracing and error control). For a list of keywords see [[Special_variables#Icon_and_Unicon]].
== Operators and Procedures ==
Line 178 ⟶ 232:
Icon/Unicon performs implicit type conversions (called coercion) where it makes sense to do so. At the same time dangerous coercions are disallowed. Details of these coercions are covered under the topic of [[Icon+Unicon/Intro#DataTypes|Data Types]]. Where a coercion is not possible, a run-time error is generated.
=== Lists of Operators ===
In the lists below the following represent data by type:
: x - anything
: s - string
: n - numeric
: i - integer
: c - cset
: S - set (or cset)
: C - co-expression
: v - variable
==== Assignment and Control Operators ====
<lang Icon> v := expr # assignment
v op:= expr # augmented assignment (see below)
v :=: v # swap
v <- expr # conditional assign
v <-> v # reversible swap</lang>
|x # repeated alternation
x | x # alternation
x \ i # limit generation to i results</lang>
==== Unary ====
<lang Icon> !x # generate elements
/x # null test
\x # non null test
+n # number (forces conversion)
-n # negate number
=s # tab(match(s))
*x # size
.x # dereference to value
?x # random element/value
~c # cset complement
^ # regenerate co-expression</lang>
==== Binary (and Augmented) ====
<lang Icon> n ^ n # power
n * n # multiplication
n / n # division
n % n # modulus
n + n # addition
n - n # subtraction
S ** S # intersection
S ++ S # union
S -- S # difference
n = n # equal
n ~= n # unequal
n < n # less than
n <= n # less than or equal
n > n # greater than
n >= n # greater than or equal
s == s # equal
s ~== s # unequal
s << s # less than
s <<= s # less than or equal
s >> s # greater than
s >>= s # greater than or equal
x === x # equivalent
x ~=== x # not equivalent
s ? expr # scanning
x @ C # activate (x optional)
s || s # string concatenation
L ||| L # list concatenation
x & x # conjunction</lang>
The operators above may be used in augmented form with normal assignment (i.e., x1 op:= x2; short for x1 := x1 op x2) . Many of these are common and natural, such as any of the mathematical group, concatenation, and comparisons for sorting. And the most common uses will be building results inside loops or scanning operations. Some of the examples include:
<lang Icon> while x1 +:= x2 # accumulation
while x1 *:= x2 # product
while S1 ++= S2 # builds a set/cset
while x1 @:= C # repeatedly call a co-expression building on its argument
while s1 ||:= s2 # build a string
while L1 |||:= L2 # build a list
while x1 <:= x2 # find maximum
s1 ?:= expr # replaces string subject</lang>
Some others are less obvious, such as:
<lang Icon> if lastx ~===:= x then ... # do work and remember when something changed</lang>
Others are obscure or even a bit baffling, such as:
<lang Icon> x1 ===:= x2 # obscure x1 := x1, can this be more that a no-op?
s1 ==:= s2 # ensures arguments are both strings (assigns but no value change)
n1 =:= n2 # numeric version of above
x1 &:= x2 # x1 := x2 unless x1 or x2 fails</lang>
Note that some documentation indicates x1 |:= x2 exists, but it isn't implemented at this time.
== Program Flow and Control ==
Line 253 ⟶ 400:
====suspend expr====
Suspend is semantically similar to 'return' with the exception that it sets up the possibility of producing additional results if needed. Rather than terminating the procedure as return does, suspend returns a result while leaving the procedure in suspension in the event additional results are needed. A suspended procedure will resume at the next point in the code. This capability is built directly into the run time rather than being an artificially constructed behaviour provided by Python or C#'s use of the 'yield' keyword. Every and all expressions may suspend or be involved in a suspending expression without any effort. Behaviorally this is closer to Prolog which also supports backtracking as a core part of the language. If the ''expr'' is capable of yielding more than one result, then suspend (if driven) will progressively yield all of those values. If the expression fails, execution continues within the procedure until the next suspend, return, or fail.
A procedure can contain several uses of ''suspend'' and it's quite reasonable for the procedure to execute many of them in any chosen order.
=== Selection Controls / Control Structures ===
All Icon and Unicon expressions, including control structures, yield results or signal failure. (Text from [[Conditional_structures#Icon_and_Unicon|Conditional Structures]]).
==== if then else ====
Icon/Unicon has an if then else expressions. Like many languages the else is optional. The
<lang Icon>
else
expr2</lang>
==== case of ====
The first successful selection expression will select and evaluate the specific case.
<lang Icon>case expr0 of {
expr3 : expr4
default: expr5
Note that expr1 and expr3 are expressions and not constants and it is possible to write expressions such as:
<lang Icon>case x of {
f(x) | g(x)
s(x) & t(x) : expr4
default: expr5
}</lang>
====Compound expressions (blocks)====
In the examples below, multiple expressions can be grouped as in:
<lang Icon>{
expr1
expr2
expr3
}</lang>
Which is equivalent to this:
<lang Icon>{expr1; expr2; expr3}</lang>
For example the following, which will write 4, looks strange but is valid:
<lang Icon>write({1;2;3;4})</lang>
The value of a compound expression is the value of the last expression in the block.
====Alternation====
Alternation of expressions yields a value for the first succeeding expression.
<lang Icon> expr1 | expr2 | expr3</lang>
====Conjunction====
Conjunctions yeild the value of the final expression provided all the previous expressions succeed.
<lang Icon> expr1 & expr2 & expr3</lang>
Alternately, conjunction can be written thus:
<lang Icon> (expr1, expr2, expr3)</lang>
====Conjunction, yielding a different result====
The alternate form of conjunction can be modified to produce a different result (other than the last)
<lang Icon> expr0(expr1, expr2, expr3)</lang>
For example:
<lang Icon> 2(expr1, expr2, expr3)</lang>
Yields the value of expr2 if all of the expressions succeed.
<br>A more complicated example showing non-constant expressions:
<lang Icon> f(expr1)(g(expr1)(expr3,expr4,expr5))</lang>
Note: if expr0 yields a value of type 'procedure' or 'string' the appropriate procedure (or operator) is invoked.
=== Looping Controls ===
Line 291 ⟶ 466:
====until====
Until will loop
====every====
The every clause is often used with the ternary operator to-by. Because to-by is an operator it can be combined in interesting ways with other operators or itself. For more examples, see [[Loops/For_with_a_specified_step#Icon_and_Unicon|Loops with a specified step]].
====next====
Skips to the beginning of the next loop. Restarts the enclosing loop. The conditional on the loop is evaluated as normal.
====break expr====
Break is used to break out of or exit from one or more enclosing loops. By default value of ''expr'' is ''&null''.
<lang Icon> x := while expression1 do {
...
Line 330 ⟶ 507:
<lang icon> runerr(errnumber, errorvalue) # choose an error number and supply the offending value</lang>
===
Co-expressions are an extremely powerful mechanism for program flow control that provide parallel execution. Consequently, co-expressions facilitate flows that can be radically different from what would normally be expected in procedural languages. Understanding, really understanding at a gut level, how these works comes with experience.
Among other uses, co-expressions can be used to implement:
* co-routines
* programmer defined control objects (PDCOs)
* result sequences
* exception mechanisms
* closures
* pipeline flows
Some characteristics of co-expressions:
* They encapsulate their working environment. They will have their own copies of local variables. They can maintain their state separate from their caller.
* Mutable local variables are still subject to side-effects if the objects they refer to are modified.
* They often have multiple entry points: the initial entry point and subsequent transfer points.
* Transfer points bind 'calling entry' and 'return' at one location in the code.
* They may need to be primed or started in order to get them to a transfer point.
* Arbitrary numbers of co-expressions may be run in parallel.
* Flows between co-expressions don't need to be hierarchical.
And while the original motivations for co-expressions was to facilitate co-routine calling flows, many of the solutions that use them do so to take advantage of these other characteristics.
==== Co-Expression Articles and References ====
Steve Wampler's "Fun With Co-Expressions" articles in The Generator
* [http://www.unicon.org/generator/TheGeneratorVol1No1Letter.pdf "Fun With Co-Expressions, part 1"]
* [http://www.unicon.org/generator/v2n1.pdf "Fun With Co-Expressions, part 2"]
* [http://www.unicon.org/generator/v2n2.pdf "Fun With Co-Expressions, part 3"]
Other articles
* [http://www.drones.com/coexp/ Shamim Mohamed's article on co-expressions]
==== Example: Function Composition ====
The following Unicon example is taken from the Rosetta Code task [[Function_composition#Unicon|function composition]] and uses a co-expression in a very procedural way.
<lang Unicon>
g := compose(sqrt,abs)
h := compose("-",g)
h(-49)
</lang>
<lang Unicon>
procedure compose(fL[]) #: compose(f1,f2,...) returns the functional composition of f1,f2,... as a co-expression
...
fL := reverse(fL) # reverse and isolate from mutable side-effects
cf := create { saveSource := &source # don't forget where we came from
repeat {
x := (x@saveSource)[1] # return result and resume here
saveSource := &source # ...
every f := !fL do x := f(x) # apply the list of 'functions'
}
}
return (@cf, cf) # 'prime' the co-expr before returning it
end</lang>
Explanation:
* '''compose''' is called as a normal procedure and returns a composite function as a co-expression ('''cf''').
* When it returns '''cf''' it first 'activates' or 'primes' it by means of '''@cf''' the co-expression which executes up to the first transfer point '''x := (x@saveSource)[1]''' where the co-expression transfers back to its caller to wait for input.
* The co-expression is now primed and ready for use .
* When the composed functions '''h''' and '''g''' are 'called', execution resumes at the transfer point with '''x''' taking on the value transmitted from its caller (a list).
* ''Note: we don't use the calling syntax:'' '''x := (saveSource(x)[1]''' to transfer back because this would force the use of a '''h(x)[1]''' wherever the composed function is called.
* Because this example acts like a traditional procedure and can be nested it is important to save the callers identity so we can return correctly. Clearly, arbitrarily complex transfer flows are possible here.
* After completing the core of the procedure (apply) the co-expression cycles and waits for another value. There is no obvious '''return''' or completion step. This co-expression never terminates and never needs to be refreshed.
== Contractions ==
Icon/Unicon have a rich set of [[Icon%2BUnicon/Intro#Binary_.28and_Augmented.29|augmented operators]] operators which when combined with the fact that all successful expressions produce values makes possible contractions. These appeal of these is somewhat a question of style and if taken to extremes there is also the possibility of being overtaken by one-liners. Having said that Icon/Unicon contractions are hardly in the same league as those of [[APL]] or [[J]]. A number of examples are presented below.
These examples initializes sum and adding all the contents of arglist.
Line 340 ⟶ 579:
sum := 0; every sum +:= !arglist do something() # ; splice
every (sum := 0) +:= !arglist do something() # a common contraction, iteration begins at the !
while (sum := 0) +:= !arglist do something() # an error. while will only get the first result</lang>
More examples of initialization in every loops:<lang Icon>every put(L := [], !X) # creates a empty list before populating it
every (s := "") || !S # create a null string before appending</lang>
Examples of using program control structures in expressions:
<lang Icon> (if i > j then i else j) := 0 # sets the larger of i and j to 0
d := if a > b then a-b else b-a # sets d to the positive difference of a and b
x := case expr of {
1: "Text 1"
Line 353 ⟶ 596:
default: "Undefined text"
} # sets x to a string based on the value of expr</lang>
The following may vary well be the most common contraction used in Icon/Unicon, initially assigning a value.
<lang Icon> if /x then # if x is null
x := value # set it
...
/x := value # contraction of the above
/x[y] := value # contraction using a table or list element</lang>
The following contraction can be used to do work in a conditional control structure. It takes advantage of the fact that comparison operators return results or fail. The only caveat is that the rest of the expression must not 'fail'. Note also this will not work with 'every'.
<lang Icon>while m > 0 do { # separate condition and statement
x := m + b
...
}
while x := (0 < m) + b do { # contraction
...
}</lang>
Deciding on the level of contraction is an art and, like any art form, easy to abuse. For example, the following procedure (from the Van de Corput Sequence task solution):
<lang Unicon>procedure vdc(n, base)
e := 1.0
result := 0.0
while result +:= 1(((0 < n) % base) / (e *:= base), n /:= base)
return result
end</lang>
already contains a number of contractions. Pushing this well beyond the bounds of
human decency yields:
<lang Unicon>procedure vdc(n, base)
every ((e:=1.0, result:=0) +:= |((0 < 1(.n,n/:=base))%base/(e*:=base))) | return result
end</lang>
This is probably only lovable by J programmers.
=== An Ugly Example ===
The following procedure "IsFilled" was taken from the [[Sierpinski_carpet#Icon_and_Unicon|Sierpinski Carpet task]]:<lang Icon>procedure IsFilled(x,y). It has the benefit of being clear. It makes use of only a few natural contractions, augmented division and chaining of comparison operators.
while x ~= 0 & y ~= 0 do {
if x % 3 = y %3 = 1 then fail
x /:= 3
y /:=3
}
return
end</lang>
We can transform this. Even if this result isn't helpful, understanding what can be done and how it works may be useful for less extreme cases.
Firstly, we can rewrite the while condition in the following ways:<lang Icon>while x ~= 0 & y ~= 0 do { # original
until not ( x ~= 0 & y ~= 0) do { # inverted
every | (0 = (x|y) & break) | &null do { # converted to an every loop (but incomplete)</lang>
One point worth noting is that expressions normally use short circuit evaluation. This construct forces both alternatives to be generated even if the second isn't needed. If ''y'' is a complex expression with side-effects this could have unexpected results.
The final transformation of a while into an ''every'' expression can be useful sometimes, but its not without challenges and can produce ugly results.
The failing condition can also be converted as in these examples:<lang Icon>
if x % 3 = y %3 = 1 then fail # original
( x % 3 = y %3 = 1) & fail ) | &null # converted for use with every | expr</lang>
The ''do'' part can be converted using conjunction.<lang Icon>
x /:= 3 # original
y /:=3 # ...
( x /:= 3 & y /:=3 ) # contracted</lang>
Putting these together and eliminating the trailing ''return'' in favor of the default fail at end, we get the rather odd looking:<lang Icon>procedure IsFilled(x,y)
every | ( (0 = (x|y) & return) | &null,
(( x % 3 = y %3 = 1) & break ) | &null,
( x /:= 3 & y /:=3 ) )
end</lang>
It's tempting to remove the ''| &null'' choices and convert the conjunction ''(expr1, expr2, expr3)'' to alternations but this isn't equivalent.
The alternations with &null can be eliminated by rewiring the path of alternatives with not expressions:<lang Icon>procedure IsFilled(x,y)
every | (not (0 = (x|y), return)) &
(not ( x % 3 = y %3 = 1, break )) &
( x /:= 3 & y /:=3 )
end</lang>
I'll resist compressing this into a one-liner.
The need for alternation with &null may require some explaining. Repeated alternation is defined as:
<pre> |expr repeatedly evaluates expr, producing its entire result
sequence each time, but failing if evaluation of expr results
in an empty result sequence.</pre>
The additional alternations are required to prevent the expression from running out of results. Part of this is due to the use of ''return'' and ''break'' to exit the loop preventing further results being generated.
The loop can be abstracted so:
<lang Icon>every (|A()) | B() | C()</lang>
Without the &null alternations (or the not expressions), once the repeated alternation fails there are no more results left to generate or backtrack into and the expression must move on. In the example, neither A() nor B() would not produce any results as they exit if successful. Since C() produces only one result and that ends the evaluation.
Overall, this example is not a very good use of these techniques.
== Odds and Ends ==
This section is a catchall for a number of Odds and Ends. In some cases, the the only criteria for inclusion is that they may be found a bit odd and have no other logical home.
=== &fail considered harmful? ===
Okay, &fail is not the evil subversive scourge of programming that the GOTO was once (still is?). However, at first glance it seems to be an oddity, it's easy to wonder about it's real worth.
In a recent discussion, someone expressed that &fail seemed like an anchor to the notion of languages that return Boolean values. And while that isn't quite how it works the appeal of that idea, especially to people new to the language, makes sense on some gut level. '&fail' simply causes the current expression to fail. Yet, you will occasionally see it used like so:
<lang Icon>...
return &fail # &fail fails and return causes the procedure to fail.
write("Surprise!") # never executed
end</lang>
Yet, in this example:
<lang Icon>...
suspend &fail # &fail fails and suspend fails
write("Surprise!") # this time this IS executed, and the procedure fails when it runs into the 'end' statement
end</lang>
Just for completeness:
<lang Icon>...
fail &fail # is a syntax error as fail takes no expression
</lang>
As one can see this is less about the behavior of &fail as it is about the behavior of return and suspend.
'&fail' does have uses as can be seen in this example from [https://www.cs.arizona.edu/icon/progcorn/pc_inl21.htm| The Icon Newsletter's Programming Corner]:
<lang Icon>
# The outcome of a looping expression such as
while expr1 do expr2
# need not be failure. If a break expression in either expr1 or expr2 is evaluated,
# the outcome of the looping expression is the outcome of the argument of the break expression.
# It is common to omit the argument of a break expression. In this case, the argument defaults to a null value.
# Consequently, if the break expression in
while expr1 do {
. . .
break
. . .
}
# is evaluated, the outcome of the looping expression is the null value.
# In fact, if this effect is not wanted,
break &fail
# can be used to assure the outcome of the looping expression is failure.
# However, the argument of a break expression can be a generator. For example, if break 1 to 5
# is evaluated in a looping expression, the result sequence for the looping expression is {1, 2, 3, 4, 5}.
</lang>
=== Semi-colons ===
Unicon and Icon don't require you insert semi-colons as line terminators like some languages. Instead the compiler/translator detects the end of an expression and automatically inserts one for you. Two caveats, (1) you must insert them yourself if you wish to write multiple expressions in a line, and (2) if you split an expression across a line boundary at an operator you must leave the operator on the first line or your expression will be prematurely terminated. As follows:
<lang Icon> x := 1; y := 2; z:= -3 # 1st case
s3 := s1 ||
s2 # 2nd case - like this
s3 := s1
|| s2 # ... not this</lang>
The other place this comes up is writing one-liners. While not a recommended style, there are tasks that require it [[Narcissist]] and [[Quine]] are examples. Consider for example the following two programs:
<lang Icon>procedure main();sub();end;procedure sub();write("1st example");end</lang>
<lang Icon>procedure main();sub();end procedure sub();write("2nd example");end</lang>
It might seem natural at first to write the first example, however, no semi-colon is needed between and end and procedure declaration. The second case is correct and the first generates a compile error.
= Run Time Considerations =
== Environment Variables ==
The following variables override the default storage allocations
* BLKSIZE Region (bytes) used for block data types like tables and lists
* COEXPSIZE Space (words) used for co-expressions
* MSTKSIZE Space (words) used for the main interpreter stack
* STRSIZE Region (bytes) use for strings
Other environment variables
* IPATH Path for pre-compiled library routines
* LPATH Path for source include files
* ICONFONT Default font name for windows opened
* TRACE Sets &trace for tracing
* NOERRBUF &errout (stderr) is buffered unless this is set.
* WICONLOG File to record output from wicont and wiconx
The defaults for [http://unicon.org/utr/utr7.html Unicon are documented in UTR7]
== Memory Allocation ==
Several keywords are available that provide information on memory allocations:
* &allocated - total memory allocated (bytes) - - generating ( total, static, string region, block region )
* &collections - number of times the garbage collector has reclaimed memory ( total, static region, string region, block region).
* ®ions - current memory size- generating ( static, string region, block region ).
* &storage - current memory used - generating ( static, string region, block region ).
Note: the value produced for static should always be 0 and is left for program compatibility. Sometimes you can see a non-zero number for static region collections (these are considered phantom collections - and this may have been fixed).
= Appendix A - Icon and Unicon Differences (Details) =
Line 359 ⟶ 794:
== Major Differences ==
=== Classes and Objects ===
<lang Unicon>package packagename
Line 384 ⟶ 817:
== Minor Differences ==
There are numerous minor differences between Icon and Unicon and they are not rigorously documented. See [http://unicon.org/generator/ The Generator articles entitled: Under-documented Unicon] for more information or contribute below.
=== Co-expression Calling ===
With co-expression ce, the following pairs of activations are equivalent in Unicon:
<lang Unicon> []@ce # sends a list to co-expression ce both Icon and Unicon
[x,y,z]@ce
Line 390 ⟶ 826:
ce(x,y,z)</lang>
=== Procedure Parameter Type Casting ===
Unicon procedure definitions allow for specification of type coercion functions and default values. There are currently two cases:
* for records and structures the type of the parameter is tested
* for types with type coercion functions (e.g. integer, real, numeric, string) the function is called to test type and perform type coercion.
<lang Unicon>procedure f1(i:integer:1,r:real,s:string,n:numeric,S:set,L:list,x:myrecordtype)</lang>
=== Event monitoring and cross-co-expression introspection ===
Unicon extends a number of procedures with extra parameters that default to the current co-expression and the current call level.
<lang Unicon> name(s) # Icon - return variable name
name(s,C) # Unicon
variable(s) # Icon - local/global variable may be read or set
variable(s, C, i) # Unicon - extended to access co-expression C and i levels up the call chain
</lang>
=== Procedures with Extended Domains ===
Unicon extended the behavior of a number of procedures.
<lang Unicon> reverse(x) # Icon x is string, Unicon x is string,list</lang>
== The Unicon Pre-processor ==
Unicon implements some of its functionality in the translator (icont) and the rest in the pre-processor (unicon). The pre-processor is typically used for syntactic enhancements like objects and parameter type checking.
If you are interested in seeing the code generated by the pre-processor, try the following command:
<pre>unicon -E source.icn</pre>
| |||