Anonymous user
Icon+Unicon/Intro: Difference between revisions
m
→General Language References
(odds and ends ... &fail considered harmful) |
|||
| (24 intermediate revisions by 3 users not shown) | |||
Line 10:
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] ▼
===== Icon =====
* [http://www.cs.arizona.edu/icon/ftp/doc/lb1up.pdf Book: The Icon Programming Language, 3rd Edition; Griswold and Griswold]
▲* [http://unicon.org/book/ub.pdf Book: Programming with Unicon; Jeffrey, Mohamed, Pereda, Parlett - note also documents details of the Icon Programming Library]
* [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]
Line 18 ⟶ 24:
==== 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/
* [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/utr13.pdf The Unicon Messaging Facilities (UTR13)]
* [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 ====
Line 40 ⟶ 50:
** [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/
== Icon and Unicon Differences ==
Line 187 ⟶ 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 385 ⟶ 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.
Line 451 ⟶ 466:
====until====
Until will loop
====every====
Line 517 ⟶ 532:
Steve Wampler's "Fun With Co-Expressions" articles in The Generator
* [http://www.unicon.org/generator/TheGeneratorVol1No1Letter.pdf
* [http://www.unicon.org/generator/v2n1.pdf
* [http://www.unicon.org/generator/v2n2.pdf
Other articles
* [http://www.drones.com/coexp/
==== Example: Function Composition ====
Line 677 ⟶ 692:
== 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,
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'
<lang Icon>...
return &fail # &fail fails and return causes the procedure to fail.
return &fail▼
write("Surprise!") # never executed
end</lang>
Yet, in this example:
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:
fail &fail # is a syntax error as fail takes no expression
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]:
# The outcome of a looping expression such as
while expr1 do expr2
▲<lang Icon>while .... }
▲end</lang>
# 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
▲<lang Icon>while .... }
.
break
. . .
}
▲end</lang>
# is evaluated, the outcome of the looping expression is the null value.
# In fact, if this effect is not wanted,
# 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 =
Line 766 ⟶ 817:
== Minor Differences ==
There are numerous minor differences between Icon and Unicon and they are not rigorously documented. See [http://unicon.org/generator/
=== Co-expression Calling ===
Line 776 ⟶ 827:
=== Procedure Parameter Type Casting ===
Unicon procedure definitions allow for specification of type coercion functions and default values.
* for records and structures the type of the parameter is tested
▲<lang Unicon>
* 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:
=== Event monitoring and cross-co-expression introspection ===
Line 791 ⟶ 843:
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>
| |||