Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ASTRO.CS.IASTATE.EDU!kelvin
From: kelvin@ASTRO.CS.IASTATE.EDU
Newsgroups: comp.lang.icon
Subject: Conicon - What?!!
Message-ID: <9002152005.AA29215@astro.cs.iastate.edu>
Date: 15 Feb 90 20:05:04 GMT
References: <9002151639.AA01848@sophist.uchicago.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 50


Conicon is a contraction for concurrent Icon.  Conicon is designed to
 provide the high-level power of Icon to real-time programmers.  The
 implementation of Conicon differs somewhat from that of Icon.  In particular,
 we use a special real-time garbage collection algorithm designed in part
 by me, and a different virtual machine encoding which allows real-time
 response to interrupts (certain machine instructions in Icon's virtual
 machine represent potentially unbounded amounts of computation.  Since
 it is not possible to switch contexts in the middle of executing a particular
 instruction, the worst-case time required to execute a virtual machine
 instruction represents a lower bound on the time required to respond to
 a high-priority interrupt.)

Also, Conicon provides several new (and different) programming paradigms:

  1) The stream data type represents an unbounded sequence of values.
     Generally, you can treat this like a pipe from a concurrent process,
     or as an I/O connection to the outside world (to A/D converters,
     keyboards, terminals, modems, etc...).  In Conicon, string scanning
     is replaced with stream scanning.  The integration is, I think, fairly
     clean and natural.  Streams are described more thoroughly in the
     paper mentioned in my earlier mail:

        A Stream Data Type that Supports Goal-Directed Pattern Matching on
          Unbounded Sequences of Values - Kelvin Nilsen
           Computer Languages, Vol. 15, No. 1, Jan. 90.

     I can provide reprints to anyone who is interested in this.

  2) Conicon supports concurrent processes.  These processes are
     spawned in one of two ways.  First, Icon's create operator serves
     in Conicon to create a concurrent process instead of creating
     a coexpression.  A stream which represents the sequence of values
     generated by the spawned expression is automatically created when
     the process is spawned.  Second, Conicon introduces yet another
     operator: binary !, which is interpreted as "concurrent alternation."
     For example,

	every write(1 to 3 ! 5 to 7)

     might output the sequence:

	5, 6, 1, 2, 3, 7

     There are a variety of useful programming techniques that can be
     based on the concurrent alternation operator.  These techniques,
     and other aspects of concurrency in Conicon are discussed more
     thoroughly in a paper submitted to Software -- Practice & Experience.
     We have not yet heard back from the referees.  If anyone would like
     to see a draft, please send me mail...