Icon+Unicon/Intro: Difference between revisions
Content added Content deleted
m (→Prelude about Goal-Directed Evaluation and Generators: ref Logic Programming) |
(rough in sections) |
||
Line 1: | Line 1: | ||
= Introduction and |
= Introduction to Icon and Unicon = |
||
== Under Construction Notes == |
|||
This page is a work in progress. The objectives of this page are as follows: |
This page is a work in progress. The objectives of this page are as follows: |
||
* Provide a place to put detailed documentation or descriptions that can be referenced from task pages or category pages |
* Provide a place to put detailed documentation or descriptions that can be referenced from task pages or category pages |
||
* Provide something akin to a readers digest condensed version of the books and other references |
* Provide something akin to a readers digest condensed version of the books and other references |
||
* Some of the information may be more appropriately moved to Paradigm pages |
* Some of the information may be more appropriately moved to Paradigm pages |
||
The initial text of this page has been taken from [[Flow-control_structures#Icon_and_Unicon]] |
The initial text of this page has been taken from [[Flow-control_structures#Icon_and_Unicon]] |
||
== Purpose == |
|||
The purpose of this page is to provide a Rosetta Code users with a enough supporting detail about Icon and Unicon to facilitate understanding and appreciation of these languages. More detail can be found in the online books. |
|||
== Icon and Unicon Differences == |
|||
[[Icon|The Icon Programming Language]] was the successor of a series of non-numeric languages including Commit, SNOBOL, [[SNOBOL4]], and SL-5. Icon provided several innovations and improvements over its predecessors including: integrating the the powerful pattern matching capabilities of SNOBOL4 into a procedural language, banishing a number of unfortunate foibles, retaining the flexibility of a typeless langauge, reining in some programming side effects, keeping platform independence. Icon was one of the first bytecode languages undergoing continuous improvement from it's inception in the late 1970s. |
|||
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, and messaging. 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. |
|||
== Variables, Data Types, and Structures == |
|||
=== un-Declarations === |
|||
Icon and Unicon do not require strict static typing of variables as does languages like [[Pascal]], nor does it require type definitions to reserve space such as in languages such as [[C]]. In fact, variables may happily change type from one moment to the next. Knowing this you might expect that declarations are non-existent. |
|||
Declarations are optional and any undeclared variables are either (a) parameters to procedures or (b) local to procedures. This design decision ensured that Icon/Unicon are not susceptible to the kind of side-effects that the global nature of variables in SNOBOL4 led to. |
|||
Still, declarations are desirable for clarity and needed for a number of special cases: |
|||
* local - variables local to a procedure |
|||
* static - permanent variables that transcend individual calls of procedures. While not visible outside of a procedure they are visible between different instances and across recursion of a procedure. |
|||
* global - variables with global visibility |
|||
Additionally, the following declarations apply to non-variables: |
|||
* record - used to define a structure with named fields |
|||
* procedure - used to define a procedure and its parameters |
|||
* invocable - used to control program linking to ensure procedures are included and available if they are called (e.g. through string invocation) |
|||
* class - used to define an object class (Unicon) |
|||
=== Self-Descriptive Safe Types === |
|||
=== Mutable and Immutable Types === |
|||
== Operators and Procedures == |
|||
=== Intuitive Generalizations === |
|||
=== Strong Typing through Operators === |
|||
=== Coercion: Implicit Type Conversions === |
|||
== Program Flow == |
|||
====Prelude about Goal-Directed Evaluation and Generators==== |
====Prelude about Goal-Directed Evaluation and Generators==== |