Anonymous user
Icon+Unicon/Intro: Difference between revisions
m
→General Language References
| (13 intermediate revisions by 2 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 27 ⟶ 33:
* [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 42 ⟶ 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 189 ⟶ 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 387 ⟶ 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 453 ⟶ 466:
====until====
Until will loop
====every====
Line 683 ⟶ 696:
=== &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.
Line 695 ⟶ 708:
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
</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 ===
Line 781 ⟶ 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 796 ⟶ 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>
| |||