From icon-group-sender  Mon Jan  3 08:08:13 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA05415
	for icon-group-addresses; Mon, 3 Jan 2000 08:06:56 -0700 (MST)
Message-Id: <200001031506.IAA05415@baskerville.CS.Arizona.EDU>
Date: Sat, 01 Jan 2000 03:58:07 -0500
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <evans@gte.net>, <icon-group@optima.CS.Arizona.EDU>
Subject: Re: REBOL
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id BAA02626
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Mark,

   I've briefly looked at Rebol and what I liked about it are its small size and the ability to easily work on the Internet.


Steve

===

>>> "Evans" <evans@gte.net> 12/24/99 12:40PM >>>
Dear Icon Group,

Dr. Dobb's just ran an article on the new REBOL language.  I am curious to know
what the Icon Consortium thinks of this language in comparison to Icon.

   http://www.rebol.com/inthenews.html 
   http://www.rebol.com/quotes.html 

REBOL is an interpreted language with an English-like syntax and is geared
mostly toward Internet functionality.  It also has strong data manipulation
features akin to Icon's.  That is the most I can say at first glance, and leads
to my question:  Where do the philosophies of REBOL and Icon diverge?

While I grasp the key underlying aspects of Icon, I can't get my head around
REBOL.  It appears to me that in some vague sense the philosophies behind the
two languages have much in common.

To take one concrete example, Unicon/Icon2 claims to be a worthy replacement for
Perl for a variety of reasons.  However REBOL makes exactly the same claim, and
is here now for all platforms while Unicon/Icon2 sits in perpetual beta state
and only for Unix.

The author of REBOL is a well-known character in Silicon Valley with a lot of
experience.  He researched over 50 languages before starting the REBOL project.
The REBOL project has attracted venture capital, but the core version is
freeware.  The commercial vision is to have REBOL running every Internet-capable
device as the core messaging engine.  Your Internet Toaster will speak REBOL to
your watch.

The major claimed benefit of REBOL is "dialects" but I fail to grasp how these
work.  If you can explain them to me in addition to the comparison with Icon,
double thanks are yours.  The REBOL literature seems a little sparse about this
feature.  Evidently it is connected with the REBOL "parse" function.

Somewhere on the REBOL pages I also read that REBOL serves as its own
meta-language, or something equally cryptic.  I need a computer scientist to
hold my hand at this point because I lost my beanie cap.

An interesting aspect of REBOL as it touches on Icon is that REBOL already
incorporates the port/socket/IO features that were supposed to be the
new-and-improved aspects of Icon2/Unicon.  This overlap is another area for
comparison and contrast.  Internet functionality is a major theme of this
language.

In summary, my questions are
1) Do you think the driving computer-science philosophies behind REBOL and Icon
are very similar?
2) Where do they differ?
3) Is Icon's destiny pointing in the direction of REBOL?

Sincerely,

Mark Evans





From icon-group-sender  Tue Jan  4 08:37:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA00571
	for icon-group-addresses; Tue, 4 Jan 2000 08:34:55 -0700 (MST)
Message-Id: <200001041534.IAA00571@baskerville.CS.Arizona.EDU>
Date: Mon, 3 Jan 2000 08:45:34 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: fbalbi@lonestar.jpl.utsa.edu, icon-group@optima.CS.Arizona.EDU
Subject: Re: sleep
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: Federico Balbi <fbalbi@lonestar.jpl.utsa.edu>
    Date: Wed, 29 Dec 1999 16:46:39 -0600
    
    Does Icon have a sleep(<seconds>) function to avoid busy-waiting? 
    

Icon has delay(i), which sleeps for i milliseconds.  In graphics programs,
call WDelay(i), which flushes graphics output before sleeping.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA


From icon-group-sender  Tue Jan  4 17:15:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA18513
	for icon-group-addresses; Tue, 4 Jan 2000 17:14:28 -0700 (MST)
Message-Id: <200001050014.RAA18513@baskerville.CS.Arizona.EDU>
Date: Tue, 04 Jan 2000 18:01:02 -0500
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Including the translator in the .exe
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id QAA16298
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I want to run my Icon program thru the linker in such a way that the resulting .exe file does not need iconx.exe present to function.  How do I do this?

Thanks.


Steve Graham



From icon-group-sender  Thu Jan  6 08:15:42 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24463
	for icon-group-addresses; Thu, 6 Jan 2000 08:14:33 -0700 (MST)
Message-Id: <200001061514.IAA24463@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: "Steve Waldo" <waldos@bitstream.net>
X-Newsgroups: comp.lang.icon
Subject: Re: Including the translator in the .exe
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Date: Wed, 05 Jan 2000 23:27:20 GMT
X-Complaints-To: abuse@bitstream.net
X-Trace: ptah.visi.com 947114840 206.144.239.167 (Wed, 05 Jan 2000 17:27:20 CST)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


Steve Graham wrote
> I want to run my Icon program thru the linker in such
> a way that the resulting .exe file does not need iconx.exe
> present to function.  How do I do this?

Use the -A option of icont. (Only applicable to the DOS version.)

--Steve




From icon-group-sender  Mon Jan 10 08:18:43 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA07560
	for icon-group-addresses; Mon, 10 Jan 2000 08:17:16 -0700 (MST)
Message-Id: <200001101517.IAA07560@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: metonymy <metonymy@newsguy.com>
X-Newsgroups: comp.lang.icon
Subject: Newbie installation problem
Date: 07 Jan 2000 20:48:05 -0600
User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I'm running red hat linux 6.0 on a 32 meg ibm aptiva. I
installed icon without apparent problems. I can compile
the demo programs without error messages. However, when
I attempt to run the compiled demo programs they crash
the shell ( bash ) i.e. I am returned abruptly to the
login prompt.  I assume I have overlooked something
obvious, but can't for the life of me see what it is.

TIA



From icon-group-sender  Mon Jan 10 08:19:05 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA07607
	for icon-group-addresses; Mon, 10 Jan 2000 08:18:55 -0700 (MST)
Message-Id: <200001101518.IAA07607@baskerville.CS.Arizona.EDU>
To: icon-group@optima.CS.Arizona.EDU
From: "Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>
Date: Sat,  8 Jan  0 15:46:48 +0300
Subject: LogIcon
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Greetings,

  I have a suggestion: to augment the Icon language and compiler with
a Prolog -> Icon preprocessor.

  Aim: to provide a balance between the "high-level", essentially declarative
language features and the operational languages features (that are usually
considered as "low-level").

  Reasons:
1) both Prolog and Icon implement backtracking and pattern matching; these
   mechanisms are implicit in Prolog while they are explicit and controllable
   by a programmer in Icon. So, it will be suitable for a programmer to have
   a choice between the implicit and explicit usage of these mechanisms, and
   freely intermix these modes within the same program module.
2) the Prolog "predicates" aren't exactly the predicates in common
   mathematical sense: generally the Prolog "predicates" correspond to the
   generators in Icon. The difference between the Prolog "predicates" (as
   well as the Icon's generators) and the mathematical predicates is clear:
   a mathematical predicate corresponds to a subset, while the Prolog
   "predicate" (as well as Icon's generator) corresponds to _ordered_ subset.

  Programmer's view: in my program I express the non-structured part of the
specifications using the Prolog facts and clauses; at the same time I express
the well-structured models and the low-level generators with the Icon
operators. The LogIcon preprocessor converts my program into a pure Icon text.

  Advantages for Icon programmer: straight and easy expression of a
non-structured information -- using the Prolog notation.

  Advantages for Prolog programmer: convenient tool for description of the
non-trivial well-structured models and for creation of the low-level
"predicates" (generators) -- using an operational language that fully supports
the familiar mechanisms of backtracking and pattern matching.

  Finally, I would like to be clear: I do not think that I have resources for
the implementation of what I just proposed. So, if someone likes this
suggestion then he may implement it himself or give it to a staff member or
a student.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg                           http://www.tarkvara.com/components
Russia



From icon-group-sender  Mon Jan 10 08:20:58 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA07756
	for icon-group-addresses; Mon, 10 Jan 2000 08:20:50 -0700 (MST)
Message-Id: <200001101520.IAA07756@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Generators and Coroutines in Python
X-Newsreader: Forte Agent 1.7/32.534
Date: Sun, 09 Jan 2000 12:40:58 GMT
X-Complaints-To: newsmaster@chello.nl
X-Trace: typhoon.chello.nl 947421658 212.187.67.243 (Sun, 09 Jan 2000 13:40:58 MET)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


For attempts to incorporate Generators & Coroutines in Python see:

http://www.pns.cc/stackless/spcpaper.htm

Enjoy,
Bob.



From icon-group-sender  Mon Jan 10 16:29:47 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA27669
	for icon-group-addresses; Mon, 10 Jan 2000 16:27:52 -0700 (MST)
Message-Id: <200001102327.QAA27669@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Jan 2000 13:38:57 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: icon-group@optima.CS.Arizona.EDU, metonymy@newsguy.com
Subject: Re: Newbie installation problem
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: metonymy <metonymy@newsguy.com>
    
    I'm running red hat linux 6.0 on a 32 meg ibm aptiva....
    when I attempt to run the compiled demo programs they crash
    the shell ( bash ) i.e. I am returned abruptly to the login prompt....

Did you remember to run the Setup script after unpacking the tar file?

Do you possibly have an ICONX environment variable that's overriding
the path in the generated files?

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA
    
    


From icon-group-sender  Wed Jan 12 10:15:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA05932
	for icon-group-addresses; Wed, 12 Jan 2000 10:13:38 -0700 (MST)
Message-Id: <200001121713.KAA05932@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: "Logichev, Sergey" <Sergey.Logichev@ru.artificial-life.com>
X-Newsgroups: comp.lang.icon
Subject: RE: LogIcon
Date: Wed, 12 Jan 2000 14:07:12 +0300
X-Trace: cool.spb.su 947678405 2122 193.125.198.3 (12 Jan 2000 12:00:05 GMT)
X-Complaints-To: usenet@cool.spb.su
X-Newsreader: Microsoft (R) Exchange Internet News Service Version 5.5.2650.12
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hi, Alexander

I don't know how you is used to using Icon, but don't think it's useful
to cross it with Prolog. Goals of this languages are very different. And
your idea is very difficult to implement. And you haven't got any
resources to do it... And who have wish and so expensive time to doing
that? By the way, there is Icon interpreter of Lisp but it's only a toy.

Sincerely,
Sergey Logichev 

>   I have a suggestion: to augment the Icon language and compiler with
> a Prolog -> Icon preprocessor.
> 



From icon-group-sender  Wed Jan 12 10:16:36 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA06136
	for icon-group-addresses; Wed, 12 Jan 2000 10:16:23 -0700 (MST)
Message-Id: <200001121716.KAA06136@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: eddie@holyrood.ed.ac.uk (Eddie Corns)
X-Newsgroups: comp.lang.icon
Subject: Re: LogIcon
Date: 12 Jan 2000 13:25:45 GMT
X-Trace: scotsman.ed.ac.uk 947683545 163 129.215.16.14 (12 Jan 2000 13:25:45 GMT)
X-Complaints-To: usenet@scotsman.ed.ac.uk
X-Newsreader: NN version 6.5.0 #2 (NOV)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Logichev, Sergey" <Sergey.Logichev@ru.artificial-life.com> writes:

>Hi, Alexander

>I don't know how you is used to using Icon, but don't think it's useful
>to cross it with Prolog. Goals of this languages are very different. And
>your idea is very difficult to implement. And you haven't got any
>resources to do it... And who have wish and so expensive time to doing
>that? By the way, there is Icon interpreter of Lisp but it's only a toy.

With Prolog being a higher level language than Icon it means that many very
common (and powerful) idioms are easily expressed.  People that use Prolog do
tend to have different goals but that is precisely why having control of the
lower layer is useful to the rest of us so that we too can benefit.  The whole
point of having high level languages is to make it easier to express problems
in any particular domain.  With some HLLs the designer chooses a domain and
how to express problems in it, if it's well designed, like Icon, the end users
can also extend it.  Contrast with something like C where there is practically
no scope for extension (you just keep writing bigger and bigger programs you
cannot for instance say "hey look I'm using this complex data in a consistent
way, I think I'll write me a control structure to express this more
concisely").

This is one of the reasons why people put together languages like Scheme to
see how far this concept can be taken.  There are of course many Prolog like
interpreters in Scheme (usually very small too).  Perhaps you could package up
some of Icon's functionality into Scheme and get the best of both worlds!  (If
you do, I'd like to know about it!!)

Anyway, did there not used to be a small Prolog interpreter in the Icon
distribution?  I remember looking for it a year or so ago because that thing
that passes for my memory thought it remembered one.

Eddie


From icon-group-sender  Fri Jan 14 12:52:15 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA16211
	for icon-group-addresses; Fri, 14 Jan 2000 12:51:03 -0700 (MST)
Message-Id: <200001141951.MAA16211@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: LogIcon
X-Newsreader: Forte Agent 1.7/32.534
Date: Fri, 14 Jan 2000 15:09:50 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: typhoon.chello.nl 947862590 212.187.67.243 (Fri, 14 Jan 2000 16:09:50 MET)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 12 Jan 2000 12:22:00 -0500, eddie@holyrood.ed.ac.uk (Eddie Corns) wrote:

>...
>Anyway, did there not used to be a small Prolog interpreter in the Icon
>distribution?  I remember looking for it a year or so ago because that thing
>that passes for my memory thought it remembered one.
>
>Eddie

First of all, sorry for the multiple postings: apparently my
newsserver failed to notify my client of a successfull posting.
I hope this time all goes well.

As to LOGICON, below you can find:

1) an abstract of an article by Guy Lapalme & Suzanne Chapleau (for article &
    source please email mr.Lapalme at lapalme@IRO.UMontreal.CA )

2) the PROLOG interpreter in ICON by Alan Finlay (further
    postings can also be found in the ICON archives)
========================================================
Date: Thu, 6 May 1999 17:09:34 -0400 (EDT)
Message-Id: <199905062109.RAA09982@ungava.IRO.UMontreal.CA>
X-Authentication-Warning: ungava.IRO.UMontreal.CA: lapalme set sender to
lapalme@ungava.IRO.UMontreal.CA using -f
From: Guy Lapalme <lapalme@IRO.UMontreal.CA>
To: nymesys@digimedia.nl
Subject: Re: LOGICON source
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=NIL
X-UIDL: 80950131b237264173f60637c751013d

Bob,
   I am surprised and pleased that somebody is still interested in logicon.

I managed to dig out the directory where you will find the icon source
(it has not been compiled for more than 10 years... so I cannot
guarantee anything),some documentation in French and formatted
with nroff!! and some examples of logicon programs.
...

Thanks for your interest

Guy Lapalme
----------------------------------------------------------------------------------------------------------------
TI- Logicon: an integration of Prolog into Icon
AU- Lapalme, G.; Chapleau, S.
CS- Dept. d'Informatique et de Recherche Operationnelle, Montreal Univ.,
    Que., Canada
JN- Software-Pract. & Exper. (GB) vol.16, no.10 925-44
PY- Oct. 1986
CD- <US Copyright Clearance Center Code> 0038-0644/86/100925-20$10.00
DT- JOURNAL PAPER; 
LA- ENGLISH
TC- PRACTICAL; 
RF- 12
AB- This paper describes the coupling of logic programming with Icon, which
    is a programming language aimed at string processing. Icon and Prolog
    have many similarities and their integration is feasible and desirable
    because the weaknesses of one can be compensated for by the strengths
    of the other. In our case, a Prolog interpreter was written as an Icon
    procedure that can be linked and called by an Icon program. This
    interpreter deals with all Icon data types and can be called in the
    context of the goal-directed evaluation of Icon. The authors give an
    example showing the power of this symbiosis between these two languages
    where a Prolog call in Icon is a generator and an Icon call in a Prolog
    clause is a built-in predicate
DE- high level languages; logic programming; PROLOG
ID- language integration; Logicon; Prolog; Icon; logic programming;
    programming language; string processing; data types; goal-directed
    evaluation; built-in predicate

========================================================
# Prolog in Icon, version 4, (C) Alan Finlay, Monash University.
########################## global variables and types ######################

record ctxt(env,subst)    # integer[string] * ((integer | struct | null) list)
record struct(name,args)  # string * ((integer | struct) list)
record rule(ids,head,body)# string list * predicate * predicate list \
record all(ids,body)      # string list * predicate list              } clauses
record one(ids,body)      # string list * predicate list             /
record fun(name,args)     # string * predicate list        \ types of 
record var(name)          # string                         / predicates
global dbase              # table of clauses indexed by head name
global consult            # stack of files being consulted
global query              # top level query

################################## driver ##################################

procedure main()
   dbase:=table([]); consult:=[&input] # empty dbase; standard input
   while \query | *consult>0 do { # more queries possible
      prog() # parse clauses, possibly setting query as a side effect
      if \query then case type(query) of {
         "all" : {every printsoln(query); write("no more solutions")}
         "one" : if not printsoln(query) then write("no")}
      else pop(consult)}
end

procedure printsoln(qry) # print first or next solution to qry 
   local ans,v
   every ans:=resolve(qry.body,1,*qry.body,newctxt(qry.ids,[])) do {
      if (type(ans)=="string") & (ans=="cut") then fail # cut query
      writes("yes")
      every v:=!qry.ids do writes(", ",v,"=",trmstr(ans.env[v],ans.subst))
      suspend write()}
end

########################### Prolog interpreter #############################

procedure resolve(qry,hd,tl,ctext) # generates all solutions of qry[hd:tl]
   local sub,q,cls,r               # and returns updated context
   if hd>tl then return ctext # terminate linear recursion
   case (q:=qry[hd]).name of {
      "assert"  : {r:=rule([],q.args[1],q.args[2:0])
                   every extractids(r.ids,!q.args)
                   dbase[q.args[1].name]:=dbase[q.args[1].name]|||[r]
                   suspend resolve(qry,hd+1,tl,ctext)} # always succeeds
      "retract" : suspend retract(q.args[1],ctext) & resolve(qry,hd+1,tl,ctext)
      "~"       : {if not (sub:=resolve(q.args,1,1,ctext).subst) |
                         (type(sub)=="string" & sub=="cut") then 
                      suspend resolve(qry,hd+1,tl,ctext)} # negation by failure
      "!"       : {suspend resolve(qry,hd+1,tl,ctext)
                   return "cut"} # causes failure of parent clause
      default   : {goal:=scanpred(q,ctext)
                   every cls := !dbase[q.name] do
                      every sub:=tryclause(goal,cls,ctext.subst) do {
                         if type(sub)=="string" & sub=="cut" then fail
                         else suspend resolve(qry,hd+1,tl,ctxt(ctext.env,sub))}
                  }
      }
end

procedure retract(pred,ctext) # removes a clause matching pred from dbase 
local cand,goal,entry,i; i:=1 # fails when no more matching clauses to remove
   goal:=scanpred(pred,ctext)
   every entry:=!dbase[goal.name] do { # check for matching clause
      cand:=scanpred(entry.head,newctxt(entry.ids,ctext.subst))
      if unify(goal,cand,copy(ctext.subst)) then { # found one so remove it
         dbase[goal.name]:=extract(dbase[goal.name],i) 
         suspend} # on backtracking more retractions can occur
      else i+:=1 # i keeps track of the entry number even with extractions
      } # n.b. this is a primitive retract since only the head is matched
end

procedure tryclause(term,cls,sub) # resolves term using given clause or fails
   local ctext,res                # a copy of sub is used so no side effects
   ctext:=newctxt(cls.ids,copy(sub)) # preallocate context for whole clause
   if unify(term,scanpred(cls.head,ctext),ctext.subst) then 
      every res:=resolve(cls.body,1,*cls.body,ctext) do {
          if (type(res)=="string") & (res=="cut") then suspend "cut"
          else suspend res.subst} 
end

######################## primitive domain operations ########################

procedure scanpred(prd,ctext) # converts predicate to structure 
   local args; args:=[] 
   if type(prd)=="var" then return ctext.env[prd.name]
   every put(args,scanpred(!prd.args,ctext))
   return struct(prd.name,args) 
end

procedure unify(t1,t2,sub) # (integer | struct),(integer | struct),sub 
   local v,i,num           # side effect: sub is updated
   if type(t1)=="integer" then {
      while type(v:=sub[t1])=="integer" do t1:=v # apply sub to t1
      return if type(v)=="struct" then unify(v,t2,sub) else sub[t1]:=t2}
   if type(t2)=="integer" then return unify(t2,t1,sub)
   if (t1.name==t2.name) & ((num:=*t1.args)=*t2.args) then {
      every i:=1 to num do if not unify(t1.args[i],t2.args[i],sub) then fail
      return}
end

procedure newctxt(ids,sub)       # forms a new context by extending sub
   local env; env:=table(&null)  # to accommodate the unbound identifiers
   every env[!ids]:=*put(sub,&null)
   return ctxt(env,sub)
end
   
procedure trmstr(trm,sub) # converts a term to a string suitable for output
   local s; s:=""
   case type(trm) of {
      "integer" : return trmstr(sub[trm],sub)
      "struct" : if s:=lstr(trm,sub) then return "["||s||"]" # non-empty list 
                 else {every s:=s||trmstr(!trm.args,sub)||","
                      return trm.name||(if *s=0 then "" else
"("||s[1:-1]||")")}
      "null" : return "undefined"}
end

procedure lstr(l,sub) # succeeds if l is a proper non-empty list and
   local hd,tl        # converts l to string suitable for output
   if l.name=="." & *l.args=2 then {
      hd:=trmstr(l.args[1],sub); tl:=l.args[2]
      while type(tl)=="integer" do tl:=sub[tl] # apply sub to tl
      case type(tl) of {
         "struct" : {if tl.name=="nil" & *tl.args=0 then return hd # nil
                     return hd||","||lstr(tl,sub)}                 # cons
         "null" : return "undefined"}}
end

procedure extract(list,el) # extract list element in position [el:el+1]
   return list:=list[1:el]|||list[el+1:0]
end

############################## Prolog parser ###############################

procedure prog() # parses consult[1] until query found or end of file
   query:=&null
   while write(read(consult[1])) ? clause() 
   if /query & consult[1]~===&input then close(consult[1])
end

procedure clause() # adds a clause to the dbase or fails when query set
   local p,b,ids,t; b:=[]; ids:=[]
   if =":-" then query:=all(ids,b:=body())
   else if ="?-" then query:=one(ids,b:=body())
   else {p:=pred(); if =":-" then b:=body()}
   if (t:=trim(tab(0)))~=="." then # syntax error
      return write("syntax error: ",t,if *t=0 then "." else " not"," expected")
   every extractids(ids,\p|!b) # list of variable identifiers
   if (\p).name=="consult" then every push(consult,open((!p.args).name))
   return dbase[(\p).name]:=dbase[p.name]|||[rule(ids,p,b)]
end
 
procedure body() # list of predicates (may be empty)
   local b; b:=[]
   if put(b,pred()) then while ="," & put(b,pred())
   return b
end

procedure dots() # converts non-empty body of list to cons cells
   local p
   if p:=pred() then if ="," then return fun(".",[p,dots()])
                     else return fun (".",[p,fun("nil",[])])
end

procedure pred() # ~pred , name(body) , uc_name , lc_name , [body] , pred|pred
   local name,args,d,p,pp; args:=[]
   if ="~" then p:=fun("~",[pred()])
   else if ="!" then p:=fun("!",[])
   else if name:=tab(many(&ucase++&lcase++'0123456789._')) then {
      if any(&ucase,name) then p:=var(name)
      else {if ="(" & args:=body() then check(")"); p:=fun(name,args)}}
   else if ="[]" then p:=fun("nil",[]) # empty list abbreviation
   else if ="[" then {p:=dots(); check("]")} # non-empty list abbreviation
   if ="|" then if pp:=pred() then return fun(".",[p,pp]) # infix cons
                else write("syntax error: missing second argument to \"|\"")
   return \p # n.b. fails if predicate invalid
end

procedure check(s) # report error if s not present or skip over it
   if not =s then write("syntax error: ",s," expected before ",tab(0))
end

procedure extractids(ids,pred) # build the set of variable identifiers 
   if type(pred)=="fun" then every extractids(ids,!pred.args)
   else if not (pred.name==!ids) then put(ids,pred.name)
   return # the identifiers have been appended to reference parameter ids
end

========================================================



From icon-group-sender  Tue Jan 18 09:10:19 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA20530
	for icon-group-addresses; Tue, 18 Jan 2000 09:08:35 -0700 (MST)
Message-Id: <200001181608.JAA20530@baskerville.CS.Arizona.EDU>
From: "J.R. Sampson" <jsampson@indexes.u-net.com>
To: icon-group@optima.CS.Arizona.EDU
Date: Mon, 17 Jan 2000 21:51:47 -0000
Subject: Re: LogIcon
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> 2) the PROLOG interpreter in ICON by Alan Finlay (further
>     postings can also be found in the ICON archives)

Is this on line anywhere?

My email client messes up program listings as it decides where the 
line breaks should be.

Regards

_John Sampson_


From icon-group-sender  Thu Jan 20 12:35:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA09251
	for icon-group-addresses; Thu, 20 Jan 2000 12:33:25 -0700 (MST)
Message-Id: <200001201933.MAA09251@baskerville.CS.Arizona.EDU>
Date: Thu, 20 Jan 2000 11:38:30 -0500
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject:  Question
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id JAA01043
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I need a program which generates all combinations (or permutations?) of 12345, i.e. 12345, 12354, 12435, etc  I have a hunch that Icon has built in facilities to accomplish this, but I haven't figured out what they are.  Any suggestions?

TIA,
Steve Graham



From icon-group-sender  Thu Jan 20 17:03:40 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA23617
	for icon-group-addresses; Thu, 20 Jan 2000 17:02:03 -0700 (MST)
Message-Id: <200001210002.RAA23617@baskerville.CS.Arizona.EDU>
Date: Thu, 20 Jan 2000 12:02:05 -0800 (PST)
From: Shamim Mohamed <soar@drones.com>
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: all permutations
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

 > I need a program which generates all combinations (or permutations?)
 > of 12345, i.e. 12345, 12354, 12435, etc

I wrote a program to do this some time ago. It actually writes out the
permutations lexicographically, and is non-recursive. I don't remember
everything about it, so if something seems strange, I might not be able
to explain it!

-s



# procedure to find the next (lexicographically) permutation of a string

# Algorithm : to generate one string from the previous,
#  i)  scan left from the end of the string till you find a char smaller
#      than the one to its right;
# ii)  find the smallest letter in the substring to its right; interchange
#      them;
# iii) sort the substring on the right
# and repeat.
#       This is a permutation since letters are only interchanged. This is
# the next higher one by inspection. (Very long and careful inspection!)

procedure next_perm(s)

   i := *s - 1

   while i > 0 & ord(s[i]) >= ord(s[i+1]) do
      i -:= 1
   if i = 0 then fail

   j := i
   min := i + 1
   while j <= *s do {
      if ord(s[j]) > ord(s[i]) & ord(s[j]) < ord(s[min]) then
         min := j
      j +:= 1
   }
   s[min] :=: s[i]
   s[i+1:0] := ssort(s[i+1:0])

   return s
end


procedure main(args)

   s := args[1] | "abcde"

   write(i:=1, " ", s)
   while s := next_perm(s) do
      write(i+:=1, " ", s)

end

procedure ssort(s)

# The straightforward approach doesn't work if the string contains duplicates
   return string(cset(s))

   ret := ""
   T := table(0)

   every c := !s do T[c] +:= 1
   every c := !cset(s) do
      ret ||:= repl(c, T[c])
   return ret
end



From icon-group-sender  Thu Jan 20 17:06:44 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA23952
	for icon-group-addresses; Thu, 20 Jan 2000 17:06:34 -0700 (MST)
Message-Id: <200001210006.RAA23952@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Question
Date: 20 Jan 2000 20:22:46 GMT
X-Trace: vishnu.jussieu.fr 948399766 688 132.227.81.128 (20 Jan 2000 20:22:46 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <200001201933.MAA09251@baskerville.CS.Arizona.EDU>,
Steve Graham <Steve_Graham@labcorp.com> wrote:
>I need a program which generates all combinations (or permutations?) of
>12345, i.e. 12345, 12354, 12435, etc  I have a hunch that Icon has built
>in facilities to accomplish this, but I haven't figured out what they
>are.  Any suggestions?

If you don't need to build them in lexicographic order, this is easily
achieved with a recursive generator.

Try this:

procedure permute(l, i)
   if i >= *l then
      return l
   else
      suspend l[i to *l] <-> l[i] & permute(l, i+1)
end

procedure write_list(l)
   every writes(!l, " ")
   write()
end

procedure main()
   every write_list(permute(["a", "b", "c"], 1))
end


-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Fri Jan 21 13:41:58 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA17609
	for icon-group-addresses; Fri, 21 Jan 2000 13:41:18 -0700 (MST)
Message-Id: <200001212041.NAA17609@baskerville.CS.Arizona.EDU>
Date: Fri, 21 Jan 2000 11:09:20 -0500
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <espie@liafa.jussieu.fr>, <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Question
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id JAA00278
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Marc,

   I figured that Icon had some mechanism to "automatically" figure out all the permutations.  I presume that the mechanism is mostly contained in the line:

suspend l[i to *l] <-> l[i] & permute(l, i+1)

   However, I don't really understand what's going on here.  I gather there's a reversible assignment being used and a recursive call.  Can you shed some light on this?

   Thanks.


Steve Graham



In article <200001201933.MAA09251@baskerville.CS.Arizona.EDU>,
Steve Graham <Steve_Graham@labcorp.com> wrote:
>I need a program which generates all combinations (or permutations?) of
>12345, i.e. 12345, 12354, 12435, etc  I have a hunch that Icon has built
>in facilities to accomplish this, but I haven't figured out what they
>are.  Any suggestions?

If you don't need to build them in lexicographic order, this is easily
achieved with a recursive generator.

Try this:

procedure permute(l, i)
   if i >= *l then
      return l
   else
      suspend l[i to *l] <-> l[i] & permute(l, i+1)
end

procedure write_list(l)
   every writes(!l, " ")
   write()
end

procedure main()
   every write_list(permute(["a", "b", "c"], 1))
end


-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'




From icon-group-sender  Mon Jan 24 08:29:36 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA29177
	for icon-group-addresses; Mon, 24 Jan 2000 08:27:31 -0700 (MST)
Message-Id: <200001241527.IAA29177@baskerville.CS.Arizona.EDU>
From: Bob Ardler <ardler@argonet.co.uk>
To: <icon-group@optima.CS.Arizona.EDU>
Date: Sun, 23 Jan 2000 12:04:01 +0000 (GMT)
Subject: permutations a la real Icon
User-Agent: Pluto/1.13f (RISC-OS/3.60)
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

(Thread called 'Question' or 'permutations', etc)

Steve Graham:
> Marc Espie:
> >suspend l[i to *l] <-> l[i] & permute(l, i+1)

>I don't really understand what's going on here.  I gather there's a
>reversible assignment being used and a recursive call.  Can you shed
>some light on this?

Me too. My iterative Basic permuter transcribed to Icon, FORs to
everys, is embarrassingly long and 20% slower than Marc's.

Marc Espie's program is real Icon as opposed to the
Algol-with-singing-dancing-strings subset of Icon which, as a
non-programmer I use for small text or numeric jobs.

No doubt time or urgency or an on-site guru or intelligence transplant
would enable one to learn real Icon, exploiting generators, suspension
and coexpressions.

However I believe there is a pedagogic problem here. I have the Griswold
book, 3rd edition. It's the best manual, best text-book and best primer
I've seen, all in under 400 pages. A remarkable achievement, evidence
that some computer scientists may be human.

Yet their patient chapters on string scanning and co-expressions couldn't
penetrate this skull. I think the missing pedagogic tools are

(1) rigorous (as in maths) definitions and statements of the semantics
involved

(2) historical asides explaining the origin of, eg, co-expressions

(3) a type of diagram, or perhaps a style of layout, which can show the
flow of control in a statement like Marc's above.

I am thinking of how, since Algol, the physical layout with indentation
of a procedural language has enabled learners and non-programmers to
write short programs and see what's going on.

"char* yukk = squawk; while ( *squawk++ = *crep++ ) ; return yukk;" is
just a gag. But 'real' Icon, like functional languages, is forced to have
one-liners with many invisible lines of control flow.

I haven't seen text-book diagrams to exhibit the behaviour of generators
or show the flow in suspension/resumption.

Do any of you have such things in your lecture notes or use them on the
blackboard? Or know of texts which diagram or elucidate 'horizontal'
control flow?

--

Bob Ardler,  ardler@argonet.co.uk



From icon-group-sender  Mon Jan 31 14:09:03 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA07066
	for icon-group-addresses; Mon, 31 Jan 2000 14:07:28 -0700 (MST)
Message-Id: <200001312107.OAA07066@baskerville.CS.Arizona.EDU>
Date: Mon, 31 Jan 2000 13:50:15 -0600
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Updating array parameters in Icon (a mini-dissertation)
Content-Disposition: inline
X-Guinevere: 1.0.12 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id MAA04310
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I have an Icon programming problem that needs clarification, but I
suspect many Icon programmers can benefit from what I've found out about
it so far.

BACKGROUND

I have from time to time needed to write a procedure that returns a list
as its value. Example:

list_value := func_1()

However, sometimes the list is an update of values in an already
existing list. This occurs frequently in numerical analysis. Example:

list_value := list(1, 10)		# Creating the list
...
list_value := func_2(list_value)	# Returning a new list

The returned value of func_2() is based on a computation using the
initial value of list_value as input to an algorithm that calculates a
vector of deltas and adds them to the original list.  This updated list
is the function result.

But once in a while it turns out that another value is a better
candidate for the returned value. The list in question then becomes a
parameter to the procedure. Example:

list_value := list(1, 10)		# Creating the list
...
if func_3(list_value) then		# Updating the list
	# success:
	x := list_value[1] # (x ~= 1)	# Using the list
else
	# failure case...

Here, func_3() updates the list_value parameter, sets some return value,
and returns, so that the updated list is ready for further use.

I knew that a scalar value, when assigned to a parameter inside a
procedure, would not survive return to the caller. I also knew that a
record data structure could be so updated. (I have even hidden a scalar
value inside a record to get around this restriction.) But I wasn't sure
about lists. I noticed that sometimes the list would come back updated,
and sometimes it wouldn't.

STRANGE BEAST ISOLATED IN CAPTIVITY!

I finally discovered that a list parameter can indeed be updated, but
you have to update it in a certain way. I wrote the following program to
illustrate the problem and the solution:

========8<==================8<====================
# Verify behavior of updated list parameters
procedure main()
	local x, y
	x := []
	y := []

	write("Before updating:")
	write("x[1] = >", (x[1] | "empty"), "<")
	write("y[1] = >", (y[1] | "empty"), "<")

	method1(x)
	method2(y)

	write("After updating:")
	write("x[1] = >", (x[1] | "empty"), "<")
	write("y[1] = >", (y[1] | "empty"), "<")
	exit()
end

# method1 - assign a new list value to the parameter
procedure method1(x)
	x := [&e]
	return
end

# method2 - put a new value on the existing list
procedure method2(x)
	put(x, &pi)
	return
end
========8<==================8<====================

The output of this program is

========8<==================8<====================
Before updating:
x[1] = >empty<
y[1] = >empty<
After updating:
x[1] = >empty<
y[1] = >3.141592653589793<
========8<==================8<====================

QUESTION

I suspect that the answer has to do with the pointer semantics of Icon,
but if anyone can flesh this out for me I'd appreciate it.  Meanwhile,
maybe some will find this a useful programming tip.

Thanks in advance,

Charles Hethcoat
Sr. Engineer
Oceaneering Space Systems
Houston, TX 77058 USA



From icon-group-sender  Tue Feb  1 11:06:54 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA00037
	for icon-group-addresses; Tue, 1 Feb 2000 11:05:33 -0700 (MST)
Message-Id: <200002011805.LAA00037@baskerville.CS.Arizona.EDU>
From: dgamey@ca.ibm.com
X-Lotus-FromDomain: IBMCA@IBMUS
To: icon-group@optima.CS.Arizona.EDU
cc: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
Date: Mon, 31 Jan 2000 21:54:54 -0500
Subject: Re: Updating array parameters in Icon (a mini-dissertation)
Content-Disposition: inline
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO



Charles,

You are correct about icon's pointer semantics.   In (my paraphrase of)
your example:

   procedure main()
      x := []
      method1( x )
      method2( x )
   end

   procedure method1(x)
      x := [&e]
      return
   end

   procedure method2(x)
      put(x, &pi)
      return
   end

You should expect that x will not be modified by method1.   The reason for
this can be illustrated with the following:

   procedure main()
   y := x := [1,2,3]
   y[2] := 5
   if x[2] = 5 then write("Changed") else write("Unchanged")
   end

This program will write "Changed"

In both method1 and method2,  local/parameter x is assigned to main's x.
In method1, local x is then assigned to a new list (creating a new
structure in the block region).
In method2, the contents of x are changed.  Since local x and main's x
"point" to the same structure block (i.e. are identical === ), then the
contents of that block are changed.
In both cases, the local value of x is destroyed upon return.

You'll find this behaviour consistent amongst the structure objects that
get allocated in the block region (lists, sets, tables, records).  Numbers
and strings behave differently. (I'm not sure about csets, but I suspect
they behave much like strings and numbers.)

David Gamey




From icon-group-sender  Tue Feb  1 11:15:52 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA00365
	for icon-group-addresses; Tue, 1 Feb 2000 11:15:42 -0700 (MST)
Message-Id: <200002011815.LAA00365@baskerville.CS.Arizona.EDU>
Date: Tue, 01 Feb 2000 10:40:43 -0500
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Question on function()
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id IAA24125
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I want to print out all Icon's functions so I write this line of code

every write(!function())

However, I get each letter of each function on a separate line.  What's wrong?


Steve



From icon-group-sender  Tue Feb  1 11:16:21 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA00409
	for icon-group-addresses; Tue, 1 Feb 2000 11:16:06 -0700 (MST)
Message-Id: <200002011816.LAA00409@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: Updating array parameters in Icon (a mini-dissertation)
Date: Tue, 01 Feb 2000 08:43:35 -0700
X-Trace: noao.edu 949419814 86549 140.252.38.6 (1 Feb 2000 15:43:34 GMT)
X-Complaints-To: abuse@noao.edu
To: Charles Hethcoat <CHETHCOA@oss.oceaneering.com>
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Charles Hethcoat wrote:

> QUESTION
> 
> I suspect that the answer has to do with the pointer semantics of Icon,
> but if anyone can flesh this out for me I'd appreciate it.  Meanwhile,
> maybe some will find this a useful programming tip.

Hi Charles,

You are correct, the answer has to do with the pointer semantics of Icon.
More precisely, (1) the "value" of a variable that contains a structured type
(record, list, table, set, etc.) is a reference (pointer) to the data
structure, not the data structure itself and (2) ALL parameters are
pass-by-value
in Icon.

So if you do:

    x := []		# The list is created in the heap, and a reference
                        #    to the list is stored in x.
    f(x)		# The value of x (a reference to the list) is *copied*
                        #    to the first parameter of f()

so in:

    procedure f(a)	# A holds a reference to the list, so the value of
                        #    a and the value of x are (at this moment) both
                        # referencing the same list in the heap.

now if you do (inside f):

        a := []		# Creates a new (empty) list in the heap and assigns
                        #    a reference for it into a.  At this moment, x and
                        #    a refer to different lists, x *still* refers to the
                        #    original list.  Any changes made to the list
referenced
                        #    in have *no effect* on the list reference in x.

but if, instead, you do (inside f, again):

        put(a,&pi)	# Takes the list referenced by a (which is the same list
                        #    list referenced by x) and add a new element to it.

now, when f returns, you'll see the change to list when you use the list
reference
in x, as you've seen.

The key is to remember that you're not assigning a list to a variable with
statements such as x := list(1, 20), but rather creating a list and assigning
a reference for it to x.  This reference is (itself) a scalar value.
  
--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Wed Feb  2 12:26:35 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA04465
	for icon-group-addresses; Wed, 2 Feb 2000 12:25:00 -0700 (MST)
Message-Id: <200002021925.MAA04465@baskerville.CS.Arizona.EDU>
Date: Wed, 02 Feb 2000 10:50:20 -0600
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Icon parameter values
Content-Disposition: inline
X-Guinevere: 1.0.12 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id KAA00040
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Thanks to all who sent in their comments on my "mini-dissertation" of a few days ago.  I am all straightened out on this now.

Shamim Mohamed said it this way in referring to my "beast in captivity" program snippet:

>In method 1, you are creating a new list and assigning a reference to it
>to the name x.
>In method 2, you are modifying the list that x has a reference to.

This difference between x := [value] and put(x, value) accounts for my confusion as to why I sometimes could, and sometimes couldn't, update the array.  In short, I was doing it both ways at different times without fully comprehending the difference.  There is no low-level clue to the different behavior in the syntax; one just has to have read the fine print.  RTFM, I think they say.

In reading what I could find about the parameter problem in the 2nd Ed. of Ralph's book (yes, I know--I need to get the 3rd), I could find nothing in the vein of "If you want to update a structured parameter from within a procedure, here is how to do it: ..."

So, in the interest of filling the gap for newcomers and oldtimers alike who may be confused, here is how to do it and guarantee that the update will make it back to the caller:

# append a value to list_arg, which is passed in from the caller
procedure append_it(list_arg)
	local new_list_value
	new_list_value := # result of some computation
	put(list_arg, new_list_value)
	return
end

# change an element of list_arg:
procedure change_it(list_arg)
	local changed_list_value, i
	i := # e.g. a binary search for the proper element to modify
	changed_list_value := # result of some computation
	list_arg[i] := changed_list_value
	return
end

And here is how NOT to do it:

# Grrr...
procedure how_dumb(list_arg)
	local new_list
	list_arg := [ # sequence of new values computed locally from list_arg
		]
	return
end

If anybody sees problems with these examples, be sure to chime in.

Charles Hethcoat



From icon-group-sender  Thu Feb  3 17:43:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA15888
	for icon-group-addresses; Thu, 3 Feb 2000 17:42:27 -0700 (MST)
Message-Id: <200002040042.RAA15888@baskerville.CS.Arizona.EDU>
From: Kostas Oikonomou <oikonomou@att.com>
Date: Thu,  3 Feb 2000 15:00:09 -0500 (EST)
To: icon-group@optima.CS.Arizona.EDU
Subject: calling a C routine from icont
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


Is it possible to call a C routine for which you have only a header available,
and whose code exists only in a library (no source available)?

I've looked through the code in the cfuncs directory, and I'm not sure if what I
want is doable.

My situation is that I have an X library that does specialized plotting of data, 
and I'd like to call some of its routines from my Icon program. 

Some example routine headers are

void hs_initialize(char *id_string);
void hs_update(void);
void hs_complete(void);
void hs_complete_and_wait(void);
void hs_histoscope(int return_immediately);
void hs_kill_histoscope(void);
int hs_create_1d_hist(int uid, char *title, char *category, 
			char *x_label, char *y_label,
			int n_bins, float min, float max);


Thanks very much.

				Kostas


From icon-group-sender  Fri Feb  4 13:29:57 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05808
	for icon-group-addresses; Fri, 4 Feb 2000 13:26:13 -0700 (MST)
Message-Id: <200002042026.NAA05808@baskerville.CS.Arizona.EDU>
Date: Thu, 3 Feb 2000 18:34:08 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: icon-group@optima.CS.Arizona.EDU, oikonomou@att.com
Subject: Re: calling a C routine from icont
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: Kostas Oikonomou <oikonomou@att.com>
    Date: Thu,  3 Feb 2000 15:00:09 -0500 (EST)
    
    Is it possible to call a C routine for which you have only a header
    available, and whose code exists only in a library (no source available)?

No.  Icon can't call arbitrary C functions -- only functions written
specifically for use with Icon.  The C function is always passed an
argc / argv pair, and the argv array contains Icon "descriptors".
Details are given in Section 3 of 
	http://www.cs.arizona.edu/icon/docs/ipd240.htm

You can, however, write interface routines that accept Icon calls
and in turn call the specialized library.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA


From icon-group-sender  Fri Feb  4 13:42:53 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA06340
	for icon-group-addresses; Fri, 4 Feb 2000 13:42:45 -0700 (MST)
Message-Id: <200002042042.NAA06340@baskerville.CS.Arizona.EDU>
Date: Fri, 04 Feb 2000 07:57:00 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: Kostas Oikonomou <oikonomou@att.com>,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: calling a C routine from icont
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Kostas Oikonomou wrote:
> 
> Is it possible to call a C routine for which you have only a header available,
> and whose code exists only in a library (no source available)?
> 
> I've looked through the code in the cfuncs directory, and I'm not sure if what I
> want is doable.
> 
> My situation is that I have an X library that does specialized plotting of data,
> and I'd like to call some of its routines from my Icon program.
> 
> Some example routine headers are
> 
> void hs_initialize(char *id_string);
> void hs_update(void);
> void hs_complete(void);
> void hs_complete_and_wait(void);
> void hs_histoscope(int return_immediately);
> void hs_kill_histoscope(void);
> int hs_create_1d_hist(int uid, char *title, char *category,
>                         char *x_label, char *y_label,
>                         int n_bins, float min, float max);

Kosta,

Yes, it is possible, but you'll need to do it indirectly.  That is, you'll
need to write (in C) wrapper functions to convert the data types between
Icon's view of the world and C's.  There are functions available to help
with those conversions, check the documentation on calling C functions
from Icon (sorry, but I've forgotten which document it is, but the
icon web page should point you to it).

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Fri Feb  4 13:43:19 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA06376
	for icon-group-addresses; Fri, 4 Feb 2000 13:43:07 -0700 (MST)
Message-Id: <200002042043.NAA06376@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: kapitan.ethanak.home: ethanak owned process doing -bs
Date: Fri, 4 Feb 2000 16:46:33 +0100 (EET)
From: "Bohdan R. Rau" <ethanak@bigfoot.com>
X-Sender: ethanak@kapitan.ethanak.home
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: calling a C routine from icont
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On Thu, 3 Feb 2000, Kostas Oikonomou wrote:

> 
> Is it possible to call a C routine for which you have only a header available,
> and whose code exists only in a library (no source available)?
> 
> I've looked through the code in the cfuncs directory, and I'm not sure if what I
> want is doable.

Sorry for my bad English, but it is not my native language :)

Some months ago I tried to write ncurses wrapper for Icon. In theory it was
very simple - adding only one paremeter (-lncurses) to gcc call. But
behaviour was very strange - on two machines (very small Linux RH 4.2/486/4
MB RAM and RH5.2/P166/32MB) it worked very good, on third (my private
machine, RH5.2/P166/32MB, practically identical to one of this two) every
call of ncurses procedure caused memory violation...

I have no idea where is the problem :(((

Regards

ethanak
http://ethanak.i.sex.pl



From icon-group-sender  Mon Feb  7 08:17:47 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08396
	for icon-group-addresses; Mon, 7 Feb 2000 08:16:27 -0700 (MST)
Message-Id: <200002071516.IAA08396@baskerville.CS.Arizona.EDU>
Date: Sun, 6 Feb 2000 23:57:50 -0200 (EDT)
From: Andrzej Solecki <andsol@mtm.ufsc.br>
To: icon-group@optima.CS.Arizona.EDU
Subject: factors.icn
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

   I've imagined that such a program (call it `fct.icn') would behave
as nicely as FreeBSD `factor' command:
		link factors
		procedure main(args)
		writes(args[1],": ")
		every writes(!factors(args[1])," ")
		write()
		end
but it returns only one factor if the number has just two (distinct)
ones. Some numbers (like 99) are also discriminated. Is it a feature
or an unexpected feature of `factors.icn'? Or anything wrong about
the way the list is formed?
   Besides, it chokes soon enough even when one of the factors
is reasonably small, say `./fct 33285' returns `33285 - 3 5 7'. Any
simple explanation, please? A quick look at `factors.icn' - at my level
of ignorance - does not furnish any clues :(
				Andrzej Solecki		



From icon-group-sender  Mon Feb  7 12:38:40 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA18693
	for icon-group-addresses; Mon, 7 Feb 2000 12:38:27 -0700 (MST)
Message-Id: <200002071938.MAA18693@baskerville.CS.Arizona.EDU>
Date: Mon, 7 Feb 2000 09:41:45 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: andsol@mtm.ufsc.br, icon-group@optima.CS.Arizona.EDU
Subject: Re: factors.icn
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: Andrzej Solecki <andsol@mtm.ufsc.br>
    
    ...[factors()] returns only one factor if the number has just two
    (distinct) ones. Some numbers (like 99) are also discriminated....
       Besides, it chokes soon enough even when one of the factors
    is reasonably small, say `./fct 33285' returns `33285 - 3 5 7'....
    
factors.icn was buggy in Icon 9.3.1.  It was fixed in the Icon 9.3.2
library.  The new version of factors.icn by itself can be found at
	http://www.cs.arizona.edu/icon/library/src/procs/factors.icn

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Tue Feb  8 08:44:09 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA06333
	for icon-group-addresses; Tue, 8 Feb 2000 08:42:07 -0700 (MST)
Message-Id: <200002081542.IAA06333@baskerville.CS.Arizona.EDU>
Date: Mon, 7 Feb 2000 23:08:42 +0000 (GMT)
From: Andrzej Solecki <andsol@mtm.ufsc.br>
To: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: factors.icn
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


On Mon, 7 Feb 2000, Gregg Townsend wrote:
> factors.icn was buggy in Icon 9.3.1.  It was fixed in the Icon 9.3.2
> library.  The new version of factors.icn by itself can be found at
> 	http://www.cs.arizona.edu/icon/library/src/procs/factors.icn
   Great. Thanks. In fact, putting `factors.icn' in `procs' directory
(as well as factors.u{1,2} in `ilib' one) makes factors of - let's
say - 6 appear as one used to know them in the high school :)
   But the information on 9.3.2 version raises the question: is there
a way to patch my 9.3.1 Linux version? In fact: is it important to upgrade
if I care more about mathematical uses than graphical applications?
That is, besides those `factors.icn' are there any other notable
corrections? (2Mb is lots of bytes for my modem...)
				Yours
				Andrzej Solecki



From icon-group-sender  Tue Feb  8 12:31:46 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14579
	for icon-group-addresses; Tue, 8 Feb 2000 12:31:26 -0700 (MST)
Message-Id: <200002081931.MAA14579@baskerville.CS.Arizona.EDU>
Date: Tue, 8 Feb 2000 09:17:29 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: andsol@mtm.ufsc.br
Cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: factors.icn
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: Andrzej Solecki <andsol@mtm.ufsc.br>

    ...But the information on 9.3.2 version raises the question: is there
    a way to patch my 9.3.1 Linux version? In fact: is it important to upgrade
    if I care more about mathematical uses than graphical applications?
    That is, besides those `factors.icn' are there any other notable
    corrections? (2Mb is lots of bytes for my modem...)

Sorry, there are no patches; you have to download the whole thing.

The main disadvantage to sticking with the older version is the risk of
wasting time over bugs (like the one you found) that have already been
fixed.  Unfortunately, there is no comprehensive list of fixes.

I would take the time to upgrade, even over a slow modem, but it's
not unreasonable to stay with 9.3.1 as long as it's working.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Thu Feb 10 16:26:43 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA17405
	for icon-group-addresses; Thu, 10 Feb 2000 16:24:16 -0700 (MST)
Message-Id: <200002102324.QAA17405@baskerville.CS.Arizona.EDU>
Date: Thu, 10 Feb 2000 17:08:23 -0600
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Dereferencing, updating, and `pseudovariables' in Icon
Content-Disposition: inline
X-Guinevere: 1.0.13 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id QAA16732
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I want to put something like the following code in an application I'm writing.  The two subordinate procedures define something that I call "pseudovariables".  (Anyone remember PL/I?)
---------------------------------8<-------------------------------------------------
procedure main()

	write("pseudovar_1() = ", pseudovar_1())
	pseudovar_1() +:= 1
	write("pseudovar_1() = ", pseudovar_1())

	write("pseudovar_2() = ", pseudovar_2())
	pseudovar_2() +:= 2	
	write("pseudovar_2() = ", pseudovar_2())

	return
end

# pseudovar_1 - return name of a local static variable
procedure pseudovar_1()
	static _pseudovar_1
	initial _pseudovar_1 := 1
	return _pseudovar_1
end

# pseudovar_2 - return value of a local static variable
procedure pseudovar_2()
	static _pseudovar_2
	initial _pseudovar_2 := 1
	return ._pseudovar_2	# note the dot!
end
---------------------------------8<-------------------------------------------------
Question:  Is there any way to retain control in this situation?  I would like to detect the attempt to assign to a read-only variable and tell the user that he can't do that.  I was hoping to be able to do this:

	pseudovar_2() +:= 2	 | stop("Hey!  Stop that!")

But it doesn't `fail'--it just suddenly croaks.  Here is what I get when I run it:

pseudovar_1() = 1
pseudovar_1() = 2
pseudovar_2() = 1

Run-time error 111
File newpseudo.icn; Line 8
variable expected
offending value: 1
Traceback:
   main()
   {1 := 3} from line 8 in newpseudo.icn

Is there any other way to accomplish this end?  It's for a split application:  I write the numerical integration code, and presumably someone else writes code implementing the differential equation describing his problem, and links it to my prewritten integrator, which, I should not forget to add, contains main() and a bunch of predefined global variables beginning with "_".  Some of these must be updated by the user, others must not be.  So I would like to use this technique (or something better, if it exists) to manage the situation.

Thanks for your time and interest in advance.

Charlie Hethcoat
Oceaneering Space Systems



From icon-group-sender  Thu Feb 10 16:27:30 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA17574
	for icon-group-addresses; Thu, 10 Feb 2000 16:27:18 -0700 (MST)
Message-Id: <200002102327.QAA17574@baskerville.CS.Arizona.EDU>
From: Chris.D.Tenaglia@jci.com
Subject: Factoring ?
To: icon-group@optima.CS.Arizona.EDU
Date: Thu, 10 Feb 2000 17:11:31 -0600
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.2 (Intl)|4 November 1999) at 02/10/2000 05:18:32 PM
Content-Disposition: inline
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

--0__=4QQHSTvC554gCP08PRRPeaqn66KO2Z6uQGSPth4CdDxFxcvSimeiYQN5
Content-type: text/plain; charset=us-ascii

                                                                   Subject:
                                                  Factoring ?
                                                             Attachment(s):
                                                  <font size=-1></font>

I noticed some discussion about factoring. I heard there is one in the IPL.
Here is a simple brute force factoring sample. It uses fct.dat which is a
file containing the series of prime number as high as you like. Nothing
fancy here. But it occurs to me that it might be interesting to experiment
with other number series in the file. Keep ot toss, enjoy....

procedure main(param)
  x      := param[1]
  value  := x
  limit  := sqrt(x) + 2
  primo  := open("fct.dat")
  primes := []
  every number := !primo do
    {
    (number < limit) | break
    put(primes,number)
    }
  close(primo)
  factors := []
  every number := !primes do
    {
    repeat
      {
      if x%number = 0 then
        {
        put(factors,number)
        x /:= number
        } else {
        break next
        }
      }
    }
  write("\n")
  write("The factors of ",value, " are:")
  every writes(!factors,", ")
  if x > 1 then write(" and ",x)
  write("\n")
  end


(Embedded image moved to file: pic20891.pcx)


--0__=4QQHSTvC554gCP08PRRPeaqn66KO2Z6uQGSPth4CdDxFxcvSimeiYQN5
Content-type: application/octet-stream; 
	name="pic20891.pcx"
Content-Disposition: attachment; filename="pic20891.pcx"
Content-Description: Paintbrush
Content-Transfer-Encoding: base64

CgUBCAAAAAAJAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABCgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADGAMMAAMYAwwAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--0__=4QQHSTvC554gCP08PRRPeaqn66KO2Z6uQGSPth4CdDxFxcvSimeiYQN5--



From icon-group-sender  Mon Feb 14 16:30:51 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA06527
	for icon-group-addresses; Mon, 14 Feb 2000 16:29:38 -0700 (MST)
Message-Id: <200002142329.QAA06527@baskerville.CS.Arizona.EDU>
Date: Mon, 14 Feb 2000 13:36:48 -0600 (CST)
From: John Paolillo <johnp@ling.uta.edu>
To: icon-group@optima.CS.Arizona.EDU
Subject: Co-expressions and backtracking in Icon (& Scheme)
Cc: johnp@ling.uta.edu
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Dear Icon Folks,

I currently planning a pair of intro NLP courses for 
non-programming linguists, to be taught at Indiana
University (I'll be visiting from next year).  
At different times in the past, I have used Icon and 
Prolog for these purposes.  

The problem is that (so I have been told) Indiana 
University is very heavily Scheme-oriented (at least with
respect to AI).  Although I don't look forward to 
the learning curve, I decided to look into what it 
would mean to use Scheme instead of Prolog or Icon.
Now I have a couple of questions about the languages
I'm hoping others could help me with.

For exotic types of control, Icon has both goal-
directed search (backtracking) and co-expressions.
I haven't used co-expressions ever, although I have
found backtracking, which resembles that of Prolog,
to be useful.  Scheme has a notion of the "continuation"
which I haven't found a clear explanation of yet.
I gather from various documentation that continuations
can be used to implement backtracking and co-routines,
as well as other types of control-passing.  What 
confounds me is that scheme has other control 
structures such as (delay <expression>) and 
(force <expression>) which look more like what one
does with coexpressions in Icon, and I can't tell 
if/how these might refer to the current continuation.

The repeated mention of backtracking and co-routines
in conjunction with one another, and the sudden 
realization that they may be similar in important ways
(saving a computational state to resume its computation
later), makes me wonder whether one might be able
to implement backtracking with co-expressions (seems 
plausible, not that you would want to) and whether
they share some aspect of their implementation in Icon.  
Can anyone explain the relationship between the two
in Icon?  And can anyone speak to the relationship
between the control aparatus of Scheme and that of 
Icon?  

Any help at all will help me in planning what my
courses should be like long term.  Of course, I'd
rather use Icon than Scheme, since I understand
it better, and have taught it in the same context, so
pointers to NLP work in Icon would be welcome too.

John Paolillo
UT Arlington Linguistics.



From icon-group-sender  Tue Feb 15 12:36:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA16209
	for icon-group-addresses; Tue, 15 Feb 2000 12:33:49 -0700 (MST)
Message-Id: <200002151933.MAA16209@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: Co-expressions and backtracking in Icon (& Scheme)
Date: Tue, 15 Feb 2000 09:26:44 -0700
X-Trace: noao.edu 950632005 72362 140.252.38.6 (15 Feb 2000 16:26:45 GMT)
X-Complaints-To: abuse@noao.edu
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

John Paolillo wrote:

> The repeated mention of backtracking and co-routines
> in conjunction with one another, and the sudden
> realization that they may be similar in important ways
> (saving a computational state to resume its computation
> later), makes me wonder whether one might be able
> to implement backtracking with co-expressions (seems
> plausible, not that you would want to) and whether
> they share some aspect of their implementation in Icon.
> Can anyone explain the relationship between the two
> in Icon?  And can anyone speak to the relationship
> between the control aparatus of Scheme and that of
> Icon?

John - There is nothing shared in the implementation of 
   backtracking and co-expressions (unless someone has
   changed that in the last couple of decades!).  They
   are complementary concepts, where the combination is
   interesting. (Without backtracking [goal-directed evaluation],
   co-expressions only implement the same functionality as
   coroutines in other languages.)  The ability to
   "capture" GDE within a co-expression lends itself
   nicely to concise representations for algorithms that
   otherwise would be considerably more difficult to express.

   Loosely speaking, during GDE, the state that is saved is
   only the immediate context *within* the expression, where 
   co-expressions "save" the context (local environment) in
   which expressions appear.

   Co-expression are more closely aligned (implementation-wise)
   with threads in other languages - in fact, it wouldn't be
   hard to modify the implementation to support thread-behavior.
   (I think that Kelvin Nilsen did this as part of his PhD, but
   it's been a while and I could be mistaken...) It would be hard,
   however, to think through the consequences of doing so.


--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Tue Feb 15 13:07:26 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA19253
	for icon-group-addresses; Tue, 15 Feb 2000 13:06:58 -0700 (MST)
Message-Id: <200002152006.NAA19253@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: agate.berkeley.edu: news set sender to <news> using -f
From: Jerry Leichter <leichter@smarts.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Co-expressions and backtracking in Icon (& Scheme)
Date: Tue, 15 Feb 2000 11:31:52 -0500
X-Trace: versa.smarts.com 950632312 3856 198.49.114.99 (15 Feb 2000 16:31:52 GMT)
X-Complaints-To: usenet@news.smarts.com
To: John Paolillo <johnp@ling.uta.edu>
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

| ...The repeated mention of backtracking and co-routines
| in conjunction with one another, and the sudden
| realization that they may be similar in important ways
| (saving a computational state to resume its computation
| later), makes me wonder whether one might be able
| to implement backtracking with co-expressions (seems
| plausible, not that you would want to) and whether
| they share some aspect of their implementation in Icon.
| Can anyone explain the relationship between the two
| in Icon?  And can anyone speak to the relationship
| between the control aparatus of Scheme and that of
| Icon?

You are asking about complex issues about which many papers have been
written over many years.

Let's first look at backtracking and co-expressions.

Starting in the late 1960's, Ralph Griswold (and others) developed a
serious of languages named SNOBOL; the last and most successful was
SNOBOL4 (which is still available).  SNOBOL was based on pattern
matching, which required full backtracking.  (The string analysis
routines of Icon model the original SNOBOL string matching.)  SNOBOL was
fully interpreted in the original implementation (though partially
compiled implementations came later).  It used two stacks to implement
pattern matching.

In (I think) the late '70's, Griswold developed an experiment language
called SL5.  SL5 was inspired by a different approach to handling
backtracking:  It used coroutines.  (A coroutine is like a function, but
instead of simply returning, it can "suspend".  Later, you can "resume"
the coroutine where it last suspended.  This has a bit of a similarity
to multiple threads, but the usage is entirely different:  Only one
coroutine ever runs at a time, and all transfers of control are
explicitly programmed.)  Using coroutines, one could re-implement all
the SNOBOL pattern matching stuff in a very general and powerful way.
(SL5 also generalized a number of other ideas that were in SNOBOL, such
as "I/O bound variables".  But those are not of real interest here.)
Using the same general framework, one could use SL5 to go general
backtracking as well.

SL5 was an experiment to see how far one could push these ideas.  Icon
had its genesis in picking out some of the ideas in SL5 that had proved
to be useful.  Also, it was found that there was a much more efficient
way to implement those pieces of the coroutine model actually needed for
backtracking using stack manipulation.  This became the basis of the
Icon approach to backtracking.  (Actually, there was a short-lived
experimental language called CG - C with Generators - that provided
generators in C using the same stack manipulation trick.)  Icon focused
on fully integrating the backtracking model - and string scanning, the
algorithm that originally inspired it - into the rest of the language.
(In SNOBOL, you essentially had a goal-directed pattern matching
language embedded in a traditional imperative language.)  In fact,
coexpressions - a form of coroutine control bound to syntactic
expressions, rather than function calls - weren't in the original
version of Icon; they were added a number of years later.  Yes, you
could implement backtracking using coexpressions - that's going back to
the original SL5 model.  However, the result wouldn't be particularly
efficient.

Scheme and its continuations is the product of yet another long
evolution.  I won't try to go into a full history here; rather, I'll
suummarize what a continuation is.  (This is my own description; others
describe it in different ways.)  Think about what happens when you call
a function.  First, arguments are pushed on the stack.  Then control is
transfered to the function.  It computes, and eventually returns.

Well, actually, the implementation has to do more:  For return to work,
before transfering control, it has to pass the address to return to.
Let's make that explicit:  Let's pretend the return address is passed as
another argument.  Rather than a return, we just "go to" the return
address.  That *almost* simulates the effect of return.  The problem is
that the stack also has to be restored to what it was before the
function was called.  Implementations do that implicitly - they either
know how much space to clear off the stack, or save the actual old stack
address.  So let's make *that* explicit, to:  Pass as an argument a
special data structure, called a closure, that contains both the address
at which to continue, and what the stack should be set to.  (The reason
this is called a "closure" is that it "closes up" all the information
needed to continue execution of a function from where it was.  In fact,
that - not a pair of addresses - is the definition of a closure; real
implementations may need to worry about saving other machine state.)

So far, we've just come up with fancy names for things without adding
anything real to the language.  Things get interesting when we allow a
program to *save* one of these closure objects - and invoke it
repeatedly.  The result is very much like a coroutine (or coexpression)
- and it turns out that it's extremely powerful.  It also leads to
virtually incomprehensible programs unless very, very carefully used. 
Usually, if you see a piece of code like:

	f();
	g();
	return;

you can reason that first f() is called, then g() is called, then we
return.  But if f() can "capture" the closure at its return point -
known as its continuation - then code elsewhere could jump back at the
call to g() any number of times, without f() running again.

Generally, explicit use of closures and continuations is discouraged as
a result:  They get used heavily inside of macros and as a compiler
technique, but few Scheme users ever use call-cc (call with current
continuation, which makes the current continuation into an explicit
argument).  However, it *is* possible to use these techniques to do what
arbitrary coroutines could do, including backtracking and generators.

							-- Jerry


From icon-group-sender  Tue Feb 15 16:26:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA12322
	for icon-group-addresses; Tue, 15 Feb 2000 16:26:38 -0700 (MST)
Message-Id: <200002152326.QAA12322@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 15 Feb 2000 15:25:42 -0600
Subject: Re: Co-expressions and backtracking in Icon (& Scheme)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>   Co-expression are more closely aligned (implementation-wise)
   with threads in other languages - in fact, it wouldn't be
   hard to modify the implementation to support thread-behavior.
   (I think that Kelvin Nilsen did this as part of his PhD, but
   it's been a while and I could be mistaken...) It would be hard,
   however, to think through the consequences of doing so.

This whole interesting discussion (co-expressions in conjunction with 
backtracking) brings up a point I hadn't considered before.

Obviously, the normal use of a co-expression involves it being called once with 
a given set of parameters, and then (normally) being resumed to return 
additional values out of a sequence of results.

But in the meantime, it's certainly possible (when backtracking, for example) to 
abandon a given invocation before all its possible return values are exhausted. 
 It's also possible (right?) to call the same coexpression again with a 
DIFFERENT set of parameters (establishing a different sequence of results to be 
returned).  And of course I'd imagine that it's also possible to call the 
coexpression again, even with a set of parameters that HAPPENS to be the same as 
a previous initiation that's still in suspense.

So how do coroutines decide whether to initiate a new return sequence, or 
specifically how and when do they decide that a suspended sequence of results is 
NEVER going to be needed?  What allows them to release the memory that 
(presumably) they're using to save their state?

One could even imagine that a coroutine is called by another coroutine, such 
that the same calling location could have several invocations of a given 
(sub-)coroutine active simultaneously...

What am I missing here?

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Wed Feb 16 12:24:56 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA27793
	for icon-group-addresses; Wed, 16 Feb 2000 12:23:12 -0700 (MST)
Message-Id: <200002161923.MAA27793@baskerville.CS.Arizona.EDU>
Date: Wed, 16 Feb 2000 11:57:28 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: gep2@terabites.com
CC: icon-group@optima.CS.Arizona.EDU
Subject: Re: Co-expressions and backtracking in Icon (& Scheme)
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

gep2@terabites.com wrote:
> 
> >   Co-expression are more closely aligned (implementation-wise)
>    with threads in other languages - in fact, it wouldn't be
>    hard to modify the implementation to support thread-behavior.
>    (I think that Kelvin Nilsen did this as part of his PhD, but
>    it's been a while and I could be mistaken...) It would be hard,
>    however, to think through the consequences of doing so.
> 
> This whole interesting discussion (co-expressions in conjunction with
> backtracking) brings up a point I hadn't considered before.
> 
> Obviously, the normal use of a co-expression involves it being called once with
> a given set of parameters, and then (normally) being resumed to return
> additional values out of a sequence of results.
> 
> But in the meantime, it's certainly possible (when backtracking, for example) to
> abandon a given invocation before all its possible return values are exhausted.
>  It's also possible (right?) to call the same coexpression again with a
> DIFFERENT set of parameters (establishing a different sequence of results to be
> returned).  And of course I'd imagine that it's also possible to call the
> coexpression again, even with a set of parameters that HAPPENS to be the same as
> a previous initiation that's still in suspense.
> 
> So how do coroutines decide whether to initiate a new return sequence, or
> specifically how and when do they decide that a suspended sequence of results is
> NEVER going to be needed?  What allows them to release the memory that
> (presumably) they're using to save their state?
> 
> One could even imagine that a coroutine is called by another coroutine, such
> that the same calling location could have several invocations of a given
> (sub-)coroutine active simultaneously...
> 
> What am I missing here?

Gordon - I think you are giving co-expressions more functionality than they
   deserve...

   It might be useful to look at the implementation (which is surprising
simple).
   I'm not sure the following is 100% accurate anymore - it's been a long time
   since I designed it, so I've forgotten the details, but who's to say it
hasn't
   changed since them.

   Forgetting about co-expressions for the moment and looking at a typical
   (Icon) execution stack at any moment in the execution, you'll see something
   like (drawn with the stack "top" at the bottom, of course...):

       |         .          |
       |         .          |
       |---- locals for FOO |  <--- start of environment for an instance of
       |         .          |          procedure FOO (includes parameters)
       |---- transient vals |  <--- values pushed during evaluation of the
       |         .          |          current expression (everything since
       |         .          |          the last Goal-directed evaluation bound)

   So, when a create expr is encountered, all that needs to be associated with
   the coexpression are the *current* values of the local area for the current
   procedure instance.  In effect, this means copying the locals area above
   into the heap.  Of course, you'll probably want to evaluate "expr" at some
   point, so you also need room for the transient values - so the heap
representation
   of the coexpression also includes room for these.  This heap value is thus
   a copy of a segment of the evaluation stack and the evaluation of expr can
   proceed in this segment copy just as easily as in the original eval stack.

   The net effect is that this heap object looks for all the world like
   the stack environment for a procedure that's being executed.  (This is
   an important way to view it, as you'll see later.)

   Now, looking at the co-expression operations:

       @ce     -- simply changes the machines stack pointer (and stack-limit
                       register if there is one) to the stack segment in the
                       heap object for the co-expression and transfers program
                       control to the expression in much the same way that
                       backtracking through a suspend transfers program control.

      r@ce     -- copies the result r onto the top of ce's stack segment and
                       performs the above operations.

      In both cases, the procedure resuming the ce behaves as if it is calling
      another procedure.  When control returns, any value produced by the ce
      will be on top of the stack.

      return (from ce) and
      suspend (from ce) -- copy the top value of the stack segment back to
            the "real" execution stack and resume execution in that environment.

   That's really not much to do (and part of the reason by co-expression
invocation
   is reasonably efficient).

   The magic, and what makes co-expressions "nicer" than co-routines is when
   the captured expression is a generator, but that just falls out thanks to the
   universal nature of GDE in Icon.

   Finally getting back to your questions:

   (1) There is only one invocation (execution environment) for a given
       co-expression.  There is no way to really think of having several
       invocations active at once (it's just that this single invocation
       doesn't care who is going to receive the next result that it
       produces).

   (2) Co-expressions don't release their memory.  The memory is freed only
       when all references to that co-expression are gone - this is consistent
       with how all other heap objects are managed.

   (3) Technically, you can't pass parameters to co-expressions - they use
       the local environment of the surrounding procedure *at the time of
       their creation*.  (In fact, if you first invoke a co-expression with
       r@ce, the value r gets tossed, since the expression that was captured
       can't be expecting a value at that point - only on subsequent invocations
       does the value of r mean anything - and then only if the expression is
       expecting a value.  Now, you can modify the environment in which the
       co-expression operates through global variable values, but this is
       the same mechanism available with 'normal' procedures.

   I hope this helps.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Feb 28 08:22:21 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA05113
	for icon-group-addresses; Mon, 28 Feb 2000 08:20:40 -0700 (MST)
Message-Id: <200002281520.IAA05113@baskerville.CS.Arizona.EDU>
From: jeffery@big-bill.CS.UNLV.EDU
To: icon-group@optima.CS.Arizona.EDU
Subject: closing a closed file
Date: Tue, 22 Feb 2000 05:42:12 -0800
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


The Icon book doesn't say what happens when you close a closed file, but
some real applications assume that it is a no-op.  On my Redhat/Mandrake
Linux system, the following program causes a memory violation in the
reference to &clock.

procedure main()
   f := open("foo.icn")
   close(f)
   close(f)
   &clock
end

So closing a closed file is a silent killer on some systems. The bug is tiny
and the fix in Icon's runtime system is trivial, but at present you may wish
to avoid closing closed files.

Clint, jeffery@cs.unlv.edu


From icon-group-sender  Mon Feb 28 12:41:59 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14946
	for icon-group-addresses; Mon, 28 Feb 2000 12:41:09 -0700 (MST)
Message-Id: <200002281941.MAA14946@baskerville.CS.Arizona.EDU>
Date: Mon, 28 Feb 2000 08:46:18 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: jeffery@big-bill.CS.UNLV.EDU,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: closing a closed file
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

jeffery@big-bill.CS.UNLV.EDU wrote:
> 
> The Icon book doesn't say what happens when you close a closed file, but
> some real applications assume that it is a no-op.  On my Redhat/Mandrake
> Linux system, the following program causes a memory violation in the
> reference to &clock.
> 
> procedure main()
>    f := open("foo.icn")
>    close(f)
>    close(f)
>    &clock
> end
> 
> So closing a closed file is a silent killer on some systems. The bug is tiny
> and the fix in Icon's runtime system is trivial, but at present you may wish
> to avoid closing closed files.

Interesting.  I don't see this under Solis (Icon 9.3) or on one Redhat 6.1
(Icon 9.3.2) system, but I do see this on another RH6.1 system (Icon 9.3.1).

I would have expected it to be a no-op, also.  

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Tue Feb 29 16:25:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA23813
	for icon-group-addresses; Tue, 29 Feb 2000 16:24:02 -0700 (MST)
Message-Id: <200002292324.QAA23813@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: kapitan.ethanak.home: ethanak owned process doing -bs
Date: Mon, 28 Feb 2000 17:43:00 +0100 (EET)
From: "Bohdan R. Rau" <ethanak@bigfoot.com>
X-Sender: ethanak@kapitan.ethanak.home
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: closing a closed file
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On Tue, 22 Feb 2000 jeffery@big-bill.CS.UNLV.EDU wrote:

> 
> The Icon book doesn't say what happens when you close a closed file, but
> some real applications assume that it is a no-op.  On my Redhat/Mandrake
> Linux system, the following program causes a memory violation in the
> reference to &clock.
> 
> procedure main()
>    f := open("foo.icn")
>    close(f)
>    close(f)
>    &clock
> end

Which version of RH? On my RH5.2 (IMHO last stable version of Red Hat)
closing the closed file is treated as no_op (your program terminates
normally).

But... when I installed new glibc I had same problems (especially with
C functions linked with Icon program). May be the problem is in glibc?
Which version of glibc You use? I reinstalled original glibc 2.0
(libc 6) and now everything is OK... Also on very old machine
with libc 5 your program does not cause any errors.

BTW IMHO file should not be closed more than one time ;-)

Regards

ethanak
http://ethanak.i.sex.pl



From icon-group-sender  Wed Mar  1 10:33:17 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA06889
	for icon-group-addresses; Wed, 1 Mar 2000 10:31:31 -0700 (MST)
Message-Id: <200003011731.KAA06889@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 29 Feb 2000 18:31:14 -0600
Subject: Re: closing a closed file
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>> The Icon book doesn't say what happens when you close a closed file, but
> some real applications assume that it is a no-op.  

That makes sense.  You close a file because you want it closed.  If it's ALREADY 
in that condition, you got what you wanted.  No biggie.

> BTW IMHO file should not be closed more than one time ;-)

IMHO the system shouldn't care.

File handles, I believe, ought to behave like other Icon items.  When you don't 
need them anymore, you simply overwrite the file handle and the file gets 
"garbage collected".  (In that case, the ENTIRE close() routine becomes a 
no-op).

Any files whose handles aren't closed before program exit ought to be closed 
when the program exits.  

I don't see a BIG problem with allowing an explicit close.  But if you reopen an 
existing file (and reuse a previously used handle) or close a file that's 
already closed, or even just forget about closing one, the system shouldn't 
really care.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Mon Mar 20 08:03:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08795
	for icon-group-addresses; Mon, 20 Mar 2000 08:01:31 -0700 (MST)
Message-Id: <200003201501.IAA08795@baskerville.CS.Arizona.EDU>
From: "Jeff Psrucha" <pyarek@home.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Printing output  9.3.1 of ICON 
Date: Sun, 19 Mar 2000 20:02:33 -0800
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BF91DE.10991BA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How to print the output of the ICON program on Windows Icon?
Version 9.3.1 of ICON for windows have a window which closes when you =
click on it.
I would appreciate you help=20

Jeff

------=_NextPart_000_000B_01BF91DE.10991BA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>How to print the output of the ICON program on =
Windows=20
Icon?</FONT></DIV>
<DIV><FONT size=3D2>Version 9.3.1 of ICON for windows have a window =
which closes=20
when you click on it.</FONT></DIV>
<DIV><FONT size=3D2>I would appreciate you help </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Jeff</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01BF91DE.10991BA0--



From icon-group-sender  Mon Mar 20 08:30:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA09977
	for icon-group-addresses; Mon, 20 Mar 2000 08:29:54 -0700 (MST)
Message-Id: <200003201529.IAA09977@baskerville.CS.Arizona.EDU>
From: Chris.D.Tenaglia@jci.com
Subject: HP-UX and getch()
To: icon-group@optima.CS.Arizona.EDU
Date: Mon, 20 Mar 2000 08:26:00 -0600
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.2 (Intl)|4 November 1999) at 03/20/2000 08:33:40 AM
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Is there a binary build or config file for HP-UX 10 and/or HP-UX 11 that
has getch() and getche()
working? X-windows would be nice too?
Thanks in advance,
Chris Tenaglia, technical analyst, (414)228-2249




From icon-group-sender  Mon Mar 20 13:26:46 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA19483
	for icon-group-addresses; Mon, 20 Mar 2000 13:26:25 -0700 (MST)
Message-Id: <200003202026.NAA19483@baskerville.CS.Arizona.EDU>
From: Chris.D.Tenaglia@jci.com
X-Newsgroups: comp.lang.icon
Subject: HP-UX and getch()
Date: 20 Mar 2000 10:32:36 -0500
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.2 (Intl)|4 November 1999) at 03/20/2000 08:33:40 AM
X-Filter: mailagent [version 3.0 PL68] for efeustel@cs.ida.org
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Is there a binary build or config file for HP-UX 10 and/or HP-UX 11 that
has getch() and getche()
working? X-windows would be nice too?
Thanks in advance,
Chris Tenaglia, technical analyst, (414)228-2249





From icon-group-sender  Wed Mar 29 17:54:06 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA11364
	for icon-group-addresses; Wed, 29 Mar 2000 17:53:10 -0700 (MST)
Message-Id: <200003300053.RAA11364@baskerville.CS.Arizona.EDU>
From: Art Eschenlauer <art.eschenlauer@sufsys.com>
To: icon-group@optima.CS.Arizona.EDU
Subject: Anyone use Icon for resource assignment?
Date: Wed, 29 Mar 2000 16:27:53 -0600
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I'm getting frustrated with Microsoft Project98's inability
to do any good "what-if" analysis.  

I'm starting to create some datastructures to solve
resource assignment problems with Icon, since the backtracking
capabilities such as are used in the queens.icn solution seem
ideal for finding acceptable solutions to these problems.

Any thoughts or suggestions? Thanks.
 
PS: Please reply to the Icon mailing list rather than directly to me.


From icon-group-sender  Thu Apr  6 09:25:12 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA14563
	for icon-group-addresses; Thu, 6 Apr 2000 09:21:45 -0700 (MST)
Message-Id: <200004061621.JAA14563@baskerville.CS.Arizona.EDU>
X-Sender: gravitmw@mail.jmu.edu
Date: Wed, 05 Apr 2000 22:09:37 -0400
To: icon-group@optima.CS.Arizona.EDU
From: Max Gravitt <gravitmw@jmu.edu>
Subject: general icon questions
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I am a Icon newbie and I have two general questions about the language.

1) Is it compiled or interpreted?  I found that you can make *.exe's, but I 
don't know if that is a sure fire way to tell how it is translated.  Does 
the translator have to be installed on the PC in order for the program to run?

2) Are there data types in the language?  One source I found said that 
there are no data types, only values.  Another source said that there were 
data types and gave a list of the types.  There may be some ambiguity on 
what a data type is.  Can anyone clear this up for me?

thanks in advance
Max



From icon-group-sender  Thu Apr  6 17:08:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28532
	for icon-group-addresses; Thu, 6 Apr 2000 17:05:46 -0700 (MST)
Message-Id: <200004070005.RAA28532@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Thu, 06 Apr 2000 17:08:17 -0500
Subject: general icon questions
To: gravitmw@jmu.edu, icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> I am a Icon newbie and I have two general questions about the language.

> 1) Is it compiled or interpreted?  

Yes.  :-)

Actually, programs compile down to a compact intermediate code which is then 
(efficiently) interpreted.

> I found that you can make *.exe's, but I don't know if that is a sure fire way 
to tell how it is translated.  

It certainly is NOT.  :-)

> Does the translator have to be installed on the PC in order for the program to 
run?

No.  All you need is the runtime/interpreter.  You do NOT have to distribute 
source code to your package to your customers.

> 2) Are there data types in the language?  One source I found said that 
there are no data types, only values.  Another source said that there were 
data types and gave a list of the types.  There may be some ambiguity on 
what a data type is.  Can anyone clear this up for me?

There are certainly distinct datatypes, although any variable (and this includes 
individual elements of tables or lists) can be (at any given point in time) any 
datatype you like, simply by assigning a value of that type to that variable or 
element.  

Does that help?

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Mon Apr 10 09:22:27 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA08883
	for icon-group-addresses; Mon, 10 Apr 2000 09:20:42 -0700 (MST)
Message-Id: <200004101620.JAA08883@baskerville.CS.Arizona.EDU>
From: "Udut, Kenneth" <kenneth.udut@spcorp.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: Are these all functions that deal with text?
Date: Fri, 7 Apr 2000 12:23:00 -0400 
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hi - name's Kenneth - I'm new to the group, and new to ICON.

Looking through a list of functions, I am wondering if
this is an accurate list of functions that deal pretty
much solely with text, user i/o, and common file reading tasks?


# locate initial character 	
any(c,s,i1,i2) : i3 

# position string at center 	
center(s1,i,s2) : s3 

# produce character 	
char(i) : s 

# remove tabs 	
detab(s1,i1,i2,...,in) : s2 

# insert tabs 	
entab(s1,i1,i2,...,in) : s2 

# find string 	
find(s1,s2,i1,i2) : i3,i4,...,iN 

# produce string image 	
image(x) : s 

# position string at left 	
left(s1,i,s2) : s3 

# locate many characters 	
many(c,s,i1,i2) : i3 

# map characters 	
map(s1,s2,s3) : s4 

# match initial string 	
match(s1,s2,i1,i2) : i3 

# replicate string 	
repl(s1,i) : s2 

# reverse string 	
reverse(s1) : s2 

# position string at right 	
right(s1,i,s2) : s3 

# convert to string 	
string(x) : s 

# set scanning position 	
tab(i) : s 

# create table 	
table(x) : T 

# trim string 	
trim(s1,c) : s2 

# locate characters 	
upto(c,s,i1,i2) : i3,i4,...,in 

# write line 	
write(x1,x2,...,xn) : xn 

# write string 	
writes(x1,x2,...,xn) 


# get keyboard character 	
getch() : s 

# get and echo keyboard character 	
getche() : s 

# check for keyboard character 	
kbhit() : n 

# read line 	
read(f) : s 

# read string 	
reads(f,i) : s 


The reason I ask is that I am going from
Visual Basic for applications (Microsoft Excel and
Access mostly, although I've used it for Word), 
and I did some work in Turbo Pascal 6 many years back...

and want to know if this is an appropriate list
to start with?

-Kenneth


From icon-group-sender  Mon Apr 10 09:23:21 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA08937
	for icon-group-addresses; Mon, 10 Apr 2000 09:23:13 -0700 (MST)
Message-Id: <200004101623.JAA08937@baskerville.CS.Arizona.EDU>
From: "Udut, Kenneth" <kenneth.udut@spcorp.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: s1 ~=== s2  :  s2
Date: Fri, 7 Apr 2000 12:35:06 -0400 
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

My question:

>From the helpfile:

s1 ~=== s2 : s2 -- compare values 

x1 ~=== x2 produces the value of x2 
if x1 and x2 do not have the same value, but fails otherwise. 


Now - I'm wondering, is this the same
as saying in BASIC:

PROCEDURE COMPARE()

	A$=""
	IF X$ <> Y$, THEN LET A$=Y$

END


Or, one of my favorite little formulas in
Excel:

=if(a2=a1,"",a2)


Is the 

s1 ~=== s2: s2

the same as that Excel function or that visual basic procedure?


-Kenneth


From icon-group-sender  Mon Apr 10 09:24:37 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA09039
	for icon-group-addresses; Mon, 10 Apr 2000 09:24:29 -0700 (MST)
Message-Id: <200004101624.JAA09039@baskerville.CS.Arizona.EDU>
From: "Udut, Kenneth" <kenneth.udut@spcorp.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: Am I understanding this correctly?  [icon --> English-ish sentenc
	e]
Date: Fri, 7 Apr 2000 13:28:01 -0400 
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I found the answers to a few of the questions
that I had by finding the 'intro to icon' helpfules.

I am wondering if I am understanding the following
correctly:

	every write(find("or", sentence1 | sentence2))

Is that saying:

Every time the following 
is true, 
write the found "or"s 
in sentence1 and sentence2.

Or, put another way:

EVERY        time the following is true
WRITE        the 
FIND         ed 
("OR",       in 
SENTENCE1 
|            and in
SENTENCE2))



Would this be accurate?

thanks!

-Kenneth


From icon-group-sender  Mon Apr 10 09:25:09 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA09080
	for icon-group-addresses; Mon, 10 Apr 2000 09:24:54 -0700 (MST)
Message-Id: <200004101624.JAA09080@baskerville.CS.Arizona.EDU>
Date: Fri, 07 Apr 2000 15:00:06 -0400
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Re: general icon questions
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id LAA00396
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

To qualify one of Gordon's comments:  With the MS-DOS version I can compile an application and run the latter without the runtime/interpreter.  Actually, I believe it is embedded in the compiled version.


Steve

---------------------------------------------------------------------------------------
Steve Graham
Senior Programmer/Analyst
LabCorp

Phone: (972) 437-5255, ext 5224
Fax:     (972) 454-1040
Mail:    grahams@labcorp.com

>>> <gep2@terabites.com> 04/06/00 05:08PM >>>
> I am a Icon newbie and I have two general questions about the language.

> 1) Is it compiled or interpreted?  

Yes.  :-)

Actually, programs compile down to a compact intermediate code which is then 
(efficiently) interpreted.

> I found that you can make *.exe's, but I don't know if that is a sure fire way 
to tell how it is translated.  

It certainly is NOT.  :-)

> Does the translator have to be installed on the PC in order for the program to 
run?

No.  All you need is the runtime/interpreter.  You do NOT have to distribute 
source code to your package to your customers.

> 2) Are there data types in the language?  One source I found said that 
there are no data types, only values.  Another source said that there were 
data types and gave a list of the types.  There may be some ambiguity on 
what a data type is.  Can anyone clear this up for me?

There are certainly distinct datatypes, although any variable (and this includes 
individual elements of tables or lists) can be (at any given point in time) any 
datatype you like, simply by assigning a value of that type to that variable or 
element.  

Does that help?

Gordon Peterson
http://web2.airmail.net/gep2/ 
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/ 
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!





From icon-group-sender  Mon Apr 10 09:43:00 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA09624
	for icon-group-addresses; Mon, 10 Apr 2000 09:42:48 -0700 (MST)
Message-Id: <200004101642.JAA09624@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Reversible assignment really reversible ?
X-Newsreader: Forte Agent 1.7/32.534
Date: Sat, 08 Apr 2000 18:16:38 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: nlnews00.chello.com 955217798 212.187.67.243 (Sat, 08 Apr 2000 17:16:38 GMT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

# WINICON 9.3.1

procedure main()
local i1,i2,i3,j1,j2,k,a1,a2,a3
i1:=2
j1:=4
i2:=4; i3:=i2
j2:=2
k:=3

# co-exp creation & @ctivation not really necessary
a1:=create((i1 <- j1) > k)
a2:=create((i2 <- j2) > k)
a3:=create(((i2:=j2)|(i2:=i3)) > k)

write(@a3)
write("co-exp1: ",@a1)
write("nested1: ",((i1 <- j1) > k))
write("muteva1: ",((i1 <- j1) & (i1 > k)))

# the following set doesn't work, so is   <- 
# really implemented or just an alias for :=  ?
write("co-exp2: ",@a2)
write("nested2: ",((i2 <- j2) > k))
write("muteva2: ",((i2 <- j2) & (i2 > k)))
                                             
end



From icon-group-sender  Mon Apr 10 09:51:28 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA09968
	for icon-group-addresses; Mon, 10 Apr 2000 09:51:21 -0700 (MST)
Message-Id: <200004101651.JAA09968@baskerville.CS.Arizona.EDU>
From: Art Eschenlauer <art.eschenlauer@sufsys.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: Has anyone written a SQL/DDL parser in Icon?
Date: Sun, 9 Apr 2000 00:05:54 -0500 
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I want to automate production of PL/SQL code from Oracle DDL and 
will most likely use Icon to do it.

I thought that I should ask if anyone else has done SQL parsing
with Icon.  Thanks.


From icon-group-sender  Mon Apr 10 09:55:10 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA10150
	for icon-group-addresses; Mon, 10 Apr 2000 09:55:00 -0700 (MST)
Message-Id: <200004101655.JAA10150@baskerville.CS.Arizona.EDU>
Date: Sun, 9 Apr 2000 22:17:13 -0700 (PDT)
From: WINNER <m_dammas@excite.com>
To: icon-group@optima.CS.Arizona.EDU
Subject: need help
X-Sender-Ip: 64.6.6.60
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Please help me to answer the following question:

Is ICON a vlock-structural language?
What are the reserve words in ICON?
How I can build 
    - Control structures
    - Scope
    - I/O.






_______________________________________________________
Get 100% FREE Internet Access powered by Excite
Visit http://freelane.excite.com/freeisp



From icon-group-sender  Mon Apr 10 10:02:25 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA10627
	for icon-group-addresses; Mon, 10 Apr 2000 10:02:17 -0700 (MST)
Message-Id: <200004101702.KAA10627@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Apr 2000 09:38:14 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: "Udut, Kenneth" <kenneth.udut@spcorp.com>,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Am I understanding this correctly?  [icon --> English-ish sentence]
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Udut, Kenneth" wrote:
> 
> I found the answers to a few of the questions
> that I had by finding the 'intro to icon' helpfules.
> 
> I am wondering if I am understanding the following
> correctly:
> 
>         every write(find("or", sentence1 | sentence2))
> 
> Is that saying:
> 
> Every time the following
> is true,
> write the found "or"s
> in sentence1 and sentence2.
> 
> Or, put another way:
> 
> EVERY        time the following is true
> WRITE        the
> FIND         ed
> ("OR",       in
> SENTENCE1
> |            and in
> SENTENCE2))
> 
> Would this be accurate?

Sort of.   There's no concept of "true" or "false" in Icon,
so this view tends to lead you away from "thinking in Icon".

It's more accurate to read this as:

  Write out every position that "or" appears in first sentence1 and then
  in sentence2.

I realize this doesn't lend itself to automatic icon-to-english translations.

  




--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Apr 10 10:02:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA10658
	for icon-group-addresses; Mon, 10 Apr 2000 10:02:36 -0700 (MST)
Message-Id: <200004101702.KAA10658@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Mon, 10 Apr 2000 11:55:46 -0500
Subject: Are these all functions that deal with text?
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> Hi - name's Kenneth - I'm new to the group, and new to ICON.

Welcome!

> Looking through a list of functions, I am wondering if
this is an accurate list of functions that deal pretty
much solely with text, user i/o, and common file reading tasks?

Well, mostly.  Note that things which are NOT text (integers for example) will 
be converted to strings automatically (so you can, for example, deal with digits 
of an integer as if it were a character string, and then even do further 
arithmetic on the result).  And some of the routines you listed (table() for 
example) can work with *any* Icon data type and don't require conversion.

> ...The reason I ask is that I am going from
Visual Basic for applications (Microsoft Excel and
Access mostly, although I've used it for Word), 

Boy, are YOU in for some fun!  :-))  Icon is a cool language.

> ....and I did some work in Turbo Pascal 6 many years back...

You're going to really appreciate how nice it is to not have to worry about data 
typeing....

> and want to know if this is an appropriate list to start with?

I'm not sure what you mean by "appropriate".  For what purpose?  As a limit?  
Something else?

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Mon Apr 10 10:14:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA11146
	for icon-group-addresses; Mon, 10 Apr 2000 10:14:24 -0700 (MST)
Message-Id: <200004101714.KAA11146@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Apr 2000 09:48:05 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: "Udut, Kenneth" <kenneth.udut@spcorp.com>,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: s1 ~=== s2  :  s2
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Udut, Kenneth" wrote:
> 
> My question:
> 
> >From the helpfile:
> 
> s1 ~=== s2 : s2 -- compare values
> 
> x1 ~=== x2 produces the value of x2
> if x1 and x2 do not have the same value, but fails otherwise.
> 
> Now - I'm wondering, is this the same
> as saying in BASIC:
> 
> PROCEDURE COMPARE()
> 
>         A$=""
>         IF X$ <> Y$, THEN LET A$=Y$
> 
> END
> 
> Or, one of my favorite little formulas in
> Excel:
> 
> =if(a2=a1,"",a2)
> 
> Is the
> 
> s1 ~=== s2: s2
> 
> the same as that Excel function or that visual basic procedure?
> 
> -Kenneth

No.  Also, carefully consider the differences in Icon between == (~==) and
=== (~===).  It's unlikely that ~=== is equivalent to <> in BASIC.

However, s1 ~== s2 is very close to both of the above. (I assume that
A$ gets returned by the COMPARE procedure in BASIC?)

The fundamental difference is on expression failure (not a concept in
either BASIC or excel, hence the difficulty in mapping).

For example, to match the excel expression, you'd need:

    (s1 ~== s2) | ""

though you probably don't want to produce an exact match anyway, as that
takes away the advantages offered by having expressions succeed or fail.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Apr 10 10:15:07 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA11195
	for icon-group-addresses; Mon, 10 Apr 2000 10:14:54 -0700 (MST)
Message-Id: <200004101714.KAA11195@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Apr 2000 09:58:51 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Reversible assignment really reversible ?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" wrote:
> 
> # WINICON 9.3.1
> 
> procedure main()
> local i1,i2,i3,j1,j2,k,a1,a2,a3
> i1:=2
> j1:=4
> i2:=4; i3:=i2
> j2:=2
> k:=3
> 
> # co-exp creation & @ctivation not really necessary
> a1:=create((i1 <- j1) > k)
> a2:=create((i2 <- j2) > k)
> a3:=create(((i2:=j2)|(i2:=i3)) > k)
> 
> write(@a3)
> write("co-exp1: ",@a1)
> write("nested1: ",((i1 <- j1) > k))
> write("muteva1: ",((i1 <- j1) & (i1 > k)))
> 
> # the following set doesn't work, so is   <-
> # really implemented or just an alias for :=  ?
> write("co-exp2: ",@a2)
> write("nested2: ",((i2 <- j2) > k))
> write("muteva2: ",((i2 <- j2) & (i2 > k)))
> 
> end

Reversible assignment really works, but not as you're picturing its use.
The assignment is reversible only so long as you're staying in the same
evaluation context (w.r.t. success and failure).  That is, the assignment
reverses ONLY if you backtrack into it.  Try the following:

   i1 := 0
   every write("i1 is ", i1 <- 1 to 3)
   write("i1 is now ", i1)

Also note that reversible assignment fails after it has reversed itself.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Apr 10 13:04:01 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA16880
	for icon-group-addresses; Mon, 10 Apr 2000 13:01:07 -0700 (MST)
Message-Id: <200004102001.NAA16880@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Mon, 10 Apr 2000 14:11:15 -0000
X-Trace: client 955390287 38.163.203.81 (Mon, 10 Apr 2000 14:11:27 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Yes, reversible assignment really is implemented. The problem is due to two
flaws in your test.

First of all, when a local variable is used in a co-expression, the
co-expression includes a copy of that variable. For example, after executing
the expression

> a1:=create((i1 <- j1) > k)

the co-expression a1 has its own copy of the variables i1, j1, and k. The
copies of the i1, j1 and k variables used in a1 are independent of the
variables in the main procedure. Thus, activating a1 can only alter the
value of its own local copy of i1, not the i1 variable defined in main, nor
any copy of i1 that may exist in other co-expressions.

Clearly, your intention is that there be only one copy of the variables i1,
i2, etc that will be used by main and the three co-expressions. To get this
effect, you need to declare these variables to have a non-local scope. I
would recommend that they be declare these variables to be static; in place
of

> local i1,i2,i3,j1,j2,k,a1,a2,a3

use this instead:

    static i1,i2,i3,j1,j2,k
    local a1,a2,a3

Now, once we make the change in the scope of the variables, consider what
happens when we activate a2, where

    i2:=4; j2:=2; k:=3
    a2:=create((i2 <- j2) > k)

When (i2<-j2) is evaluated, i2 is set to 2 and "<-" suspends with i2. Then
(i2 > k) fails (since i2 = 2 < 3 = k), so we resume the (i2<-j2) expression.
When (i2<-j2) is resumed, the previous value of i2 (4) is restored, and then
this expression fails. With no other suspended expressions to resume, the
whole expression ((i2 <-j2) > k) fails. Thus @a2 SHOULD fail if Icon is
working properly! Similarly, the expressions

    ((i2 <- j2) > k)
    ((i2 <- j2) & (i2 > k))

should (and do) fail. It is therefore not surprising that the last three
write calls produce no output.

To confirm that the assignment of i2 in @a2 has been reversed, try inserting
this call

    write("i2=",i2,",j2=",j2)

before and after the activation of a2. You will see that the assignment (i2
<- j2) has been reversed.


"F.G. van DORP" <F.G.van.Dorp@digimedia.nl> wrote in message
news:gqtues8c3cp5jaf9h9u6akcalmv6c1ddfb@4ax.com...
> # WINICON 9.3.1
>
> procedure main()
> i1:=2
> j1:=4
> i2:=4; i3:=i2
> j2:=2
> k:=3
>
> # co-exp creation & @ctivation not really necessary
> a2:=create((i2 <- j2) > k)
> a3:=create(((i2:=j2)|(i2:=i3)) > k)
>
> write(@a3)
> write("co-exp1: ",@a1)
> write("nested1: ",((i1 <- j1) > k))
> write("muteva1: ",((i1 <- j1) & (i1 > k)))
>
> # the following set doesn't work, so is   <-
> # really implemented or just an alias for :=  ?
> write("co-exp2: ",@a2)
> write("nested2: ",((i2 <- j2) > k))
> write("muteva2: ",((i2 <- j2) & (i2 > k)))
>
> end
>




From icon-group-sender  Mon Apr 10 13:04:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA17029
	for icon-group-addresses; Mon, 10 Apr 2000 13:04:23 -0700 (MST)
Message-Id: <200004102004.NAA17029@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Apr 2000 15:00:03 -0400 (EDT)
From: Taybin Rutkin <trutkin@black.clarku.edu>
To: icon-group@optima.CS.Arizona.EDU
Subject: Crow: a messaging Icon
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello, just wanted to make a small announcement:
Ahem

I've created a preprocessor for Icon that extends Icon to make it a
messaging language.  Not messaging in the Rebol sense but messaging in the
concurrent/messaging-algorithm sense.  The program, Crow, takes a Crow
file and translates it to Icon.  It also does fun stuff like appending a
runtime system to simulate concurrency and stuff like that.  So it's a
superset of Icon.

Anyways, documentation, source code, and examples are located at
http://www.clarku.edu/~trutkin/Crow/index.html

Taybin Rutkin -- trutkin@black.clarku.edu



From icon-group-sender  Wed Apr 12 09:23:10 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA05391
	for icon-group-addresses; Wed, 12 Apr 2000 09:22:02 -0700 (MST)
Message-Id: <200004121622.JAA05391@baskerville.CS.Arizona.EDU>
Date: Tue, 11 Apr 2000 23:23:36 -0400 (EDT)
From: Taybin Rutkin <trutkin@black.clarku.edu>
To: icon-group@optima.CS.Arizona.EDU
Subject: Idol function pointers
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I hope this is the right forum to discuss Idol...

How would I pass a method as a variable?  I'm trying to create an event
system.  The call I'm using is

edges$watch(vertices$E_Update)

watch is the function that links the method to a list of procedures.  I'm
trying to call a method in a specific object.  vertices is the instance 
and E_Update is the method that should be called at a later date.  The
code works fine if I use a regular procedure.  I poked through the Icon 
output but the code it generated for that line was:

edges.__m.watch(edges,vertices.__m.E_Update(vertices))

I mostly understand that line, so I guess I need a way to remove the
vertices arguement at the end.

Any hints?

Taybin

Taybin Rutkin -- trutkin@black.clarku.edu



From icon-group-sender  Wed Apr 12 09:24:02 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA05468
	for icon-group-addresses; Wed, 12 Apr 2000 09:23:55 -0700 (MST)
Message-Id: <200004121623.JAA05468@baskerville.CS.Arizona.EDU>
From: eddie@holyrood.ed.ac.uk (Eddie Corns)
X-Newsgroups: comp.lang.icon
Subject: changes to proc() ??
Date: 12 Apr 2000 11:27:24 GMT
X-Trace: scotsman.ed.ac.uk 955538844 3603 129.215.16.14 (12 Apr 2000 11:27:24 GMT)
X-Complaints-To: usenet@scotsman.ed.ac.uk
X-Newsreader: NN version 6.5.0 #2 (NOV)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello world,

Have there been any changes to the proc() procedure lately.  I'm writing a tiny
little interpreter and wanted to make use of calling my procedures by
evaluating the commands read from the input stream.  So f'rinstance I have:

procedure show()
        every writes(!sort(stack[-1])," ")
    write("")
end

then later on:

 if line == !ops then
   x := proc(line)
   x()

(except with {} - I must stop my newsreader from using vi).

Anyway, my reading of the book suggests this should work and indeed on an old
version of the interpreter I have lying around it does work but not on newer
ones.  The version I tested on linux which fails is 9.3.2, I think the Solaris
version which faile is 9.0.? and the Solaris version which worked is unknown.

I couldn't find any reference in the docs except an old (9.0) version documenting
the addition of 0 as the second arg.

Thanks,
Eddie



From icon-group-sender  Wed Apr 12 10:26:43 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA07719
	for icon-group-addresses; Wed, 12 Apr 2000 10:26:25 -0700 (MST)
Message-Id: <200004121726.KAA07719@baskerville.CS.Arizona.EDU>
Date: Wed, 12 Apr 2000 09:40:48 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: Taybin Rutkin <trutkin@black.clarku.edu>,
        icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Idol function pointers
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Taybin Rutkin wrote:
> 
> I hope this is the right forum to discuss Idol...
> 
> How would I pass a method as a variable?  I'm trying to create an event
> system.  The call I'm using is
> 
> edges$watch(vertices$E_Update)
> 
> watch is the function that links the method to a list of procedures.  I'm
> trying to call a method in a specific object.  vertices is the instance
> and E_Update is the method that should be called at a later date.  The
> code works fine if I use a regular procedure.  I poked through the Icon
> output but the code it generated for that line was:
> 
> edges.__m.watch(edges,vertices.__m.E_Update(vertices))
> 
> I mostly understand that line, so I guess I need a way to remove the
> vertices arguement at the end.
> 
> Any hints?

Taybin - in many OO languages, including Idol (and Java...), you cannot
disassociate a method from its class in the way you'd like.  Pass the
class down and invoke the method within the procedure.  Note that this
imposes some discipline on how you write the code.  In Java, you'd use
an interface to enforce the discipline; in Idol, you'll have to rely
on self-discipline.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Thu Apr 13 12:43:11 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14559
	for icon-group-addresses; Thu, 13 Apr 2000 12:41:47 -0700 (MST)
Message-Id: <200004131941.MAA14559@baskerville.CS.Arizona.EDU>
Date: Thu, 13 Apr 2000 09:00:07 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: eddie@holyrood.ed.ac.uk, icon-group@optima.CS.Arizona.EDU
Subject: Re: changes to proc() ??
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

The effect you're seeing is due to a change in the Icon linker
a few years ago.  To avoid wasting space, the linker discards
procedures that are never referenced in the code.  This makes a
huge difference (megabytes vs. kilobytes) for some programs that
reference library procedures.

Since in your example the procedure show() is never referenced,
it is discarded, and so it's no longer around to be found by
proc("show").  A simple solution is to just reference any such
procedures once in the code -- they don't need to be called,
just referenced.

For example:

	procedure main()
	   references()
	   p := proc(read())
	      ...
	end

	procedure references()
	   # list otherwise unreferenced procedures here
	   show
	      ...
	end

Alternatively you can use the "invocable" declaration:
	invocable "show"
There's also 
	invocable all
but that completely disables the suppression of unused code.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA


From icon-group-sender  Thu Apr 13 12:58:09 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14960
	for icon-group-addresses; Thu, 13 Apr 2000 12:57:50 -0700 (MST)
Message-Id: <200004131957.MAA14960@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: changes to proc() ??
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Thu, 13 Apr 2000 11:52:19 -0000
X-Trace: client 955641152 38.163.203.81 (Thu, 13 Apr 2000 11:52:32 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

You're going to have to give this NG more details to trace down this
problem. What are the values of line that give a result you didn't expect?
Is line an operator name, such as "-" or ":="? Is line a predefined function
name, e.g. "write"? Is line the name of one of your procedures? I cannot
reproduce your problem, but this could be due to not calling proc with the
right parameter.




From icon-group-sender  Thu Apr 13 13:00:56 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA15075
	for icon-group-addresses; Thu, 13 Apr 2000 13:00:02 -0700 (MST)
Message-Id: <200004132000.NAA15075@baskerville.CS.Arizona.EDU>
From: eddie@holyrood.ed.ac.uk (Eddie Corns)
X-Newsgroups: comp.lang.icon
Subject: Re: changes to proc() ??
Date: 13 Apr 2000 17:02:49 GMT
X-Trace: scotsman.ed.ac.uk 955645369 12797 129.215.16.14 (13 Apr 2000 17:02:49 GMT)
X-Complaints-To: usenet@scotsman.ed.ac.uk
X-Newsreader: NN version 6.5.0 #2 (NOV)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com> writes:

>You're going to have to give this NG more details to trace down this
>problem. What are the values of line that give a result you didn't expect?
>Is line an operator name, such as "-" or ":="? Is line a predefined function
>name, e.g. "write"? Is line the name of one of your procedures? I cannot
>reproduce your problem, but this could be due to not calling proc with the
>right parameter.

Sorry, I forgot to put in the line where ops was set to contain "show" (amongst
other things).  Anyway, a few people have pointed out to me that I need to
use the new(ish) 'invocable' command and I now have it working.  Thanks to
everyone for their effort.

Eddie



From icon-group-sender  Fri Apr 14 09:17:54 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA19699
	for icon-group-addresses; Fri, 14 Apr 2000 09:17:09 -0700 (MST)
Message-Id: <200004141617.JAA19699@baskerville.CS.Arizona.EDU>
From: David Feder <A12266@frontiernet.net>
X-Newsgroups: comp.lang.icon
Subject: IDOL
Date: Fri, 14 Apr 2000 01:52:07 -0400
X-Trace: node17.cwnet.frontiernet.net 955691663 234740 63.21.132.88 (14 Apr 2000 05:54:23 GMT)
X-Complaints-To: abuse@frontiernet.net
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Is there a version of IDOL that is available for Windows98?

If so, is it in public domain?

Where can it be downloaded from?



From icon-group-sender  Fri Apr 14 12:45:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA25665
	for icon-group-addresses; Fri, 14 Apr 2000 12:44:18 -0700 (MST)
Message-Id: <200004141944.MAA25665@baskerville.CS.Arizona.EDU>
To: David Feder <A12266@frontiernet.net>
cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: IDOL 
Date: Fri, 14 Apr 2000 11:07:01 -0700
From: Clinton L Jeffery <jeffery@big-bill.CS.UNLV.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


> Is there a version of IDOL that is available for Windows98?
> If so, is it in public domain?  Where can it be downloaded from?

The last version of Windows Icon that I put together purports to
offer integrated support for Idol. A permanent copy resides at
http://icon.cs.unlv.edu/winicon.zip.  Those binaries also fix a
reported problem on Windows NT client/server sites, in which a
MS C library function tries to write a temporary file to C:\ which
is not writable by regular users in that configuration.

Clint Jeffery
jeffery@cs.unlv.edu


From icon-group-sender  Mon Apr 17 07:41:15 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA28574
	for icon-group-addresses; Mon, 17 Apr 2000 07:39:46 -0700 (MST)
Message-Id: <200004171439.HAA28574@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Newsreader: Forte Agent 1.7/32.534
Date: Sat, 15 Apr 2000 17:43:15 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: nlnews00.chello.com 955820595 212.187.67.243 (Sat, 15 Apr 2000 16:43:15 GMT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 10 Apr 2000 16:06:19 -0400, "Frank J. Lhota"
<NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:

>Yes, reversible assignment really is implemented. The problem is due to two
>flaws in your test.
>
>First of all, when a local variable is used in a co-expression, 
>...
Important lesson learnt: don't mess around with co-expressions, especially when
"not really necessary".
Although I appreciate all replies explaining the pitfalls of co-expressions
(maybe someone could also explain the INFIX @-operator, I always wondered
about that one too), I'm still puzzled by the implementation of reversible
assignment.
#------------------------------------------------------------------------------
procedure revass(a,b)         # pardon the expression
local c
c:=a
suspend ((a:=b)  |  ((a:=c) & (&fail)))
end                                          ######
#------------------------------------------------------------------------------
procedure myrevass(a,b)
local c
c:=a
suspend ((a:=b)  |  ((a:=c)  ))      # &(&fail)))
end                                                   #######
#------------------------------------------------------------------------------

Which considerations (if any  ;-)  led to picking the first
implementation ?

Thanks again.



From icon-group-sender  Mon Apr 17 13:31:54 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA09054
	for icon-group-addresses; Mon, 17 Apr 2000 13:31:31 -0700 (MST)
Message-Id: <200004172031.NAA09054@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Mon, 17 Apr 2000 15:33:47 -0000
X-Trace: client 956000040 38.163.203.81 (Mon, 17 Apr 2000 15:34:00 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> Although I appreciate all replies explaining the pitfalls of
co-expressions
> (maybe someone could also explain the INFIX @-operator, I always wondered
> about that one too), I'm still puzzled by the implementation of reversible
> assignment.
>
#---------------------------------------------------------------------------
---
> procedure revass(a,b)         # pardon the expression
> local c
> c:=a
> suspend ((a:=b)  |  ((a:=c) & (&fail)))
> end                                          ######
>
#---------------------------------------------------------------------------
---
> procedure myrevass(a,b)
> local c
> c:=a
> suspend ((a:=b)  |  ((a:=c)  ))      # &(&fail)))
> end                                                   #######
>
#---------------------------------------------------------------------------
---
>
> Which considerations (if any  ;-)  led to picking the first
> implementation ?

The idea behind reversible assignment is to provide data backtracking. If we
execute

i := 1;
text ? {
    (i := 3) &
    (j := (i < find("q")))
    }

and the expression (i < find("q")) fails, i will end up with the value 3. We
will backtrack to the expression (i := 3), but normal assignment is not a
generator, and so the previous value of i is not restored. Assume that we do
not want the scanning expression to change i unless it succeeds. We can get
the desired effect by using reversable assignment.

i := 1;
text ? {
    (i <- 3) &
    (j := (i < find("q")))
    }

Now if (i < find("q")) succeeds (for example, if text is "unique"), the
assignment of 3 to i remains in effect, and if (i < find("q")) fails, the
old value of i is restored.

If I understand your question correctly, you are wondering why reversible
assignment fails after resumption. The reason for this is that it would have
an undesired effect on control backtracking. Consider the scanning
expression above, where text is "queen":

    (i <- 3) assigns 3 to i and suspends;
    (j < find("q")) fails, so we resume the most recently suspended
expression;
    (i <- 3) is resumed, so i gets its previous value (1);

Now if (i <- 3) were to succeed after being resumed, goal-driven evaluation
requires that we evaluate (i < find("q")) again, this time with i=1. This
evaluation would succeed, and therefor the whole scanning expression would
succeed, giving j=1. Clearly, this is not what you wanted.






From icon-group-sender  Wed Apr 19 07:35:44 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA19877
	for icon-group-addresses; Wed, 19 Apr 2000 07:33:53 -0700 (MST)
Message-Id: <200004191433.HAA19877@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Icon and network programming.
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 19 Apr 2000 08:44:28 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 956133868 24.226.208.172 (Wed, 19 Apr 2000 04:44:28 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello,

    I haven't really seen any consistant implementation of network
programming functions for Icon, beside maybe Unicon. Is there such similar
(and elegant) library available for Icon? Or will Unicon added features
being part of next version of Icon?

best regards,

--
Ian Trudel




From icon-group-sender  Wed Apr 19 13:55:31 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA00991
	for icon-group-addresses; Wed, 19 Apr 2000 13:54:56 -0700 (MST)
Message-Id: <200004192054.NAA00991@baskerville.CS.Arizona.EDU>
From: PHOEBEJEN@aol.com
Date: Wed, 19 Apr 2000 13:28:59 EDT
Subject: Icon Question???
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello!

I am a student at the University of New Orleans, and I am giving a 
presentation on the Icon Programming Language.  I was hoping maybe you could 
clarify what some of Icon's current uses/applications are.  For example, Java 
is used on a lot of web sites and C is used for systems programming.  I think 
what I am really looking for are maybe some current sites/companies that 
display an implementation of Icon.  I would like to demonstrate in my 
presentation some Icon's current uses.  Any help you can offer in this matter 
would be greatly appreciated!  Thank you in advance for your time.

Sincerely,

Jennifer Mader
phoebejen@aol.com


From icon-group-sender  Wed Apr 19 13:56:14 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA01144
	for icon-group-addresses; Wed, 19 Apr 2000 13:56:00 -0700 (MST)
Message-Id: <200004192056.NAA01144@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Newsreader: Forte Agent 1.7/32.534
Date: Wed, 19 Apr 2000 19:19:26 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: nlnews00.chello.com 956171966 212.187.67.243 (Wed, 19 Apr 2000 18:19:26 GMT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 17 Apr 2000 16:33:32 -0400, "Frank J. Lhota"
<NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:

>...
>
>If I understand your question correctly, you are wondering why reversible
>assignment fails after resumption. The reason for this is that it would have
>an undesired effect on control backtracking. Consider the scanning
>expression above, where text is "queen":
>
>                               (i <- 3) assigns 3 to i and suspends;
>                               (j <   find("q")) fails, so we resume the most recently 
Surely you mean i <=

>suspended expression;
>    (i <- 3) is resumed, so i gets its previous value (1);
>
>Now if (i <- 3) were to succeed after being resumed, goal-driven evaluation
>requires that we evaluate (i < find("q")) again, this time with i=1. This
>evaluation would succeed, and therefor the whole scanning expression would
>succeed, giving j=1. Clearly, this is not what you wanted.
Why not, after all it would still be true !
However, with the present implementation the first rev.assignment that gets
resumed in a compound expression, will make the whole expression fail.
Such a waste...
Besides, I'd imagine you'd avoid using regular assignments in compound
expressions in the first place: should the expression fail in the end, all
succesful regular assignments within this expression would still
be permanent, contrary to rev.assignments (your version or mine). 
==================



From icon-group-sender  Wed Apr 19 13:56:55 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA01199
	for icon-group-addresses; Wed, 19 Apr 2000 13:56:30 -0700 (MST)
Message-Id: <200004192056.NAA01199@baskerville.CS.Arizona.EDU>
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
Date: Wed, 19 Apr 2000 13:25:45 -0700
X-Trace: noao.edu 956175946 66179 140.252.38.6 (19 Apr 2000 20:25:46 GMT)
X-Complaints-To: abuse@noao.edu
To: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" wrote:
> 
> On 17 Apr 2000 16:33:32 -0400, "Frank J. Lhota"
> <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
> 
> >...
> >
> >If I understand your question correctly, you are wondering why reversible
> >assignment fails after resumption. The reason for this is that it would have
> >an undesired effect on control backtracking. Consider the scanning
> >expression above, where text is "queen":
> >
> >                               (i <- 3) assigns 3 to i and suspends;
> >                               (j <   find("q")) fails, so we resume the most recently
> Surely you mean i <=

No, he means i <- 3,  "<-" is the reversible assignment operation.
(The assignment operation ":=" is not reversible.  "<=" is a comparison
operator and does no assignment.)

> However, with the present implementation the first rev.assignment that gets
> resumed in a compound expression, will make the whole expression fail.

No, it will continue performing control backtracking until all subexpressions
have no more results.

> Such a waste...

No, it's vital to a correct implementation of data backtracking.  Otherwise
you cannot do compound reversible assignments, as in:

   row[r] <- down[r+c+1] <- up[8+r-c] <- r

or even the more simple:

   if f((k <- 1 to 3), (n <- "a"|"b"|"c")) then ....

(If the backtracking into reversible assignment were to succeed, you'd
then do *forward* evaluation from that point instead of continuing back
through the expression, which means you would not be assured of having
tried all possible combinations of results from all subexpressions.)

> Besides, I'd imagine you'd avoid using regular assignments in compound
> expressions in the first place: should the expression fail in the end, all
> succesful regular assignments within this expression would still
> be permanent, contrary to rev.assignments (your version or mine).

Depends on what you're trying to do, you may want some assignments to
be permanent regardless of the outcome of the entire evaluation...


--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Apr 24 07:43:03 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA25545
	for icon-group-addresses; Mon, 24 Apr 2000 07:42:14 -0700 (MST)
Message-Id: <200004241442.HAA25545@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Newsreader: Forte Agent 1.7/32.534
Date: Sat, 22 Apr 2000 16:52:57 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: nlnews00.chello.com 956422377 212.187.67.243 (Sat, 22 Apr 2000 15:52:57 GMT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 19 Apr 2000 16:57:54 -0400, Steve Wampler <swampler@noao.edu> wrote:

First of all, I agree with Frank J. Lhota that at least the distribution list
seems to duplicate postings.

>"F.G. van DORP" wrote:
>> 
>> On 17 Apr 2000 16:33:32 -0400, "Frank J. Lhota"
>> <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
>> 
>> >...
>> >expression above, where text is "queen":
>> >
>> >                               (i <- 3) assigns 3 to i and suspends;
>> >                               (j <   find("q")) fails, so we resume the most recently
>> Surely you mean i <=
>
>No, he means i <- 3...
I should've known better with this mailer to try formatting with spaces again,
but what I meant was
                         (i <= find("q")........

Besides, this may be an unfortunate example by mr. Lhota, because according
to the Icon book data backtracking is implicit in string scanning.
>
>> However, with the present implementation the first rev.assignment that gets
>> resumed in a compound expression, will make the whole expression fail.
>
>No, it will continue performing control backtracking until all subexpressions
>have no more results.
>....
I realised I made a terrible mistake by using the term "compound expression"
which in the Icon book has exactly the opposite meaning: a context in which
subexpressions are isolated from backtracking.
The opposite would be called a "backtracking context", I guess...
At this point it would be wise to consider a "tactical retreat" in order to let
my rev.assignment version loose on some other examples from the book,
as Steve Wampler seems to suggest.
.



From icon-group-sender  Mon Apr 24 12:32:59 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12740
	for icon-group-addresses; Mon, 24 Apr 2000 12:32:41 -0700 (MST)
Message-Id: <200004241932.MAA12740@baskerville.CS.Arizona.EDU>
Date: Mon, 24 Apr 2000 11:04:31 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: ian.trudel@tr.cgocable.ca, icon-group@optima.CS.Arizona.EDU
Subject: Re: Icon and network programming.
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
    Date: Wed, 19 Apr 2000 08:44:28 GMT
    
        I haven't really seen any consistant implementation of network
    programming functions for Icon, beside maybe Unicon. Is there such similar
    (and elegant) library available for Icon? Or will Unicon added features
    being part of next version of Icon?

There are a few loadable C functions in the Icon Program Library
that are enough to implement a TCP client (but not a server).

The Icon language is essentially stable now and I don't see us adding
the Unicon features.  The occasional new version of Icon typically just
fixes bugs and portability problems.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Mon Apr 24 12:34:24 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12805
	for icon-group-addresses; Mon, 24 Apr 2000 12:34:12 -0700 (MST)
Message-Id: <200004241934.MAA12805@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Mon, 24 Apr 2000 15:15:29 -0000
X-Trace: client 956603743 38.163.203.81 (Mon, 24 Apr 2000 15:15:43 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" <F.G.van.Dorp@digimedia.nl> wrote in message
news:74l3gsc7so87bhvn0tapp8ol5dni6h27sa@4ax.com...
> On 19 Apr 2000 16:57:54 -0400, Steve Wampler <swampler@noao.edu> wrote:
> Besides, this may be an unfortunate example by mr. Lhota, because
according
> to the Icon book data backtracking is implicit in string scanning.

I assume that the Icon book you are referring to is "The Icon Programming
Language", third edition. The book does say that the scanning functions
"tab" and "move" restore the previous position if resumed. In that sense,
data backtracking of &pos is done by the scanning functions. The book does
not say that  the ":=" operator behaves like the "<-" operator within string
scanning, and I can assure you that Icon does not work this way.






From icon-group-sender  Wed Apr 26 12:35:31 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12171
	for icon-group-addresses; Wed, 26 Apr 2000 12:33:58 -0700 (MST)
Message-Id: <200004261933.MAA12171@baskerville.CS.Arizona.EDU>
From: Lloyd Uhler <luhler@excel.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: Questions on ICON
Date: Wed, 26 Apr 2000 08:52:28 -0500
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

1) For Version 9.3.1 on WIN NT and WIN 98, textbox input does not work for
VIB generated code as follows:

############################################################################
#
#	File:     C:\Icon9.3\vib_tst.icn
#
#	Subject:  Program to ...
#
#	Author:   
#
#	Date:     January 21, 1999
#
############################################################################
#
#
#
############################################################################
#
#  Requires:
#
############################################################################
#
#  Links: vsetup
#
############################################################################

#  This vib interface specification is a working program that responds
#  to vidget events by printing messages.  Use a text editor to replace
#  this skeletal program with your own code.  Retain the vib section at
#  the end and use vib to make any changes to the interface.

link vsetup

procedure main(args)
   local vidgets, root, paused

   (WOpen ! ui_atts()) | stop("can't open window")
   vidgets := ui()				# set up vidgets
   root := vidgets["root"]

   paused := 1					# flag no work to do
   repeat {
      # handle any events that are available, or
      # wait for events if there is no other work to do
      while (*Pending() > 0) | \paused do {
         ProcessEvent(root, QuitCheck)
         }
      # if <paused> is set null, code can be added here
      # to perform useful work between checks for input
      }
end

procedure text_input_cb1(vidget, value)
#    write("value = ", value)
   return
end

#===<<vib:begin>>===	modify using vib; do not remove this marker line
procedure ui_atts()
   return ["size=600,378", "bg=#C0C0C0"]
end

procedure ui(win, cbk)
return vsetup(win, cbk,
   [":Sizer:::0,0,600,378:",],
   ["button1:Button:regular::270,349,32,20:OK",button_cb1],
   ["text_input1:Text::46:95,111,367,20:Enter Your
Name:\\=",text_input_cb1],
   )
end
#===<<vib:end>>===	end of section maintained by vib
procedure button_cb1(vidget, value)
#

#  write("button_cb1")
#
# This does not work with the original viface module
# The local one has been revised to detect Window closure
# and do this without error. This will return to the statement
# after GetEvents. The program can then process or do what it
# needs with the results for the GUI data capture. Data values
# can be inserted into global variables so they are available
# to the rest of the program.
#
#  WClose( &window )
  return
end

2) There seems to be no way to gather a set of file names from a specified
directory:
    (System & popen do not work the same as command-line version of ICON
(Nticont, Nticonx)).
    (F.F and pipe.001 are empty)

 link graphics, dialog, popen, xio

 procedure main()
#
#
# the 45 is the width
#
  txt := TextDialog("Specify Directory Path:",  "Path", "C:\\temp" , 45)

  Path := dialog_value[1]
  write("Path = ", Path)

  cmd := "Dir /b/l "
#
# See if F.F Generated fro BAT File
#
  system( "CALL C:\\ICON9.3\\WDIR.CMD" || Path )
#
# Try popen to get file of file names
#
  fin := popen( cmd || Path, "r")
  while line := trim(read(fin)) do write(line)

  pclose(fin)

 end

REM
REM Wdir.BAT
REM
REM Purpose: Directory Listing
REM
DIR /b/l %1 > F.F


From icon-group-sender  Thu Apr 27 07:33:19 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA15502
	for icon-group-addresses; Thu, 27 Apr 2000 07:32:55 -0700 (MST)
Message-Id: <200004271432.HAA15502@baskerville.CS.Arizona.EDU>
From: "Lloyd M. Uhler, Jr." <luhler@cyberramp.net>
X-Newsgroups: comp.lang.icon
Subject: using "system" or "popen" in WIN ICON
Date: Wed, 26 Apr 2000 19:18:56 -0500
X-Orig-Message-ID: <39078770.7583CB2D@cyberramp.net>
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Wed Apr 26 19:17:43 2000
X-Accept-Language: en,pdf
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I have tried to use both "system" or "popen" in WIN ICON to get a
directory listing of
files which I can process. I use a text dialog to get the directory
path.

I have tried this both under WIN NT and WIN 98. It seems that
redirection ( " > ") does not
work.

How do you do this in a WIN ICON program?



From icon-group-sender  Thu Apr 27 07:34:52 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA15547
	for icon-group-addresses; Thu, 27 Apr 2000 07:34:44 -0700 (MST)
Message-Id: <200004271434.HAA15547@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 26 Apr 2000 09:14:05 -0000
X-Trace: client 956754859 38.163.203.81 (Wed, 26 Apr 2000 09:14:19 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Icon, as currently written, is designed to work with 8 bit characters. We
are seeing increased use of Unicode, a 16 bit character encoding that
includes the letters of all the major alphabets. Internally, Windows NT /
2000 represents all text in Unicode format. As a result, Windows can be
internationalized without the old DOS code pages.

Is anyone working on a version of Icon for Unicode? The Icon Analyst once
reported that someone at the University of Hong Kong developed a version of
Icon for working with Chinese text, although I could not find any
information from the University web page.

A Unicode version could be quite useful, and it might not be that hard to
do. Is anyone working on this?




From icon-group-sender  Thu Apr 27 07:35:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA15614
	for icon-group-addresses; Thu, 27 Apr 2000 07:35:19 -0700 (MST)
Message-Id: <200004271435.HAA15614@baskerville.CS.Arizona.EDU>
From: gmt@optima.CS.Arizona.EDU (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 26 Apr 2000 09:28:22 -0700
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <LYBN4.9$pb6.213@client>,
Frank J. Lhota <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
>  A Unicode version could be quite useful, and it might not be that hard
>  to do. Is anyone working on this?

A Unicode version of Jcon (the Java implementation of Icon) would not
be a huge task.  The hardest problem would be deciding language issues,
notably the definitions of the predefined csets.  You'd also want a
different internal representation for csets.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Thu Apr 27 12:31:53 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA24045
	for icon-group-addresses; Thu, 27 Apr 2000 12:31:32 -0700 (MST)
Message-Id: <200004271931.MAA24045@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Thu, 27 Apr 2000 12:35:56 -0000
X-Trace: client 956853371 38.163.203.81 (Thu, 27 Apr 2000 12:36:11 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


"Gregg Townsend" <gmt@CS.Arizona.EDU> wrote in message
news:8e75f6$5pr@baskerville.CS.Arizona.EDU...
> A Unicode version of Jcon (the Java implementation of Icon) would not
> be a huge task.  The hardest problem would be deciding language issues,
> notably the definitions of the predefined csets.

Actually, even for the eight bit version of Icon, the definitions of
&letters, &lcase, and &ucase deserve a second look. For international use,

    char( 16rE0 to 16rFE )

often represent lower case letters (such as "a" with an umlaut), and

    char( 16rC0 to 16rDE )

often represent upper case letters, but none of these characters do not show
up in &letter, &lcase or &ucase. These predefined csets restrict their
attention exclusively to the &ascii characters.

Granted, this is due to the strange evolution of 8 bit character coding.
Standards for how to interpret characters with the high bit on were slow to
evolve. Some ASCII platforms had quite novel interpretations of these
characters. MS-DOS machines, for example, had the OEM character set, which
used most of the upper half of &cset for math symbols and symbols useful for
drawing boxes. Amidst this anarchy, it would be foolhardy for Icon to
include any characters outside of &ascii in &letters, &lcase, or &ucase.

We may, unfortunately, be at a point where this is too late to change the
predefined csets. There are probably Icon programs out there that depend on
*&letters = 52, *&lcase = *&ucase = 26, &letters ++ &ascii === &ascii, etc.,
and hence changing the csets would cause them to break. The right fix might
be to add new prefined csets, so that new code could be properly
internationalized.

> You'd also want a
> different internal representation for csets.

Currently, a cset is basically stored as a packed array of 256 bits (one bit
for each 8-bit character). For 32 bit platforms, this requires just 8 words.
If we were to use the packed array of bits approach for wide characters, a
cset would be represented by 2048 words -- Yikes! Clearly, we would need to
use a different internal representation.

I would suggest representing a cset as an ordered list  of character
intervals. For example, the cset of characters that can be used in an Icon
identifier would be represented as this sequence of intervals:

    [ "0" to "9", "A" to "Z", "_" to "_", "a" to "z" ]

I will grant that, in the worst case, this representation method can take up
a lot of storage. A cset of all wide characters c with the lowest order bit
on would require 32,768 intervals. Most csets that actually occur in
applications, however, could be represented by a handful of intervals.

I must confess that I am just starting to learn Java, so it will be awhile
before I can try this on my own :(




From icon-group-sender  Mon May  1 21:00:51 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id UAA10001
	for icon-group-addresses; Mon, 1 May 2000 20:58:42 -0700 (MST)
Message-Id: <200005020358.UAA10001@baskerville.CS.Arizona.EDU>
Date: Fri, 28 Apr 2000 12:31:31 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
To: NOSPAM.Frank.Lhota@lexma.meitech.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
> We may, unfortunately, be at a point where this is too late to change the
> predefined csets. ... The right fix might be to add new prefined csets,
> so that new code could be properly internationalized.
	
May I suggest instead new *functions* for getting csets?
	lower_case_cset(Locale) -> Cset
	upper_case_cset(Locale) -> Cset
	title_case_cset(Locale) -> Cset
	letter_cset(Locale) -> Cset
and so on, where a Locale could be a string such as "en_NZ".	

> If we were to use the packed array of bits approach for wide characters, a
> cset would be represented by 2048 words -- Yikes! Clearly, we would need to
> use a different internal representation.

It's worse than that.  One of the core design principles of Unicode was
that it coded characters, not languages; language tagging was supposed to
be left to a higher-level protocol.  Well, that's not true in Unicode 3.0
any more.  There are language markup tags in Plane 14.  Now 2048 words is
enough for one plane...  Plane 0 is now pretty much full, and useful stuff
is going in Plane 1, so the age of 16 bit characters didn't really last
very long.

> I would suggest representing a cset as an ordered list  of character
> intervals. ... Most csets that actually occur in
> applications, however, could be represented by a handful of intervals.
	
Not unless you have rather large hands.
I just ran a little AWK script against unidata2.txt (I don't have
the Unicode 3.0 version yet), and found

	DIGIT		 22 intervals
	LETTER		179 intervals
	CAPITAL LETTER	337 intervals
	SMALL LETTER	349 intervals

I suspect that letter csets will be wanted rather often.
Perhaps a hybrid representation might be better:
 - a bitmap for the first 256 characters of Unicode
 - a "window pointer" selecting another block of 256 characters,
   so that the current locale (Cyrillic, or Greek, or Arabic, or whatever)
   can be accessed fairly fast
 - a bitmap for the characters in the selected window
 - an ordered list of intervals for the remaining characters



From icon-group-sender  Mon May  1 21:13:12 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id VAA10390
	for icon-group-addresses; Mon, 1 May 2000 21:13:03 -0700 (MST)
Message-Id: <200005020413.VAA10390@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Fri, 28 Apr 2000 04:01:42 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 956894502 24.226.208.172 (Fri, 28 Apr 2000 00:01:42 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Gregg Townsend" <gmt@CS.Arizona.EDU> a écrit dans le message news:
8e75f6$5pr@baskerville.CS.Arizona.EDU...
> In article <LYBN4.9$pb6.213@client>,
> Frank J. Lhota <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
> >  A Unicode version could be quite useful, and it might not be that hard
> >  to do. Is anyone working on this?
>
> A Unicode version of Jcon (the Java implementation of Icon) would not
> be a huge task.  The hardest problem would be deciding language issues,
> notably the definitions of the predefined csets.  You'd also want a
> different internal representation for csets.

How about investigate a "pluginizable" data type for Icon? As far as I
remember, Squeak Smalltalk (see http://www.squeak.org/ ) has a nice plugin
system for such. Stephan Rudolf made a nifty LargeInteger plugin, for
example. I think such thing would be quite interesting in Icon. Data type
could be added to the Icon's runtime system on the fly. It would allow us to
add more _primitive_ types to Icon (without recompiling Icon source code?
::) such as Unicode support. Though I've noticed the dynamic loadable C
fonction system within Icon is a strong and interesting, it would not help
on Unicode support, since this is an Icon's internal matter.

Any thoughts on this?

--
Ian Trudel,
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Mon May  1 21:14:02 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id VAA10421
	for icon-group-addresses; Mon, 1 May 2000 21:13:37 -0700 (MST)
Message-Id: <200005020413.VAA10421@baskerville.CS.Arizona.EDU>
From: Guido Milanese <gmilanese@mclink.it>
X-Newsgroups: comp.lang.icon
Subject: Help: graphics
Date: Fri, 28 Apr 2000 11:40:24 +0200
X-Accept-Language: it, en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I am a rather new user of Icon -- I have being used Spitbol for
ages, but the lack of graphics and of reliable control structures
persuaded me to try Icon. I like the language, particularly after
moving from Windows to Linux. I still have some problems about
graphics. I have the 2nd edition of the IPL manual, but I have
already ordered a copy of the 3rd edition and of the graphics
manual.

I use the function WOpen with this syntax:
WOpen("bg=green","fg=vivid black","pos=25,25","size=800,700")
| stop("no window")

and it's all right. But how can I give a name to this window? In
the documentation (IPD281) and in the otherwise excellent manual
by T.W. Chistopher I found the syntax, but I am afraid I did not
understand it (I receive a "null" error message, because &window
is still set to null).

Could someone kindly give me some examples?

Many thanks in advance,

gm

------------------------------------------------------
Guido Milanese            Vocal Ensemble "Ars Antiqua"
gmilanese@mclink.it       http://fly.to/arsantiqua
Salita del Passero 11     I-16126 Genova GE, Italy
* Sed nomini tuo da gloriam *             MMMR 4.70reg


From icon-group-sender  Tue May  2 08:44:20 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02046
	for icon-group-addresses; Tue, 2 May 2000 08:44:00 -0700 (MST)
Message-Id: <200005021544.IAA02046@baskerville.CS.Arizona.EDU>
X-Originating-IP: [24.234.0.80]
From: "Ray Pereda" <raypereda@hotmail.com>
To: gmilanese@mclink.it, icon-group@optima.CS.Arizona.EDU
Subject: Re: Help: graphics
Date: Mon, 01 May 2000 22:28:13 PDT
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

You can look it up online:
http://www.cs.arizona.edu/icon/docs/ipd281/gipd_c.htm

>I use the function WOpen with this syntax:
>WOpen("bg=green","fg=vivid black","pos=25,25","size=800,700")
>| stop("no window")
>
>and it's all right. But how can I give a name to this window? In

Try WOpen("label=My Window Title")

-Ray

>From: Guido Milanese <gmilanese@mclink.it>
>To: icon-group@optima.CS.Arizona.EDU
>Subject: Help: graphics
>Date: Fri, 28 Apr 2000 11:40:24 +0200
>
>I am a rather new user of Icon -- I have being used Spitbol for
>ages, but the lack of graphics and of reliable control structures
>persuaded me to try Icon. I like the language, particularly after
>moving from Windows to Linux. I still have some problems about
>graphics. I have the 2nd edition of the IPL manual, but I have
>already ordered a copy of the 3rd edition and of the graphics
>manual.
>
>I use the function WOpen with this syntax:
>WOpen("bg=green","fg=vivid black","pos=25,25","size=800,700")
>| stop("no window")
>
>and it's all right. But how can I give a name to this window? In
>the documentation (IPD281) and in the otherwise excellent manual
>by T.W. Chistopher I found the syntax, but I am afraid I did not
>understand it (I receive a "null" error message, because &window
>is still set to null).
>
>Could someone kindly give me some examples?
>
>Many thanks in advance,
>
>gm
>
>------------------------------------------------------
>Guido Milanese            Vocal Ensemble "Ars Antiqua"
>gmilanese@mclink.it       http://fly.to/arsantiqua
>Salita del Passero 11     I-16126 Genova GE, Italy
>* Sed nomini tuo da gloriam *             MMMR 4.70reg
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From icon-group-sender  Tue May  2 08:45:07 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02091
	for icon-group-addresses; Tue, 2 May 2000 08:44:45 -0700 (MST)
Message-Id: <200005021544.IAA02091@baskerville.CS.Arizona.EDU>
X-Originating-IP: [24.234.0.80]
From: "Ray Pereda" <raypereda@hotmail.com>
To: ian.trudel@tr.cgocable.ca, icon-group@optima.CS.Arizona.EDU
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Mon, 01 May 2000 22:36:21 PDT
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hi Ian,

>How about investigate a "pluginizable" data type for Icon?

The Jcon design makes it easy to add new data types.  In the object-oriented 
implementation every data type is derived from a common base class that has 
many useful defaults.  Go to the www.cs.arizona.edu/icon to read more about 
Jcon.

>Data type could be added to the Icon's runtime system on the fly.

I've heard this idea mentioned before.  This would take a little bit more 
thinking things through, but it would be a big win for Icon programmers.

-Ray
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From icon-group-sender  Wed May 10 10:50:56 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA18153
	for icon-group-addresses; Wed, 10 May 2000 10:48:55 -0700 (MST)
Message-Id: <200005101748.KAA18153@baskerville.CS.Arizona.EDU>
Date: Wed, 10 May 2000 09:27:03 +0200 (CEST)
From: Guido Milanese <gmilanese@mclink.it>
To: icon-group@optima.CS.Arizona.EDU
Subject: VIB for Linux?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Dear all,
I am using Linux at home and Win9x at work. I downloaded the Windows version of Icon and found the very interesting program VIB, available directly from the programming environment. My question is: is this program available also for Linx? Does it require adaptation? Or: can I use under Linux the code produced by VIB under Win95?

Thanks,
gm

PS Many thanks to those who replied my questions on graphics. I had a major computer crash and could not reply immediately. Will send a private reply ASAP.



Guido Milanese               -- gmilanese@mclink.it
Vocal Ensemble "Ars Antiqua" -- http://fly.to/arsantiqua
Salita del Passero 11, I-16126 Genova GE, Italy
* SED NOMINI TUO DA GLORIAM *








From icon-group-sender  Wed May 10 12:46:01 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA21921
	for icon-group-addresses; Wed, 10 May 2000 12:43:54 -0700 (MST)
Message-Id: <200005101943.MAA21921@baskerville.CS.Arizona.EDU>
Date: Wed, 10 May 2000 14:46:04 -0400 (EDT)
From: Taybin Rutkin <trutkin@black.clarku.edu>
To: Guido Milanese <gmilanese@mclink.it>
cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: VIB for Linux?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On Wed, 10 May 2000, Guido Milanese wrote:

> Dear all,
>environment. My question is: is this program available also for
>Linx? Does it require adaptation? Or: can I use under Linux the code
>produced by VIB

I've been using VIB on linux quite successfully.  I'd guess that the
graphics code that it generates is cross platform.  The easist way to find
out is to try.

I've got a general question though.  Is it based on Tk?

Taybin Rutkin -- trutkin@black.clarku.edu

Creativity can only be anarchic, capitalist, Darwinian
	-- Umberto Eco



From icon-group-sender  Wed May 10 12:46:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA22033
	for icon-group-addresses; Wed, 10 May 2000 12:46:15 -0700 (MST)
Message-Id: <200005101946.MAA22033@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Jcon implementation of csets
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 10 May 2000 15:20:03 -0000
X-Trace: client 957986427 38.163.203.81 (Wed, 10 May 2000 15:20:27 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

The recent discussion of a Unicode version of Icon and Unicode csets lead me
to look at the Jcon implementation of 8 bit csets. A Jcon cset is
represented using four long (i.e. 64 bit) integers, declared as follows:

    long w1, w2, w3, w4;        // four words of cset bits

What I do not understand is why these four longs are represented as separate
members, rather than as an array of longs:

    long[ ] w = new long[4];        // four words of cset bits

Is there some peculiarity about Java that would prohibit this?




From icon-group-sender  Wed May 10 16:25:07 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA02024
	for icon-group-addresses; Wed, 10 May 2000 16:24:53 -0700 (MST)
Message-Id: <200005102324.QAA02024@baskerville.CS.Arizona.EDU>
Date: Wed, 10 May 2000 13:06:39 -0700 (MST)
From: Gregg Townsend <gmt>
To: Frank.Lhota@lexma.meitech.com, icon-group
Subject: Re: Jcon implementation of csets
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
    
    What I do not understand is why these four longs are represented
    as separate members, rather than as an array of longs:
        long[ ] w = new long[4];        // four words of cset bits
    Is there some peculiarity about Java that would prohibit this?

An array would work.  However, an array would allocate another heap
object and would be slower to access, so I went with four longs.

Because Icon works essentially the same way, I won't call this aspect
of Java "peculiar".  :-)

	Gregg

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA
    
    
    


From icon-group-sender  Thu May 11 07:58:43 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA01669
	for icon-group-addresses; Thu, 11 May 2000 07:58:05 -0700 (MST)
Message-Id: <200005111458.HAA01669@baskerville.CS.Arizona.EDU>
Date: Thu, 11 May 2000 10:23:01 -0400 (EDT)
From: Taybin Rutkin <trutkin@black.clarku.edu>
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: VIB for Linux?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On Wed, 10 May 2000, Steve Wampler wrote:

> Taybin Rutkin wrote:
> 
> > I've got a general question though.  Is it based on Tk?
> 
> No, it's pure Icon code, originally written by a student
> of Ralph's for a course.  I don't think the student
> knew about Tk at the time.

Actually, I'm asking about the entire graphics system.  Does it call
X-Windows directly?  How is it cross-platform then?  I'm just asking
'cause a lot of other languages found Tk a really easy way to add
graphic capabilities.  I never liked having to install Tcl to use Python
though.

I'm wondering how hard it would be to add gtk+ support.  It's been
something I've been considering working on for a while.

Taybin Rutkin

trutkin@black.clarku.edu



From icon-group-sender  Thu May 11 12:47:55 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA16266
	for icon-group-addresses; Thu, 11 May 2000 12:47:08 -0700 (MST)
Message-Id: <200005111947.MAA16266@baskerville.CS.Arizona.EDU>
To: Taybin Rutkin <trutkin@black.clarku.edu>
cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: VIB for Linux? 
Date: Thu, 11 May 2000 09:11:55 -0700
From: Clinton L Jeffery <jeffery@big-bill.CS.UNLV.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


> Actually, I'm asking about the entire graphics system.  Does it call
> X-Windows directly?  How is it cross-platform then?

I wrote the bulk of the Xlib code. Then Gregg Townsend and Sandy Miller
improved it.  Then Darren Merrill ported it to OS/2.  Then I further
separated out the platform-dependencies, and wrote the MS Windows code.
The built-in functions are native and cross-platform. The higher level
GUI toolkits are Icon-specific and cross-platform.

> I'm wondering how hard it would be to add gtk+ support.

I guess it would not be easy, but I'd be glad if you proved me wrong. :-)

Clint, jeffery@cs.unlv.edu


From icon-group-sender  Fri May 12 10:19:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA00987
	for icon-group-addresses; Fri, 12 May 2000 10:18:52 -0700 (MST)
Message-Id: <200005121718.KAA00987@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
To: "Ray Pereda" <raypereda@hotmail.com>, <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Fri, 12 May 2000 01:14:09 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

----- Original Message -----
From: "Ray Pereda" <raypereda@hotmail.com>
To: <ian.trudel@tr.cgocable.ca>; <icon-group@optima.CS.Arizona.EDU>
Sent: Tuesday, May 02, 2000 1:36 AM
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?


> Hi Ian,
>
> >How about investigate a "pluginizable" data type for Icon?
>
> The Jcon design makes it easy to add new data types.  In the
object-oriented
> implementation every data type is derived from a common base class that
has
> many useful defaults.  Go to the www.cs.arizona.edu/icon to read more
about
> Jcon.
>
> >Data type could be added to the Icon's runtime system on the fly.
>
> I've heard this idea mentioned before.  This would take a little bit more
> thinking things through, but it would be a big win for Icon programmers.

Hello,

    I agree on this, the extra flexibility given by such system would be
really interesting. It would probably also avoid multiple version, or
distribution, of Icon, such as Unicon, MT Icon, etc. (Speaking of
'distroing', that's something I dislike from Linux. There is like a gazilion
of distro, making the thing hard sometime..)

I've glanced the Jcon source code. Truely remarkable, adding a new data type
is pretty simple. That's not so true for the original Icon system though.
The main problem is the primitive data types are embedded in some
switch()s', so adding a new type requires editing many files and stuff.
That's error prone. However, it would certainly be possible to add a new
dynamic primitive, which would allow us to add new primitives on the fly.
This could also allow either statically linked (with Icon source) or
dynamically linked (shared library or dynamic linked library). This special
primitive could let a third party 'register' his new data type along his
special functions. The primitive system would, of course, expecting some
basic functions such as data convertion or Icon operators, for example. Note
the dynamic primitive data type would requires us to add only one new
descriptor.

But Hey, hang on a minute.. why not rewrite the whole primitive system
(*giggles*) now we speaking of it! A certain system dictionary could
maintain the primitive set and manage them. No need of a dynamic dictionary,
I think the primitive data types should be a limited ressource anyway. A
limit of 255 primitives would be just enough for a while! Anyway, we should
be able to register a primitive to the system (or) primitive dictionary,
along the new functions. If name spacing possible, no need to register basic
functions (such as convertion), they could have standard name (such as
toString, toCSet, toInteger, ..., or fromInteger, etc) or if none found, the
prim's function is automatically failing. This would be also good at the
source code level, each primitive could be a new C file. So, if I want to
dig into CSet functionalites, I glance in primCSet.c (or whatever). Things
are clear in the implementation book and the tech reports, but at the source
code level, it's somehow mixed up and there is no roadmap. Erm..

There is some bad sides of this, of course, like changing the whole source
is not so trivial or making primitives co-existing may be sometimes hard
(hey, what happen if you add a new prim? do we have to add convertion
functions to each other prims? etc)... what else.. a new C interface (for
loadable C fonction) would be needed? Anyway, I'm pretty sure you can find
others.

Icon implementation is not as simple as Smalltalk, for example, but it's
nonetheless interesting. There is lotsa things from Smalltalk (or Squeak)
that could be good in Icon without changing the whole Icon's implementation.
I know the Icon project ppl seeking the stability and portability of their
programming language, but I think the dynamic primitive data type system
would just be awesome!! It'd certainly worth the effort.

Any thoughts?

Ok, I'm off to bed..
Ian Trudel

PS: If you're curious, check out these URL (Squeak primitive stuff):
http://www.create.ucsb.edu/squeak/DIYSqPrims.html
http://minnow.cc.gatech.edu/squeak/464



From icon-group-sender  Fri May 12 12:34:30 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA06511
	for icon-group-addresses; Fri, 12 May 2000 12:34:17 -0700 (MST)
Message-Id: <200005121934.MAA06511@baskerville.CS.Arizona.EDU>
From: collberg@optima.CS.Arizona.EDU (Christian S. Collberg)
X-Newsgroups: comp.lang.icon
Subject: XML tools in Icon?
Date: 12 May 2000 10:44:10 -0700
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Are there any XML readers/writers available for Icon?

Thanks.

-- 

/CC
_______________________
http://www.collberg.com


From icon-group-sender  Fri May 12 12:35:09 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA06563
	for icon-group-addresses; Fri, 12 May 2000 12:34:57 -0700 (MST)
Message-Id: <200005121934.MAA06563@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Fri, 12 May 2000 14:57:07 -0000
X-Trace: client 958157853 38.163.203.81 (Fri, 12 May 2000 14:57:33 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I would agree that it is much easier to add a new primitive type to the Java
implementation of Icon, as opposed to the C implementation. In either case,
however, adding a new primitive type involves coding in a language other
than Icon. Ideally, it would be nice to be able to write a new type, along
with its associated primitive operations, in Icon.

Currently, Icon permits one to define a new type with a record declaration,
such as

    record Unicode_cset( ... )

A programmer can then define procedures for the new record type. A record
type, however, fails to extend the set of primitive types, for the following
reasons:

1.    You cannot (re)define the primitive operators, such as "*", "++", or
"<<", for a record type;
2.    You cannot define implicit /explicit type conversions between a record
type and the existing types; and
3.    You cannot define the behaviour of functions such as image and write
for the new record type.

Now imagine that we modify Icon so that we could define operators, type
conversions, etc. for user-defined Icon types. Would this give us a
"pluggable" capability, similar to Squeak?




From icon-group-sender  Tue May 16 12:23:51 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA28222
	for icon-group-addresses; Tue, 16 May 2000 12:22:54 -0700 (MST)
Message-Id: <200005161922.MAA28222@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Newsreader: Forte Agent 1.7/32.534
Date: Tue, 16 May 2000 18:42:07 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: flipper 958502527 212.187.67.243 (Tue, 16 May 2000 20:42:07 MET DST)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 24 Apr 2000 15:36:45 -0400, "Frank J. Lhota"
<NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:

>...

My problem with reversible assignment was partly due
to an (in hindsight) obvious oversight about
the nature of resumption within backtracking.
A generator that has spent all of its results
will NOT make the whole expression fail, but will
make the subexpression(s) in front of it resume and
on their success will then resume providing its own
results all over again. See GEN2() below
#-------------------------------------------------------------------------
procedure main()
write(a:=gen1(),b:=gen2(),9<(a+b))
end

procedure gen1()
local p; p:=0
while (p<5) do {p +:=1;write("p=",p);suspend p}
end

procedure gen2()
local q; q:=4
while (q<8) do {q +:=1;write("q=",q);suspend q}
end
#------------------------------------------------------------------------

BTW,
#-------------------------------------
procedure revass(a,b)
local c; c:=a
suspend (a:=b|(a:=c, &fail))
#-------------------------------------
doesn't seem to work in the 8queens example, neither
does MYREVASS() (without the &FAIL),
but that was no big surprise.




From icon-group-sender  Wed May 17 07:39:25 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00548
	for icon-group-addresses; Wed, 17 May 2000 07:38:12 -0700 (MST)
Message-Id: <200005171438.HAA00548@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 17 May 2000 02:40:50 GMT
X-Trace: vishnu.jussieu.fr 958531250 5464 132.227.81.128 (17 May 2000 02:40:50 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>,
Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
>Yes, but there are many factors that may not be in favor of doing primitive
>types in Icon. Speed issue may be a problem. Or when the primitive uses
>system depend things, such as sockets or some database API. Yet, the spirit
>of Icon is not "everything should be made in Icon" such as Smalltalk
>communities. Icon is not even bootstrapped. This latter made me surprised,
>Icon is so powerful and his text processing feature would just let anyone
>write good, complete and yet understandable compiler/interpreter!
I've always been under the impression that the Icon project has a shortage
of man power, which means that many cool things actually don't exist.

Personally, I would love to see Icon extended to be Idol (without the
preprocessing, which makes things awkward enough to debug for me that I
seldom use idol), or I would love to see the icon compiler resurrected, and
extended to handle separate compilation and direct translation to C
primitive numeric types (well, C++ looks like a more viable alternative,
but then I'm weird).

Unfortunately, I don't believe that the projet has resources to do that,
and I also know that I'm tangled up in enough programming projects that 
I can't afford yet another one :(
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Wed May 17 07:40:12 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00581
	for icon-group-addresses; Wed, 17 May 2000 07:39:57 -0700 (MST)
Message-Id: <200005171439.HAA00581@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 02:32:35 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 958530755 24.226.208.172 (Tue, 16 May 2000 22:32:35 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello Frank,

    really interesting comments here.

> I would agree that it is much easier to add a new primitive type to the
Java
> implementation of Icon, as opposed to the C implementation. In either
case,
> however, adding a new primitive type involves coding in a language other
> than Icon. Ideally, it would be nice to be able to write a new type, along
> with its associated primitive operations, in Icon.

Yes, but there are many factors that may not be in favor of doing primitive
types in Icon. Speed issue may be a problem. Or when the primitive uses
system depend things, such as sockets or some database API. Yet, the spirit
of Icon is not "everything should be made in Icon" such as Smalltalk
communities. Icon is not even bootstrapped. This latter made me surprised,
Icon is so powerful and his text processing feature would just let anyone
write good, complete and yet understandable compiler/interpreter!

> Currently, Icon permits one to define a new type with a record
declaration,
> such as
>
>     record Unicode_cset( ... )
>
> A programmer can then define procedures for the new record type. A record
> type, however, fails to extend the set of primitive types, for the
following
> reasons:
>
> 1.    You cannot (re)define the primitive operators, such as "*", "++", or
> "<<", for a record type;
> 2.    You cannot define implicit /explicit type conversions between a
record
> type and the existing types; and
> 3.    You cannot define the behaviour of functions such as image and write
> for the new record type.

Good points here. I'm not sure it should be part of Icon programming
language though. It appears much more like "object orientation" than the old
procedural language style. (BTW, is it a feature of Idol? I never used it..)

To be honest, I'm not sure if it's a good idea to have primitive data type
ability at Icon's level. Primitive should be a limited resource. It would
also require much more work and I have no idea on the position of Icon
Project Group. Yet my intend is not to go against their vision and I do not
want to start a new dialect.

> Now imagine that we modify Icon so that we could define operators, type
> conversions, etc. for user-defined Icon types. Would this give us a
> "pluggable" capability, similar to Squeak?

Not exactly, but it'd be impressive as well. Actually, Squeak and Icon are
different in their nature. Squeak is a Smalltalk dialect. Smalltalk is a
pure object-oriented programming environment/language. Icon is not an
environment nor OO. Smalltalk is also bootstrapped. Smalltalk is written in
Smalltalk. Usually, the virtual machine is not in Smalltalk though. But here
comes Squeak, they're cheating!! The Squeak virtual machine is written in
Slang, a Smalltalk subset, and debugged under Squeak environment! It's just
awesome.. but it does not end here, because Squeak generate portable C code.
Did you guess? Yes, they're generating the virtual machine in C code and
compile it for virtually any plateforms!

Enough of Squeak/Smalltalk, let's talk about Icon again. Yes, that'd be nice
to write primitive in Icon. If we had a dynamic primitive data types system.
And no, we wouldn't have to change Icon's implementation for being able to
write primitive in Icon. Why? As I said earlier, Icon's text processing
features could just be great for compiler things. We could write a Icon to C
generator. I've seen a little thing provided with Icon (icn2c.icn, I think),
would not be too hard to extend it or rewriting it for that purpose.
Primitives could still be written in the old C way as well..

Anyway, I think adding dynamic primitive data type system would be valuable
at all points. IMHO, it'd be also acceptable for Icon Project Group, because
it doesn't require to change everything in their actual implementation. I
know they strive for some ultime stability and portability, which is great!
On the other hand, that would allow a faster evolution of Icon without
changing the base system, the work of Icon Project Group. Plus, if someone
like me does a new primitive data type and Icon Project Group likes it, this
could be easily integrated to the next release.. without redownloading the
whole Icon or even recompiling Icon *mega grin*.

PS: It'd be also nice to bootstrap Icon. Ok, ok, there's enough work to do
yet. ::))

--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Wed May 17 07:40:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00658
	for icon-group-addresses; Wed, 17 May 2000 07:40:36 -0700 (MST)
Message-Id: <200005171440.HAA00658@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 05:26:27 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 958541187 24.226.208.172 (Wed, 17 May 2000 01:26:27 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Marc Espie" <espie@liafa.jussieu.fr> a écrit dans le message news:
8ft0ri$5ao$1@vishnu.jussieu.fr...
> In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>,
> Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
> >Yes, but there are many factors that may not be in favor of doing
primitive
> >types in Icon. Speed issue may be a problem. Or when the primitive uses
> >system depend things, such as sockets or some database API. Yet, the
spirit
> >of Icon is not "everything should be made in Icon" such as Smalltalk
> >communities. Icon is not even bootstrapped. This latter made me
surprised,
> >Icon is so powerful and his text processing feature would just let anyone
> >write good, complete and yet understandable compiler/interpreter!
> I've always been under the impression that the Icon project has a shortage
> of man power, which means that many cool things actually don't exist.

Well, yet I just mean things that already exist.. but maybe Icon can help us
to do these in some easier manners?! ::)

> Personally, I would love to see Icon extended to be Idol (without the
> preprocessing, which makes things awkward enough to debug for me that I
> seldom use idol), or I would love to see the icon compiler resurrected,
and
> extended to handle separate compilation and direct translation to C
> primitive numeric types (well, C++ looks like a more viable alternative,
> but then I'm weird).

My feeling about Idol is: this is just the same as C and Objective-C. Having
Idol implemented in the core of Icon's implementation may not be trivial
task at all. I don't know Idol, but Objective-C allows many dynamic things
that you just couldn't do in C++. If Idol does so, it makes the full C
implementation harder to write. Since I haven't tried Idol, I can't speak
with much concern, but it may just be matter of changing few things out the
current preprocessing implementation to make it stronger. Yet, you could
also build a special debugging tool.

I'm some C fellow, but I'm just thinking as an Icon programmer, we should
get out of any direct contact with C. Hence I'm getting interest in some
bootstrapping, writting primitives in Icon (which they would be translated
in C for compilation and linking). If Icon would allow us to write shared
library, that'd really rocks. We could write some high level primitives that
really needs to be written in Icon (only few cases, IMO). Unfortunatly,
handling shared library is often OS-oriented. Under *NIX, it's pretty easy,
but under Windows and OS/2, it requires some special structure. Anyway, this
is just a thought!

As you write about C++, I don't see any point of it. Icon is implemented in
C and C is available on a *lot* of platforms and works quite same (I've got
a weird feeling "quite same", "quite same", [..]). You should not forget
that the interface with generated code and Icon would probably be in C
rather than C++ anyway. I think the standard translator should translate
Icon to C, but nothing says there should not be a C++ translator available
as well.

BTW, I just like your "icon compiler resurrected" ! It's an interesting
thing that talks by itself. Actually, the current Icon implementation is a
little bit complex. I've seen worst, of course, Icon is nonetheless clearly
written. But since I'm some VM hacker wannabe (*LOL*), I got in touch with
some implementations out there. Smalltalk's VM came up the easiest one.
Squeak in particular is bringing a new vision of VM implementations.
Squeak's VM is pretty easy to understand, even for a newbie VM hacker. I
don't think it should remplace Icon. I'm not promoting Smalltalk here. I
just think it could help to reimplement Icon in a new, fresh, and very
simple manner. For exemple, block contexts in Smalltalk are just the same as
"scanning environment", but they are not specific to strings, not specific
at all! This would be a long term project that IPG would probably not want
to do. However, the dynamic primitive data types would be much more
interesting and smaller project.

> Unfortunately, I don't believe that the projet has resources to do that,
> and I also know that I'm tangled up in enough programming projects that
> I can't afford yet another one :(

I don't know the position of IPG in the moment, they'll probably hook on our
thread this week. I don't know if I would do it myself, I'm kinda concerned
in professional development and willing to write software(s) in Icon. The
fact is I need something to pay my university fees. ::) Another fact is, if
I would do it.. will IPG integrate it to Icon? If the answer is no, I would
not even write a line of code because this would lead to ANOTHER dialect of
the language. I'd rather support fully Icon.

cheer,
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Wed May 17 07:41:46 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00700
	for icon-group-addresses; Wed, 17 May 2000 07:41:01 -0700 (MST)
Message-Id: <200005171441.HAA00700@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 07:24:25 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 958548265 24.226.208.172 (Wed, 17 May 2000 03:24:25 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> I'm some C fellow, but I'm just thinking as an Icon programmer, we should
> get out of any direct contact with C. Hence I'm getting interest in some
> bootstrapping, writting primitives in Icon (which they would be translated
> in C for compilation and linking). If Icon would allow us to write shared
> library, that'd really rocks. We could write some high level primitives
that
> really needs to be written in Icon (only few cases, IMO). Unfortunatly,
> handling shared library is often OS-oriented. Under *NIX, it's pretty
easy,
> but under Windows and OS/2, it requires some special structure. Anyway,
this
> is just a thought!

Oh yeah, I forgot some things. First, Icon generates bytecodes which are
interpreted by the virtual machine. But hey, Java is bytecoded and there is
no executable files? Yeah, right, the virtual machine is copied and the code
is appended or something. That's why a simple "hello world" takes 300k! he
he he. Basically, the problem comes from this issue and the calling
convention. Shared library are modeled from C language and its calling
convention. Icon as no such support! So, adding support for generation of
shared library is like having a special virtual machine that handle calling
convention and "understand" it to run proper procedures. That'd also make
big shared library.. Anyway, if I'd be worrying about something, I would do
for the calling convention thing. ::)

I'm not sure about "how hard" it'd be to do. However, that'd be another cool
thing about Icon. Gee, wouldn't be nice to do plugins for your favorite apps
in Icon?!

see ya,
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Wed May 17 07:42:23 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00760
	for icon-group-addresses; Wed, 17 May 2000 07:41:59 -0700 (MST)
Message-Id: <200005171441.HAA00760@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 17 May 2000 09:45:59 GMT
X-Trace: vishnu.jussieu.fr 958556759 17223 132.227.81.128 (17 May 2000 09:45:59 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <74qU4.790$to2.107064@carnaval.risq.qc.ca>,
Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
>As you write about C++, I don't see any point of it. Icon is implemented in
>C and C is available on a *lot* of platforms and works quite same (I've got
>a weird feeling "quite same", "quite same", [..]). You should not forget
>that the interface with generated code and Icon would probably be in C
>rather than C++ anyway. I think the standard translator should translate
>Icon to C, but nothing says there should not be a C++ translator available
>as well.
C++ is available on a lot of platforms. Find me a platform that doesn't
support a C++ compiler.

I've seen Icon runtime library, I know C, I know C++. I know that the
translation to C++ of quite a few concepts would be fairly direct (most
icon objects would just get a class, and handling polymorphism is not much
harder, especially with type deduction running along, since you don't always
need polymorphism). There are also fairly reasonable ways to `invert' Icon
concepts such as generators into fast C++ constructs.

My main concern with the icon-to-C  compiler was size and speed: it's not
reasonable to use over a 3000 lines project which translate to >90000 lines
of C, which then proceeds to exceed 80MB of memory to compile...

At a guess, the corresponding translation to C++ would be 10 times smaller,
and much more easy to tweak. But then, this means having someone with free
time on their hands, and knowing C++...

As far as byte-code and the java analogy goes, I'm not convinced at all.
We already have a perfectly good working, somewhat slow, icon implementation.
What's the benefit of doing yet another slow implementation ?

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Wed May 17 07:43:13 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00794
	for icon-group-addresses; Wed, 17 May 2000 07:42:44 -0700 (MST)
Message-Id: <200005171442.HAA00794@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: Re: Reversible assignment really reversible ?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 09:21:29 -0000
X-Trace: client 958569712 38.163.203.81 (Wed, 17 May 2000 09:21:52 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


"F.G. van DORP" <F.G.van.Dorp@digimedia.nl> wrote in message
news:h553is4c3ulev333pul872qcr7e5uvubih@4ax.com...
> BTW,
> #-------------------------------------
> procedure revass(a,b)
> local c; c:=a
> suspend (a:=b|(a:=c, &fail))
> #-------------------------------------
> doesn't seem to work in the 8queens example, neither
> does MYREVASS() (without the &FAIL),
> but that was no big surprise.

There may be a misunderstanding here. In Icon, all procedure parameters are
passed by value, not by reference. When the procedure revass is called, a
and b are assigned the values of the first and second actual parameters (or
&null if these parameters are not specified). If the statements in revass
changes in a and b, these changes are NOT copied back to the actual
parameters. If we were to execute the following Icon code:

    c := 3
    revass( c, 4 )

the value of c would not be affected. The revass function would assign 4 to
the local variable a, but that would have no impact on c.

The situation is similar in the C language. The C function

    int Assign( int a, int b )
    {
        return ( a = b );
    }

does NOT simulate C integer assignment, since the assignment statement ( a =
b ) only changes the local variable a.

If you want to simulate reversible assignment, you need a more sophisticated
approach. Icon structures such as lists and records use pointer semantics,
and can be used to get the effect of pass by reference.




From icon-group-sender  Wed May 17 07:44:01 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00845
	for icon-group-addresses; Wed, 17 May 2000 07:43:27 -0700 (MST)
Message-Id: <200005171443.HAA00845@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 13:52:48 GMT
X-Complaints-To: abuse@cgocable.ca
X-Trace: carnaval.risq.qc.ca 958571568 24.226.208.172 (Wed, 17 May 2000 09:52:48 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

1/ I ain't no C++ support, fellow, fan, or not even like the language. Let's
not talk about it. ::)
2/ The point of my original post is not really Icon reimplementation, but
adding a new feature to the language.
3/ I feel your post "hide" something, like transforming Icon to some OOP
language. If we change Icon's nature, we're no longer having Icon. It'd be
better to support Idol instead, in that concern.
4/ My point about platform availability was about backward compatibility. I
know that nowaday's machines and system have C++ compilers available, but
Icon also runs on older machines/systems.
5/ and finaly, speed issue only speaks by benchmarking.

> My main concern with the icon-to-C  compiler was size and speed: it's not
> reasonable to use over a 3000 lines project which translate to >90000
lines
> of C, which then proceeds to exceed 80MB of memory to compile...

Actually, we should not forget one thing about Icon. Even though Icon looks
to my eye pretty young, fresh and complete, the fact is the first
implementation was made in 1979! I'm not sure when the C implemention has
started, but it's sure old. Most concepts of Icon implementation just rocks,
but it doesn't mean these are using the newer and better techniques.

> At a guess, the corresponding translation to C++ would be 10 times
smaller,
> and much more easy to tweak. But then, this means having someone with free
> time on their hands, and knowing C++...

Well, I agree on this. But good C code can be just similar. A *small*
reminder: C is a simple language, even though pointer arithmetics may drive
some crazy, it has few keywords and structures. C++ is a complex language,
it has full C compatibility, plus it has its own good and bad things. There
is a *lot* of concepts in C++ and avanced one are even not usually convered
by popular books.

There is many things that was not even concerned in the seventies and
eighties, such as resuability, portability, information hidding and stuff.
So, the techniques have lot changed and there is more and more valuable
documents on the newer way of implementing old concepts (nowaday's GC
implementations are just crazy, it almost worth any custom made memory
management. There is just almost no reason to not use GC now ::).

You should also dig into Squeak's Virtual Machine source code. You'd
probably be impressed how clean/clear their C implementation is made. Don't
forget it's generated C code, for most parts. I guess they found no reason
to implement it in C++. Squeak is much more portable than Icon, it runs on
everything gcc do (and runs virtually the same on every platform!), the only
exception is the need of bitblt functionalities.

Anyway, I still recall my primary concern was/is about dynamic primitive
data types in Icon. Wouldn't it be nice if..

Cheer, ::)
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Wed May 17 09:34:16 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04298
	for icon-group-addresses; Wed, 17 May 2000 09:33:54 -0700 (MST)
Message-Id: <200005171633.JAA04298@baskerville.CS.Arizona.EDU>
Date: Wed, 17 May 2000 08:01:08 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Ian Trudel wrote:

> Actually, we should not forget one thing about Icon. Even though Icon looks
> to my eye pretty young, fresh and complete, the fact is the first
> implementation was made in 1979! I'm not sure when the C implemention has
> started, but it's sure old. Most concepts of Icon implementation just rocks,
> but it doesn't mean these are using the newer and better techniques.

Just for historical accuracy...

1979 is the first C implemenation of Icon (done by Cary Coutant and me) -
the first implementation of Icon (an amazing beast written in FORTRAN that
producing FORTRAN (really RatFor) executables) was several years old by
that time.  Also, the C implementation was done on a PDP 11/70, with
its 64K address space - so some of the implementation decisions were driven
by considerations that are no longer relevant!

Cary produced a compiler for Icon at the same time, but there was surprisingly
little improvement over the interpreter because Icon spends most of its time
in the run-time system, which is already compiled code.  It wasn't until later
that Ken Walker's work produced a more efficient optimizing compiler.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Wed May 17 12:23:02 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA09657
	for icon-group-addresses; Wed, 17 May 2000 12:22:45 -0700 (MST)
Message-Id: <200005171922.MAA09657@baskerville.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Wed, 17 May 2000 10:49:08 -0700
x-sender: cary@adlmail.cup.hp.com
From: Cary Coutant <cary@cup.hp.com>
To: "Steve Wampler" <swampler@noao.edu>,
        "icon-group" <icon-group@optima.CS.Arizona.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>Just for historical accuracy...
>
>1979 is the first C implemenation of Icon (done by Cary Coutant and me) -
>the first implementation of Icon (an amazing beast written in FORTRAN that
>producing FORTRAN (really RatFor) executables) was several years old by
>that time.  Also, the C implementation was done on a PDP 11/70, with
>its 64K address space - so some of the implementation decisions were driven
>by considerations that are no longer relevant!
>
>Cary produced a compiler for Icon at the same time, but there was 
>surprisingly
>little improvement over the interpreter because Icon spends most of its time
>in the run-time system, which is already compiled code.  It wasn't until 
>later
>that Ken Walker's work produced a more efficient optimizing compiler.

To clarify a bit more, the first implementation we did in 1979 was sort 
of a compiler. The icon translator still generated the "u-code" -- our 
intermediate representation -- and the icon linker then generated a 
single, large, PDP-11 assembly-language source file. This file was then 
assembled and linked against the large Icon runtime library to produce a 
native executable. The assembly code was really little more than calls to 
the runtime system, and was a very straightforward and simple translation 
of the Icon intermediate code.

The problem with this approach was that the runtime library was so huge 
that link times were large even for a simple "hello, world" program.

Around 1981, I think, I spent a week modifying the Icon linker to produce 
the Icon byte code instead of PDP-11 assembly language, and then built a 
small interpreter, linked to the runtime system. Now, the Icon linker 
needed only to produce a small bytecode file that could be read and 
interpreted by "iconx." The result was greatly improved compile and link 
times, very little runtime performance difference, and -- finally -- 
easier portability to other Unix machines.

At the time, I was just copying the idea of a bytecode interpreter from 
the Pascal p-system. Little did I realize that Sun had yet to "invent" 
bytecode!

-cary


From icon-group-sender  Wed May 17 12:23:58 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA09697
	for icon-group-addresses; Wed, 17 May 2000 12:23:23 -0700 (MST)
Message-Id: <200005171923.MAA09697@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 17 May 2000 18:46:29 GMT
X-Trace: vishnu.jussieu.fr 958589189 2939 132.227.81.128 (17 May 2000 18:46:29 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <200005171443.HAA00845@baskerville.CS.Arizona.EDU>,
Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
>3/ I feel your post "hide" something, like transforming Icon to some OOP
>language. If we change Icon's nature, we're no longer having Icon. It'd be
>better to support Idol instead, in that concern.
Wow, powerful drugs. Read what I write, and not what you feel like I'm
writing.
>4/ My point about platform availability was about backward compatibility. I
>know that nowaday's machines and system have C++ compilers available, but
>Icon also runs on older machines/systems.
I'm perfectly aware of the machines Icon runs upon.
Don't speak about `older machines/systems', give me the name of one such
system which does not support a C++ compiler. Speaking in generalities
lead nowhere.

>5/ and finaly, speed issue only speaks by benchmarking.
I've run some fairly large icon projects in the past. I have a fairly good
idea about what slowed them down eventually. I even have a submitted paper
to a conference that pits icon against maple and C++.

>There is many things that was not even concerned in the seventies and
>eighties, such as resuability, portability, information hidding and stuff.
>So, the techniques have lot changed and there is more and more valuable
>documents on the newer way of implementing old concepts (nowaday's GC
>implementations are just crazy, it almost worth any custom made memory
>management. There is just almost no reason to not use GC now ::).

Like wow, I was around in the eighties, and I haven't noticed portability
and reusability coming out of nowhere... It was around pretty much forever...
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Wed May 17 16:24:48 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA19139
	for icon-group-addresses; Wed, 17 May 2000 16:24:21 -0700 (MST)
Message-Id: <200005172324.QAA19139@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
To: "Icon Project Group" <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Wed, 17 May 2000 17:24:01 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Marc Espie" <espie@liafa.jussieu.fr> a écrit dans le message news:
200005171923.MAA09697@baskerville.CS.Arizona.EDU...
> In article <200005171443.HAA00845@baskerville.CS.Arizona.EDU>,
> Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
> >3/ I feel your post "hide" something, like transforming Icon to some OOP
> >language. If we change Icon's nature, we're no longer having Icon. It'd
be
> >better to support Idol instead, in that concern.
> Wow, powerful drugs. Read what I write, and not what you feel like I'm
> writing.

Is it OK with you if my feeling is wrong? Whatever, you confirmed my feeling
was wrong, no need to add insult with it. ::)

> >4/ My point about platform availability was about backward compatibility.
I
> >know that nowaday's machines and system have C++ compilers available, but
> >Icon also runs on older machines/systems.
> I'm perfectly aware of the machines Icon runs upon.
> Don't speak about `older machines/systems', give me the name of one such
> system which does not support a C++ compiler. Speaking in generalities
> lead nowhere.

I'm sorry about this point. Indeed, I don't really care about C++, I usually
avoid projects requiring it. I'm not taking part of an official C++
opposition! I'm not going to build a list of plateforms that don't support
C++, if any. That'd be pointless as well as speaking about generalities.

> >5/ and finaly, speed issue only speaks by benchmarking.
> I've run some fairly large icon projects in the past. I have a fairly good
> idea about what slowed them down eventually. I even have a submitted paper
> to a conference that pits icon against maple and C++.

Now that's interesting, is your paper online?

> >There is many things that was not even concerned in the seventies and
> >eighties, such as resuability, portability, information hidding and
stuff.
> >So, the techniques have lot changed and there is more and more valuable
> >documents on the newer way of implementing old concepts (nowaday's GC
> >implementations are just crazy, it almost worth any custom made memory
> >management. There is just almost no reason to not use GC now ::).
>
> Like wow, I was around in the eighties, and I haven't noticed portability
> and reusability coming out of nowhere... It was around pretty much
forever...

Funny, they're still talking about it today. Actually, I haven't worked for
huge companies that have plenty of money to pay me to make things fully
reuseable. But I've been pretty lucky cause most of the time, my bosses
allowed me to take the time to think about reusable components. However,
many of my friends are working in small and average companies that are
willing them to produce results fast-fast-fast. They know and talk about
reusability with me, they have interesting point of views on it.. but they
actually never reuse anything nor making things to be reusable. My point is,
they are nice words, but the code doesn't always show their significations.
It was true yestarday, in eighties, it's still (too often, in my taste) true
today. Yet, I'm younger, so the eighties is sometime blurry in my mind, but
I have plenty of books that reminds me the decade.

I'm not willing to fight with you or anyone. My interests are not in
rewriting Icon, though having an intelligent conversation with people on
this list may be instructive and interesting. I'm primarly interested in
adding ONE specific feature to Icon so it would let us extent some parts of
the language without remodeling/rewriting the whole implementation and
create some new dialect(s). Some other things along this feature such as
Icon to "whatever language you want" may be interesting as well. If you're
not personally interested by this topic, it's ok, let's just stop messages
here.

regards,
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/




From icon-group-sender  Wed May 17 16:25:44 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA19236
	for icon-group-addresses; Wed, 17 May 2000 16:25:36 -0700 (MST)
Message-Id: <200005172325.QAA19236@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
To: "icon-group" <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Wed, 17 May 2000 17:29:12 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Thanks for the enlightement, I was not aware of this. "The Implementation Of
The Icon Programming Language" book says:

"The first implementation of Icon (Griswold and Hanson 1979) was written in
RatFor, a preprocessor for Fortran that supports structured programming
features (Kernighan 1975).", p.6.

regards,
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/

----- Original Message -----
From: "Cary Coutant" <cary@cup.hp.com>
To: "Steve Wampler" <swampler@noao.edu>; "icon-group"
<icon-group@optima.CS.Arizona.EDU>
Sent: Wednesday, May 17, 2000 1:49 PM
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?


> >Just for historical accuracy...
> >
> >1979 is the first C implemenation of Icon (done by Cary Coutant and me) -
> >the first implementation of Icon (an amazing beast written in FORTRAN
that
> >producing FORTRAN (really RatFor) executables) was several years old by
> >that time.  Also, the C implementation was done on a PDP 11/70, with
> >its 64K address space - so some of the implementation decisions were
driven
> >by considerations that are no longer relevant!
> >
> >Cary produced a compiler for Icon at the same time, but there was
> >surprisingly
> >little improvement over the interpreter because Icon spends most of its
time
> >in the run-time system, which is already compiled code.  It wasn't until
> >later
> >that Ken Walker's work produced a more efficient optimizing compiler.
>
> To clarify a bit more, the first implementation we did in 1979 was sort
> of a compiler. The icon translator still generated the "u-code" -- our
> intermediate representation -- and the icon linker then generated a
> single, large, PDP-11 assembly-language source file. This file was then
> assembled and linked against the large Icon runtime library to produce a
> native executable. The assembly code was really little more than calls to
> the runtime system, and was a very straightforward and simple translation
> of the Icon intermediate code.
>
> The problem with this approach was that the runtime library was so huge
> that link times were large even for a simple "hello, world" program.
>
> Around 1981, I think, I spent a week modifying the Icon linker to produce
> the Icon byte code instead of PDP-11 assembly language, and then built a
> small interpreter, linked to the runtime system. Now, the Icon linker
> needed only to produce a small bytecode file that could be read and
> interpreted by "iconx." The result was greatly improved compile and link
> times, very little runtime performance difference, and -- finally --
> easier portability to other Unix machines.
>
> At the time, I was just copying the idea of a bytecode interpreter from
> the Pascal p-system. Little did I realize that Sun had yet to "invent"
> bytecode!
>
> -cary
>



From icon-group-sender  Thu May 18 07:56:14 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA14529
	for icon-group-addresses; Thu, 18 May 2000 07:53:43 -0700 (MST)
Message-Id: <200005181453.HAA14529@baskerville.CS.Arizona.EDU>
From: Patrick Scheible <kkt@itchy.serv.net>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 18 May 2000 00:11:21 GMT
X-Newsreader: Gnus v5.3/Emacs 19.34
Cache-Post-Path: dns2.serv.net!unknown@itchy.serv.net
X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

espie@liafa.jussieu.fr (Marc Espie) writes:

> >There is many things that was not even concerned in the seventies and
> >eighties, such as resuability, portability, information hidding and stuff.
> >So, the techniques have lot changed and there is more and more valuable
> >documents on the newer way of implementing old concepts (nowaday's GC
> >implementations are just crazy, it almost worth any custom made memory
> >management. There is just almost no reason to not use GC now ::).
> 
> Like wow, I was around in the eighties, and I haven't noticed portability
> and reusability coming out of nowhere... It was around pretty much forever...

Yes, portability and reusability have been concerns since Fortran and
COBOL were invented.

-- Patrick Scheible


From icon-group-sender  Thu May 18 12:21:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA21692
	for icon-group-addresses; Thu, 18 May 2000 12:21:15 -0700 (MST)
Message-Id: <200005181921.MAA21692@baskerville.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Thu, 18 May 2000 10:23:07 -0700
x-sender: cary@adlmail.cup.hp.com
From: Cary Coutant <cary@cup.hp.com>
To: "Ian Trudel" <ian.trudel@tr.cgocable.ca>,
        "icon-group" <icon-group@optima.CS.Arizona.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Steve said:
>> >1979 is the first C implemenation of Icon (done by Cary Coutant and me) -
>> >the first implementation of Icon ... was several years old by
>> >that time.

And I replied:
>> To clarify a bit more, the first implementation we did in 1979 was sort
>> of a compiler. 

Then Ian quoted this from the Icon implementation book:
>"The first implementation of Icon (Griswold and Hanson 1979) was written in
>RatFor, a preprocessor for Fortran that supports structured programming
>features (Kernighan 1975).", p.6.

In replying to Steve's message, I was referring to the first 
implementation that Steve and I did in C on the PDP/11. Yes, there was 
the Ratfor version (on the DEC-10) by Tim Korb (aka "bikmort"), et. al., 
before that.

Sorry, I didn't mean to mislead anyone.

-cary


From icon-group-sender  Thu May 18 16:24:39 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA28120
	for icon-group-addresses; Thu, 18 May 2000 16:23:25 -0700 (MST)
Message-Id: <200005182323.QAA28120@baskerville.CS.Arizona.EDU>
From: "J.R. Sampson" <jsampson@indexes.u-net.com>
To: icon-group@optima.CS.Arizona.EDU
Date: Thu, 18 May 2000 22:52:24 +0100
Subject: Logicon Prolog interpreter
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello -

I have been looking at Alan Finlay's Prolog interpreter v.4 which Mr 
Van Dorp kindly sent me some time ago.
Impressions so far:
At first I thought it didn't like me, but I have found postings about it 
in the newsgroup file group90a.txt in the newsgroup directory in the 
Icon FTP site. For the first time I was able to enter material to the 
interpreter without it complaining of a syntax error every time - a 
'Eureka' moment for me as always.

There is documentation in group90a.txt for Version 2, but Version 4 
is more advanced, implementing assert and retract clauses etc. I 
have not been able to find the test files test1.plg etc. that are 
mentioned in the postings.

Queries should not have spaces after the prefix ':-' or ?-' e.g.
:-predicate,....,predicate. I think on the whole LogIcon does not like 
spaces at all, but I haven't experimented much.

I think files for it to 'consult' should strictly be UNIX format text files 
rather than MS-DOS format.

The interpreter itself is in the above-mentioned archive file, as well 
as its predecessors, but beware of emailer mangling of the format.

Regards

_John Sampson_


From icon-group-sender  Fri May 19 07:54:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA24950
	for icon-group-addresses; Fri, 19 May 2000 07:53:32 -0700 (MST)
Message-Id: <200005191453.HAA24950@baskerville.CS.Arizona.EDU>
Date: Fri, 19 May 2000 17:26:43 +1000 (EST)
From: Rohan McLeod <rohan@micom.asn.au>
To: icon_group <icon-group@optima.CS.Arizona.EDU>
Subject: Stupid newbie query re Icon compiler   
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

When I first started to learn Icon the options for executables on
both Linux and NT were:
(1)run with interpreter
(2)compile to C  then compile the C code.
Has anything much changed? 
eg is it possible (or will it ever be) to compile direct?
                                       thanks Rohan 
                                       Melbourne,Australia 



From icon-group-sender  Fri May 19 12:25:07 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA02361
	for icon-group-addresses; Fri, 19 May 2000 12:24:33 -0700 (MST)
Message-Id: <200005191924.MAA02361@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 19 May 2000 15:09:30 GMT
X-Trace: vishnu.jussieu.fr 958748970 2780 132.227.81.128 (19 May 2000 15:09:30 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <200005172324.QAA19139@baskerville.CS.Arizona.EDU>,
Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
>> >5/ and finaly, speed issue only speaks by benchmarking.
>> I've run some fairly large icon projects in the past. I have a fairly good
>> idea about what slowed them down eventually. I even have a submitted paper
>> to a conference that pits icon against maple and C++.
>
>Now that's interesting, is your paper online?

Not yet, sorry. There are proceedings involved, and I'll have to see if
there is red tape involved with Springer.

Briefly put, the gist of the matter was to compare methods to generate
Dyck words (well-parenthesized words).

I asked a friend who is a typical user of maple to write it in a way natural
to maple, which I compared to the typical icon generator:

procedure dyck(n)
	if n = 0 then
		suspend ""
	else
		every i := 0 to n-1 do
			suspend "("||dyck(i)||")"||dyck(n-i-1)
end

As far as C++ goes, I exposed a simple technique to `revert' generators 
control, e.g, model
every write(gen())
as an `application of' every(write(.))  to gen.

The traditional icon implementation does have write call gen repetitively.
Instead, we have gen produce results and pass them to a `continuation' of
write that tells whether it needs more results. This combines nicely with
the Template Method design pattern, and leads to an almost automatic
translation to C++ that does not need any extra control structures to handle
generators (e.g., the program flow is more or less hardcoded into templates).

For Dyck words, the results looks like (more or less, generator.h left
aside for brevity):

#include <string>
#include "generator.h"

class DyckWord3: public Function<string> {
	const Function<string>& f; const string& b;
public:
	DyckWord3(const string& b_, const Function<string>& f_):
		f(f_), b(b_) {}
	bool operator() (const string& e) const {
		return f(b+e);
	}
};
class DyckWord2: public Generator<string> { const string& a; int r;
public:
	DyckWord2(const string& a_, int r_): a(a_), r(r_) {}
	bool iterate(const Function<string>& consume) const;
};
class DyckWord1: public Function<string> {
	const Function<string>& f; const int n;
public:
	DyckWord1(const Function<string>& f_, int n_): f(f_), n(n_) {}
	bool operator()(const string &a) const {
		return DyckWord2("("+a+")", n).iterate(f);
	}
};
class DyckWord: public Generator<string> { const int n;
public:
	DyckWord(int n_): n(n_) {}
	bool iterate(const Function<string>& consume) const {
		if (n == 0) return consume("");
		else for (int i = 0; i < n; i++)
				if (!DyckWord(i).iterate(DyckWord1(consume, n-1-i)))
					return false;
		return true;
	}
}; 
bool DyckWord2::iterate(const Function<string>& consume) const {
		return DyckWord(r).iterate(DyckWord3(a, consume));
}


Granted, this is somewhat longer than the icon version.

Both the Icon and C++ version outperform Maple by a huge factor (as maple
is not geared toward generators, and the traditional Dyck word generator
is memory-heavy).  Somewhat surprisingly, the C++ implementation is not much
faster than the Icon implementation (factor of 3).  This was traced down
to the particular C++ string implementation not being well-suited to the job
at hand.  

In similar cases where strings are not involved and where memory consumption
can be taken out of the way (permutations, with in-place list construction),
C++ outperforms icon by a factor of 10 or more, which is quite logical.

The Icon compiler does not gain that much, which was to be expected as well.
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Mon May 22 08:02:27 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA06633
	for icon-group-addresses; Mon, 22 May 2000 08:01:21 -0700 (MST)
Message-Id: <200005221501.IAA06633@baskerville.CS.Arizona.EDU>
From: corre@alpha1.csd.uwm.edu (Alan D Corre)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 22 May 2000 04:21:06 GMT
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant 
<cary@cup.hp.com> writes:

>
>At the time, I was just copying the idea of a bytecode interpreter from 
>the Pascal p-system. Little did I realize that Sun had yet to "invent" 
>bytecode!

This prompts me to ask a question that has been bothering me for some time,
and to which I would appreciate a reply that is not overly technical. I used
Apple Pascal what seems like eons ago. It was a really nice system, invented
by Ken Bowles, if I remember correctly. My question is, why is there so much
fuss about Java working across different platforms? Was not the p-system a
"virtual machine" which could function in just that way?


-- 
			Alan D. Corre
		Emeritus Professor of Hebrew Studies
		University  of  Wisconsin-Milwaukee
		    http://www.uwm.edu/~corre/


From icon-group-sender  Mon May 22 08:02:57 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA06721
	for icon-group-addresses; Mon, 22 May 2000 08:02:43 -0700 (MST)
Message-Id: <200005221502.IAA06721@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: 22 May 2000 08:03:05 GMT
X-Trace: vishnu.jussieu.fr 958982585 29937 132.227.81.128 (22 May 2000 08:03:05 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <8gacji$ob4$1@uwm.edu>,
Alan D Corre <corre@alpha1.csd.uwm.edu> wrote:
>This prompts me to ask a question that has been bothering me for some time,
>and to which I would appreciate a reply that is not overly technical. I used
>Apple Pascal what seems like eons ago. It was a really nice system, invented
>by Ken Bowles, if I remember correctly. My question is, why is there so much
>fuss about Java working across different platforms? Was not the p-system a
>"virtual machine" which could function in just that way?
Yes, it was.

As for java, the answer is simple: marketing hype.
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Mon May 22 12:33:55 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA13937
	for icon-group-addresses; Mon, 22 May 2000 12:33:36 -0700 (MST)
Message-Id: <200005221933.MAA13937@baskerville.CS.Arizona.EDU>
Date: Mon, 22 May 2000 12:15:57 -0500
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <corre@alpha1.csd.uwm.edu>, <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Content-Disposition: inline
X-Guinevere: 1.0.13 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id KAA10273
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Absolutely the same, except that the Java system purports to be more security-aware.

Moreover, the original portable Pascal compiler by N. Wirth was done the same way, so the UCSD system wasn't the first, by a long shot, but it was pretty popular on Apples for a time.  But it was basically just a copy of Wirth's original portable Pascal kit.  (BTW, I still have a copy of the Pascal P-Machine spec from ETH Zurich!)

The only thing UCSD Pascal lacked, and the only thing that Java lacks, is a hardware implementation.  It puzzles me:  all the complaints about Java's speed, or lack of it, could easily be fixed by a hardware implementation of the virtual machine--a plug-in board, say--but I never hear anyone asking for it or proposing to do it.  Odd.

Is anyone old enough to remember the Burroughs B-5500?  The HP 9000?  These were stack machines that implemented Algol semantics in hardware.

Charles Hethcoat

>>> Alan D Corre <corre@alpha1.csd.uwm.edu> 00-05-21 11:21:06 PM >>>
In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant 
<cary@cup.hp.com> writes:

>
>At the time, I was just copying the idea of a bytecode interpreter from 
>the Pascal p-system. Little did I realize that Sun had yet to "invent" 
>bytecode!

This prompts me to ask a question that has been bothering me for some time,
and to which I would appreciate a reply that is not overly technical. I used
Apple Pascal what seems like eons ago. It was a really nice system, invented
by Ken Bowles, if I remember correctly. My question is, why is there so much
fuss about Java working across different platforms? Was not the p-system a
"virtual machine" which could function in just that way?


-- 
			Alan D. Corre
		Emeritus Professor of Hebrew Studies
		University  of  Wisconsin-Milwaukee
		    http://www.uwm.edu/~corre/ 




From icon-group-sender  Mon May 22 12:34:31 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA13969
	for icon-group-addresses; Mon, 22 May 2000 12:34:08 -0700 (MST)
Message-Id: <200005221934.MAA13969@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Mon, 22 May 2000 12:37:45 -0500
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>At the time, I was just copying the idea of a bytecode interpreter from 
>the Pascal p-system. Little did I realize that Sun had yet to "invent" 
>bytecode!

> This prompts me to ask a question that has been bothering me for some time,
and to which I would appreciate a reply that is not overly technical. I used
Apple Pascal what seems like eons ago. It was a really nice system, invented
by Ken Bowles, if I remember correctly. My question is, why is there so much
fuss about Java working across different platforms? Was not the p-system a
"virtual machine" which could function in just that way?

Yes of course, and in fact that's part of why those of us who have been in the 
business for so long have quite a "big deal, ho-hum" attitude about Java.  
Especially given Sun's repugnant attempt to blatantly use it as a blunt tool to 
bludgeon their biggest software competitor.

Besides the fact that, given (legitimate) security concerns, I *really* do not 
want Webmasters to be able to run their own executable code on my machine just 
because I stop in to browse their Web site.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Mon May 22 12:56:57 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14412
	for icon-group-addresses; Mon, 22 May 2000 12:56:46 -0700 (MST)
Message-Id: <200005221956.MAA14412@baskerville.CS.Arizona.EDU>
To: corre@alpha1.csd.uwm.edu (Alan D Corre)
cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: Is Anyone Working On A Unicode Version Of Icon? 
User-Agent: EMH/1.10.0 SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (mips-dec-ultrix4.4) MULE/4.0 (HANANOEN)
Date: Mon, 22 May 2000 20:32:06 +0100
From: "Olivier Lecarme" <ol@i3s.unice.fr>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>>>> Regarding Re: Is Anyone Working On A Unicode Version Of Icon?; corre@alpha1.csd.uwm.edu (Alan D Corre) adds:


ADC> In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant 
ADC> <cary@cup.hp.com> writes:

>> 
>> At the time, I was just copying the idea of a bytecode interpreter from 
>> the Pascal p-system. Little did I realize that Sun had yet to "invent" 
>> bytecode!

ADC> This prompts me to ask a question that has been bothering me for some time,
ADC> and to which I would appreciate a reply that is not overly technical. I used
ADC> Apple Pascal what seems like eons ago. It was a really nice system, invented
ADC> by Ken Bowles, if I remember correctly. My question is, why is there so much
ADC> fuss about Java working across different platforms? Was not the p-system a
ADC> "virtual machine" which could function in just that way?

Pcode was not invented by Ken Bowles at all. It was only the result of a
practical project by three or four undergraduate students of Niklaus
Wirth in Zurich Polytechnicum. The Pcode-generating compiler and Pcode
interpreter, both written in Pascal of course, were first published in
two working documents of the Zurich Computer Science Department
(characteristic small yellow booklets; I should still have them at
work).

Since it was public domain, Ken Bowles managed to make money with the
idea, without ever acknowledging his debt to the Zurich team. He did not
ever attempt to complete the compiler, which did not implement some
features considered too complicated, like procedural parameters for
example. The unimplemented features of this compiler managed to remain
intact in Borland Turbo-Pascal, but that is another history...

Anyway, this is simply one more example of the perpetual re-inventing of
the wheel. It works very well when people no longer remember that the
wheel has been in use for years. Thus, most of the fuss about Java
virtual machine, portability by interpretation, bytecode and so on, is
completely unjustified, since there is nothing new in this approach.

The authors of the initial idea are Niklaus Wirth, his assistant Urs
Amman, and the student team, whose names I can retrieve in a few days.
Of course, language implementation by interpretation is much older, and
comes back to the very first programming languages.

-- 


			Olivier Lecarme


From icon-group-sender  Tue May 23 07:39:43 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA09912
	for icon-group-addresses; Tue, 23 May 2000 07:38:54 -0700 (MST)
Message-Id: <200005231438.HAA09912@baskerville.CS.Arizona.EDU>
Date: Tue, 23 May 2000 15:37:39 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
To: CHETHCOA@oss.oceaneering.com, corre@alpha1.csd.uwm.edu,
        icon-group@optima.CS.Arizona.EDU
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

	Moreover, the original portable Pascal compiler by N. Wirth was
	done the same way, so the UCSD system wasn't the first, by a long shot,
	but it was pretty popular on Apples for a time.

I still have a copy of UCSD Pascal running on a Mac Plus.
I wonder what the status of the source code is these days?

But it was basically
just a copy of Wirth's original portable Pascal kit.

Well, it added concurrent processes, so it wasn't JUST a copy.

I'm not quite sure where BCPL fits into the chronology.
The published BCPL compiler compiled to an abstract instruction set;
there was an interpreter available for that.

	The only thing UCSD Pascal lacked, and the only thing that Java
	lacks, is a hardware implementation.  It puzzles me:

Sun designed a Java machine.  I've seen a photograph of one
The problem with a Java machine is that it doesn't support legacy
software (well, there is a COBOL to JVM compiler, so I guess it does
support legacy software).  Make that "doesn't support legacy *C* code."
Like it won't run Microsoft Outlook.  Which is why Microsoft tried to
impair the portability of Java...  And the market share for hardware
that doesn't support good virus hosts is fairly limited.

	Is anyone old enough to remember the Burroughs B-5500?

Will B6700 and HP 3000 do?  Generating code for the B6700 was so easy
an undergraduate could do it in a couple of days.  The B6700
architecture has had a fair few implementations, including one
PC-sized.


From icon-group-sender  Tue May 23 07:40:17 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA09991
	for icon-group-addresses; Tue, 23 May 2000 07:40:04 -0700 (MST)
Message-Id: <200005231440.HAA09991@baskerville.CS.Arizona.EDU>
Date: Tue, 23 May 2000 08:59:11 -0500
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <Icon-group@optima.CS.Arizona.EDU>
Subject: Hardware for HLLs
Content-Disposition: inline
X-Guinevere: 1.0.13 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id HAA09150
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>> Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> 00-05-23 4:19:45 AM >>> >http://www.sun.com/970722/cover/javace.html 

> and a better reference I have lost suggest Sun are on to this and
> have a java non-virtual machine.

I checked that out and it looks like you're right.  Oh, well, I guess there's nothing new under the sun.

> "Richard A. O'Keefe" <ok@atlas.otago.ac.nz> wrote:

> And the market share for hardware that doesn't support good virus hosts is fairly limited.

2 + 2 = ... Awright!  Hardware virus acceleration!  We're gonna get RICH!!!

Charles Hethcoat

P. S.  I can't help but notice that we got way off the topic of the original post, so I changed it...



From icon-group-sender  Tue May 23 16:34:23 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA27759
	for icon-group-addresses; Tue, 23 May 2000 16:33:28 -0700 (MST)
Message-Id: <200005232333.QAA27759@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 23 May 2000 14:53:24 -0500
Subject: Hardware for HLLs
To: Icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>> ...and a better reference I have lost suggest Sun are on to this and
> have a java non-virtual machine.

> I checked that out and it looks like you're right.  Oh, well, I guess there's 
nothing new under the sun.

>> "Richard A. O'Keefe" <ok@atlas.otago.ac.nz> wrote:

>> And the market share for hardware that doesn't support good virus hosts is 
fairly limited.

> 2 + 2 = ... Awright!  Hardware virus acceleration!  We're gonna get RICH!!!

Some years ago a company called Proximity Technology developed a marvelous LSI 
chip to do proximity ranking of a series of [near-]matches.  The idea was 
wonderful, although within just a few years the software version was faster when 
running on widely available standard PCs.

The reasons you don't see more of these specialized HLL processors are simple.  
The market is limited;  few people need the additional performance badly enough 
to put up with the cost and configuration hassles (need an available slot and of 
the right kind etc etc).  Given the limited money available to support the 
development, you'll probably never be able to keep up in the throughput 
technology curve with the general-purpose, mass-market processors.  Eventually 
(and probably SOON) your balls-out high-speed specialized custom processor will 
be blown away by a simple interpreter running on cheap generic iron.

If you go back about 7-8 years there was a lot of press about how Sun's 
revolutionary SPARC RISC processor was going to put the Intel-family CISC 
processors out of business, and redefine the PC.  It hasn't really happened that 
way, has it?

The HP9000 at one of my consulting customers (a $50K+ box) uses their 
fancy-schmancy HP/PA microprocessor.  (You will remember that the whole raison 
d'etre of RISC was that by designing a brain-damaged processor with a crippled 
primitive instruction set, they could turn the crank faster...)  Anyhow, the 
HP/PA "we can turn the crank faster" microprocessors runs at... wait for it... 
100MHz.  (!!)

Anyhow, after designing a specialized, custom-built processor (which only works 
for SOME of the workload you have, and probably isn't even DRAMATICALLY faster 
for that segment) you then have to figure out how to find the money to keep 
REdesigning it to compete with the constantly raised bar coming from companies 
like AMD and Intel (which probably have a LOT more money to play the high-stakes 
game than you do).

So anyhow it's scarcely surprising that there aren't a lot of such specialized 
HLL-based processors out there.  If anybody was going to do it for JAVA, it 
would probably be Sun... and even there, they haven't exactly been hugely 
successful selling even their SPARC chips.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Thu May 25 12:39:54 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA03284
	for icon-group-addresses; Thu, 25 May 2000 12:38:32 -0700 (MST)
Message-Id: <200005251938.MAA03284@baskerville.CS.Arizona.EDU>
Date: Thu, 25 May 2000 11:15:45 -0500
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <Icon-group@optima.CS.Arizona.EDU>
Subject: Re: Hardware for HLLs
Content-Disposition: inline
X-Guinevere: 1.0.13 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id JAA27165
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>> <gep2@terabites.com> 00-05-23 2:53:24 PM >>> writes:
> The market is limited;  few people need the additional performance badly enough 
> to put up with the cost and configuration hassles

Video cards, sound cards, DSP chipsets, ... .  Some do find it useful to speed up software by means of custom hardware, and are willing to pay for it.  Of course, that by itself is no guarantee of financial success for companies supplying such hardware.  As for configuration hassles, well, a cynic would say that's what generic PCs are all about.

> Given the limited money available to support the development, you'll probably never 
> be able to keep up in the throughput technology curve with the general-purpose, 
> mass-market processors.

Money is always limited, which is precisely why people must always ask what is the correct way to do things.  I would frame the following general question:  Where, disregarding historical accidents and existing market factors, is the line properly drawn between hardware and software?

> Eventually (and probably SOON) your balls-out high-speed 
> specialized custom processor will be blown away by a simple interpreter running on 
> cheap generic iron.

True, if it is not on the Intel learning curve.  I'm sure a present day "Winvideo" display running off one of today's Intel CPUs would outrun the best video card on the market of 5 years ago.  But speed isn't my main issue (read on).

> If you go back about 7-8 years there was a lot of press about how Sun's revolutionary 
> SPARC RISC processor was going to put the Intel-family CISC processors out of 
> business, and redefine the PC.  It hasn't really happened that way, has it?

I won't comment on the RISC/CISC wars---not smart enough---but I think your point is that the chip fab technology is capital-intensive, that Intel has the most capital, and therefore nobody but Intel could succeed at it today.  I somewhat forlornly agree (and would hope to be shown wrong).  This is the money issue again. 

It's understandable why Intel chose the 4004/8008 CPU model over something like the Burroughs B5500/B6700 model in the year 197X---it wasn't possible to put a mainframe CPU on a controller chip then.  Today, it is.  But Intel's subsequent market success has, as you rightly point out, foreclosed all questions similar to these we are dealing with in this discussion for two decades.

> (You will remember that the whole raison d'etre of RISC was that by designing a brain-
> damaged processor with a crippled primitive instruction set, they could turn the crank 
> faster...)  

To me, it's not so much seeing who's faster as simplifying life by replacing multiple software layers with silicon hardware designs informed by enduring software principles, i. e. HLL hardware.  Once it's in silicon, it will be on the same chip-fab curve that the current Intel processors are on (especially if Intel did our hypothetical HLL chip and could make it a market success).

I do share your scepticism about the RISC concept.  I was never really convinced that the RISC designs I used to see in Byte magazine articles would be intrinsically better for general purpose computing than, say, the Shannon-encoded stack machine that Tanenbaum (I believe it was) designed, _if_ both were designed as rippin' fast hardware.



From icon-group-sender  Thu May 25 16:36:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA12383
	for icon-group-addresses; Thu, 25 May 2000 16:34:42 -0700 (MST)
Message-Id: <200005252334.QAA12383@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Thu, 25 May 2000 17:07:40 -0500
Subject: Re: Hardware for HLLs;  side helping of computer history
To: Icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>>> <gep2@terabites.com> 00-05-23 2:53:24 PM >>> writes:
> The market is limited;  few people need the additional performance badly 
enough to put up with the cost and configuration hassles

> Video cards, sound cards, DSP chipsets, ... .  Some do find it useful to speed 
up software by means of custom hardware, and are willing to pay for it.  

True enough, for THOSE applications (where, in fact, you pretty much need the 
hardware anyhow whether it has its own CPU capability or not).  In the case of 
Java, it's harder to justify *every* user paying for a hardware solution when 
the *easier* and better solution is simple... just say NO to Java, and write the 
software in a language that's inherently that much more efficient (or more) to 
begin with.  :-)

> Of course, that by itself is no guarantee of financial success for companies 
supplying such hardware.  

Absolutely.  I think it's a safe guess that the company developing such a 
specialized Java hardware processor would fail (and probably after investing a 
LOT of money in development).  Even Sun, which apparently HAS such a processor 
developed, isn't exactly racing to market with it.

> As for configuration hassles, well, a cynic would say that's what generic PCs 
are all about.

I'm not THAT cynical.  It's more an issue of "what kind of slot would you plug 
the board into?" and "do you HAVE a spare slot of that type?" etc etc.  And of 
course, these "legacy-free PCs" and other sealed-box "PCs" that some dumb 
companies keep trying to promote would simply not allow adding such a board, 
anyhow.

>> Given the limited money available to support the development, you'll probably 
never be able to keep up in the throughput technology curve with the 
general-purpose, mass-market processors.

> Money is always limited, which is precisely why people must always ask what is 
the correct way to do things.  I would frame the following general question:  
Where, disregarding historical accidents and existing market factors, is the 
line properly drawn between hardware and software?

Well, I'd give an example which I think clearly errs in terms of putting too 
much in software:  these stupid "Winmodems" where they replace a $2.00 dedicated 
processor on the modem card with 30-50% of a $200 processor...

>> Eventually (and probably SOON) your balls-out high-speed 
> specialized custom processor will be blown away by a simple interpreter 
running on cheap generic iron.

> True, if it is not on the Intel learning curve.  

Or tha AMD learning curve, or the Cyrix learning curve, or the IBM learning 
curve, or one of the other such curves.  And it's not even an issue of 
"learning", it's an issue of how much money you have to keep developing more and 
more complex and sophisticated versions to keep up.  If the market for a Java 
processor is limited to begin with, I think there's not going to be enough money 
there to stay competitive (if there is even enough money to get a competitive 
product to market to begin with).

>> If you go back about 7-8 years there was a lot of press about how Sun's 
revolutionary 
> SPARC RISC processor was going to put the Intel-family CISC processors out of 
> business, and redefine the PC.  It hasn't really happened that way, has it?

> I won't comment on the RISC/CISC wars---not smart enough---but I think your 
point is that the chip fab technology is capital-intensive, that Intel has the 
most capital, and therefore nobody but Intel could succeed at it today.  

Certainly there is an *enormous* installed base of software and hardware, which 
is not going to disappear overnight.  Like in the case of the mainframe wars of 
the 60's and 70's, even companies like Amdahl and Memorex developing 
"compatible" mainframes wasn't enough to dislodge IBM... it took a major change 
of paradigm (the PC combined with the LAN that allowed clustering a nearly 
arbitrarily large bunch of them around one or more shared databases) that simply 
made the old-style mainframe largely irrelevant... to pretty much consign those 
monsters to history.

I think that Intel (who _ought_ to understand that lesson well) is making a 
*major* strategic mistake in the incompatible architecture of their 
next-generation processors... one which is likely to leave AMD with a much 
larger piece of the pie than they presently have.

> I somewhat forlornly agree (and would hope to be shown wrong).  This is the 
money issue again. 

I think you'll see a lot of advance by AMD into Intel's current territory.  This 
will be the biggest goof by Intel since their braindead CPU-serial-number thing 
they built into the Pentium III.

> It's understandable why Intel chose the 4004/8008 CPU model over something 
like the Burroughs B5500/B6700 model in the year 197X---it wasn't possible to 
put a mainframe CPU on a controller chip then.  

There's actually an interesting story there.  Turns out that Intel designed the 
4004, but a company called Computer Terminal Corporation in San Antonio (later 
Datapoint Corporation) developed the architecture and instruction set for the 
8008... Intel was one of several companies which was approached to build it for 
them, and in fact both TI and Intel made (sorta) working prototypes.  Intel did 
it very reluctantly, because they were convinced that there WAS no market for a 
general-purpose microcomputer-on-a-chip.  The only reason they agreed to build 
the part at all was because Intel back then considered themselves a MEMORY 
company, and Computer Terminal Corporation was at the time the world's largest 
buyer of MOS memory.  So Intel was hoping to cement the loyalty (and memory 
business) of Datapoint by building this "foolish" CPU chip for them.  As it 
turned out, the TI chip was electrically noisy enough that it barely worked at 
all, and by the time Intel's was finally ready Datapoint had already advanced 
enough on their own temporary design that the LSI part wasn't really all that 
attractive.  Datapoint signed away to Intel the rights to the design basically 
in exchange for being relieved of the obligation to buy it from them, and Intel 
(which had meanwhile leaked rumors about the 8008 project to other customers, 
and found that there indeed MIGHT be a market for a microcomputer-on-a-chip 
after all) went ahead to sell it for their own account. The rest, as they say, 
is history.  :-)

Datapoint, of course, is also the company that in 1976 developed the first 
commercially successful local area network (hardware and software delivered to 
first customer in Sept 1977 and announced in Dec 1977) and together with the 
cheap/powerful single-chip microprocessor that Datapoint also had invented, 
these two products (and their successors) later merged to create the world of 
computing that we have today.

>> (You will remember that the whole raison d'etre of RISC was that by designing 
a brain-damaged processor with a crippled primitive instruction set, they could 
turn the crank faster...)  

> To me, it's not so much seeing who's faster as simplifying life by replacing 
multiple software layers with silicon hardware designs informed by enduring 
software principles, i. e. HLL hardware.  

I think it's basically a strategic error to presume that "the solution" is to 
try to make one single processor go infinitely fast.  I think a much better 
solution (and this is part of what Datapoint's (and my as primary developer of 
the software for it) LAN concept was about) is to try to eliminate the 
horsepower race BY DESIGN.  To produce simple, to-be-cheap modules and to 
arrange things to maximize the potential fanout... so you can easily cluster as 
much processing horsepower units around a given database as its load requires 
(regardless of how many individual processors that means).

Meanwhile, I think it's much easier (and faster and cheaper to develop) to 
manage complexity in software than in hardware.

> Once it's in silicon, it will be on the same chip-fab curve that the current 
Intel processors are on (especially if Intel did our hypothetical HLL chip and 
could make it a market success).

It's not just fab technology, though.  If it was, we'd still be making 
hugely-fast 8008's.  To get the speed up, they've developed *hugely* more 
complicated and expensive processor designs, at enormous cost (although clearly 
the market has repaid that investment many times over).

> I do share your scepticism about the RISC concept.  I was never really 
convinced that the RISC designs I used to see in Byte magazine articles would be 
intrinsically better for general purpose computing than, say, the 
Shannon-encoded stack machine that Tanenbaum (I believe it was) designed, _if_ 
both were designed as rippin' fast hardware.

Absolutely.  If you want performance, it seems pretty obvious to ME that putting 
the subroutine or macro to execute a complex series of microinstructions RIGHT 
ON THE DIE makes a lot more sense than to force the processor to fetch the 
(maybe dozens of) RISC instructions from main memory to accomplish the same 
thing.

And I think that a good part of what eventually put Byte Magazine out of the 
business was their having made SO MANY bad calls through the 80's and early 
90's.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Fri May 26 08:34:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02191
	for icon-group-addresses; Fri, 26 May 2000 08:33:22 -0700 (MST)
Message-Id: <200005261533.IAA02191@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: CODE() and  @/2
X-Newsreader: Forte Agent 1.7/32.534
Date: Fri, 26 May 2000 09:38:12 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: flipper 959333892 212.187.67.243 (Fri, 26 May 2000 11:38:12 MET DST)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


Although ICON has PROC() and VARIABLE(), there doesn't seem  to be
a built-in to translate & execute string data as a (more substantial) piece
of code in runtime, hence SNOBOL's CODE().
Is this because of certain implementation features ?

Can  somebody please explain the infix @ operator  ?
The closest I can get  is something like:  @'s first argument gets  pushed
onto its second argument's  stack  before the latter is activated  (and  
at  this  point my  mind goes  blank...  OK,  so  the  infix is just  a prefix
@ with &NULL as the first argument, which doesn't help me a lot either).
Its purpose is apparently  to have co-expressions communicate between
themselves (thus enabling  them to gang up against the programmer  ?)

Does ICON  provide for local auxiliary variables  other than  within  the
body  of a  named procedure  ?

Thanks  a bunch,
Bob.



From icon-group-sender  Fri May 26 08:35:41 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02292
	for icon-group-addresses; Fri, 26 May 2000 08:35:31 -0700 (MST)
Message-Id: <200005261535.IAA02292@baskerville.CS.Arizona.EDU>
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: CODE() and  @/2
Date: Fri, 26 May 2000 07:54:20 -0700
X-Trace: noao.edu 959352862 96002 140.252.38.6 (26 May 2000 14:54:22 GMT)
X-Complaints-To: abuse@noao.edu
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" wrote:
> 
...
> Can  somebody please explain the infix @ operator  ?
> The closest I can get  is something like:  @'s first argument gets  pushed
> onto its second argument's  stack  before the latter is activated  (and
> at  this  point my  mind goes  blank...  OK,  so  the  infix is just  a prefix
> @ with &NULL as the first argument, which doesn't help me a lot either).
> Its purpose is apparently  to have co-expressions communicate between
> themselves (thus enabling  them to gang up against the programmer  ?)

Think of co-expressions a threads that don't execute simultaneously.
Instead, co-expressions cooperate by explicitly passing control between
them using the @ operator as a "transfer point".  Logically, the CPU resource
is being passed among the co-expressions (remember that Icon's execution
starts in a co-expression, referenced by &main).

Now, think of the @ operator from the point of view of the co-expression
that is invoking it - the behavior of the @ is very much like that
co-expression making a function call - execution of the co-expression
(call it "A") is suspended until execution "returns" from the @ - perhaps by
some
other co-expression (call it "B") invoking the first via an @ [think about
that for a moment, it's probably the confusing part!].  If B uses the
infix @ - as in (say) "foo" @ A, then A will see its @ operator as "returning"
the value "foo".

So, each co-expression sees @ as an operator that "invokes" another
co-expression
to produce a result.  The result can be produced in one of two ways:

(1) Since a co-expression is an expression, and since all expressions in Icon
    produce results, there is an implicit transfer of the result of that
    expression back to the invoking co-expression.  This is how most people
    use co-expressions, as in:

       nextLabel := create "L" || seq()

    to produce a unique label whenever activated.  (Note that this can also
    be done using a procedure, as in:

       procedure newLabel()
          static suffix
          initial suffix := 0
          return "L" || (suffix +:= 1)
       end

    but some people find the co-expression form simpler.  Also note that

       procedure newLabel2()
          return "L" || seq()
       end

    and

       procedure newLabel3()
          suspend "L" || seq()
       end

    do *not* perform the same function.)
          

(2) A co-expression may explicitly return a value to a waiting co-expression
    using the binary @ operator.  The explicit transfer of control used here
    more closely matches the role of coroutines found in some other languages,
    and is likely to be used only in situations where coroutines would be used
    in those other languages.  However, useful situations for applying
coroutines
    are few and far between and almost always very complex situations.  It is
    difficult to find simple examples where using coroutines is cleaner than
    alternatives.

  

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon May 29 08:47:25 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA28734
	for icon-group-addresses; Mon, 29 May 2000 08:45:42 -0700 (MST)
Message-Id: <200005291545.IAA28734@baskerville.CS.Arizona.EDU>
X-Priority: 3 (Normal)
Date: Mon, 29 May 2000 14:27:56 +0200 (CEST)
From: Guido Milanese <gmilanese@mclink.it>
To: icon-group@optima.CS.Arizona.EDU
Subject: Lists: sort on more than one field?
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I am currently working on a small databaseof library data. Data
is the output of a database program and is in comma-delimited
format, therefore easily accesible as lists or records. I would
like to sort data not only by one field (I use sortf for that)
but one more than one field: i.e. sort on field_1 and osrt all
data with the same value for field_1 by field_4, for example. Is
it possible? I did not find anything in the Icon library for
that. May I ask for advice?

Thank you all!
gm


-------------------------------------------w
E-Mail: Guido Milanese <gmilanese@mclink.it>
Homepage: http://fly.to/arsantiqua
29-May-00 - XFMail on Linux SuSE
*************NON NOBIS DOMINE*************
-------------------------------------------


From icon-group-sender  Mon May 29 11:57:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA02046
	for icon-group-addresses; Mon, 29 May 2000 11:57:10 -0700 (MST)
Message-Id: <200005291857.LAA02046@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Mon, 29 May 2000 11:39:43 -0500
Subject: Lists: sort on more than one field?
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> I am currently working on a small databaseof library data. Data
is the output of a database program and is in comma-delimited
format, therefore easily accesible as lists or records. I would
like to sort data not only by one field (I use sortf for that)
but one more than one field: i.e. sort on field_1 and osrt all
data with the same value for field_1 by field_4, for example. Is
it possible? I did not find anything in the Icon library for
that. May I ask for advice?

The answer is so simple as to be trivial.... simply build an additional (single) 
field (perhaps temporarily) which contains all the fields you wish to sort on, 
in the order of precedence (most important first).  :-)

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Tue May 30 07:38:07 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA23286
	for icon-group-addresses; Tue, 30 May 2000 07:37:36 -0700 (MST)
Message-Id: <200005301437.HAA23286@baskerville.CS.Arizona.EDU>
Date: Tue, 30 May 2000 20:17:59 +1000
From: Rohan McLeod <rohan@micom.asn.au>
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Subject: silly question about iconc
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

This will no doubt demonstrate my beginners status but here is my problem:
there is mention of an Icon compiler;  iconc

eg "Icon Programming Language Handbook" p141
"On some systems an Icon compiler is available."

Now in a previous query I gathered that this still produces C ,
which has then to be put through a C compiler...I guess I can live
with that;but what systems is an Icon compiler available for and
where (URL?) can I find binaries ?
I have looked all over http://www.cs.arizona.edu/icon/ without avail!



From icon-group-sender  Tue May 30 12:07:40 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA19353
	for icon-group-addresses; Tue, 30 May 2000 12:06:08 -0700 (MST)
Message-Id: <200005301906.MAA19353@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: CODE() and  @/2
X-Newsreader: Forte Agent 1.7/32.534
Date: Tue, 30 May 2000 18:55:33 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: flipper 959712933 212.187.67.243 (Tue, 30 May 2000 20:55:33 MET DST)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 26 May 2000 11:38:34 -0400, Steve Wampler <swampler@noao.edu> wrote:

>"F.G. van DORP" wrote:
>> 
>...
>> Can  somebody please explain the infix @ operator  ?
>> The closest I can get  is something like:  @'s first argument gets  pushed
>> onto its second argument's  stack  before the latter is activated....
>>...
>
>So, each co-expression sees @ as an operator that "invokes" another
>co-expression
>to produce a result.  The result can be produced in one of two ways:
>
>(1) Since a co-expression is an expression, and since all expressions in Icon
>    produce results, there is an implicit transfer of the result of that
>    expression back to the invoking co-expression.  This is how most people
>    use co-expressions, as in:
>
>       nextLabel := create "L" || seq()
>
Thanks for replying.
I tried

       nextLabel := create "L" || (1 to 10) || ("foo" @ &source)
       write(@nextlabel)
        ....

and to my very surprise it did act as a regular RETURN (no
ASSEMBLER jargon necessary after all), writing

      L1foo
      ....

Unfortunately results are quite unpredictable: either some aren't
written at all, or Win32 preempts further execution with an "illegal
 operation" error.
>  



From icon-group-sender  Tue May 30 17:06:44 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28345
	for icon-group-addresses; Tue, 30 May 2000 17:06:32 -0700 (MST)
Message-Id: <200005310006.RAA28345@baskerville.CS.Arizona.EDU>
Date: Tue, 30 May 2000 13:40:37 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: CODE() and  @/2
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" wrote:

> I tried
> 
>        nextLabel := create "L" || (1 to 10) || ("foo" @ &source)

What did you intend the above to do?  I'm confused as to why you
have the ("foo" @ &source) there.  If all you want are labels Lxfoo,
where x is replaced by 1 to 10, you should use

        nextLabel := create "L" || (1 to 10) || "foo"

>        write(@nextlabel)

This must have been write(@nextLabel), right?

>         ....
> 
> and to my very surprise it did act as a regular RETURN (no
> ASSEMBLER jargon necessary after all), writing
> 
>       L1foo
>       ....

I don't see how the co-expression you've given would produce the above,
are you sure that isn't the output from some other try?

In fact, I would expect to see "foo" printed by itself first, followed
by a "string expected, offending value: &null" error if you activate
nextLabel a second time without passing a value to it...

Try the following sample program:

    procedure main()
        nextLabel := create "L" || (1 to 10) || "foo"

        write("Label 1 is ", @nextLabel)
        write("Label 2 is ", @nextLabel)
        write("Label 3 is ", @nextLabel)
        write("Label 4 is ", @nextLabel)
        write("Label 5 is ", @nextLabel)

        every write("Label ",6 to 10," is ",@nextLabel)
    end

You should see the output:

    Label 1 is L1foo
    Label 2 is L2foo
    Label 3 is L3foo
    Label 4 is L4foo
    Label 5 is L5foo
    Label 6 is L6foo
    Label 7 is L7foo
    Label 8 is L8foo
    Label 9 is L9foo
    Label 10 is L10foo






--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Tue May 30 17:07:50 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28385
	for icon-group-addresses; Tue, 30 May 2000 17:07:41 -0700 (MST)
Message-Id: <200005310007.RAA28385@baskerville.CS.Arizona.EDU>
From: Bob Ardler <ardler@argonet.co.uk>
To: Icon-group <icon-group@optima.CS.Arizona.EDU>
Date: Tue, 30 May 2000 21:42:49 +0100
Subject: coexpression history
User-Agent: Pluto/2.02b (RISC-OS/3.60)
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Did the word 'coexpression' or the associated idea originate with icon?
Or is it a high school computer science thing?

-- 

Bob Ardler,  ardler@argonet.co.uk



From icon-group-sender  Tue May 30 17:08:16 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28470
	for icon-group-addresses; Tue, 30 May 2000 17:08:06 -0700 (MST)
Message-Id: <200005310008.RAA28470@baskerville.CS.Arizona.EDU>
Date: Tue, 30 May 2000 15:43:45 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: icon-group@optima.CS.Arizona.EDU, rohan@micom.asn.au
Subject: Re: silly question about iconc
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    what systems is an Icon compiler available for and
    where (URL?) can I find binaries ?

Because of limited resources, we no longer support the compiler or produce
binaries for it.  Most people found that using the compiler wasn't worth
the extra compliation time or the hassles involved.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Wed May 31 08:37:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17431
	for icon-group-addresses; Wed, 31 May 2000 08:37:07 -0700 (MST)
Message-Id: <200005311537.IAA17431@baskerville.CS.Arizona.EDU>
From: "Jim Mehl" <mehl@ihot.com>
To: "icon-group" <icon-group@optima.CS.Arizona.EDU>
Subject: Re: coexpression history
Date: Tue, 30 May 2000 19:45:05 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I don't think so. I have this vague remembrance that 
coexpression/coroutine was actually proposed many years
ago in the context of a COBOL compiler of all things.
Maybe someone with a better sense of computer science
history can help me out here.
 
Jim Mehl

> Did the word 'coexpression' or the associated idea originate with icon?
> Or is it a high school computer science thing?




From icon-group-sender  Wed May 31 08:38:06 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17464
	for icon-group-addresses; Wed, 31 May 2000 08:37:55 -0700 (MST)
Message-Id: <200005311537.IAA17464@baskerville.CS.Arizona.EDU>
From: "Jim Mehl" <mehl@ihot.com>
To: "icon-group" <icon-group@optima.CS.Arizona.EDU>
Subject: Re: coexpression history
Date: Tue, 30 May 2000 20:15:00 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

OK, I think I found it. The reference is M. E. Conway, "Design of a 
separable transition-diagram compiler", CACM, Vol. 6, No. 7,
July 1963, pp 396-408. If I'm wrong, I'm sure there are enough 
scholars on this list to tell me so.

Jim Mehl

 > Did the word 'coexpression' or the associated idea originate with icon?
> Or is it a high school computer science thing?




From icon-group-sender  Wed May 31 08:38:42 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17496
	for icon-group-addresses; Wed, 31 May 2000 08:38:33 -0700 (MST)
Message-Id: <200005311538.IAA17496@baskerville.CS.Arizona.EDU>
Date: Wed, 31 May 2000 06:49:35 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: coexpression history
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Bob Ardler wrote:
> 
> Did the word 'coexpression' or the associated idea originate with icon?
> Or is it a high school computer science thing?

The word originated with Icon.  The associated idea grew out of talks
between Ralph and me but has roots in several places, with the two
most prominent ones being the general concept of coroutines (several
languages) and a feature found in the pattern matching language that
is embedded in SNOBOL4.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Wed May 31 12:45:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA25222
	for icon-group-addresses; Wed, 31 May 2000 12:43:57 -0700 (MST)
Message-Id: <200005311943.MAA25222@baskerville.CS.Arizona.EDU>
Date: Wed, 31 May 2000 08:47:44 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: coexpression history
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Jim Mehl wrote:
> 
> OK, I think I found it. The reference is M. E. Conway, "Design of a
> separable transition-diagram compiler", CACM, Vol. 6, No. 7,
> July 1963, pp 396-408. If I'm wrong, I'm sure there are enough
> scholars on this list to tell me so.
> 
> Jim Mehl
> 
>  > Did the word 'coexpression' or the associated idea originate with icon?
> > Or is it a high school computer science thing?

Yes, that's the original reference (as far as I can remember) for the
coroutine side of co-expressions.  Coroutines were then implemented in
a number of languages.  The one that comes to mind as having the most
influence here is Simula.  Note that coroutines were/are considerably
more heavyweight than coexpressions as they have always been implemented
as full procedures, not just single expressions.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Thu Jun  1 13:40:20 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA08649
	for icon-group-addresses; Thu, 1 Jun 2000 13:38:26 -0700 (MST)
Message-Id: <200006012038.NAA08649@baskerville.CS.Arizona.EDU>
From: Bob Ardler <ardler@argonet.co.uk>
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Date: Thu, 01 Jun 2000 17:36:39 +0100
Subject: Re: coexpression history
User-Agent: Pluto/2.02b (RISC-OS/3.60)
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Steve Wampler wrote:
> Jim Mehl wrote:
> > OK, I think I found it. The reference is M. E. Conway, "Design of a
> > separable transition-diagram compiler", CACM, Vol. 6, No. 7, July
> > 1963, pp 396-408. If I'm wrong, I'm sure there are enough scholars on
> > this list to tell me so.

> Yes, that's the original reference (as far as I can remember) for the
> coroutine side of co-expressions. Coroutines were then implemented in a
> number of languages. The one that comes to mind as having the most
> influence here is Simula. Note that coroutines were/are considerably
> more heavyweight than coexpressions as they have always been
> implemented as full procedures, not just single expressions.
Ah, coroutines, so that's where to look. Knuth I elaborates the history a
bit on p.226, starting with Conway, mentioning earlier ('primitive') &
later stuff. He also explains coroutines thoroughly, to those who speak
MIX. Thanks to you both.

-- 

Bob Ardler,  ardler@argonet.co.uk



From icon-group-sender  Thu Jun  1 13:46:33 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA08842
	for icon-group-addresses; Thu, 1 Jun 2000 13:46:26 -0700 (MST)
Message-Id: <200006012046.NAA08842@baskerville.CS.Arizona.EDU>
From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
X-Newsgroups: comp.lang.icon
Subject: Re: CODE() and  @/2
X-Newsreader: Forte Agent 1.7/32.534
Date: Thu, 01 Jun 2000 18:56:01 GMT
X-Complaints-To: abuse@chello.nl
X-Trace: flipper 959885761 212.187.67.243 (Thu, 01 Jun 2000 20:56:01 MET DST)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

On 30 May 2000 20:09:35 -0400, Steve Wampler <swampler@noao.edu> wrote:

>"F.G. van DORP" wrote:
>
>> I tried
>> 
>>        nextLabel := create "L" || (1 to 10) || ("foo" @ &source)
>
>What did you intend the above to do? 
....to find out if binary @ behaves like a regular RETURN

>
>        nextLabel := create "L" || (1 to 10) || "foo"
>
>>        write(@nextlabel)
>
>This must have been write(@nextLabel), right?
Yes. I can't copy&paste because ICON is on another machine, which
in fact is entirely "dedicated" to ICON because of all those illegal
co-ex operations   ...just kidding.

Under my ICON (Windows Icon  v.9.3.1, Wi  v.1.01)  above example
prints "L1foo" immediately followed by an illegal op. error.
I f  you change it to, let's say
             procedure main
             nextLabel := create (("L" || (1 to 10) || "foo") @ &source)
             write("1 ",@nextLabel)
             write("2 ",@nextLabel)
             write("3 ",@nextLabel)
             write("4 ",@nextLabel)
             write("5 ",@nextLabel)
             end
it prints

             "1 L1foo"
             "2"
             "3 L2foo"
             "4"
              illegal op error

This behavior doesn't change if you replace ("L" || (1 to 10) || "foo") 
with any other generator, nor  &source with  &main in this particular example.



From icon-group-sender  Thu Jun  1 16:56:55 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA15837
	for icon-group-addresses; Thu, 1 Jun 2000 16:56:35 -0700 (MST)
Message-Id: <200006012356.QAA15837@baskerville.CS.Arizona.EDU>
Date: Thu, 01 Jun 2000 14:10:08 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>
Subject: Re: CODE() and  @/2
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"F.G. van DORP" wrote:
> 
> On 30 May 2000 20:09:35 -0400, Steve Wampler <swampler@noao.edu> wrote:
> 
> >"F.G. van DORP" wrote:
> >
> >> I tried
> >>
> >>        nextLabel := create "L" || (1 to 10) || ("foo" @ &source)
> >
> >What did you intend the above to do?
> ....to find out if binary @ behaves like a regular RETURN

Ah, it "sortof" does, but when you reactivate the co-expression, you're
going to resume execution as if you've returned from "foo" @ &source
(with the &null value since the activation "@nextLabel" is unary.)
This &null value can't be concatentated to the string you're
building.

> 
> >
> >        nextLabel := create "L" || (1 to 10) || "foo"
> >
...
> 
> Under my ICON (Windows Icon  v.9.3.1, Wi  v.1.01)  above example
> prints "L1foo" immediately followed by an illegal op. error.

Hmmm, can you email me the full program where this is happening?
I'd like to take a closer look...

> I f  you change it to, let's say
>              procedure main
>              nextLabel := create (("L" || (1 to 10) || "foo") @ &source)
>              write("1 ",@nextLabel)
>              write("2 ",@nextLabel)
>              write("3 ",@nextLabel)
>              write("4 ",@nextLabel)
>              write("5 ",@nextLabel)
>              end
> it prints
> 
>              "1 L1foo"
>              "2"
>              "3 L2foo"
>              "4"
>               illegal op error
> 
> This behavior doesn't change if you replace ("L" || (1 to 10) || "foo")
> with any other generator, nor  &source with  &main in this particular example.

Well, that's nearly correct (except for the illegal op error at the end...):

I get:

1 L1foo
2 
3 L2foo
4 
5 L3foo

You shouldn't have the @source there, it's not doing what you want, because
you're "returning" into the co-expression...

However, it does look like there is a bug in 9.3.1 for Windows.  Please
email me the exact program (I can tell you had to type the above one
in by hand...)!

I don't see this problem under either 9.3 or 9.3.2 with either Linux
or Solaris.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Thu Jun  1 16:58:42 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA15892
	for icon-group-addresses; Thu, 1 Jun 2000 16:58:34 -0700 (MST)
Message-Id: <200006012358.QAA15892@baskerville.CS.Arizona.EDU>
Date: Thu, 1 Jun 2000 16:15:16 -0700 (MST)
From: Gregg Townsend <gmt>
To: icon-group
Subject: Icon Newsletter #60 published
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

The sixtieth Icon Newsletter is now available on the web at:
	http://www.cs.arizona.edu/icon/inl/inl60/inl60.htm

This is the final edition of the newsletter.  In the future, we plan
to utilize other avenues of communication, including the Icon Analyst,
our website, and this mailing list.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA


From icon-group-sender  Fri Jun  2 07:56:46 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02816
	for icon-group-addresses; Fri, 2 Jun 2000 07:56:12 -0700 (MST)
Message-Id: <200006021456.HAA02816@baskerville.CS.Arizona.EDU>
From: "Bernard Diaz (Diz)" <B.M.Diaz@csc.liv.ac.uk>
Subject: Co-expression history ...
To: icon-group@optima.CS.Arizona.EDU
Date: Fri, 2 Jun 2000 10:39:53 +0100 (BST)
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hi,

I believe Conway's paper is also used as introduction in describing 
Java threads ... is there more similarity than the "separate processing"
which treads and co-routines imply ?

Regards - Diz

+===========================================+==================================+
| e-mail: b.m.diaz@csc.liv.ac.uk            |  Dr Bernard M. Diaz              |
|                                           |  Department of Computer Science  |
| Tel: 0151 794 3696 (direct office line)   |  The University of Liverpool     |
|      0151 794 6923 (Departmental office   |  Chadwick Building, Peach Street |
| Fax:  +44 151 794 3715 (International no) |  Liverpool, ENGLAND.             |
| Tlx: 627095 UniLpl G                      |  L69 7ZF                         |
+===========================================+==================================+



From icon-group-sender  Fri Jun  2 14:07:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA13288
	for icon-group-addresses; Fri, 2 Jun 2000 14:04:31 -0700 (MST)
Message-Id: <200006022104.OAA13288@baskerville.CS.Arizona.EDU>
Date: Fri, 02 Jun 2000 10:56:45 -0500
From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Coexpressions, etc.
Content-Disposition: inline
X-Guinevere: 1.0.13 ; Oceaneering Int'l
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id IAA04192
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Couldn't some of the more esoteric aspects of Icon (suspend/resume, coexpressions) be expressed as the state changes of an SECD machine, or an extension to it, or something similar?  For an example of what I mean, consult (for example) Burge's book on functional programming, especially the discussions of extensions to the lambda calculus to handle a  variety of messy real-life programming constructs in Algol-like languages.

Charles Hethcoat
Senior Engineer
Oceaneering Space Systems
Houston, Texas USA



From icon-group-sender  Fri Jun  2 14:09:57 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA13423
	for icon-group-addresses; Fri, 2 Jun 2000 14:08:16 -0700 (MST)
Message-Id: <200006022108.OAA13423@baskerville.CS.Arizona.EDU>
From: "Charles Evans" <Charles_Evans@zxmail.com>
X-Newsgroups: comp.lang.icon
Subject: Re: silly question about iconc
Date: Fri, 2 Jun 2000 17:46:20 -0400
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Trace: 2 Jun 2000 16:50:25 -0400, bris-c-208-27-20-254.intermediatn.net
X-Original-NNTP-Posting-Host: 206.107.125.34
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


Rohan McLeod wrote in message
<200005301437.HAA23286@baskerville.CS.Arizona.EDU>...
>there is mention of an Icon compiler;  iconc...

>"On some systems an Icon compiler is available."...
>which has then to be put through a C compiler...I guess I can live
>with that;but what systems is an Icon compiler available for and
...
What C compiler do you have?





From icon-group-sender  Mon Jun 12 08:47:19 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19743
	for icon-group-addresses; Mon, 12 Jun 2000 08:45:53 -0700 (MST)
Message-Id: <200006121545.IAA19743@baskerville.CS.Arizona.EDU>
From: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
X-Newsgroups: comp.lang.icon
Subject: User defined operators for Icon
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Tue, 6 Jun 2000 10:39:33 -0000
X-Trace: client 960302410 38.163.203.81 (Tue, 06 Jun 2000 10:40:10 EDT)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In the thread on a Unicode version of Icon, a topic came up that deserves
more investigation. Currently, an Icon programmer can create new types in
Icon using a record declaration, e.g.

    record complex( x, y )

The programmer can then write new procedures that work with the new type.
This ability to create new types is quite useful, but extending the types in
Icon is not as convenient as it could be. It is hard to integrate the new
type with the others due to the following reasons:


1.    You cannot (re)define the primitive operators, such as "*", "++", or
"<", for a record type;
2.    You cannot define implicit /explicit type conversions between a record
type and the existing types; and
3.    You cannot define the behavior of functions such as image and write
for the new record type.

Languages such as C++ and Ada permit the programmer to define the behavior
of operators and predefined functions for user defined types. Would it be
desirable to add such a capacity to Icon? If so, what would this facility
look like?







From icon-group-sender  Mon Jun 12 08:47:45 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19788
	for icon-group-addresses; Mon, 12 Jun 2000 08:47:29 -0700 (MST)
Message-Id: <200006121547.IAA19788@baskerville.CS.Arizona.EDU>
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: User defined operators for Icon
Date: Tue, 06 Jun 2000 08:36:26 -0700
X-Trace: noao.edu 960305789 18654 140.252.38.6 (6 Jun 2000 15:36:29 GMT)
X-Complaints-To: abuse@noao.edu
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"Frank J. Lhota" wrote:
> 
> Languages such as C++ and Ada permit the programmer to define the behavior
> of operators and predefined functions for user defined types. Would it be
> desirable to add such a capacity to Icon? If so, what would this facility
> look like?

Well, I have an opinion, though unicon is probably the place to pursue this,
as I don't see any major enhancements being made to Icon right now.  Perhaps
whatever works in unicon could be backed into Icon later.

There are several parts (others probably have better ways to do this):

(1) Have keywords for every function (as apposed to procedures) that
    always get you the "original" definition.  This would be useful
    now as it would allow access to the original functions even when
    procedure definitions attach new meanings to the names.  There
    may be a problem where existing keywords match existing function
    names - that would need to be resolved.

(2) Have keywords for every operand (e.g. &+, &:=, etc.) which would
    act in the same way that string invocation of operators does now,
    but always reference the original definitions for the operators.

(3) add a way to assign new definitions to operators, perhaps with
    syntax:

    operator "+"(a,b)
       ...
    end

    where the number of parameters determines which operation is
    being redefined [could even generate compile-time error if
    no such operation exists].

    So, adding complex numbers could be (well, you could do better
    than this, but it's a start):

    operator +(a,b)

       if (type(a) == "complex") & (type(b) == "complex") then {
           return complex(a.x + b.x, a.y + b.y)
           # or: return complex( &+(a.x, b.x), &+(a.y,b.y))
           }
       return &+(a,b)

    end

Or course, unicon, with its inheritance, may be able to provide
considerably more flexibility, since the above scheme only allows
one level of redefinition...

Why do I like this?:

(a) most of the mechanisms for implementing this are already in place.

(b) there are minimal syntactic changes to the language (even less if
    you go with using the reserved work "procedure" instead of adding
    the reserved work "operator").

(c) with proper implementation, there should be little, if any,
    performance penalty involved.

--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Mon Jun 12 08:48:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19816
	for icon-group-addresses; Mon, 12 Jun 2000 08:47:55 -0700 (MST)
Message-Id: <200006121547.IAA19816@baskerville.CS.Arizona.EDU>
From: espie@liafa.jussieu.fr (Marc Espie)
X-Newsgroups: comp.lang.icon
Subject: Re: User defined operators for Icon
Date: 6 Jun 2000 17:04:00 GMT
X-Trace: vishnu.jussieu.fr 960311040 3784 132.227.81.128 (6 Jun 2000 17:04:00 GMT)
X-Complaints-To: Newsmaster@jussieu.fr.
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

In article <e38%4.29$tx4.556@client>,
Frank J. Lhota <NOSPAM.Frank.Lhota@lexma.meitech.com> wrote:
>1.    You cannot (re)define the primitive operators, such as "*", "++", or
>"<", for a record type;
>2.    You cannot define implicit /explicit type conversions between a record
>type and the existing types; and
>3.    You cannot define the behavior of functions such as image and write
>for the new record type.

>Languages such as C++ and Ada permit the programmer to define the behavior
>of operators and predefined functions for user defined types. Would it be
>desirable to add such a capacity to Icon? If so, what would this facility
>look like?

idol, or an extension of idol, most certainly.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'


From icon-group-sender  Mon Jun 12 08:49:16 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19862
	for icon-group-addresses; Mon, 12 Jun 2000 08:48:49 -0700 (MST)
Message-Id: <200006121548.IAA19862@baskerville.CS.Arizona.EDU>
Date: Wed, 07 Jun 2000 13:11:59 +1000
From: rebeccal@library.lib.rmit.edu.au
X-Accept-Language: en
X-Newsgroups: comp.lang.icon
Subject: cross.icn
X-Trace: 7 Jun 2000 13:11:19 +1000, carltonrebeccal.lib.rmit.edu.au
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello
Why is the program waiting for more input ?

I tried using 2 different versions (ms-dos and ms-windows) but
everytime i run cross, the result is the same.
TIA


From icon-group-sender  Mon Jun 12 08:50:27 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19978
	for icon-group-addresses; Mon, 12 Jun 2000 08:50:11 -0700 (MST)
Message-Id: <200006121550.IAA19978@baskerville.CS.Arizona.EDU>
Date: Sat, 10 Jun 2000 11:38:46 -0500
From: Bob Hamilton <vodalee@gte.net>
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Subject: Icon; missing functions
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


--------------98F4815ED066F13756E60A9F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I downloaded and installed Icon for Windows.  Several of the functions
are missing:
e.g. trunc, ceil, floor and many others.  Are these functions in some
other FTP site?

TIA,

bob hamilton
mail@bobh.to


--------------98F4815ED066F13756E60A9F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I downloaded and installed Icon for Windows.&nbsp; Several of the functions
are missing:
<br>e.g. trunc, ceil, floor and many others.&nbsp; Are these functions
in some other FTP site?
<p>TIA,
<p>bob hamilton
<br><u>mail@bobh.to</u>
<br>&nbsp;</html>

--------------98F4815ED066F13756E60A9F--



From icon-group-sender  Tue Jun 13 07:47:06 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02504
	for icon-group-addresses; Tue, 13 Jun 2000 07:46:28 -0700 (MST)
Message-Id: <200006131446.HAA02504@baskerville.CS.Arizona.EDU>
To: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
Cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: User defined operators for Icon 
Date: Mon, 12 Jun 2000 17:30:38 -0700
From: Clinton L Jeffery <jeffery@bo.Egr.UNLV.EDU>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


The discussion of extending Icon with new types is very interesting.
I have a couple additions to the ideas people have contributed so far:

1. You can define the behavior of functions such as image() and write() for
new types, by providing procedures with those names.  It is awkward to make
this work when independently written types (say, in procedure libraries)
need to be used together; they can't both supply a definition of image(),
though you can devise passable workarounds for this.

2. You can always get at the original definitions of overloaded functions,
using the proc() function.

3. You can devise explicit type conversion functions between record types
and existing types, you just can't do implicit ones.

Object oriented programming is all about creating a strong facility for
writing user-defined types.  I can't say whether operator overloading or
implicit type conversions are appropriate or desirable for Icon, but
Unicon's object-oriented facilities (the successor and replacement for Idol)
would benefit directly from Frank's suggestions.

There are some controversial issues (read this as: "problems") involving
operator overloading and type conversions as found in C++.  I will probably
think about them carefully, and discuss them on the Unicon mailing list,
before I go and implement them for Unicon.  Besides, I have to finish
implementing packages and get the UNLV release of Unicon for UNIX and
Windows out the door, before I think about any other features. :-)

Clint, jeffery@cs.unlv.edu


From icon-group-sender  Tue Jun 13 07:48:53 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02562
	for icon-group-addresses; Tue, 13 Jun 2000 07:48:45 -0700 (MST)
Message-Id: <200006131448.HAA02562@baskerville.CS.Arizona.EDU>
Date: Tue, 13 Jun 2000 19:15:38 +1000
From: Gowri Raviganesh <e22322@rmit.edu.au>
X-Accept-Language: en
X-Newsgroups: comp.lang.icon
Subject: setting environment variables
X-Trace: 13 Jun 2000 19:10:27 +1000, lv13-17-1.bf.rmit.edu.au
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hi
How can you set an environment variable in a dos window from an icon
program ?
tia




From icon-group-sender  Tue Jun 13 10:16:17 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA06876
	for icon-group-addresses; Tue, 13 Jun 2000 10:15:19 -0700 (MST)
Message-Id: <200006131715.KAA06876@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 13 Jun 2000 10:35:29 -0500
Subject: setting environment variables
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> How can you set an environment variable in a dos window from an icon
program ?

I'm not sure that you can.  Some time back, I recall hearing that Windows was changed to crunch out unused space in the environment area when opening DOS windows (as a way to reduce memory usage... not that that's QUITE so important anymore).

I'm curious what you intend to accomplish by setting the environment variables, though.  If you open a DOS window from an Icon program, and if you COULD set the environment variable within that DOS window, you ought to understand that that environment variable would disappear anyhow when the DOS window closes (i.e. upon return to Icon) since environment variables do NOT propagate back to higher DOS windows.  You don't therefore change the environment variables that the Icon program would see, for instance.  

If you CAN set them at all (subject to the space available, which MIGHT be zero) for use in later programs running under that SAME DOS shell) you would probably need to do that using a batch file which includes a SET statement prior to the command that runs the target program.

The workaround for the "collapsed environment area" that was usually discussed back when this "feature" of Windows came out was to create in the AUTOEXEC.BAT file one or more dummy "placeholder" environment variables which could be undefined (or defined to a null string, or at least something shorter, thus releasing the space) within your Icon program's invoked DOS shell prior to adding the new environment variable.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Thu Jun 15 12:44:20 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA29861
	for icon-group-addresses; Thu, 15 Jun 2000 12:43:10 -0700 (MST)
Message-Id: <200006151943.MAA29861@baskerville.CS.Arizona.EDU>
From: Kostas Oikonomou <oikonomou@att.com>
Date: Thu, 15 Jun 2000 14:47:42 -0400 (EDT)
To: icon-group@optima.CS.Arizona.EDU
Subject: Comparisons of reals
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO


I'm trying to write Icon procedures that implement the approximate <, >, and =
relations for real numbers that are in Knuth Vol. 2, section 4.2.2, p. 218 in
the 2nd ed.

It seems to me that to write these efficiently one needs access to the floating
point representation of reals, i.e. fractional part and exponent.

Is that possible?  Even better, has anybody already written something like this?

				Kostas


From icon-group-sender  Mon Jun 19 12:22:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA10487
	for icon-group-addresses; Mon, 19 Jun 2000 12:20:34 -0700 (MST)
Message-Id: <200006191920.MAA10487@baskerville.CS.Arizona.EDU>
From: Lloyd Uhler <luhler@excel.com>
To: "'icon-group@cs.arizona.edu'" <icon-group@optima.CS.Arizona.EDU>
Subject: RE: Questions on ICON
Date: Mon, 19 Jun 2000 10:10:01 -0500
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Any fix for textbox input in VIB?

Thanks.

> -----Original Message-----
> From:	Lloyd Uhler 
> Sent:	Wednesday, April 26, 2000 8:52 AM
> To:	'icon-group@cs.arizona.edu'
> Subject:	Questions on ICON
> 
> 1) For Version 9.3.1 on WIN NT and WIN 98, textbox input does not work for
> VIB generated code as follows:
> 
> ##########################################################################
> ##
> #
> #	File:     C:\Icon9.3\vib_tst.icn
> #
> #	Subject:  Program to ...
> #
> #	Author:   
> #
> #	Date:     January 21, 1999
> #
> ##########################################################################
> ##
> #
> #
> #
> ##########################################################################
> ##
> #
> #  Requires:
> #
> ##########################################################################
> ##
> #
> #  Links: vsetup
> #
> ##########################################################################
> ##
> 
> #  This vib interface specification is a working program that responds
> #  to vidget events by printing messages.  Use a text editor to replace
> #  this skeletal program with your own code.  Retain the vib section at
> #  the end and use vib to make any changes to the interface.
> 
> link vsetup
> 
> procedure main(args)
>    local vidgets, root, paused
> 
>    (WOpen ! ui_atts()) | stop("can't open window")
>    vidgets := ui()				# set up vidgets
>    root := vidgets["root"]
> 
>    paused := 1					# flag no work to do
>    repeat {
>       # handle any events that are available, or
>       # wait for events if there is no other work to do
>       while (*Pending() > 0) | \paused do {
>          ProcessEvent(root, QuitCheck)
>          }
>       # if <paused> is set null, code can be added here
>       # to perform useful work between checks for input
>       }
> end
> 
> procedure text_input_cb1(vidget, value)
> #    write("value = ", value)
>    return
> end
> 
> #===<<vib:begin>>===	modify using vib; do not remove this marker line
> procedure ui_atts()
>    return ["size=600,378", "bg=#C0C0C0"]
> end
> 
> procedure ui(win, cbk)
> return vsetup(win, cbk,
>    [":Sizer:::0,0,600,378:",],
>    ["button1:Button:regular::270,349,32,20:OK",button_cb1],
>    ["text_input1:Text::46:95,111,367,20:Enter Your
> Name:\\=",text_input_cb1],
>    )
> end
> #===<<vib:end>>===	end of section maintained by vib
> procedure button_cb1(vidget, value)
> #
> 
> #  write("button_cb1")
> #
> # This does not work with the original viface module
> # The local one has been revised to detect Window closure
> # and do this without error. This will return to the statement
> # after GetEvents. The program can then process or do what it
> # needs with the results for the GUI data capture. Data values
> # can be inserted into global variables so they are available
> # to the rest of the program.
> #
> #  WClose( &window )
>   return
> end
> 
> 2) There seems to be no way to gather a set of file names from a specified
> directory:
>     (System & popen do not work the same as command-line version of ICON
> (Nticont, Nticonx)).
>     (F.F and pipe.001 are empty)
> 
>  link graphics, dialog, popen, xio
> 
>  procedure main()
> #
> #
> # the 45 is the width
> #
>   txt := TextDialog("Specify Directory Path:",  "Path", "C:\\temp" , 45)
> 
>   Path := dialog_value[1]
>   write("Path = ", Path)
> 
>   cmd := "Dir /b/l "
> #
> # See if F.F Generated fro BAT File
> #
>   system( "CALL C:\\ICON9.3\\WDIR.CMD" || Path )
> #
> # Try popen to get file of file names
> #
>   fin := popen( cmd || Path, "r")
>   while line := trim(read(fin)) do write(line)
> 
>   pclose(fin)
> 
>  end
> 
> REM
> REM Wdir.BAT
> REM
> REM Purpose: Directory Listing
> REM
> DIR /b/l %1 > F.F


From icon-group-sender  Fri Jun 23 07:42:26 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA10510
	for icon-group-addresses; Fri, 23 Jun 2000 07:41:12 -0700 (MST)
Message-Id: <200006231441.HAA10510@baskerville.CS.Arizona.EDU>
From: "J.R. Sampson" <jsampson@indexes.u-net.com>
To: icon-group@optima.CS.Arizona.EDU
Date: Fri, 23 Jun 2000 12:34:06 +0100
Subject: Error messages
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Hello -

I am an occasional Icon user, which means I have to look 
everything up instead of assuming I know anything.
Is there a key to, or description of, the error messages and reports 
that occur while compiling or running Icon programs?

I had an error message 114, 'Invalid type to subscript operation' 
which I eventually traced to the fact that I had typed square 
brackets where there should have been parens. However, the 
phrase quoted doesn't make sense to me as it stands. What I had 
done was to write, in effect, 'foo := set[bar]' - perhaps if I don't 
make sense to the compiler I can't expect it to make sense to me! 
It is really a syntax error.

Also, some of the library functions, although documented, look as 
if they were added as part of various studies. Are there references 
to these projects anywhere?

Regards

_John Sampson_


From icon-group-sender  Fri Jun 23 08:15:13 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA11792
	for icon-group-addresses; Fri, 23 Jun 2000 08:15:03 -0700 (MST)
Message-Id: <200006231515.IAA11792@baskerville.CS.Arizona.EDU>
Date: Fri, 23 Jun 2000 07:57:52 -0700
From: Steve Wampler <swampler@noao.edu>
X-Accept-Language: en
To: icon-group <icon-group@optima.CS.Arizona.EDU>, jsampson@indexes.u-net.com
Subject: Re: Error messages
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

"J.R. Sampson" wrote:

> I had an error message 114, 'Invalid type to subscript operation'
> which I eventually traced to the fact that I had typed square
> brackets where there should have been parens. However, the
> phrase quoted doesn't make sense to me as it stands. What I had
> done was to write, in effect, 'foo := set[bar]' - perhaps if I don't
> make sense to the compiler I can't expect it to make sense to me!
> It is really a syntax error.

Actually, no - it's not a syntax error.  Function names are not
reserved names, but simply global variables with predefined values.

Somewhere earlier (in the execution of the program) you may have
done:

    set := table()

and then the line

    foo := set[bar]

makes complete sense.  (This type of language flexibility does
make it difficult to produce error messages that always make
sense to the user, who may be thinking of something entirely
different - which is why having a traceback that includes line
numbers is so useful!)


--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu


From icon-group-sender  Tue Jun 27 10:09:53 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA09414
	for icon-group-addresses; Tue, 27 Jun 2000 10:06:39 -0700 (MST)
Message-Id: <200006271706.KAA09414@baskerville.CS.Arizona.EDU>
Date: Tue, 27 Jun 2000 10:27:30 -0400
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject:  Permutations/Combinations
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id HAA05105
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L.  I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter.  Can anyone help me?

Thanks,

Steve Graham

---------------------------------------------------------------------------------------
Steve Graham
Senior Programmer/Analyst
LabCorp

Phone: (972) 437-5255, ext 5224
Fax:     (972) 454-1040
Mail:    grahams@labcorp.com
---------------------------------------------------------------------------------------




From icon-group-sender  Tue Jun 27 12:49:32 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14033
	for icon-group-addresses; Tue, 27 Jun 2000 12:49:15 -0700 (MST)
Message-Id: <200006271949.MAA14033@baskerville.CS.Arizona.EDU>
Date: Tue, 27 Jun 2000 10:31:35 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: Permutations/Combinations
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: "Steve Graham" <Steve_Graham@labcorp.com>
    
    We have a brain teaser floating around work whose object is to find all
    6-letter English words which can be made from the letters A, E, R, B,M
    and L.  I'm sure you can do this with Icon's reversible assignment,
    but I don't understand the latter.  Can anyone help me?

If you have a list of English words, an easy solution to the brain teaser
is to run the list through this filter:

	procedure main()
	   local word
	   while word := read() do
	      if *word = 6 & cset(map(word)) == 'aerbml' then
		 write(word)
	end

Of course, I have managed to avoid entirely your question about
reversible assignment.
    
   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Tue Jun 27 12:51:19 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14139
	for icon-group-addresses; Tue, 27 Jun 2000 12:51:11 -0700 (MST)
Message-Id: <200006271951.MAA14139@baskerville.CS.Arizona.EDU>
Date: Tue, 27 Jun 2000 14:21:56 -0400
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Permutations/Combinations
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id LAA11829
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

You're right, Gregg, you did avoid the reversible assignment topic.  

Although I do not know how to utilize Icon's built-in features to generate all possible combinations/permutations (which one is it?) where the letters appear once and only once, I do believe that, given the generated list, I will recognize the valid words.  And I'm sure that Icon can EASILY produce the list, whether the algorthim utilizes reversible assignment or not.  Can someone show me how?

TIA,

Steve

===

---------------------------------------------------------------------------------------
Steve Graham
Senior Programmer/Analyst
LabCorp

Phone: (972) 437-5255, ext 5224
Fax:     (972) 454-1040
Mail:    grahams@labcorp.com
---------------------------------------------------------------------------------------


>>> Gregg Townsend <gmt@baskerville.CS.Arizona.EDU> 06/27/00 12:31PM >>>
    From: "Steve Graham" <Steve_Graham@labcorp.com>
    
    We have a brain teaser floating around work whose object is to find all
    6-letter English words which can be made from the letters A, E, R, B,M
    and L.  I'm sure you can do this with Icon's reversible assignment,
    but I don't understand the latter.  Can anyone help me?

If you have a list of English words, an easy solution to the brain teaser
is to run the list through this filter:

	procedure main()
	   local word
	   while word := read() do
	      if *word = 6 & cset(map(word)) == 'aerbml' then
		 write(word)
	end

Of course, I have managed to avoid entirely your question about
reversible assignment.
    
   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA




From icon-group-sender  Tue Jun 27 12:52:55 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14195
	for icon-group-addresses; Tue, 27 Jun 2000 12:52:47 -0700 (MST)
Message-Id: <200006271952.MAA14195@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 27 Jun 2000 14:39:11 -0500
Subject: Permutations/Combinations
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L.  I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter.  Can anyone help me?

First off, one has to presume that you have available a list of English words from which universe you will find matching words that meet the criteria.

You can then either generate all possible permutations (which seems to be the approach you're taking) and then look each such word up in the list of valid English words, or else you can work the other way and use your list of words and qualify each to see if it fits the criteria.

I'd think that the second approach is simpler, although perhaps the first is faster.

Presuming that you have a file with one English-language word (all in lower case) per line:

procedure main()
   while line := trim(read()) do {
       if *line = 6 then
          if *(line ** 'aerbml') = 6 then 
	    write(line)
   }
end

Character sets really make short work of many such problems.  :-)

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Tue Jun 27 16:55:20 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21064
	for icon-group-addresses; Tue, 27 Jun 2000 16:55:06 -0700 (MST)
Message-Id: <200006272355.QAA21064@baskerville.CS.Arizona.EDU>
Date: Tue, 27 Jun 2000 13:08:59 -0700 (MST)
From: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
To: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: Permutations/Combinations
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

    From: "Steve Graham" <Steve_Graham@labcorp.com>
    
    Although I do not know how to utilize Icon's built-in features to generate
    all possible combinations/permutations (which one is it?) where the letters
    appear once and only once, I do believe that, given the generated list, I
    will recognize the valid words.  And I'm sure that Icon can EASILY produce
    the list, whether the algorthim utilizes reversible assignment or not.
    Can someone show me how?
    
The Icon program library contains a nice little permutation generator
(in the procs/strings.icn file):

	procedure permute(s)
	   local i
	   if *s = 0 then return ""
	      suspend s[i := 1 to *s] || permute(s[1:i] || s[i+1:0])
	end

So to generate all 720 permutations you'd just do this:

	procedure main()
	   every write(permute("abelmr"))
	end

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA


From icon-group-sender  Tue Jun 27 16:58:58 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21141
	for icon-group-addresses; Tue, 27 Jun 2000 16:58:51 -0700 (MST)
Message-Id: <200006272358.QAA21141@baskerville.CS.Arizona.EDU>
To: Gregg Townsend <gmt@baskerville.CS.Arizona.EDU>
cc: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU,
        wgg@cs.ucsd.edu
Subject: Re: Permutations/Combinations 
Date: Tue, 27 Jun 2000 13:28:05 -0700
From: William Griswold <wgg@cs.ucsd.edu>
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Or you can turn it around and generate all possible 6 letter permutations
and run the results through a spell checker.  6 factorial isn't that bad. :)
A small catch is that spell checkers tell you what is bad, rather than good,
and some make mistakes and let stuff through.

procedure main(args)
  every write(genstrings(cset(args[1])))
end

procedure genstrings(chars)
  if *chars = 1 then return chars
  every c := !chars do
    suspend (c || genstrings(chars -- c))
end


Here is a Unix shell script that completes the job:

#!/bin/csh
set tmp = /tmp/tmp$$

permute $1 > $tmp.perm
spell $tmp.perm > $tmp.misp

cat $tmp.misp $tmp.perm | sort | uniq -u

rm -f $tmp.perm $tmp.misp


--bill

In msg <200006271949.MAA14033@baskerville.CS.Arizona.EDU>, Gregg Townsend says:
>    From: "Steve Graham" <Steve_Graham@labcorp.com>
>    
>    We have a brain teaser floating around work whose object is to find all
>    6-letter English words which can be made from the letters A, E, R, B,M
>    and L.  I'm sure you can do this with Icon's reversible assignment,
>    but I don't understand the latter.  Can anyone help me?
>
>If you have a list of English words, an easy solution to the brain teaser
>is to run the list through this filter:
>
>	procedure main()
>	   local word
>	   while word := read() do
>	      if *word = 6 & cset(map(word)) == 'aerbml' then
>		 write(word)
>	end
>
>Of course, I have managed to avoid entirely your question about
>reversible assignment.
>    
>   ---------------------------------------------------------------------------
>   Gregg Townsend         Staff Scientist      The University of Arizona
>   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA
>
>


From icon-group-sender  Tue Jun 27 16:59:29 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21185
	for icon-group-addresses; Tue, 27 Jun 2000 16:59:18 -0700 (MST)
Message-Id: <200006272359.QAA21185@baskerville.CS.Arizona.EDU>
Date: Tue, 27 Jun 2000 16:38:22 -0400
From: "Steve Graham" <Steve_Graham@labcorp.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Permutations/Combinations
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id NAA15678
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Gregg,

   That's exactly what I was looking for.  Now, let me have some time to ponder why it works...

---------------------------------------------------------------------------------------
Steve Graham
Senior Programmer/Analyst
LabCorp

Phone: (972) 437-5255, ext 5224
Fax:     (972) 454-1040
Mail:    grahams@labcorp.com
---------------------------------------------------------------------------------------


>>> Gregg Townsend <gmt@baskerville.CS.Arizona.EDU> 06/27/00 03:08PM >>>
    From: "Steve Graham" <Steve_Graham@labcorp.com>
    
    Although I do not know how to utilize Icon's built-in features to generate
    all possible combinations/permutations (which one is it?) where the letters
    appear once and only once, I do believe that, given the generated list, I
    will recognize the valid words.  And I'm sure that Icon can EASILY produce
    the list, whether the algorthim utilizes reversible assignment or not.
    Can someone show me how?
    
The Icon program library contains a nice little permutation generator
(in the procs/strings.icn file):

	procedure permute(s)
	   local i
	   if *s = 0 then return ""
	      suspend s[i := 1 to *s] || permute(s[1:i] || s[i+1:0])
	end

So to generate all 720 permutations you'd just do this:

	procedure main()
	   every write(permute("abelmr"))
	end

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Wed Jun 28 12:53:21 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA24028
	for icon-group-addresses; Wed, 28 Jun 2000 12:51:30 -0700 (MST)
Message-Id: <200006281951.MAA24028@baskerville.CS.Arizona.EDU>
Date: Wed, 28 Jun 2000 11:11:18 -0700 (MST)
From: Gregg Townsend <gmt>
To: icon-group
Subject: Wanted: beta testers for map viewing program
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

A new application for viewing USGS topo maps under Unix is described
in the last Icon newsletter:
	http://www.cs.arizona.edu/icon/inl/inl60/inl60.htm#USGS

If you'd be interested in beta testing this application, please
send me a note.

   ---------------------------------------------------------------------------
   Gregg Townsend         Staff Scientist      The University of Arizona
   gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA



From icon-group-sender  Thu Jun 29 08:24:53 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA26522
	for icon-group-addresses; Thu, 29 Jun 2000 08:23:06 -0700 (MST)
Message-Id: <200006291523.IAA26522@baskerville.CS.Arizona.EDU>
Date: Thu, 29 Jun 2000 16:43:25 +1000
From: Rohan McLeod <rohan@micom.asn.au>
X-Accept-Language: en
To: Steve Graham <Steve_Graham@labcorp.com>
CC: icon-group@optima.CS.Arizona.EDU
Subject: Re: Permutations/Combinations
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Nope!
But here is another ;in case your bored after you solve the first one.
(First some back ground.) I was horrified when I realized that the sentence:
"the quick brown fox jumped over the lazy dog" actually repeats some letters;
(yes compulsive/obsessive personality disorder).So the problem is :
"What is the greatest number of non-repeating alphabetic characters (case insensitive) in a  gramatically correct English sentence."

Steve Graham wrote:

> We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L.  I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter.  Can anyone help me?
>
> Thanks,
>
> Steve Graham
>
> ---------------------------------------------------------------------------------------
> Steve Graham
> Senior Programmer/Analyst
> LabCorp
>
> Phone: (972) 437-5255, ext 5224
> Fax:     (972) 454-1040
> Mail:    grahams@labcorp.com
> ---------------------------------------------------------------------------------------



From icon-group-sender  Thu Jun 29 12:30:23 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA03447
	for icon-group-addresses; Thu, 29 Jun 2000 12:29:52 -0700 (MST)
Message-Id: <200006291929.MAA03447@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: clayton.cs.monmouth.edu: rclayton set sender to rclayton@monmouth.edu using -f
From: "R. Clayton" <rclayton@monmouth.edu>
Date: Thu, 29 Jun 2000 12:20:58 -0400 (EDT)
To: icon-group@optima.CS.Arizona.EDU
Subject: Oh, wow - synchronicity.
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

  I was horrified when I realized that the sentence:  "the quick brown fox
  jumped over the lazy dog" actually repeats some letters; (yes
  compulsive/obsessive personality disorder).So the problem is : "What is the
  greatest number of non-repeating alphabetic characters (case insensitive) in
  a  gramatically correct English sentence." 

You may think this is an idle, fatuous problem but it's not.  I recently bought
a set of 26 magnetic letters for my office door and made the same shocking
discovery that Rohan McLeod made, which immediately led me to a similar
question: What's the best 26 non-repeating letter sentence?  Unfortunately, my
icon investigations into this problem are unfinished, having been stopped at
the words-into-sentences part by other matters (which, co-incidentally enough,
include the data structures course I'm teaching this summer - perhaps there is
some synegery here too).



From icon-group-sender  Thu Jun 29 13:35:10 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05215
	for icon-group-addresses; Thu, 29 Jun 2000 13:34:49 -0700 (MST)
Message-Id: <200006292034.NAA05215@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Thu, 29 Jun 2000 15:14:07 -0500
Subject: Oh, wow - synchronicity.
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

>>  I was horrified when I realized that the sentence:  "the quick brown fox
  jumped over the lazy dog" actually repeats some letters; (yes
  compulsive/obsessive personality disorder).So the problem is : "What is the
  greatest number of non-repeating alphabetic characters (case insensitive) in
  a  gramatically correct English sentence." 

> You may think this is an idle, fatuous problem but it's not.  I recently bought
a set of 26 magnetic letters for my office door and made the same shocking
discovery that Rohan McLeod made, which immediately led me to a similar
question: What's the best 26 non-repeating letter sentence?  Unfortunately, my
icon investigations into this problem are unfinished, having been stopped at
the words-into-sentences part by other matters (which, co-incidentally enough,
include the data structures course I'm teaching this summer - perhaps there is
some synegery here too).

If you can't repeat letters, you have a very basic problem... there are only five or six vowels
and you must have at least one per word...


Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Thu Jun 29 13:58:04 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05871
	for icon-group-addresses; Thu, 29 Jun 2000 13:57:44 -0700 (MST)
Message-Id: <200006292057.NAA05871@baskerville.CS.Arizona.EDU>
From: David S Cargo <escargo@ann.skypoint.net>
Date: Thu, 29 Jun 2000 15:52:57 -0500 (CDT)
To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: Oh, wow - synchronicity.
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

One other alternative that remember is "Pack my bags with five dozen
liquor jugs."

dsc


From icon-group-sender  Thu Jun 29 13:58:34 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05910
	for icon-group-addresses; Thu, 29 Jun 2000 13:58:21 -0700 (MST)
Message-Id: <200006292058.NAA05910@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Thu, 29 Jun 2000 16:14:22 -0500
Subject: Re: Oh, wow - synchronicity.
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> One other alternative that remember is "Pack my bags with five dozen
liquor jugs."

Right, but way too much reuse of vowels... at least for the "all 
twenty-six letters, ONCE EACH" challenge.

Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
   fraudulent sham of representative government.  Voters, remember it!



From icon-group-sender  Thu Jun 29 16:57:18 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA10913
	for icon-group-addresses; Thu, 29 Jun 2000 16:56:52 -0700 (MST)
Message-Id: <200006292356.QAA10913@baskerville.CS.Arizona.EDU>
From: Charles G Shirley <cshirle@sandia.gov>
X-Newsgroups: comp.lang.icon
Subject: Re: Oh, wow - synchronicity.
Date: Thu, 29 Jun 2000 15:40:51 -0600
X-Accept-Language: en,pdf
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Zing! vext cwm fly jabs Kurd qoph.

That's one I recall from a book titled _Literary Oddities and
Curiosities_. The sentence describes an irritated fly from a high
mountain valley attempting to sting a Hebrew letter being written by a
Kurd. Not often useful in real life, but it is grammatically correct.


"R. Clayton" wrote:
> 
>   I was horrified when I realized that the sentence:  "the quick brown fox
>   jumped over the lazy dog" actually repeats some letters; (yes
>   compulsive/obsessive personality disorder).So the problem is : "What is the
>   greatest number of non-repeating alphabetic characters (case insensitive) in
>   a  gramatically correct English sentence."
> 
> You may think this is an idle, fatuous problem but it's not.  I recently bought
> a set of 26 magnetic letters for my office door and made the same shocking
> discovery that Rohan McLeod made, which immediately led me to a similar
> question: What's the best 26 non-repeating letter sentence?  Unfortunately, my
> icon investigations into this problem are unfinished, having been stopped at
> the words-into-sentences part by other matters (which, co-incidentally enough,
> include the data structures course I'm teaching this summer - perhaps there is
> some synegery here too).


From icon-group-sender  Fri Jun 30 08:03:17 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA04466
	for icon-group-addresses; Fri, 30 Jun 2000 08:02:19 -0700 (MST)
Message-Id: <200006301502.IAA04466@baskerville.CS.Arizona.EDU>
Date: Thu, 29 Jun 2000 23:22:07 -0700 (PDT)
From: Shamim Mohamed <soar@drones.com>
To: gep2@terabites.com
Cc: icon-group@optima.CS.Arizona.EDU
Subject: Re: Oh, wow - synchronicity.
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

 >> One other alternative that remember is "Pack my bags with five dozen
 >> liquor jugs."

 > Right, but way too much reuse of vowels... at least for the "all
 > twenty-six letters, ONCE EACH" challenge.

Try "Cwm fjord bank glyphs vext quiz."

(With a little imagination it even makes sense!)

-s


From icon-group-sender  Fri Jun 30 08:05:28 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA04572
	for icon-group-addresses; Fri, 30 Jun 2000 08:05:20 -0700 (MST)
Message-Id: <200006301505.IAA04572@baskerville.CS.Arizona.EDU>
Date: 30 Jun 2000  09:31:28 BST
From: rjhare@ed.ac.uk
Subject: Re: Oh, wow - synchronicity.
To: "R. Clayton" <rclayton@monmouth.edu>
cc: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

> question: What's the best 26 non-repeating letter sentence?  Unfortunately, \
> my
> icon investigations into this problem are unfinished, having been stopped at
> the words-into-sentences part by other matters (which, co-incidentally \
> enough,
> include the data structures course I'm teaching this summer - perhaps there \
> is
> some synegery here too).

There's a good article on just this topic in one of Stephen Jay Goulds books -
from memory, it's in `Bully For Brontosaurus', but I'm not absolutely sure.

I think that one of the attempts in the article is:

The five boxing wizards jump quickly.

If it's not, I have no memory of where I got that one, but it's `better' than
the fox thing...

Roger Hare


From icon-group-sender  Fri Jun 30 12:31:59 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12426
	for icon-group-addresses; Fri, 30 Jun 2000 12:31:08 -0700 (MST)
Message-Id: <200006301931.MAA12426@baskerville.CS.Arizona.EDU>
From: Kostas Oikonomou <oikonomou@att.com>
X-Newsgroups: comp.lang.icon
Subject: Approximate comparisons of reals
Date: Fri, 30 Jun 2000 11:32:55 -0400
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

I'm trying to write Icon procedures that implement the approximate <, >,
and =
relations for real numbers that are in Knuth Vol. 2, section 4.2.2, p.
218 in
the 2nd ed.  I would  like to put these in a library.

It seems to me that to write such procedures efficiently one needs
access to the floating
point representation of reals, i.e. fractional part and exponent.

Is it possible ro access the representation of reals in Icon?  Or has
someone already written something like this?

                                                       Kostas




From icon-group-sender  Fri Jun 30 12:46:54 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12801
	for icon-group-addresses; Fri, 30 Jun 2000 12:46:45 -0700 (MST)
Message-Id: <200006301946.MAA12801@baskerville.CS.Arizona.EDU>
From: Atle <trollet@skynet.be>
X-Newsgroups: comp.lang.icon
Subject: Re: coexpression history
Date: Fri, 30 Jun 2000 19:06:58 -0100
X-Trace: news0.skynet.be 962384486 19918 195.238.7.176 (30 Jun 2000 17:01:26 GMT)
X-Complaints-To: abuse@skynet.be
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Jim Mehl wrote:
> 
> I don't think so. I have this vague remembrance that
> coexpression/coroutine was actually proposed many years
> ago in the context of a COBOL compiler of all things.
> Maybe someone with a better sense of computer science
> history can help me out here.
In any case, it was part of Simula, I think Simula started around 1967 ...

Atle


From icon-group-sender  Fri Jun 30 12:47:23 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12839
	for icon-group-addresses; Fri, 30 Jun 2000 12:47:14 -0700 (MST)
Message-Id: <200006301947.MAA12839@baskerville.CS.Arizona.EDU>
From: Atle <trollet@skynet.be>
X-Newsgroups: comp.lang.icon
Subject: Re: coexpression history
Date: Fri, 30 Jun 2000 19:12:07 -0100
X-Trace: news1.skynet.be 962384795 6678 195.238.7.176 (30 Jun 2000 17:06:35 GMT)
X-Complaints-To: abuse@skynet.be
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Steve Wampler wrote:
>  
> Yes, that's the original reference (as far as I can remember) for the
> coroutine side of co-expressions.  Coroutines were then implemented in
> a number of languages.  The one that comes to mind as having the most
> influence here is Simula.
The idea of coroutines is being 'revamped' as 'component object' in Beta, the successor to Simula.
Beta takes the idea of 'object oriented programming' one step further, to 'pattern-oriented programming'. I first saw coroutines in
Icon, but now, when I have looked a little at Beta and gotten a very superficial overview of what they were part of, I realy feel i
understand it better.

People interested in these aspects of Icon would progrably find Beta interesting:

www.mjolner.dk

-- at least I assume so :-)

Atle


From icon-group-sender  Wed Jul  5 08:03:33 2000
Return-Path: <icon-group-sender>
Received: (from root@localhost)
	by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24576
	for icon-group-addresses; Wed, 5 Jul 2000 08:02:11 -0700 (MST)
Message-Id: <200007051502.IAA24576@baskerville.CS.Arizona.EDU>
From: Atle <trollet@skynet.be>
X-Newsgroups: comp.lang.icon
Subject: Re: Error messages
Date: Sat, 01 Jul 2000 12:21:15 -0100
X-Trace: news0.skynet.be 962446543 8139 194.78.236.172 (1 Jul 2000 10:15:43 GMT)
X-Complaints-To: abuse@skynet.be
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO

Steve Wampler wrote:
>
> 
>     set := table()
> 
> and then the line
> 
>     foo := set[bar]
> 
> makes complete sense.  (This type of language flexibility does
> make it difficult to produce error messages that always make
> sense to the user, who may be thinking of something entirely
> different - which is why having a traceback that includes line
> numbers is so useful!)
This may not be related to Icon at all (although I feel that Icon, ProLog, Simula and Beta are 'close cousins :) - but I have been
fooling around with the idea of writing a parser in ProLog - I started out with something close to the grammar for 8086 assembly.
Why? Because the syntax is simple, so syntax errors wont contain much information as to what the error actually is, but the
semantics possibilities are enormous compared to, say, Pascal.
Now, this is where I think it might be relevant: Wouldn't some kind of knowledge base help in producing more meaningful error
messages? I have been through Icon enough to write small programs in it, and I had the same impression: The error messages really
only say: "Error" - and you have to find the rest out for yourself. The case here about the [] could be added to the knowledgebase,
so the next time, the error would be "I told myself I wouldn't use [] here!" :-)

Any thoughts? Should I drop the idea of using an AI language to build an assembler?
(I actually wanted to use Beta)