ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group02a.txt

Internet Message Format | 2003-01-02 | 295KB

From icon-group-sender Wed Jan 30 16:30:27 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g0UNT2s07895
    for icon-group-addresses; Wed, 30 Jan 2002 16:29:02 -0700 (MST)
Message-Id: <[e-mail]>
Date: Wed, 30 Jan 2002 16:25:19 -0500
From: Dean JOLLY <[e-mail]>
To: <[e-mail]>
Subject: Re: serial port (fwd)
Errors-To: [e-mail]
Status: RO




Dean JOLLY wrote:
>
> Hi,
>
> I downloaded Icon earlier this month and I found that I can do most things
> I awnt with it. But I do have a problem, I would like to use it to do some
> acquisition and control via a serial port. I have tried several things,
> including just opening the port as a file, but nothing seems to work???
>
> Has anyone ever tried this? Or is it just not supported?
> I may be able to do it by opening a dll, again I was not successfull.
>
> Thanks,
>
> Dean Jolly
>
> Cyclotron unit
> Montreal Neurological Institute

--
Sandra L Miller
Department of Computer Science
University of Arizona



From icon-group-sender Thu Feb  7 08:38:22 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g17Fams10854
    for icon-group-addresses; Thu, 7 Feb 2002 08:36:48 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 07 Feb 2002 10:12:47 +1100
From: PACaleala <[e-mail]>
X-Accept-Language: en
X-Newsgroups: comp.lang.icon
Subject: puzzle solving program
To: [e-mail]
Errors-To: [e-mail]
Status: RO


given a random set of 9 letters
i need to find all combinations up to 9 letters long
do you have any sugestions suitable for a beginner ?


From icon-group-sender Thu Feb  7 12:28:04 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g17JReY19218
    for icon-group-addresses; Thu, 7 Feb 2002 12:27:41 -0700 (MST)
Message-Id: <[e-mail]>
X-Authentication-Warning: ptah.u.arizona.edu: acarr owned process doing -bs
Date: Thu, 7 Feb 2002 10:13:31 -0700 (MST)
From: Andrew J Carr <[e-mail]>
X-X-Sender:  <[e-mail]>
To: PACaleala <[e-mail]>
cc: <[e-mail]>
Subject: Re: puzzle solving program
Errors-To: [e-mail]
Status: RO

On Thu, 7 Feb 2002, PACaleala wrote:

> given a random set of 9 letters
> i need to find all combinations up to 9 letters long
> do you have any sugestions suitable for a beginner ?

Well, recursion works nicely. You're basically looking for a list of all
permutations generated by those 9 letters. Now the question is do you want
duplicates or do you want unique permutations all the way?

I can have a solution worked up by tonight, provided you aren't doing this
for a school project... then I could just give some psuedo-code for you.

--
Andrew Carr - [e-mail] - http://www.u.arizona.edu/~acarr
AIM/ICQ: Andyrew480/3100804
"Everyone is kneaded out of the same dough but not baked in the same oven."
                    - Yiddish Proverb



From icon-group-sender Mon Feb 11 08:18:43 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1BFGlI23920
    for icon-group-addresses; Mon, 11 Feb 2002 08:16:47 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 11 Feb 2002 11:46:06 +1300 (NZDT)
From: "Richard A. O'Keefe" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  puzzle solving program
Errors-To: [e-mail]
Status: RO

PACaleala <[e-mail]> wrote:

    given a random set of 9 letters
    i need to find all combinations up to 9 letters long
    do you have any sugestions suitable for a beginner ?

Start by saying clearly what you mean by
'all combinations up to 9 letters long'.

For example, given the set {A,B,C,D,E,F,G,H,I},
is AAAAAAAAA one of the allowed combinations?



From icon-group-sender Wed Feb 13 16:29:34 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1DNR0218632
    for icon-group-addresses; Wed, 13 Feb 2002 16:27:00 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Antonella)
X-Newsgroups: comp.lang.icon
Subject: Help needed with some Icon code!
Date: Wed, 13 Feb 2002 22:03:11 +0000
To: [e-mail]
Errors-To: [e-mail]
Status: RO

I'm stuck with some Icon code!  Is there an expert out there who could help?

What I need is a routine that will replace certain strings of text that
appear in lines in a text file, according to words found in previous
lines.  For instance, taking an example text file of the form:

Ann loves Brian
This is a line of prose text that talks about apples and bananas.
Ann hates Dave
This is a line of prose with a few words about apples and also cows.
Edward likes Frank
This line talks about elephants and also about foxes.
(And so-on, in pairs of lines, with a "two-word" line always being
followed by a longer line.)

The code should scan this text, and, in the above example, on finding the
line "Ann loves Brian", it should change, in the next line, every instance
of "apples" to "pears" (because it found "Ann" in the previous line), and
every instance of "bananas" to "oranges" (because it found "Brian" in the
previous line).

When the program finds the line "Ann hates Dave", it should change, in the
next line, every instance of "apples" to "pears" (because, again, it found
"Ann" in the previous line), and every instance of "cows" to "sheep"
(because it found "Dave" in the previous line).

Similarly, when it gets to the line "Edward likes Frank" it should change
all instances in the next line of "elephants" to "tigers" (because it
found "Edward" in the previous line), and every instance of "foxes" to
"lions" (because it found "Dave" in the previous line).

In other words, the program looks at the two words in each of the two-word
lines, and, depending on what they are, changes any and every occurrence
of corresponding words in the following longer lines.

Any help greatly appreciated!


From icon-group-sender Mon Feb 18 08:09:20 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1IF88A04637
    for icon-group-addresses; Mon, 18 Feb 2002 08:08:08 -0700 (MST)
Message-Id: <[e-mail]>
From: "Ken Kupisz" <[e-mail]>
To: <[e-mail]>
Subject: Rounding real numbers
Date: Sat, 16 Feb 2002 18:54:57 -0500
Status: RO

Could someone tell me what Icon proc is used to roundoff real numbers. =
Is there any discussion in the Analyst about this subject?

From icon-group-sender Thu Feb 21 09:12:27 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1LGB4Y17201
    for icon-group-addresses; Thu, 21 Feb 2002 09:11:04 -0700 (MST)
Message-Id: <[e-mail]>
From: "Daniel Ajoy" <[e-mail]>
To: <[e-mail]>
Date: Wed, 20 Feb 2002 22:16:45 -0500
Subject: Re: Rounding real numbers
X-Confirm-Reading-To: Daniel Ajoy <[e-mail]>
X-pmrqc: 1
X-LINE1: ABCDEF0123456789
Content-description: Mail message body
Errors-To: [e-mail]
Status: RO

On 16 Feb 2002 at 18:54, Ken Kupisz wrote:

> Could someone tell me what Icon proc is used to roundoff real numbers. =
> Is there any discussion in the Analyst about this subject?
>

I'm new here, what is the "Analyst"?

Daniel



From icon-group-sender Thu Feb 21 12:44:55 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1LJih627142
    for icon-group-addresses; Thu, 21 Feb 2002 12:44:44 -0700 (MST)
Message-Id: <[e-mail]>
Date: 21 Feb 2002  16:41:11 GMT
From: [e-mail]
Subject: Re: Rounding real numbers
To: "Daniel Ajoy" <[e-mail]>
cc: <[e-mail]>
Errors-To: [e-mail]
Status: RO

> I'm new here, what is the "Analyst"?

Icon `magazine' published from August 1990 to June 2001 - a total of 66
issues. The first several years are available online. See:

http://www.cs.arizona.edu/icon/

RH


From icon-group-sender Thu Feb 21 12:45:08 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1LJj5c27207
    for icon-group-addresses; Thu, 21 Feb 2002 12:45:05 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Eka Laiman)
Subject: Re: Rounding real numbers
To: [e-mail]
Date: Thu, 21 Feb 2002 09:11:39 -0800 (PST)
Errors-To: [e-mail]
Status: RO

> Could someone tell me what Icon proc is used to roundoff real
> numbers. Is there any discussion in the Analyst about this
> subject?

I think there is ambiguity in the phrase "roundoff". What does
this mean? Suppose I have 24.7231, what do I want to round it off to?
The answer can be:

1. 24 which is the round "off" to the integer. If this is the case,
   then a simple function int will do the job.
2. 25 which is the "proper rounding" of a real number to the nearest
   integer. If this is the case then simply add half the precision and
   do the truncation. For our example: int(24.7231 + 0.5) = 25.
3. Or .... round it (off or to the nearest) hundreth. In this case
   simply multiply the number by 100 and do the proper rounding as
   described in 1 or 2 above.

-eka-



From icon-group-sender Thu Feb 21 17:44:29 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1M0i5U10224
    for icon-group-addresses; Thu, 21 Feb 2002 17:44:05 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 21 Feb 2002 15:10:48 -0600
From: Benjamin Pharr <[e-mail]>
To: [e-mail]
Subject: Seeding the Random Number Generator
Content-Disposition: inline
Status: RO

Does anyone have any good tips for seeding the random number generator?
Right now I'm doing:

&random := integer( &time )

but since my program's startup time doesn't vary much that's not doing
me much good. Thanks in advance.

Ben Pharr
[e-mail]

From icon-group-sender Fri Feb 22 08:10:17 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1MF8dg29115
    for icon-group-addresses; Fri, 22 Feb 2002 08:08:39 -0700 (MST)
Message-Id: <[e-mail]>
From: "Daniel Ajoy" <[e-mail]>
To: <[e-mail]>
Date: Thu, 21 Feb 2002 21:23:30 -0500
Subject: Re: Rounding real numbers
X-Confirm-Reading-To: Daniel Ajoy <[e-mail]>
X-pmrqc: 1
X-LINE1: ABCDEF0123456789
Content-description: Mail message body
Errors-To: [e-mail]
Status: RO

On 21 Feb 2002 at 16:41, [e-mail] wrote:

> > I'm new here, what is the "Analyst"?
>
> Icon `magazine' published from August 1990 to June 2001 - a total of 66
> issues. The first several years are available online. See:
>
> http://www.cs.arizona.edu/icon/
>
> RH
>

Oh, thanks for the pointer.

Daniel





From icon-group-sender Fri Feb 22 08:10:44 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1MFAVQ29220
    for icon-group-addresses; Fri, 22 Feb 2002 08:10:31 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 21 Feb 2002 22:37:11 -0500
From: "David.Gamey" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
To: Benjamin Pharr <[e-mail]>
CC: [e-mail]
Subject: Re: Seeding the Random Number Generator
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.191.113] using ID <[e-mail]> at Thu, 21 Feb 2002 22:45:08 -0500
Errors-To: [e-mail]
Status: RO

Well that really depends upon the application.   Most (pseudo) random
number generators (PRNG) such as Icon/Unicon are intended for
applications such as simulations and games. There are volumes of
information about this available, such as Knuth's Semi-numerical
algorithms, and some good sites on random number generation.  They
describe not only how to construct them and characteristics, but also
good tests or randomness.  Simple tests include chi-squares of
distributions, correlations by plotting n-tuples of numbers in an
n-dimensional space and looking for patterns.  There are also some more
advanced tests, such as the spectral test.

If memory servers, there was an article on the Icon generator in the
Analyst within the last four years or so.  It has the odd (pardon the
pun in advance) characteristic that it produces two independant
repeating sequences depending upon it's input.  Odd seeds produce one
sequence, even another.  For more info see
http://www.cs.arizona.edu/icon/library/src/procs/random.icn which
includes a duplicate of the builtin PNRG.

Clint Jeffrey has suggested using:
    &random := map("sSmMhH", "Hh:Mm:Ss", &clock) + map("YyXxMmDd",
"YyXx/Mm/Dd", &date)
to seed using the date and clock time.  This code is actually used in
randomize() part of random.icn

Now if you're doing something that requires strong random numbers for a
cryptographic or authentication system this kind of PNRG isn't adequate.
 There are many more volumes of material on that subject including why
various classes of PNRG (including Icon's) are unsuitable and how to get
truly good entropy to seed these applications.  Some open source
projects like GNU Privacy Guard (Open PGP) have modules devoted to this.
 Also a number of notable companies have been embarassed by not getting
enough entropy into their RNG's (e.g. Netscape SSL in 1995).

Hope this helps.

David

Benjamin Pharr wrote:

>Does anyone have any good tips for seeding the random number generator?
>Right now I'm doing:
>
>&random := integer( &time )
>
>but since my program's startup time doesn't vary much that's not doing
>me much good. Thanks in advance.
>
>Ben Pharr
>[e-mail]

From icon-group-sender Fri Feb 22 08:11:03 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1MFAuE29257
    for icon-group-addresses; Fri, 22 Feb 2002 08:10:56 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 21 Feb 2002 22:42:10 -0500
From: "David.Gamey" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
To: "David.Gamey" <[e-mail]>
CC: Benjamin Pharr <[e-mail]>, [e-mail]
Subject: Re: Seeding the Random Number Generator (correction)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.191.113] using ID <[e-mail]> at Thu, 21 Feb 2002 22:49:53 -0500
Errors-To: [e-mail]
Status: RO

Ooops. While Clint suggested this, I beleive that Ralph Griswold and/or
Gregg Townsend deserve original credit (since they wrote random.icn). My
mistake.

David.Gamey wrote:

>
> Clint Jeffrey has suggested using:
> &random := map("sSmMhH", "Hh:Mm:Ss", &clock) + map("YyXxMmDd",
> "YyXx/Mm/Dd", &date)
> to seed using the date and clock time. This code is actually used in
> randomize() part of random.icn
>




From icon-group-sender Fri Feb 22 08:11:20 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1MFBDI29322
    for icon-group-addresses; Fri, 22 Feb 2002 08:11:13 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 21 Feb 2002 22:54:58 -0500
From: "David.Gamey" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
To: "David.Gamey" <[e-mail]>
CC: Benjamin Pharr <[e-mail]>, [e-mail]
Subject: Re: Seeding the Random Number Generator (more on cryptographic PNRG's)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.191.113] using ID <[e-mail]> at Thu, 21 Feb 2002 23:02:43 -0500
Errors-To: [e-mail]
Status: RO

I just found this in sci.crypt that might be of interest.
I'll stop (hopefully) before I'm guilty of too much information.

David

--------------------
Zeljko Vrba wrote:


>> Given a sequence of consecutive pseudo-random numbers and a known method
>> (e.g. linear congruential method), is it possible to recover the random
>> seed and how many (minimally) consecutive numbers from the sequence are needed
>> so that the seed can be determined uniquely?
>>
>> Any pointers to the subject are appreciated.
>

The difficulty of the problem depends on the details of the pseudo-random
number generating algorithm. For the case of linear congruential sequences,
I believe the original work was by J. Boyar and Donald Knuth --- a google
search on "boyar knuth" is fruitful. Another famously insecure PRNG is
the linear-feedback shift register, whose state can be found from a number
of output bits equal to the length of the register.

A cryptographically strong PRNG must have the property that knowing
past outputs and future outputs will not help to find present outputs.
Some good examples appear in the appendices of the FIPS 186
standard (http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf).

- Peter

p p e a r s o n (at) r c n (dot) c o m







From icon-group-sender Fri Feb 22 08:11:36 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1MFBT229341
    for icon-group-addresses; Fri, 22 Feb 2002 08:11:29 -0700 (MST)
Message-Id: <[e-mail]>
Date: 22 Feb 2002  08:58:11 GMT
From: [e-mail]
Subject: Re: Seeding the Random Number Generator
To: Benjamin Pharr <[e-mail]>
cc: [e-mail]
Errors-To: [e-mail]
Status: RO

> Does anyone have any good tips for seeding the random number generator?
> Right now I'm doing:
>
> &random := integer( &time )
>
> but since my program's startup time doesn't vary much that's not doing
> me much good. Thanks in advance.

I always use:

&random:=&date[6:8]||&date[9:11]||&clock[1:3]||&clock[4:6]||&clock[7:9]

It seems to work, but I don't know if there is any good mathematical reason for
this. Anyone with a greater knowledge of random number generation care to
comment? I'd like to know more myself.

RH


From icon-group-sender Mon Feb 25 08:19:19 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1PFHDA06347
    for icon-group-addresses; Mon, 25 Feb 2002 08:17:13 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Sun, 24 Feb 2002 13:10:28 -0000
Subject: icon or perl?
Errors-To: [e-mail]
Status: RO

Hi
I've recently come back to icon after a break of about 10 years (v 5
or v6) I was wondering whether to put most of my effort into perl or
icon.
It seems to me that perl is far more versatile than icon & has the
advantage of sohpisticated pattern matching using regular
expressions.
Is anyone a regular use of both programs & can point to
advantages of one or the other for text processing?
Maybe there has been a thread like this previously, in which case it
might be better to point me in that direection rather then grinding
the same wheat through the mill!

Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Thu Feb 28 12:29:46 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g1SJSao06768
    for icon-group-addresses; Thu, 28 Feb 2002 12:28:36 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Robert Baker)
X-Newsgroups: comp.lang.icon
Subject: Re: puzzle solving program
Date: 28 Feb 2002 10:49:28 -0800
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

PACaleala <[e-mail]> wrote in message news:<[e-mail]>...
> given a random set of 9 letters
> i need to find all combinations up to 9 letters long
> do you have any sugestions suitable for a beginner ?

Firstly, I'm afraid you've got your terminology wrong.  If you have
nine letters, there's only one *combination* of all nine -- but there
are 362,880 *permutations*, which I think is what you meant.

I'm afraid I don't know Icon (I came in here looking for *icons* -- if
anyone knows which newsgroup is appropriate, or a good website, please
e-mail me, but you need to delete "korax1214" and substitute
"robert.bak", as the account with which I post to UseNet is just a
spam-sink and I'll never see anything sent there), but in Pascal
(perhaps someone could translate) a simple bit of code to do something
like what you want goes like this:

{ l[1..9] is a 9-character string
  n (passed from a procedure header?) is the number of letters
    required in the permutation
}
for a:=1 to 9 do
  for b:=1 to 9 do
    if b<>a then for c:=1 to 9 do
       if (c<>a) and (c<>b) then for d:=1 to 9 do
.... (I think you get the idea)
                writeln(l[a],l[b],l[c],l[d],l[e],l[f],l[g],
                   l[h],l[i]);

The above (crude and clumsy, but it will work) writes all 362,880
perms, one to a line, to standard output.  With luck you may be able
to adapt it (or the idea at least) to something approaching your
needs...


From icon-group-sender Fri Mar  1 12:54:22 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g21JqEc03768
    for icon-group-addresses; Fri, 1 Mar 2002 12:52:14 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Fri, 1 Mar 2002 18:37:17 -0000
Subject: compile or interpret?
Errors-To: [e-mail]
Status: RO

Even after reading the icon docs, I'm not sure what is being
compiled and what is interpreted (or needs some sort of run-time
library).
In Windows, an exe program is produced, but does this depend on
a run-time to work? (I can't try this at work as its all Solaris/Linux).

Basically, I want to supply a copy of an icon program one for
Windows, one for Linux to people who don't have icon on their
systems. I was wondering whether these were truly stand-alone, or
whether I should also supply a translator with them - icont, wicont,
or whatever.
Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Fri Mar  1 16:51:45 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g21NpWs05354
    for icon-group-addresses; Fri, 1 Mar 2002 16:51:32 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 1 Mar 2002 13:17:43 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: compile or interpret?
Errors-To: [e-mail]
Status: RO

>  From: "Chris Korycinski" <[e-mail]>
>
>  In Windows, an exe program is produced, but does this depend on
>  a run-time to work? (I can't try this at work as its all Solaris/Linux).
>  Basically, I want to supply a copy of an icon program one for
>  Windows, one for Linux to people who don't have icon on their
>  systems....

The icont command "compiles" and "links" to produce code for an
abstract virtual machine.  The interpreter for this virtual machine
is needed at execution time.

On Windows, I *think* the .exe contains the interpreter and is
sufficient by itself.

On Linux (or any Unix system), the "iconx" executable is also needed.
Ship a copy of it in the same directory as the file produced by icont.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Fri Mar  1 16:53:04 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g21Nr2605412
    for icon-group-addresses; Fri, 1 Mar 2002 16:53:02 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Fri, 1 Mar 2002 21:21:58 -0000
Subject: RE: icon or perl?
Errors-To: [e-mail]
Status: RO

Thanks for the replies to my original query.

After a bit of thought, I'm going for both! Perl because I have to (we
have programs like 'sgmlperl'  which processes sgml/xml text on
an entity level, but which uses perl to do all the bits of processing
you want to do. It is PD if anyone is interested (try the university of
Edinburgh informatics or cognitive science section if Google
doesn't come up with the goods)

However, perl seems to me like someone took VB, C and a few
other languages and stuffed them all into a liquidiser - perl was the
result. It lack coherence (to me). I don't think I want to go back to
C unless I have to, so press on with icon...
Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Mon Mar  4 08:19:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g24FIUc28746
    for icon-group-addresses; Mon, 4 Mar 2002 08:18:30 -0700 (MST)
Message-Id: <[e-mail]>
From: Bob Ardler <[e-mail]>
To: [e-mail]
Date: Sat, 02 Mar 2002 10:32:20 +0000 (GMT)
Subject: Re: icon or perl?
User-Agent: Pluto/2.03e (RISC-OS/4.03)
Errors-To: [e-mail]
Status: RO

Chris Korycinski <[e-mail]> wrote:
> Thanks for the replies to my original query.
What replies? Emailed privately? O-o-o-o-oh, boy.



From icon-group-sender Mon Mar  4 08:21:16 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g24FLDc28972
    for icon-group-addresses; Mon, 4 Mar 2002 08:21:13 -0700 (MST)
Message-Id: <[e-mail]>
From: "John Sampson" <[e-mail]>
To: <[e-mail]>
Subject: RE: icon or perl?
Date: Sat, 2 Mar 2002 20:54:45 -0000
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Errors-To: [e-mail]
Status: RO

Hello -

Language from a liquidiser? Sounds like English!

Icon seems to be ahead of its time in that its features turn up in newer
languages, e.g. generators recently added to Python.

Regards

_John Sampson_




From icon-group-sender Mon Mar 11 12:54:35 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2BJpTw19284
    for icon-group-addresses; Mon, 11 Mar 2002 12:51:29 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Cygwin for Icon Win32
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Date: Mon, 11 Mar 2002 15:04:19 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Currently, the Windows version of Icon comes with support for precisely one
compiler: MS VC/C++. Granted, this is quite arguably the only proprietary C
compiler for Windows worth mentioning, but given the strong ties between
Icon and the free software movement, it is surprising that no one has ported
Icon to the GNU-licensed C compiler for Win32, namely Cygwin.

I am willing to work on such a port in my spare time. But first, I would
like to know if anyone has either done this port or started to do this port,
so that I may avoid duplicated effort.






From icon-group-sender Mon Mar 11 17:06:07 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2C05nU01530
    for icon-group-addresses; Mon, 11 Mar 2002 17:05:49 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 11 Mar 2002 16:00:22 -0700
From: Clint Jeffery <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Cygwin for Icon Win32
Errors-To: [e-mail]
Status: RO


[Frank Lhota asks about non-MSVC C compiler support for Windows Icon]

The eternally-beta Unicon distribution includes support for GCC 2.95.2 using
Mingw32.  There is a config/win32/gcc directory you could use as a good
starting point for making a config/win32/cygwin configuration, along with
#ifdef NTGCC codes throughout the sources.  These are all in the public
Unicon CVS repository at present, but not yet in the prepackaged Unicon
distributions.

While I am focused on (and taking forever to complete) Unicon and claim it
is an improvement upon Windows Icon in many respects, I will be very happy
to assist anyone willing to work on porting Windows Icon to new compilers,
or updating and maintaining it, especially if I can add such new compiler
configurations to Unicon.

Regards,
Clint Jeffery, [e-mail]


From icon-group-sender Wed Mar 13 08:04:33 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2DF32Q11769
    for icon-group-addresses; Wed, 13 Mar 2002 08:03:02 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Tue, 12 Mar 2002 22:36:09 -0000
Subject: Re: Cygwin for Icon Win32
Errors-To: [e-mail]
Status: RO

On 11 Mar 2002, at 15:04, Frank J. Lhota wrote:

> I am willing to work on such a port in my spare time. But first, I would
> like to know if anyone has either done this port...

I don't know of anyone who has done this, but I'd just like to say
how welcome your work would be.
Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Wed Mar 13 08:04:50 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2DF4lo11841
    for icon-group-addresses; Wed, 13 Mar 2002 08:04:47 -0700 (MST)
Message-Id: <[e-mail]>
From: rkstuart <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
X-Newsgroups: comp.lang.icon
Subject: Printers?
X-Complaints-To: [e-mail]
X-UserInfo1: Q[R_PJONGZTUC\\[OROLN[YFQ[WJBQ\KCA_@LWQIMASTUSAANNTEAK_ZQL[^HVWKGFDWJ@^NJ^[D_DKBRFW]NVHG@^RQXS\HJ@X^B_KBETUD@EP_XC@NIQKASLEE[KJMML^CJIZM\YYWWICSELXINHC_FK^XWQKIHA[Y@@OB@CCRA_LEY\FLLQ\GXVUKQPBL
Date: Tue, 12 Mar 2002 22:30:30 GMT
To: [e-mail]
Errors-To: [e-mail]
Status: RO

I've been reading through the documentation for Icon and haven't noticed
anything about sending data to a printer.  Is this not a part of the
language or have I missed it?



From icon-group-sender Thu Mar 14 12:27:34 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2EJQQA27476
    for icon-group-addresses; Thu, 14 Mar 2002 12:26:26 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 14 Mar 2002 09:10:55 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Printers?
Errors-To: [e-mail]
Status: RO

>  From: rkstuart <[e-mail]>
>  Date: Tue, 12 Mar 2002 22:30:30 GMT
>
>  I've been reading through the documentation for Icon and haven't noticed
>  anything about sending data to a printer.  Is this not a part of the
>  language or have I missed it?

It's not part of the language.  (Icon developed in an environment
where programs just write files and don't talk directly to printers.)

There are some library procedures that assist in writing PostScript,
if a text file does not suffice.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Fri Mar 15 12:21:31 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2FJKl602971
    for icon-group-addresses; Fri, 15 Mar 2002 12:20:47 -0700 (MST)
Message-Id: <[e-mail]>
From: Gregg Townsend <gmt>
Date: Fri, 15 Mar 2002 09:49:37 -0700 (MST)
To: icon-group, [e-mail]
Subject: Re: PostScript
Errors-To: [e-mail]
Status: RO


> There are some library procedures that assist in writing PostScript,
> if a text file does not suffice.

>  From [e-mail] Fri Mar 15 02:02:15 2002
>
>  Can you remind us (me) where they are? ...

Here are a few packages in the Icon program library that help
write PostScript files from Icon.

procs/pscript.icn is for programs that want to write PostScript
directly.  It just writes out a PostScript header to set up the
coordinate system.  See:
   http://www.cs.arizona.edu/icon/library/procs/pscript.htm

gprocs/psrecord.icn is for graphics programs that also want to
create a PostScript version of output.  It emulates many of the
Icon graphics functions, and can be turned on or off.  See:
   http://www.cs.arizona.edu/icon/library/gprocs/psrecord.htm

gprocs/autopost.icn makes it easy to hook up psrecord to an
existing Icon program.  Because psrecord is imperfect, this
works better for some programs than others.
   http://www.cs.arizona.edu/icon/library/gprocs/autopost.htm

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Mon Mar 18 12:59:09 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2IJvss28880
    for icon-group-addresses; Mon, 18 Mar 2002 12:57:54 -0700 (MST)
Message-Id: <[e-mail]>
From: "Boulet, Dan" <[e-mail]>
To: "'IconGroup'" <[e-mail]>
Subject: Calling C functions
Date: Mon, 18 Mar 2002 11:01:12 -0500
Status: RO

I'd be interested to know if anybody has had any success calling C functions
from within Icon.  I operate in a Windows NT environment and I'm using
Borland's C++ compiler (version 5.02).

If someone has a working example, I would appreciate seeing it.

Regards,

Daniel J. Boulet
[e-mail] <mailto:[e-mail]>
Technical Systems Centre - C113-4
[phone]

From icon-group-sender Wed Mar 20 17:08:04 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2L06Oo27062
    for icon-group-addresses; Wed, 20 Mar 2002 17:06:24 -0700 (MST)
Message-Id: <[e-mail]>
From: Bruce Gordon Rennie <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Application error under UNICON on Windows NT4.0
Date: Wed, 20 Mar 2002 13:08:06 +1100
X-Complaints-To: [e-mail]
X-Accept-Language: en
Cache-Post-Path: mango.dcsi.net.au![e-mail]
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

The following code is causing this error

CODE:

procedure main()
local inp, outp, dirl,sdir, cfile

    sdir := "\"e:\\program files\\bigforth\""


    write(chdir())
    chdir(sdir)         <--  error at this point
    write(chdir())
    #dirl := open(sdir)
    #every cfile := !sdir do {
    #    cfile ? (write(move(upto('.'))) & =".fb")
    #}
end


ERROR:

Exception stack overflow(0xc00000fd), Address: 0x00412d85

This error is generated irrespective of the form of the string supplied

variations tried are

"e:/program files/bigforth"
"e:\\program files\\bigforth"
"\"e:\\program files\\bigforth\""


regards
--
Bruce Rennie ( from God's Own Country Downunder )
Disciple of Jesus Christ in Training

The Cross of Jesus Christ - Salvation for all men.

Song of Solomon ( Song of Songs ) - The greatest Love Story Ever
and a story for our times.

Be a GOD Chaser.




From icon-group-sender Thu Mar 28 15:22:17 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g2SMKqI11933
    for icon-group-addresses; Thu, 28 Mar 2002 15:20:52 -0700 (MST)
Message-Id: <[e-mail]>
Date: Wed, 27 Mar 2002 16:58:55 -0700 (MST)
From: Gregg Townsend <gmt>
To: icon-group
Subject: Announcing Icon 9.4.1 for Unix (and now Macintosh)
Errors-To: [e-mail]
Status: RO

Version 9.4.1 of Icon is now available for Unix systems.  This version
addresses several minor portability and installation issues and adds a
facility for using Icon programs as script files.

Icon 9.4.1 can be built and run in a terminal window on an Apple Macintosh
running MacOS X version 10.1.  Icon's graphics facilities are available if
XFree86 is installed.

The Version 9.4.1 library is also available separately for use with Icon
9.3.2 for Windows, which remains current, or with other versions of Icon.

For more information, see
    http://www.cs.arizona.edu/icon/v941

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Mon Apr  1 16:00:34 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g31N0UA20686
    for icon-group-addresses; Mon, 1 Apr 2002 16:00:30 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Icon for DOS?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Date: Thu, 28 Mar 2002 14:52:28 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

While trying to port Icon to use the Cygwin compiler, I couldn't help but
notice how much system-specific code was in there for MS-DOS compilers. At
this point, is there anyone still using Icon under DOS? After all, MS-DOS
and PC-DOS have not been supported for years. DR-DOS is now no longer
supported. The only version of DOS that is actively supported is FreeDOS,
and the only active C/C++ DOS compiler DJGPP, which unfortunately is the
only DOS compiler that Icon does NOT support! Instead, we have macros for
compiling Icon using the Borland 286 or Zortech compiler, development tools
that are very hard to find now.

I think it's time to decide whether Icon for DOS is worth supporting. If we
do want Icon for DOS, we should port it to the DJGPP compiler (it's not
hard, I've done it once before). Whether we do or don't support DOS,
however, we could certainly clean up the code considerably by cutting all
the code specific to dead DOS compilers.





From icon-group-sender Mon Apr  1 16:01:08 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g31N12Y20727
    for icon-group-addresses; Mon, 1 Apr 2002 16:01:02 -0700 (MST)
Message-Id: <[e-mail]>
X-Originating-IP: [208.142.142.82]
From: "brian balote" <[e-mail]>
To: [e-mail]
Date: Fri, 29 Mar 2002 08:56:15 +0000
X-OriginalArrivalTime: 29 Mar 2002 08:56:16.0380 (UTC) FILETIME=[95F2B3C0:01C1D6FF]
Errors-To: [e-mail]
Status: RO

im currently working on a txt editor for screenplay writing.

im having some trouble with icon's file i/o funtionalities.

please send me some working code samples of all open("s1","s2") functions

it would really help my work

thanks alot

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From icon-group-sender Mon Apr  1 16:02:55 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g31N2q620870
    for icon-group-addresses; Mon, 1 Apr 2002 16:02:52 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon for DOS?
Date: 29 Mar 2002 17:57:45 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <M6Go8.8953$[e-mail]>,
Frank J. Lhota <[e-mail]> wrote:
>
> I think it's time to decide whether Icon for DOS is worth supporting. If we
> do want Icon for DOS, we should port it to the DJGPP compiler (it's not
> hard, I've done it once before). Whether we do or don't support DOS,
> however, we could certainly clean up the code considerably by cutting all
> the code specific to dead DOS compilers.

After consultation with Steve Waldo, who built the last set of MS-DOS
binaries, I removed the MS-DOS configurations from Icon 9.4.0 as part
of a large cleanup.  Some more debris has vanished from the new 9.4.1.

However, there *is* still a lot of obsolete code in Icon.  I've
occasionally excised chunks as opportunity permitted, but if I
wasn't sure about something, I generally left it in.

Part of the problem is that I don't know what some of that stuff is,
or whether any remnants of the MS-DOS code might still be useful in
MS Windows, its descendant.  I'd be happy to be enlightened.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Mon Apr  1 16:03:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g31N39620912
    for icon-group-addresses; Mon, 1 Apr 2002 16:03:09 -0700 (MST)
Message-Id: <[e-mail]>
Date: Sat, 30 Mar 2002 18:00:50 -0500 (EST)
From: [e-mail]
To: [e-mail]
Subject: Icon 9.4.1 and Mac OS X
Errors-To: [e-mail]
Status: RO

Folks,

The new Unix Icon doesn't compile under Mac OS X completely
as advertised; I tried compilation on two different systems
with XFree86 installed, and got numerous (ultimately fatal)
messages to the effect that the X11R6 include files couldn't
be found.  Meanwhile, on another system, a member of our Unix
support staff discovered this:

>In config/unix/ppc_macos/Makedefs I had to add -I/usr/X11R6/include.
>Whoever built the package must have had a link in /usr/include to the
>X11 includes.

So with the above change, everything should compile as
advertised.

John Paolillo
SLIS and Informatics
Indiana University


From icon-group-sender Fri Apr  5 11:07:14 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I7CI28097
    for icon-group-addresses; Fri, 5 Apr 2002 11:07:12 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 1 Apr 2002 17:20:51 -0700
From: Clint Jeffery <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Icon for DOS?
Errors-To: [e-mail]
Status: RO


[Gregg comments]
> Part of the problem is that I don't know what some of that stuff is,
> or whether any remnants of the MS-DOS code might still be useful in
> MS Windows, its descendant.  I'd be happy to be enlightened.

The MS Windows configuration definitely does use stuff under #if MSDOS
but does not use DOS-compiler-specific #ifdefs such as for Borland
or Zortech.

The conservatism we have for source code is well-founded, but maybe at
some point what I'd vote for is to (a) make a major purge of compiler
specific code for dead compilers/platforms, and (b) keep a copy of
the old pre-purge source distribution available, in case anyone needs
to use one of the old compilers.

Clint [e-mail]


From icon-group-sender Fri Apr  5 11:06:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I5bk28035
    for icon-group-addresses; Fri, 5 Apr 2002 11:05:37 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 1 Apr 2002 16:33:28 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Icon 9.4.1 and Mac OS X
Errors-To: [e-mail]
Status: RO

>> In config/unix/ppc_macos/Makedefs I had to add -I/usr/X11R6/include.
>> Whoever built the package must have had a link in /usr/include to the
>> X11 includes.

Thanks; I'll make that change for the next edition.

I wonder if that link is made by some of the numerous XFree86/Mac
distributions and not by others.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Fri Apr  5 11:08:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I88I28155
    for icon-group-addresses; Fri, 5 Apr 2002 11:08:08 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 02 Apr 2002 10:46:02 -0500
From: "Steve Graham" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Icon for DOS?
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g32FlC907783
Errors-To: [e-mail]
Status: RO

While I still do write utilites on the DOS version at times, I could easily use the Windows version.

Steve

===

>>> "Frank J. Lhota" <[e-mail]> 03/28/02 08:52AM >>>
While trying to port Icon to use the Cygwin compiler, I couldn't help but
notice how much system-specific code was in there for MS-DOS compilers. At
this point, is there anyone still using Icon under DOS? After all, MS-DOS
and PC-DOS have not been supported for years. DR-DOS is now no longer
supported. The only version of DOS that is actively supported is FreeDOS,
and the only active C/C++ DOS compiler DJGPP, which unfortunately is the
only DOS compiler that Icon does NOT support! Instead, we have macros for
compiling Icon using the Borland 286 or Zortech compiler, development tools
that are very hard to find now.

I think it's time to decide whether Icon for DOS is worth supporting. If we
do want Icon for DOS, we should port it to the DJGPP compiler (it's not
hard, I've done it once before). Whether we do or don't support DOS,
however, we could certainly clean up the code considerably by cutting all
the code specific to dead DOS compilers.







From icon-group-sender Fri Apr  5 11:08:46 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I8hM28188
    for icon-group-addresses; Fri, 5 Apr 2002 11:08:43 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Bridging the CLI and GUI versions
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Date: Wed, 03 Apr 2002 18:49:01 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

When I raised the question of whether anyone is still using the DOS version
of Icon, I got a few replies stating that they still frequently use the
command line interface (CLI) version of Icon. For the record, I use the CLI
version of Icon far more often than the GUI version. Icon is great for
massaging piped data, as its many Icon users can attest.

What is bothersome is that on platforms such as NT, there are separate
facilities (i.e. versions of icont, iconx) for the CLI/GUI versions of Icon.
If we want to resume maintenance of the Icon native compiler from the
current code base, we would probably need to have separate versions of iconc
and the rt library for the CLI and GUI version.

What would be nice is if we could have one version of icont / iconx that
could serve the needs of both CLI and GUI programs. Life would be simpler if
there were one icont that could create Icon applications that uses a CLI, a
GUI, or both. My ideal version of iconx would behave as follows:

- Whether or not iconx is run from a command line, the Icon program can use
the graphics facilities, the CLI, or both.

- When run from a command line, iconx would implement &input, &output, and
&errout using the current console's standard input, standard output and
standard error respectively, including any redirection and piping.

- When run from some place other than a command line, iconx would not create
a console unless the program never performs an I/O operation with one of the
standard files &input, &output, or &errout, and that file is not redirected.
The first time such an I/O operation is performed, a console would be
created (preferably a character console if the OS supports it), and then all
non-redirected standard I/O operations would use this console.

Have any of the Unix versions of Icon accomplished this? Currently, there is
no NT version of Icon that behaves this way: when wiconx is executed from a
command line, it completely ignores the standard handles. I'm looking into
how to create one version of icont / iconx that bridges the CLI and GUI
environments, so if anyone else has looked into this, please share your
experiences.





From icon-group-sender Fri Apr  5 11:08:58 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I8tM28251
    for icon-group-addresses; Fri, 5 Apr 2002 11:08:55 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Icon Analyst back issues now on line
Date: 4 Apr 2002 17:28:06 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

The full set of back issues of the Icon Analyst, all 66 issues
from 1990 - 2001, is now on line in PDF format at:
    http://www.cs.arizona.edu/icon/analyst/ia.htm

The Icon Analyst provided in-depth coverage of Icon with an emphasis
on programming.  It ceased publication in 2001.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Fri Apr  5 11:09:29 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g35I9NU28300
    for icon-group-addresses; Fri, 5 Apr 2002 11:09:23 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Re: Bridging the CLI and GUI versions
Date: 4 Apr 2002 17:50:11 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <x8Iq8.1175$[e-mail]>,
Frank J. Lhota <[e-mail]> wrote:

> ...What would be nice is if we could have one version of icont / iconx that
> could serve the needs of both CLI and GUI programs....
> Have any of the Unix versions of Icon accomplished this?

I can answer for Icon 9.4.1 and its predecessors, the main Unix line:

There's no GUI variant of Icon, although it can be built with graphics
disabled (e.g. for webservers that lack graphics libraries).  The same
icont/iconx are used with both CLI and GUI programs.  Unix Icon has
never contemplated opening a console window for the standard I/O files.
That would be very unexpected in a Unix context.

What you propose as the ideal interface does sound like the "obviously
correct" thing to do in a windows-based environment.  Actually, it's
how I'd expect the C runtime system to act, in which case Icon wouldn't
need any special code itself.  But apparently most C implementations
don't do that.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Mon Apr  8 07:58:01 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38EueY08748
    for icon-group-addresses; Mon, 8 Apr 2002 07:56:40 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Bridging the CLI and GUI versions
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Fri, 05 Apr 2002 19:29:30 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

"Gregg Townsend" <[e-mail]> wrote in message
news:a8isc3$[e-mail]...
> Unix Icon has
> never contemplated opening a console window for the standard I/O files.
> That would be very unexpected in a Unix context.

Perhaps I should have made myself clearer. In my ideal interface, iconx
would open a console window only if:

- the application was NOT started from within a console window, and
- an I/O operation is performed on a non-redirected, standard file.

In these circumstances, the current wiconx creates an ersatz console window
for the standard I/O.

Currently, I don't have access to a Unix platform either at home or at work,
so I'm not sure how Unix Icon handles standard I/O when the application is
started from a non-console environment.

> What you propose as the ideal interface does sound like the "obviously
> correct" thing to do in a windows-based environment.  Actually, it's
> how I'd expect the C runtime system to act, in which case Icon wouldn't
> need any special code itself.  But apparently most C implementations
> don't do that.

Good news: it appears that Cygwin DOES act this way. I wrote a prototype to
see how a Cygwin windows application handles standard I/O from either a . My
prototype passed the test with flying colors. It behaved exactly as my ideal
iconx would.

This was a tremendous surprise, because this is certain not true of MSVC
windows applications. MSVC windows applications seems to sever all ties with
the standard file handles, so this compiler would require two separate tools
for CLI and GUI
development. But there is no need for this with Cygwin, another good reason
to use this compiler for developing Win32 Icon.





From icon-group-sender Mon Apr  8 07:59:53 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38Exog08886
    for icon-group-addresses; Mon, 8 Apr 2002 07:59:50 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Re: Bridging the CLI and GUI versions
Date: 5 Apr 2002 13:05:43 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <uWmr8.1109$[e-mail]>,
Frank J. Lhota <[e-mail]> wrote:

> Currently, I don't have access to a Unix platform either at home or at work,
> so I'm not sure how Unix Icon handles standard I/O when the application is
> started from a non-console environment.

In Unix, it's not unusual for a program to run with standard I/O
connected to "nothing" (/dev/null in Unix terms).  That's a normal
way of indicating that there's no input or that the output should
be silently discarded.  Very few Unix programs make any provision
for "a non-console environment" -- that's a foreign concept. The
Unix implementation can't provide any guidance here for Windows Icon.

> Good news: it appears that Cygwin DOES act this way. I wrote a prototype to
> see how a Cygwin windows application handles standard I/O from either a . My
> prototype passed the test with flying colors. It behaved exactly as my ideal
> iconx would.

And so Icon built with Cygwin would also work that way, we may hope.

One more thing to test:  If a program writes a message to stderr,
and then exits, does the error window disappear before the user
has a chance to read it?

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Mon Apr  8 08:00:06 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38F03A08948
    for icon-group-addresses; Mon, 8 Apr 2002 08:00:03 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Bridging the CLI and GUI versions
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Fri, 05 Apr 2002 21:49:00 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

> One more thing to test:  If a program writes a message to stderr,
> and then exits, does the error window disappear before the user
> has a chance to read it?

Good point. I tried the following program with Cygwin:

    #include <stdio.h>

    int main( void )
    {
        fprintf( stderr, "AHHHH! We're all going to die!\n" );
        return 1;
    }

Run from a command line, this program works great. The user can see the
message, and the error message can be re-directed and piped any way the user
wants to. If this program is executed outside of a console window, such as
from the "Run..." dialog on the Start menu, or by double-clicking the
"panic.exe" icon, the results are much less satisfactory. The Cygwin runtime
allocates a console, displays the message, and then the console disappears
before the user can read it.

Some research will be required to find the best way to fix this. This is not
really a problem for pure CLI applications, since these are bound to be run
from a command line. For GUI applications, we need to delay the termination
of iconx until the user acknowledges the error output. Here is one possible
fix:

- Set a flag when wopen is called;
- In c_exit, display a MessageBox if wopen has ever been called.

It's not ideal, but this fix should plug most holes. I must admit that this
whole venture has left me with a strong feeling of Unix envy.




From icon-group-sender Mon Apr  8 08:00:18 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38F0F208975
    for icon-group-addresses; Mon, 8 Apr 2002 08:00:15 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Re: Bridging the CLI and GUI versions
Date: 6 Apr 2002 21:44:13 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <gZor8.1581$[e-mail]>,
Frank J. Lhota <[e-mail]> wrote:

> Some research will be required to find the best way to fix this. This is not
> really a problem for pure CLI applications, since these are bound to be run
> from a command line...

Don't bet on that.  I support a program that dates from the days of DOS.
Windows users double-click it and interact when a console window pops up.
But if there's an error, the message vanishes as the program exits.

I don't know what a proper general solution would be.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Mon Apr  8 08:00:28 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38F0Qg09005
    for icon-group-addresses; Mon, 8 Apr 2002 08:00:26 -0700 (MST)
Message-Id: <[e-mail]>
Date: Sun, 7 Apr 2002 16:15:50 +0200
From: Marc Espie <[e-mail]>
To: Clint Jeffery <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [Unicon-group] dead compiler #ifdef purge?
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Errors-To: [e-mail]
Status: RO

On Sun, Apr 07, 2002 at 01:26:23AM -0700, Clint Jeffery wrote:
>
> Hi,
>
> This is a question for those who build from the sources.
>
> Is *anyone* using, or planning to use, any of the following compilers/platforms
I don't use any of these.

In my opinion, it's largely past-time to switch to a features-based set
of defines, which is the only reasonable way to do this, long term.


From icon-group-sender Mon Apr  8 08:00:39 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38F0bM09024
    for icon-group-addresses; Mon, 8 Apr 2002 08:00:37 -0700 (MST)
Message-Id: <[e-mail]>
Date: Sun, 7 Apr 2002 01:26:23 -0700
From: Clint Jeffery <[e-mail]>
To: [e-mail], [e-mail]
Subject: dead compiler #ifdef purge?
Errors-To: [e-mail]
Status: RO


Hi,

This is a question for those who build from the sources.

Is *anyone* using, or planning to use, any of the following compilers/platforms
in current or future Icon or Unicon builds?  Most of them refer to dead
compilers/platforms whose #ifdef's are just making the source code more
complicated and less maintainable, so we might as well remove them.  If
your platform of choice does not appear, it is because we suspect it
might still be alive.  If any of these platforms are not dead yet
[obligatory Monty Python reference omitted] please speak up so we don't
delete any useful code!  I am sure we will keep the pre-purge sources
around in case we make any accidents.  And: if you know of another dead
platform I am forgetting, feel free to suggest purging it. :-)

Please post replies to me and to [e-mail]; we probably do not
want to clutter up the lists with this.

Clint [e-mail]

Proposed Dead(?) Ifdefs for Deletion from Current Sources

ATARI_ST
ATTM32
AZTEC_C
BORLAND_286
BORLAND_386
CSET2
HIGHC_386
INTEL_386
LATTICE
OS2
OS2EMX
OS2_32
PresentationManager
PYRAMID
__SASC
SASC
SCCX_MX
SCO_XENIX
TURBO
WATCOM
XENIX_386
ZTC_386


From icon-group-sender Mon Apr  8 08:00:53 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38F0pI09084
    for icon-group-addresses; Mon, 8 Apr 2002 08:00:51 -0700 (MST)
Message-Id: <[e-mail]>
From: "Walter" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon for DOS?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Complaints-To: [e-mail]
Date: Mon, 08 Apr 2002 08:43:03 GMT
To: [e-mail]
Errors-To: [e-mail]
Status: RO


"Frank J. Lhota" <[e-mail]> wrote in message
news:M6Go8.8953$[e-mail]...
> While trying to port Icon to use the Cygwin compiler, I couldn't help but
> notice how much system-specific code was in there for MS-DOS compilers. At
> this point, is there anyone still using Icon under DOS? After all, MS-DOS
> and PC-DOS have not been supported for years. DR-DOS is now no longer
> supported. The only version of DOS that is actively supported is FreeDOS,
> and the only active C/C++ DOS compiler DJGPP, which unfortunately is the
> only DOS compiler that Icon does NOT support! Instead, we have macros for
> compiling Icon using the Borland 286 or Zortech compiler, development
tools
> that are very hard to find now.
> I think it's time to decide whether Icon for DOS is worth supporting. If
we
> do want Icon for DOS, we should port it to the DJGPP compiler (it's not
> hard, I've done it once before). Whether we do or don't support DOS,
> however, we could certainly clean up the code considerably by cutting all
> the code specific to dead DOS compilers.

The Digital Mars C/C++ compiler, free from www.digitalmars.com, actively
supports 16 bit DOS. It should compile most old Zortech code with little to
no modification. -Walter
>
>




From icon-group-sender Mon Apr  8 12:31:14 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g38JUu222536
    for icon-group-addresses; Mon, 8 Apr 2002 12:30:56 -0700 (MST)
Message-Id: <[e-mail]>
From: Steve Wampler <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Analyst back issues now on line
Date: Mon, 08 Apr 2002 10:24:55 -0700
X-Complaints-To: [e-mail]
X-Accept-Language: en
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Gregg Townsend wrote:
>
> The full set of back issues of the Icon Analyst, all 66 issues
> from 1990 - 2001, is now on line in PDF format at:
>     http://www.cs.arizona.edu/icon/analyst/ia.htm
>

That is *very* nice.  Thanks for setting that up!

--
Steve Wampler -- [e-mail]
O sibile, si ergo.  Fortibus es enaro.
Nobile, demis trux.  Demis phulla causan dux.


From icon-group-sender Fri Apr 19 07:55:15 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3JEs4Y29490
    for icon-group-addresses; Fri, 19 Apr 2002 07:54:04 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Chinese Icon
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Fri, 19 Apr 2002 13:00:39 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Speaking of the Icon Analyst, I remember seeing an item in one issue
announcing a Chinese version of Icon developed at the University of Hong
Kong. I would be interested to see that version, for they would have had to
solve the many of the same technical problems involved with developing a
Unicode version of Icon.

Has anyone seen the Chinese version or know where it can be found? I could
not find anything about it on the Hong Kong University web page.





From icon-group-sender Mon Apr 29 08:05:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3TF4Wk08902
    for icon-group-addresses; Mon, 29 Apr 2002 08:04:32 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (James Price)
X-Newsgroups: comp.lang.icon
Subject: Regexes
Date: 27 Apr 2002 01:15:15 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Hi, I'm new to Icon and was wondering if anyone has  written a program that
produces random strings based on regular expressions and put this in the
public domain?

Thanks.


From icon-group-sender Mon Apr 29 16:52:00 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3TNpZo04977
    for icon-group-addresses; Mon, 29 Apr 2002 16:51:35 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Mon, 29 Apr 2002 22:11:10 +0100
Subject: Re: Regexes
Errors-To: [e-mail]
Status: RO

On 27 Apr 2002, at 1:15, James Price wrote:

> Hi, I'm new to Icon and was wondering if anyone has  written a program that
> produces random strings based on regular expressions and put this in the
> public domain?
>

Sorry, I've not heard of this one, but wouldn't it be possible to use
csets to get random characters and then filter them (or pipe them)
through a regular expression 'matcher'. There is one iin the icon
library.

If you are looking seriously at filtering strings in this way, then I
guess you are also looking at writing grammars. For ordinary
language (as opposed to some form of restricted language) there
are a lot of NLP tools about whcih will do this if you are using unix.
Practically nothing worthwhile if you are Windowing.

Try a websearch for TTT if you _really_ want to get heavily into this!
It will do the most complicated regex matching you would ever wish to do.
Steep learning curve, though. Probably good for the soul, though.
Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Tue Apr 30 07:59:32 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3UExAk22305
    for icon-group-addresses; Tue, 30 Apr 2002 07:59:10 -0700 (MST)
Message-Id: <[e-mail]>
Date: 30 Apr 2002  12:40:48 BST
From: [e-mail]
Subject: Editors in Icon
To: [e-mail]
Organisation:  Edinburgh Parallel Computing Centre
Errors-To: [e-mail]
Status: RO

Does anyone know of the existence of a windows based editor in Icon?
I'm sure I remember seeing reference to one a year or so back but can find
no hint of it in the IPL.

Thanks.

Roger Hare


From icon-group-sender Tue Apr 30 13:04:00 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3UK2xU06495
    for icon-group-addresses; Tue, 30 Apr 2002 13:02:59 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 30 Apr 2002 09:22:41 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Editors in Icon
Errors-To: [e-mail]
Status: RO

>  From: [e-mail]
>
>  Does anyone know of the existence of a windows based editor in Icon?
>  I'm sure I remember seeing reference to one a year or so back but can find
>  no hint of it in the IPL.

Unfortunately, the automatic IPL indexer doesn't handle the packs
and gpacks.  There's an editor in  ipl/gpacks/ged.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Tue Apr 30 13:09:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3UK9WI06758
    for icon-group-addresses; Tue, 30 Apr 2002 13:09:32 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 30 Apr 2002 10:41:55 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Editors in Icon
Errors-To: [e-mail]
Status: RO

[Roger asks about windows editors in Icon]

Hi Roger,

As several people will probably report, the gpacks area of the Icon Program
Library has Bob Alexander's GED, a full featured mac-like text editor.

The Windows native facilities also include access to the Windows
standard texteditor widget; it is used for the Windows IDE.

Clint [e-mail]


From icon-group-sender Tue Apr 30 13:10:17 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3UKAFg06832
    for icon-group-addresses; Tue, 30 Apr 2002 13:10:15 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 30 Apr 2002 10:07:50 -0700
From: Ralph Griswold <[e-mail]>
To: [e-mail]
Subject: Going-out-of-Business Sale
Errors-To: [e-mail]
Status: RO


No, the Icon Project is not going away. But its "store", which
sells books and other documentation related to Icon, will cease
operation on June 30, 2002.

Between now and that time, we're holding a half-price sale -- 50%
off on all items in stock.

To see what's available, look at

    http://www.cs.arizona.edu/icon/orderi.htm

When you place an order, simply note the 50% discount.

Note:  Shipping to addresses in the United States, Canada, and Mexico
is free.  The discount does not apply to shipping charges to other
countries.

Stock of some items is limited, so if you are interested, do not
delay.

Please direct any questions to

    [e-mail]


From icon-group-sender Tue Apr 30 16:45:36 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g3UNjMY15803
    for icon-group-addresses; Tue, 30 Apr 2002 16:45:22 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 30 Apr 2002 16:16:35 -0400 (EDT)
From: Taybin Rutkin <[e-mail]>
X-Sender: [e-mail]
To: [e-mail]
cc: [e-mail]
Subject: Re: Editors in Icon
Errors-To: [e-mail]
Status: RO

On Tue, 30 Apr 2002, Clint Jeffery wrote:

> The Windows native facilities also include access to the Windows
> standard texteditor widget; it is used for the Windows IDE.

Heh, there's probably an emacs or vi port to windows.  They do Icon
highlighting pretty nicely.  Probably not what you're looking for
though.

Taybin



From icon-group-sender Wed May  1 07:55:35 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g41EtHc18923
    for icon-group-addresses; Wed, 1 May 2002 07:55:17 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Eka Laiman)
Subject: Re: Editors in Icon
To: [e-mail]
Date: Tue, 30 Apr 2002 17:23:24 -0700 (PDT)
Errors-To: [e-mail]
Status: RO

Taybin Rutkin wrote:
> Heh, there's probably an emacs or vi port to windows.  They do Icon
> highlighting pretty nicely.  Probably not what you're looking for
> though.

I was (and still am) a heavy emacs user, but for the past few years I
have been using vim (vi improved) for most of my editing both in
work-station (UNIX platform) as well as on PC.

Both emacs (version 20) and vim (version 6.0) are available in binary
forms for PC (Windows). Emacs has icon-mode which understands the
syntax of icon. Vim has "color syntax" for many languages, icon is one
of them.

-eka-



From icon-group-sender Wed May  1 07:55:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g41Etnw18961
    for icon-group-addresses; Wed, 1 May 2002 07:55:49 -0700 (MST)
Message-Id: <[e-mail]>
Date: Wed, 1 May 2002 09:39:22 +0100 (BST)
From: Hugh Sasse Staff Elec Eng <[e-mail]>
X-X-Sender: hgs@neelix
To: Taybin Rutkin <[e-mail]>
cc: [e-mail], <[e-mail]>
Subject: Re: Editors in Icon
Errors-To: [e-mail]
Status: RO

On Tue, 30 Apr 2002, Taybin Rutkin wrote:

> On Tue, 30 Apr 2002, Clint Jeffery wrote:
>
> > The Windows native facilities also include access to the Windows
> > standard texteditor widget; it is used for the Windows IDE.
>
> Heh, there's probably an emacs or vi port to windows.  They do Icon
> highlighting pretty nicely.  Probably not what you're looking for

There's vim:
/usr/local/share/vim/vim61/syntax/icon.vim
(syntax highlighting file for icon)
See http://www.vim.org/ , http://vim.sourceforge.net/

> though.
>
> Taybin
>
        Hugh
>
>



From icon-group-sender Wed May  1 16:26:16 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g41NP9o12427
    for icon-group-addresses; Wed, 1 May 2002 16:25:09 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Wed, 1 May 2002 21:45:14 +0100
Subject: Re: Editors in Icon
Errors-To: [e-mail]
Status: RO

On 30 Apr 2002, at 17:23, Eka Laiman wrote:

> Emacs has icon-mode which understands the
> syntax of icon. Vim has "color syntax" for many languages, icon is one
> of them.
.. so does emacs (so I suppose xemacs must, too). Looks pretty
with icon, but perl produces even more colours and fonts.
Chris Korycinski

===========================================================
Please send attachments only as plain text or .rtf files


From icon-group-sender Fri May  3 07:48:25 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g43EkQY03640
    for icon-group-addresses; Fri, 3 May 2002 07:46:26 -0700 (MST)
Message-Id: <[e-mail]>
From: Jay Rinkel <[e-mail]>
X-Accept-Language: en
X-Newsgroups: comp.lang.icon
Subject: Re: 100% Cpu usage
X-Complaints-To: [e-mail]
X-Abuse-Info: Please be sure to forward a copy of ALL headers
X-Abuse-Info: Otherwise we will be unable to process your complaint properly.
Date: Thu, 02 May 2002 20:02:04 -0500
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Maurizio Ferreira wrote:

> I've made a simple program in Unicon using IVIB
> It has only a single button on the main a dialog, with associated an
> empty procedure.
> As as I start the application, (both from the environment than from
> explorer) , when the mouse pointer gets over the application window
> I get 100% cpu usage.
> Even  IVIB itsef uses 100% cpu power.
> Any suggestion ?
> (i'm using Window Unicon vers 10.0 beta, 18 jan 2001
> and I'm woking on Windows 2000 prof)
> Regards.

I have seen this problem before with interpreted languages under Windows
where the program will want to hog up 100% of the CPU.  I am fairly sure
that there is little you can do in your Icon / Unicon source code to fix
this problem.  But is 100% CPU bad?  If other applications are running,
they WILL also get CPU time.   They just will run more slowly.  Also you
mentioned that this occurs when the mouse pointer is over the
application window.  Maybe just avoid putting your mouse over the window
when you aren't using it at the moment.  You could contact the
maintainers of Unicon and see if they have observed this behavior and if
they have any remedies.

Anyway, my guess is there is little you can do to fix this problem
without digging into the source code of Unicon itself and even then, not
sure of that.

Jay Rinkel




From icon-group-sender Mon May  6 09:44:04 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g46GdUE00875
    for icon-group-addresses; Mon, 6 May 2002 09:39:30 -0700 (MST)
Message-Id: <[e-mail]>
From: David Harrison <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: What is the origin of the name "Icon"?
Date: Sun, 05 May 2002 08:50:32 -0700
User-Agent: Thoth/1.5.2 (Carbon/OS X)
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO


I am always amused when I see postings to this newsgroup from those
looking for graphic icons.  But now it has me thinking: does anyone know
why Griswold chose the name "Icon" for the language?


From icon-group-sender Mon May  6 09:47:23 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g46GidQ01060
    for icon-group-addresses; Mon, 6 May 2002 09:44:39 -0700 (MST)
Message-Id: <[e-mail]>
X-Newsreader: knews 1.0b.1
From: [e-mail] (Robby)
Subject: Re: What is the origin of the name "Icon"?
X-Newsgroups: comp.lang.icon
Date: Mon, 06 May 2002 11:35:53 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <[e-mail]>,
    David Harrison <[e-mail]> writes:
>
> I am always amused when I see postings to this newsgroup from those
> looking for graphic icons.  But now it has me thinking: does anyone know
> why Griswold chose the name "Icon" for the language?

All typos are mine.

>From "History of the Icon Programming Language" in History of
Programming Languages II, edited by Thomas J. Bergin, Jr. and Richard
G. Gibson, Jr., ACM Press, ISBN 0-201-89502-1 (Page 600):

12.1.2 The Name

"SNOBOL5" as the first name used for the language that was to become
Icon. One issue in the choice of name was the degree of connection it
would imply with the SNOBOL languages. "Product Identification" with
the SNOBOL languages was viewed as giving the new language credibility
and visibility, but it had the disadvantage of looking backward
instead of forward. More significantly, the use of "SNOBOL" in the
name would be misleading if the language turned out to be (as it did)
very different from the SNOBOL languages.

So a new name was needed. Dave Hanson suggested "s" --- a homage to
"C" with its minimalistic one-character name, but in lowercase,
reflecting the distaste for computer-generated text that, at the time,
still was frequently printed in all uppercase. As an abstraction from
"SNOBOL5" and "SL5", "s" made some sense without drawing too close a
connection between the old languages and the new one. But "s" wasn't a
happy choice for several reasons, not least of which was its
typographical difficulties in documentation (which forced the awkward
quoting here).

Over a period of months, the name "s" was disparaged and sometimes
ridiculed ("sssssssss"). Other names were suggested ("irving", "bard",
and "TL" ("The Language")), but nothing stuck until Madge and Ralph
Griswold suggested "icon" (then with the initial lowercase).

The name "icon" is not an acronym, nor was any particular meaning
attached to it, although the word "iconoclast" was immediately offered
as describing the flavor of the new language.

This choice of name was made before Xerox started to use it for little
screen images. It was only later that confusion arose between "Icon,
the programming language" and screen icons. By then, it was too late.
It didn't help that the programming language significantly predated
the usage that is so common now.

Although an occasional person has mistaken Icon as a programming
language for manipulating screen images, the confusion has been less
than might be suspected and has never been a serious problem. Perhaps
this is because so many company and product names now include the
substring "icon".

End of quote

Robby



From icon-group-sender Mon May  6 09:54:34 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g46GpnI01376
    for icon-group-addresses; Mon, 6 May 2002 09:51:49 -0700 (MST)
Message-Id: <[e-mail]>
From: "Shmuel (Seymour J.) Metz" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: What is the origin of the name "Icon"?
Date: Mon, 06 May 2002 11:53:27 -0400
Mail-Copies-To: nobody
X-Cise: "Tony Schliesser" <[e-mail]>
X-CompuServe-Customer: Yes
X-Coriate: [e-mail]
X-Ecrate: Bob Germer <[e-mail]>
X-Punge: Micro$oft
X-Sanguinate: [e-mail]
X-Terminate: SPA(GIS)
X-Tinguish: Mark Griffith <[e-mail]>
X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In <tUtB8.23245$[e-mail]>, on 05/06/2002
   at 11:35 AM, [e-mail] (Robby) said:

>From "History of the Icon Programming Language" in History of
>Programming Languages II, edited by Thomas J. Bergin, Jr. and Richard
>G. Gibson, Jr., ACM Press, ISBN 0-201-89502-1 (Page 600):

The author of that quote seems to believe that "SL/5" and "Icon" are
two names for the same language. In fact, SL/5 was very different.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to [e-mail]



From icon-group-sender Tue May  7 08:01:56 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g47F1Hk06994
    for icon-group-addresses; Tue, 7 May 2002 08:01:17 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 7 May 2002 16:10:28 +1200 (NZST)
From: "Richard A. O'Keefe" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: What is the origin of the name "Icon"?
Errors-To: [e-mail]
Status: RO

[e-mail] (Robby) quoted from HOPL II:
    So a new name was needed. Dave Hanson suggested "s" --- a homage to
    "C" with its minimalistic one-character name, but in lowercase,
    reflecting the distaste for computer-generated text that, at the time,
    still was frequently printed in all uppercase. As an abstraction from
    "SNOBOL5" and "SL5", "s" made some sense without drawing too close a
    connection between the old languages and the new one. But "s" wasn't a
    happy choice for several reasons, not least of which was its
    typographical difficulties in documentation (which forced the awkward
    quoting here).

Not that long afterwards, AT&T produced a statistics language called S
(upper-case S).  Just imagine the confusion if people had used "s" to
process data for analysis by "S". (:-)


From icon-group-sender Thu May  9 13:15:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g49KEcE20037
    for icon-group-addresses; Thu, 9 May 2002 13:14:38 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Dead compilers
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Thu, 09 May 2002 15:04:16 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

I have just completed a port of Icon to the CYGWIN compiler for NT. During
this effort, I noticed that there is a lot of code in there for dead MSDOS
compilers. This code is generally within "#if ... #endif" blocks. The
following preprocessor symbols are for compilers that I am fairly certain
are no longer in use:

    BORLAND_286
    HIGHC_386
    INTEL_386
    SCCX_MX
    TURBO
    WATCOM
    ZTC_386

I assume that the code for the BORLAND_386 symbol is useful for the current
Borland compiler. Can anyone here confirm whether this is the case?

Also, I believe that the DosFncs facility, permitting INT 21h calls from
Icon programs, can be officially retired. I say this with a tinge of
sadness, for I have found the DOS functions to be quite useful in the past.
The DosFncs interface, however, has been problematic for a while. Even
before the demise of DOS / Win 3.x, this facility was plagued with issues of
addressing modes: real versus 286 protected versus 386 protected. Now in the
current NT / XP environment, the C compilers no longer support the int86x
function.

I am not certain about which compilers are still available for the AMIGA or
OS2, or whether the ArmFncs are still in use. All in all, it may be possible
to do a major source code clean-up at some time.




From icon-group-sender Fri May 10 08:33:06 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g4AFWLA03449
    for icon-group-addresses; Fri, 10 May 2002 08:32:21 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 09 May 2002 19:37:13 -0700
From: Anthony Hewitt <[e-mail]>
X-Accept-Language: en
To: [e-mail]
Subject: Dead compilers
Errors-To: [e-mail]
Status: RO

Winicon is an excellent GUI environment for creating programs but I
often use Icon under Windows NT or 2000  to make filters which I add to
the standard Cygwin Linux arsenal. These I string together in a DOS or
bash shell. The Winicon interface doesn't let me execute in this
antiquated WYTIWYG mode so, unless the source is tiny, I edit in emacs
and compile in the shell. I don't see any reason the Winicon compiler
shouldn't work fine for this, but I've seen it create zombie processes
under Windows 2000 that have to be killed by the task mangler (I swear
they survive a reboot).

So here I am, using the DOS Icon compiler under NT4. This may seem
perversely atavistic, but I'd be sorry to see it disappear.
--
Anthony V. Hewitt        [e-mail]
===============================================
not -------------------------- (invert failure)
not expr produces the null value if expr fails,
    but fails if expr succeeds




From icon-group-sender Sat May 18 17:15:27 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g4J0Doq08897
    for icon-group-addresses; Sat, 18 May 2002 17:13:50 -0700 (MST)
Message-Id: <[e-mail]>
From: Christopher Browne <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Printers?
Date: Sat, 11 May 2002 10:54:25 -0400
X-Orig-Path: chvatal.cbbrowne.com
X-Home-Page: http://www.cbbrowne.com/info/
X-Emacs-Acronym: Every Moron Assumes CCA is Superior
Microsoft: Making the world a better place... for Microsoft.
X-Shopping-List:  (1) Neurotic bread (2) Insignificant absorbers (3) Hydroelectric hiders
X-Uboat-Death-Message: ANNOYED BY ATOMIC BOMB. TORPEDOS. SINKING. U-77.
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Common Lisp, i386-debian-linux)
Cancel-Lock: sha1:HfQ6cdBCZlmu0Ymaao4/2plYAfc=
To: [e-mail]
Errors-To: [e-mail]
Status: RO

rkstuart <[e-mail]> wrote:
> I've been reading through the documentation for Icon and haven't
> noticed anything about sending data to a printer.  Is this not a part
> of the language or have I missed it?

Printing is a spectacularly platform-dependent matter which tends to
take over the architecture of applications that are used to print
things.

Apparently it is considered preferable to leave that issue for
platform-specific tools that you might use alongside Icon...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.cbbrowne.com/info/printing.html
"I once went  to a shrink.  He  told me to speak freely.   I did.  The
damn fool tried to charge me $90 an hour."
-- [e-mail] (Jim Moore Jr)


From icon-group-sender Sat May 18 17:15:42 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g4J0Fdx09033
    for icon-group-addresses; Sat, 18 May 2002 17:15:39 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 14 May 2002 19:20:04 +0200
From: =?iso-8859-1?Q?antis=E8ptic?= <[e-mail]>
X-Accept-Language: ca,en,de
To: [e-mail]
Subject: PDF
Errors-To: [e-mail]
Status: RO

Hi there!

Has anybody written a library to manipulate pdf files in Icon? It would
be nice to have one.



From icon-group-sender Mon Jun 10 13:17:04 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5AKFbN02903
    for icon-group-addresses; Mon, 10 Jun 2002 13:15:37 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: VMS and Wildcards
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Mon, 10 Jun 2002 13:53:28 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

If you're a VMS programmer, I would invite you to take a look at the Icon
source file "src/h/filepat.h". This file defines typedefs and macros for
finding matches to a filename with wildcards for various systems. I'm almost
positive that one could implement this wildcard matching facility in VMS,
using LIB$FIND_FILE / LIB$FIND_FILE_END. I would try this out myself, but
unfortunately I do not currently have access to a VMS platform. I therefore
invite the VMS programmers in this NG to give this a shot.




From icon-group-sender Wed Jun 12 08:10:36 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5CF9Kg23733
    for icon-group-addresses; Wed, 12 Jun 2002 08:09:20 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 11 Jun 2002 23:01:11 -0500 (CDT)
From: John Paolillo <[e-mail]>
To: [e-mail], [e-mail]
Subject: Jcon
Errors-To: [e-mail]
Status: RO

Dear Iconographers,

I am having some difficulties getting Jcon configured correctly.
The installation seems to be correct: things compile and link
okay, programs run etc, but programs that use the IPL (e.g.
anything with a "link graphics" directive) cannot seem to find
the appropriate files to link (I get the error message: cannot
find "graphics" for linking).

This is in spite of the fact that icont is able to find those same
files, and that other programs apparently using graphical capabilities
(e.g. fonts, resize, gpxmisc) link and run just fine. Also, the
graphics facilities work just fine under X-Windows (i.e. no problem
finding the IPL).

Can anyone suggest what the problem might be?  My installation is
Icon 9.4.1 ppc_macos configured for X-windows. Jcon is version 2.1.


Thanks iin advance for any help

John Paolillo
SLIS, Indiana University


From icon-group-sender Wed Jun 12 08:19:16 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5CFJ8Z24276
    for icon-group-addresses; Wed, 12 Jun 2002 08:19:08 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Mark Kot)
X-Newsgroups: comp.lang.icon
Subject: String matching
Date: 11 Jun 2002 18:17:02 GMT
X-Complaints-To: [e-mail]
User-Agent: slrn/0.9.5.7 (UNIX)
To: [e-mail]
Errors-To: [e-mail]
Status: RO


What string-matching algorithm(s) does Icon use ?


From icon-group-sender Wed Jun 12 08:20:00 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5CFJv024305
    for icon-group-addresses; Wed, 12 Jun 2002 08:19:57 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: String matching
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Tue, 11 Jun 2002 19:35:17 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Are you asking about how string matching functions, such as match and find,
is implemented in the Icon runtime? Currently, the implementation is rather
straightforward.




From icon-group-sender Wed Jun 12 12:27:08 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5CJQst02550
    for icon-group-addresses; Wed, 12 Jun 2002 12:26:54 -0700 (MST)
Message-Id: <[e-mail]>
Date: Wed, 12 Jun 2002 10:30:19 -0700 (PDT)
From: Mark Kot <[e-mail]>
Subject: Re: String matching
To: [e-mail]
Cc: [e-mail]
Errors-To: [e-mail]
Status: RO


>From: "Frank J. Lhota" <[e-mail]>
>X-Newsgroups: comp.lang.icon
>Subject: Re: String matching
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
>Date: Tue, 11 Jun 2002 19:35:17 GMT
>X-Complaints-To: [e-mail]
>To: [e-mail]
>
>Are you asking about how string matching functions, such as match and find,
>is implemented in the Icon runtime? Currently, the implementation is rather
>straightforward.
>
>
>

Dear Frank,

    Yes, that's exactly the question.

    I've been seeing a number of new works on string matching
and searching algorithms (e.g., Navarro, G. and Raffinot, M. 2002.
Flexible Pattern Matching in Strings:  Practical On-Line Search
Algorithms for Texts and Biological Sequences.  Cambridge University
Press, Cambridge).  These books discuss traditional algorithms such
as Boyer-Moore, but also some new approaches.  That got me to wondering
how find is actually implemented and which algorithm is being
used.  (There would seem to be less need for extreme efficiency for
match.)

    There's no pressing need on this one.  I was mostly
just curious.

                        Best wishes,

                        Mark





From icon-group-sender Thu Jun 13 08:40:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5DFdk025544
    for icon-group-addresses; Thu, 13 Jun 2002 08:39:46 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 13 Jun 2002 02:17:43 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail]
Subject: spell checker, anyone?
Errors-To: [e-mail]
Status: RO


Hi, does anyone have a spell checker written in or accessible from Icon?
I don't seem to see one in the IPL... any and all suggestions will be
greatfully received!

Cheers,
Clint [e-mail]


From icon-group-sender Fri Jun 14 17:09:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5F08vZ16598
    for icon-group-addresses; Fri, 14 Jun 2002 17:08:57 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 14 Jun 2002 13:32:07 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Jcon
Errors-To: [e-mail]
Status: RO

>  From: John Paolillo <[e-mail]>
>
>  I am having some difficulties getting Jcon configured correctly.
>  The installation seems to be correct: things compile and link
>  okay, programs run etc, but programs that use the IPL (e.g.
>  anything with a "link graphics" directive) cannot seem to find

The Icon program library is not bundled with the Jcon package.
You can download precompiled Jcon binaries from the library page
   http://www.cs.arizona.edu/icon/library/

After unpacking the tar file you'll need to set the IPATH environment
variable, and then Jcon should work.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Fri Jun 14 17:11:09 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5F0B6i16709
    for icon-group-addresses; Fri, 14 Jun 2002 17:11:06 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 14 Jun 2002 18:10:31 -0500
Subject: Re: Jcon
Cc: [e-mail], [e-mail]
To: Gregg Townsend <[e-mail]>
From: John Paolillo <[e-mail]>
Errors-To: [e-mail]
Status: RO


On Friday, June 14, 2002, at 03:32  PM, Gregg Townsend wrote:
> The Icon program library is not bundled with the Jcon package.
> You can download precompiled Jcon binaries from the library page
>    http://www.cs.arizona.edu/icon/library/
>
> After unpacking the tar file you'll need to set the IPATH environment
> variable, and then Jcon should work.

This took care of it. In fact it was what I was trying to do,
although I didn't realize that I needed another version
of the library.

BTW, although I know Jcon is "old news", I hadn't managed to
use it before, and just running through the tests, I have to say
I'm quite impressed.

Thanks,

John Paolillo
SLIS and Informatics
Indiana University



From icon-group-sender Fri Jun 21 08:01:24 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g5LExWk23674
    for icon-group-addresses; Fri, 21 Jun 2002 07:59:33 -0700 (MST)
Message-Id: <[e-mail]>
From: Bruce Gordon Rennie <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: After location of data file primes.lst
Date: Fri, 21 Jun 2002 10:32:18 +1000
X-Complaints-To: [e-mail]
X-Accept-Language: en
Cache-Post-Path: mango.dcsi.net.au![e-mail]
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

To all,

Greetings from the land down under.

I'm looking for the location of the data file primes.lst - which I believe used
to be in the IPL. But the copies I have don't have it.

regards
--
Bruce Rennie ( from God's Own Country Downunder )
Disciple of Jesus Christ in Training

The Cross of Jesus Christ - Salvation for all men.

Song of Solomon ( Song of Songs ) - The greatest Love Story Ever
and a story for our times.

Be a GOD Chaser.


From icon-group-sender Mon Jul  1 16:28:55 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g61NRko29081
    for icon-group-addresses; Mon, 1 Jul 2002 16:27:46 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 1 Jul 2002 15:23:17 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail], [e-mail]
Subject: Icon Books
Errors-To: [e-mail]
Status: RO


Hello,

A substantial quantity of Icon and Unicon books are now available at
http://www.zianet.com/jeffery/books/ including *free* Icon books you can get
for research, teaching, or evangelism.  On-line ordering via paypal should
be up, with any luck, by sometime Tuesday 7/2/2002.

Cheers,
Clint [e-mail]


From icon-group-sender Thu Jul  4 13:45:38 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g64KiLA21316
    for icon-group-addresses; Thu, 4 Jul 2002 13:44:21 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: :list
Date: Thu, 4 Jul 2002 18:36:33 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO


I'm wondering how to create a list with numbers 3 to 640.  The following works
fine:

num := list ( 638 )
every on := 3 to 640 do
num[on - 2] := on

but isn't there a simpler way?  I've tried this:

num := [ 3, 4, 5, ... 638, 639, 640 ]

or this:

num := [ 3, 4, ..., 640 ]

but neither work. Thanks for any suggestions.


From icon-group-sender Thu Jul  4 13:45:57 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g64Kjqw21501
    for icon-group-addresses; Thu, 4 Jul 2002 13:45:52 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Jesse Tov)
X-Newsgroups: comp.lang.icon
Subject: Re: :list
Date: 4 Jul 2002 19:58:28 GMT
User-Agent: slrn/0.9.6.2 (Linux)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Inquit ernobe <[e-mail]>:
>num := list ( 638 )
>every on := 3 to 640 do
>num[on - 2] := on

how about:
    num := list( )
    every put(num, 3 to 640)

hth,
Jesse
--
"A hungry man is not a free man."         --Adlai Stevenson


From icon-group-sender Fri Jul  5 12:34:09 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g65JXds23263
    for icon-group-addresses; Fri, 5 Jul 2002 12:33:39 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Eka Laiman)
Subject: Re: :list
To: [e-mail] (ernobe)
Date: Fri, 5 Jul 2002 08:57:05 -0700 (PDT)
Cc: [e-mail]
Errors-To: [e-mail]
Status: RO

> I'm wondering how to create a list with numbers 3 to 640.  The following works
> fine:
>
> num := list ( 638 )
> every on := 3 to 640 do
> num[on - 2] := on
>
> but isn't there a simpler way?  I've tried this:

I think a simpler way would be:

    num := []
    every i := 3 to 640 do
    put(num, i);

-eka-


From icon-group-sender Thu Jul 11 12:33:13 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6BJVks10073
    for icon-group-addresses; Thu, 11 Jul 2002 12:31:46 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: XML Parser
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Thu, 11 Jul 2002 16:06:35 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Is there an XML parser written in Icon? It sounds like it could be
challenging but fun project.




From icon-group-sender Fri Jul 12 08:04:26 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6CF3lE00087
    for icon-group-addresses; Fri, 12 Jul 2002 08:03:47 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: XML Parser
Date: Fri, 12 Jul 2002 02:54:19 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <f2iX8.10129$[e-mail]>,
[e-mail] says...
> Is there an XML parser written in Icon? It sounds like it could be
> challenging but fun project.
>
>
>
Who would consider such a parser to be of value?  I'm not asking in terms of
monetary value, I'm just curious to know, for the sake of doing something
useful in Icon, if it could be used instead of XML.  That sounds like a real
challenge.. not that it couldn't be fun, though.


From icon-group-sender Fri Jul 12 12:30:29 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6CJU8626373
    for icon-group-addresses; Fri, 12 Jul 2002 12:30:08 -0700 (MST)
Message-Id: <[e-mail]>
X-Originating-IP: [63.99.124.30]
From: "Ray Pereda" <[e-mail]>
To: [e-mail]
Subject: Re: XML Parser
Date: Fri, 12 Jul 2002 10:04:45 -0700
X-OriginalArrivalTime: 12 Jul 2002 17:04:45.0413 (UTC) FILETIME=[38DDF950:01C229C6]
Errors-To: [e-mail]
Status: RO

Python and Perl have used Jim Clark's expat SAX parser.  I've used expat
extensively.  It is small, fast, and pretty.  Other than a bunch of Unicode
crap, it the code is readable.  I think a SAX interface in Icon would be
very useful.  XML is basically three things:
1. structured -- it uses tags
2. well-formed -- the tags are properly nested
3. text -- works in an editor

Icon kicks butt on text.  With a SAX interface, numbers 1 and 2, are
leveraged within Icon.

-Ray


>From: "Frank J. Lhota" <[e-mail]>
>To: [e-mail]
>Subject: XML Parser
>Date: Thu, 11 Jul 2002 16:06:35 GMT
>
>Is there an XML parser written in Icon? It sounds like it could be
>challenging but fun project.




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From icon-group-sender Mon Jul 15 07:57:09 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6FEtp214476
    for icon-group-addresses; Mon, 15 Jul 2002 07:55:52 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Sun, 14 Jul 2002 00:30:59 +0100
Subject: Re: XML Parser
Content-description: Mail message body
Errors-To: [e-mail]
Status: RO

On 12 Jul 2002 at 2:54, ernobe wrote:

> Who would consider such a parser to be of value?  I'm not asking in
> terms of monetary value, I'm just curious to know.

...er me, for one. Virtually all the work we are doing in the
language technology group at Edinburgh Uni. is on text which has been
converted to xml. Having an icon version would make it far easier to
adapt (and even understand) as I  don't know java.



Chris

===========================================================
Please send attachments only as plain text or .rtf files



From icon-group-sender Tue Jul 16 07:09:38 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6GE95o13847
    for icon-group-addresses; Tue, 16 Jul 2002 07:09:05 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 16 Jul 2002 13:23:55 +1200 (NZST)
From: "Richard A. O'Keefe" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: XML Parser
Errors-To: [e-mail]
Status: RO

"Chris Korycinski" <[e-mail]> wrote:
    > Who would consider such a parser to be of value?  I'm not asking in
    > terms of monetary value, I'm just curious to know.

    ...er me, for one. Virtually all the work we are doing in the
    language technology group at Edinburgh Uni. is on text which has been
    converted to xml. Having an icon version would make it far easier to
    adapt (and even understand) as I  don't know java.

Edinburgh have a fine XML parser of their own.  Unlike expat, it actually
understands *all* of XML 1.0.  It can spit out ESIS.  Now it isn't very
hard to write an ESIS reader, I've done it in several languages.
To a first approximation,
    <ESIS> ::= <element> [<correct>?]
    <element> ::= <attribute>* <begin> <content>* <end>
    <content> ::= <element> | <data>
    <attribute> ::= 'A'<name>' '<type>[' '<value>]'\n'
    A value is present unless the <type> is IMPLICIT
    <begin> ::= '('<name>'\n'
    <end> ::= ')'<name>'\n'
    <text> ::= '-'<value>'\n'
    <value> ::= (<character> | <escape>)*
    <character> ::= anything except newline or \
    <escape> ::= '\n' or '\ooo' (3 octal digits) or '\uxxxx' (4 hex digits)
        or '\#ddddd;' (any number of decimal digits)
    <correct> ::= 'C\n' (omitted if validation failed)

There's more to it than that, but for many purposes, not _much_ more.
Most SGML and many XML parsers can emit ESIS (nsgmls, which can handle
XML, sgml (comes with SWI Prolog), some in various functional languages,
and the Edinburgh LTG's parser _certainly_ can).  For those that don't,
it's usually easy to plug in an ESIS writer.

In fact, SAX is nothing more than a procedural interface to ESIS.
(Or ESIS is nothing more than a textual representation of a SAX
event stream, take your pick.)

So running the XML parser as a separate process, parsing its ESIS output
stream in Icon, and building whatever data structure you want in Icon,
should be pretty easy.



From icon-group-sender Thu Jul 18 16:39:31 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6INaOk07218
    for icon-group-addresses; Thu, 18 Jul 2002 16:36:24 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 18 Jul 2002 15:33:26 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail]
Subject: Icon pretty printer
Errors-To: [e-mail]
Status: RO


Hi,

Does anyone have a pretty printer for Icon lying about?
I didn't see one in a quick scan of the IPL, and before I
go reinvent the wheel I thought I should see if someone
has one they are willing to share.

Clint [e-mail]


From icon-group-sender Sun Jul 21 17:12:09 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6M0AhU28959
    for icon-group-addresses; Sun, 21 Jul 2002 17:10:43 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 19 Jul 2002 08:45:21 -0400
From: Wendell Turner <[e-mail]>
X-Accept-Language: en
To: [e-mail]
Subject: Re: Icon pretty printer
Errors-To: [e-mail]
Status: RO


> Does anyone have a pretty printer for Icon lying about?
> I didn't see one in a quick scan of the IPL, and before I
> go reinvent the wheel I thought I should see if someone
> has one they are willing to share.

Yes.  I am using a slightly older version of enscript (1.6.1),
and  hacked one of the language rules to get something working
for Icon.

'enscript' is a GNU utility that will print programs on a
Postscript printer.  With the -E option it will pretty-print
source code.  Here are the necessary definitions to make it
pretty-print Icon programs.

1) get enscript 1.6.1 (not the latest, I think the definition
format file changed) from
  http://people.ssh.com/mtr/genscript/
and install it.

2) Edit the config file

   vim /usr/local/share/enscript/enscript.st

and add in the namerules section a line for the Icon
extension similar to:

  namerules
  {
     ...
     /\.icn$/     icon;
     ...
  }

And add somewhere in the file the Icon formatting
rules shown below.  It works for me.

Wendell Turner

--------------- cut here -----------------

/**
 * Name: Icon
 * Description: Icon programming language.
 * Author: Wendell Turner <[e-mail]>
 */

state icon
{
  BEGIN {
    header ();
  }
  END {
    trailer ();
  }

  /* Comments. */
  /#/ {
    comment_face (true);
    language_print ($0);
    call (eat_one_line);
    comment_face (false);
  }

  /* String constants. */
  /\"/ {
    string_face (true);
    language_print ($0);
    call (c_string);
    string_face (false);
  }

  /* Cset constants. */
  /\'/ {
    string_face (true);
    language_print ($0);
    call (c_string);
    string_face (false);
  }

  /* Keywords. */
   /\$(define|e(l(if|se)|ndif)|if(|def|ndef)|undef)\b\
|\&(a(llocated|scii)|c(lock|ollections|set|urrent)\
|d(ate(|line)|igits|ump)|e(|rro(r(|number|text|value)|ut))\
|f(ail|eatures|ile)|host|input|l(case|e(tters|vel)|ine)|main|null\
|output|p(hi|i|os|rogname)|r(andom|egions)|s(ource|torage|ubject)\
|t(ime|race)|ucase|version)\
|\b(a(bs|cos|ny|rgs|sin|tan)|b(al|reak|y)\
|c(a(llout|se)|enter|h(ar|dir)|lose|o(llect|py|s)|reate|set)\
|d(e(fault|l(ay|ete)|tab)|isplay|o|tor)\
|e(lse|n(d|tab)|rrorclear|very|x(it|p))|f(ail|ind|lush|unction)\
|g(et(|ch(|e)|env)|lobal)\
|i(and|com|f|mage|n(itial|sert|teger)|or|shift|xor)|k(bhit|ey)\
|l(eft|i(nk|st)|o(adfunc|cal|g))|m(a(ny|p|tch)|ember|ove)\
|n(ame|ext|ot|umeric)|o(f|pen|rd)|p(o(p|s)|roc(|edure)|u(ll|sh|t))\
|r(e(a(d(|s)|l)|cord|move|name|p(eat|l)|turn|verse)|ight|tod|unerr)\
|s(ave|e(ek|q|t)|in|ort(|f)|qrt|t(atic|op|ring)|uspend|ystem)\
|t(a(b(|le)|n)|hen|o|rim|ype)|u(ntil|pto)|variable\
|w(h(ere|ile)|rite(|s)))\b/ {
    keyword_face (true);
    language_print ($0);
    keyword_face (false);
  }

  LANGUAGE_SPECIALS {
    language_print ($0);
  }
}


From icon-group-sender Thu Jul 25 16:27:19 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6PNQB228636
    for icon-group-addresses; Thu, 25 Jul 2002 16:26:11 -0700 (MST)
Message-Id: <[e-mail]>
From: "John Sampson" <[e-mail]>
To: <[e-mail]>
Subject: Run-time error messages
Date: Thu, 25 Jul 2002 23:00:03 +0100
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Errors-To: [e-mail]
Status: RO

Hello -

I am using nticon in Windows 98. My program is producing a run-time error,
but the trace-back after the error message is causing the error message
itself to scroll off the screen before I can read it. I need either to turn
off the trace-back or divert the error output to a file so that I can see
it.

Is there a way of doing either of these things?

Regards

_John Sampson_



From icon-group-sender Wed Jul 31 12:29:16 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6VJSCM28079
    for icon-group-addresses; Wed, 31 Jul 2002 12:28:12 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Icon Wish List
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Wed, 31 Jul 2002 16:46:58 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Looking over the last several versions of Icon, the last several versions
did little more than adding a few functions and fix a few bugs. It has been
a while since there have been major enhancements to the Icon language. This
type of stagnation harms Icon's long term prospects. It is time to consider
some major upgrades to Icon.

Listed below are some possible major enhancements to Icon. Of these possible
improvements, which ones are important to you. Which are unimportant? Is
there an enhancement you'd like to see that is not listed?

1) Object-Oriented Programming

Icon, in its current form, does not support OOP. This is most unfortunate,
for even first generation languages such as Fortran and Cobol now support
OOP. Icon is virtually alone in its lack of support for object classes.

Yes, I know that we can do OOP using the IDOL preprocessor, but this
requires the preprocessor step, and that we us to use the "$" notation for
overloaded operators. It would be a real plus if IDOL was merged into the
language, so that we could compile a program with the class / method
constructs. IDOL is actually a rather interesting OOP language; it is the
only one I know of that allows classes to have cyclic class dependencies. If
IDOL was merged into Icon, it would make the language very appealing to the
OOD community.

2) Better Interfacing to External Programs

Right now, it is difficult for an Icon program to call a function not
written in Icon. On some platforms, there are facilities such as 'loadfunc'
that permit an external function to be loaded and called, but the external
function must be written specifically to interface with Icon. What would be
nice is if we could write, in Icon, a call to an arbitrary function in a
shared library / DLL.

Granted, this can be complicated. The Icon data model and the C (say) data
model are quite a bit different. In C, integers can come in several
different lengths, and may or may not have a sign. Icon has only one integer
type, and the length of these integers is limited only by memory. Icon
memory blocks are movable, and never require an explicit "free" call. C
works with fixed memory blocks, and an allocated memory block frequently
needs to be freed to avoid memory leaks.

Nevertheless, other languages provide ways of calling external functions and
handling external memory. Why can't Icon have these abilities?

3) Unicode Support

This issue has come up several times before: given that Icon's main focus is
text processing, it is a shame that it cannot handle Unicode text in a
natural fashion. There are some difficult issues involved with creating a
Unicode version of Icon:

- How should Unicode csets be represented?
- What should some of the cset keywords (e.g. &upper, &digits) return?
- Should we revise how the map function is implemented?

As difficult as these issues may be, Unicode is becoming too large to
ignore. How should Icon deal with this?

4) Icon as a Scripting Language

For the record, I strongly prefer Icon to PERL. Icon is more readable. Icon
with its generator facility, along with the string scanning facility, is
more powerful than PERL. And yet, I can see one good reason why PERL has
taken the world by storm: it works very well as a scripting language. If you
want something that combines shell script file management with some string
processing, PERL works great: just start the program with a "hash bang" and
you're ready to go. Icon, in contrast, was not designed to be run this way.
This is unfortunate; the power of Icon could be a real asset for script
writers.




From icon-group-sender Wed Jul 31 16:57:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6VNvfA25882
    for icon-group-addresses; Wed, 31 Jul 2002 16:57:41 -0700 (MST)
Message-Id: <[e-mail]>
X-Originating-IP: [205.158.212.246]
From: "Ray Pereda" <[e-mail]>
To: [e-mail]
Subject: Re: Icon Wish List
Date: Wed, 31 Jul 2002 14:13:09 -0700
X-OriginalArrivalTime: 31 Jul 2002 21:13:10.0117 (UTC) FILETIME=[129C9150:01C238D7]
Errors-To: [e-mail]
Status: RO

Does anyone know how to do "hash bang", e.g., #!c:\bin\iconx.exe as the
first line of text script, on a Windows platform?  -Ray


>From: "Frank J. Lhota" <[e-mail]>
>To: [e-mail]
>Subject: Icon Wish List
>Date: Wed, 31 Jul 2002 16:46:58 GMT
>
>Looking over the last several versions of Icon, the last several versions
>did little more than adding a few functions and fix a few bugs. It has been
>a while since there have been major enhancements to the Icon language. This
>type of stagnation harms Icon's long term prospects. It is time to consider
>some major upgrades to Icon.
>
>Listed below are some possible major enhancements to Icon. Of these
>possible
>improvements, which ones are important to you. Which are unimportant? Is
>there an enhancement you'd like to see that is not listed?
>
>1) Object-Oriented Programming
>
>Icon, in its current form, does not support OOP. This is most unfortunate,
>for even first generation languages such as Fortran and Cobol now support
>OOP. Icon is virtually alone in its lack of support for object classes.
>
>Yes, I know that we can do OOP using the IDOL preprocessor, but this
>requires the preprocessor step, and that we us to use the "$" notation for
>overloaded operators. It would be a real plus if IDOL was merged into the
>language, so that we could compile a program with the class / method
>constructs. IDOL is actually a rather interesting OOP language; it is the
>only one I know of that allows classes to have cyclic class dependencies.
>If
>IDOL was merged into Icon, it would make the language very appealing to the
>OOD community.
>
>2) Better Interfacing to External Programs
>
>Right now, it is difficult for an Icon program to call a function not
>written in Icon. On some platforms, there are facilities such as 'loadfunc'
>that permit an external function to be loaded and called, but the external
>function must be written specifically to interface with Icon. What would be
>nice is if we could write, in Icon, a call to an arbitrary function in a
>shared library / DLL.
>
>Granted, this can be complicated. The Icon data model and the C (say) data
>model are quite a bit different. In C, integers can come in several
>different lengths, and may or may not have a sign. Icon has only one
>integer
>type, and the length of these integers is limited only by memory. Icon
>memory blocks are movable, and never require an explicit "free" call. C
>works with fixed memory blocks, and an allocated memory block frequently
>needs to be freed to avoid memory leaks.
>
>Nevertheless, other languages provide ways of calling external functions
>and
>handling external memory. Why can't Icon have these abilities?
>
>3) Unicode Support
>
>This issue has come up several times before: given that Icon's main focus
>is
>text processing, it is a shame that it cannot handle Unicode text in a
>natural fashion. There are some difficult issues involved with creating a
>Unicode version of Icon:
>
>- How should Unicode csets be represented?
>- What should some of the cset keywords (e.g. &upper, &digits) return?
>- Should we revise how the map function is implemented?
>
>As difficult as these issues may be, Unicode is becoming too large to
>ignore. How should Icon deal with this?
>
>4) Icon as a Scripting Language
>
>For the record, I strongly prefer Icon to PERL. Icon is more readable. Icon
>with its generator facility, along with the string scanning facility, is
>more powerful than PERL. And yet, I can see one good reason why PERL has
>taken the world by storm: it works very well as a scripting language. If
>you
>want something that combines shell script file management with some string
>processing, PERL works great: just start the program with a "hash bang" and
>you're ready to go. Icon, in contrast, was not designed to be run this way.
>This is unfortunate; the power of Icon could be a real asset for script
>writers.
>
>
>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From icon-group-sender Wed Jul 31 16:59:32 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6VNxTE26082
    for icon-group-addresses; Wed, 31 Jul 2002 16:59:29 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Wed, 31 Jul 2002 23:32:06 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <6wU19.159$[e-mail]>,
[e-mail] says...
> Looking over the last several versions of Icon, the last several versions
> did little more than adding a few functions and fix a few bugs. It has been
> a while since there have been major enhancements to the Icon language. This
> type of stagnation harms Icon's long term prospects. It is time to consider
> some major upgrades to Icon.

As a beginner to Icon, I tend to regard it as a revolutionary approach to
programming, considering that it is founded upon expression evaluation.  This
has made it, I think, easier for those developing the language to document it
in a way that makes it relatively more accessible than other computer languages
for those who are new to computer programming in general.   On this basis, it
would appear that the only reason the language could stagnate at this point is
if its immediate, obvious benefits are not being more openly presented to the
programming community.  This can be achieved by using the language in ways that
would make it more note-worthy to those using other programming languages.
Lack of use of the language in creative new ways is what stagnates it, since
its revolutionary new approach represents the enhancement of computer
programming in general.  It cannot be further enhanced by what would represent
its degradation to the level of what other languages regard as essential.
Furthermore, by adopting the usages of other languages, the users of Icon will
be thrown into the arena of issues facing the development of those other
languages, issues which the basic principles of Icon are so well suited to
solve as they are.  I am not a computer specialist, but I'd like to voice my
support and express my conviction to the developers of the language, that, if a
computer language is supposed to present the medium by which problems facing
computer science in general may be better approached and solved, Icon has the
elements which other languages should be looking to for adoption, not the other
way around.  If Mr. Llota would care to explain how his proposed enhancements
can improve existing elements of the language, and not in any way detract from
them, I would be much obliged.





From icon-group-sender Wed Jul 31 16:59:57 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g6VNxsE26158
    for icon-group-addresses; Wed, 31 Jul 2002 16:59:54 -0700 (MST)
Message-Id: <[e-mail]>
From: Eka Laiman <[e-mail]>
Subject: Re: Icon Wish List
To: [e-mail] (Frank J. Lhota)
Date: Wed, 31 Jul 2002 15:03:16 -0700 (PDT)
Cc: [e-mail]
Errors-To: [e-mail]
Status: RO

Frank Lhota wrote:
> Looking over the last several versions of Icon, the last several versions did
> little more than adding a few functions and fix a few bugs. It has been a
> while since there have been major enhancements to the Icon language. This
> type of stagnation harms Icon's long term prospects. It is time to consider
> some major upgrades to Icon.

I agree with what Frank wrote. I used to write a lot of C/C++ codes but
nowadays unless the program has be run fast and will be used often, I
am writing ICON program most of the time. I would not like to see ICON
becoming a "dead" language like its predecessor, SNOBOL.

> Listed below are some possible major enhancements to Icon. Of these possible
> improvements, which ones are important to you. Which are unimportant? Is
> there an enhancement you'd like to see that is not listed?
>
> 1) Object-Oriented Programming
>
> Icon, in its current form, does not support OOP. This is most unfortunate,
> for even first generation languages such as Fortran and Cobol now support
> OOP. Icon is virtually alone in its lack of support for object classes.
>
> Yes, I know that we can do OOP using the IDOL preprocessor, but this requires
> the preprocessor step, and that we us to use the "$" notation for overloaded
> operators. It would be a real plus if IDOL was merged into the language, so
> that we could compile a program with the class / method constructs. IDOL is
> actually a rather interesting OOP language; it is the only one I know of that
> allows classes to have cyclic class dependencies. If IDOL was merged into
> Icon, it would make the language very appealing to the OOD community.

I am not sure whether I agree with OO being a desirable feature. For me
the only thing that C++ brings to the table with its object orientedness
is "it provides better lexical analysis". I have always written object
oriented program even in C hey days. The thing which I dislike about C
is having to call "listInsert", "hashInsert", etc. C++ solves this problem
by being able to call these functions as "insert". Which "insert"? This
is distinguished by the "type of object" used.

But in ICON we do not know "what type of object" a certain variable
belongs to until the run time. With this in mind, I am not sure how ICON
will handle this object orientedness.

> 2) Better Interfacing to External Programs
>
> Right now, it is difficult for an Icon program to call a function not written
> in Icon. On some platforms, there are facilities such as 'loadfunc' that
> permit an external function to be loaded and called, but the external
> function must be written specifically to interface with Icon. What would be
> nice is if we could write, in Icon, a call to an arbitrary function in a
> shared library / DLL.
>
> Granted, this can be complicated. The Icon data model and the C (say) data
> model are quite a bit different. In C, integers can come in several different
> lengths, and may or may not have a sign. Icon has only one integer type, and
> the length of these integers is limited only by memory. Icon memory blocks
> are movable, and never require an explicit "free" call. C works with fixed
> memory blocks, and an allocated memory block frequently needs to be freed to
> avoid memory leaks.
>
> Nevertheless, other languages provide ways of calling external functions and
> handling external memory. Why can't Icon have these abilities?

I also agree with this one. In recent release of ICON (9.2) a new
function is provided: "opendir". Immediately the thing that comes
to mind is "how do I test whether a given file is a directory or
normal file"? I know that I can do this using "fstat" in C. Unfortunately
interfacing ICON to external program is difficult at best.

> 3) Unicode Support
>
> This issue has come up several times before: given that Icon's main focus is
> text processing, it is a shame that it cannot handle Unicode text in a
> natural fashion. There are some difficult issues involved with creating a
> Unicode version of Icon:
>
> - How should Unicode csets be represented?  - What should some of the cset
> keywords (e.g. &upper, &digits) return?  - Should we revise how the map
> function is implemented?
>
> As difficult as these issues may be, Unicode is becoming too large to ignore.
> How should Icon deal with this?

Have we heard the last word on UNICODE yet?

> 4) Icon as a Scripting Language
>
> For the record, I strongly prefer Icon to PERL. Icon is more readable. Icon
> with its generator facility, along with the string scanning facility, is more
> powerful than PERL. And yet, I can see one good reason why PERL has taken the
> world by storm: it works very well as a scripting language. If you want
> something that combines shell script file management with some string
> processing, PERL works great: just start the program with a "hash bang" and
> you're ready to go. Icon, in contrast, was not designed to be run this way.
> This is unfortunate; the power of Icon could be a real asset for script
> writers.

Again I agree whole-heartedly with Frank that ICON's construct is a much
better construct than that of PERL. What I see the "deficiency" of ICON
over PERL is the "system functions" similar to "fstat" which I described
above. I don't mind so much having to go through "icont" path, after all
the "compile" time is very fast.

-eka-



From icon-group-sender Thu Aug  1 07:58:42 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g71EwJ219373
    for icon-group-addresses; Thu, 1 Aug 2002 07:58:19 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 1 Aug 2002 00:31:12 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO


[Frank Lhota asks for OOP, a better "loadfunc()", Unicode, and scripting]
[others have debated whether we should copy other languages, and asked for
fstat()]

As Frank is aware, if he merged Idol's OOP features into Icon as he
suggests, and added a juicy POSIX interface with things like fstat(), he'd
get a language called Unicon (http://unicon.sourceforge.net). Objects are
a thing that some applications genuinely benefit from, and others don't.
The same could be said about records, or string scanning.  Unicon is
usable entirely without objects; it comes with an "icont" and "iconx"
that work as in normal Icon and omit OOP features but make things
like POSIX functions, networking, and databases accessible.

I will post a detailed message on Frank's other very interesting requests
on the Unicon group mailing list tomorrow; I already wrote it but am not
posting it here since Icon Project are the right folks to answer requests for
language features for Icon.  Unicon's position toward Icon Project is one of
reverential worship and cooperation :-), and we continue to benefit from the
improvements to the Icon code that they make.

Clint [e-mail]


From icon-group-sender Thu Aug  1 07:59:02 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g71EwvY19497
    for icon-group-addresses; Thu, 1 Aug 2002 07:58:57 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Thu, 01 Aug 2002 13:54:10 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

First of all, I am a long time Icon user and I am a long-time Icon fan. I,
too, appreciate the power of the Icon expression evaluation mechanism. I
have been using the language since the mid-1980's. I frequently use Icon for
program generation / analysis, data analysis, rapid prototyping, and even
for small A.I. projects. I have contributed to the Icon Programming Library,
and have done some Icon development work in my spare time. I am the proud
owner of the complete run of the "Icon Analyst", and I always looked forward
to the elegant code samples included in each issue. (Side note: issues of
the IA are now available for download from the Icon project site. I would
strongly recommend them to all Icon enthusiasts).

When it comes to programming something for personal use, one-shot
applications or the like, I am very happy with Icon. I do consider it
superior to many of the other languages. Why, then, did I submit the wish
list? Because in spite of Icon's virtues, it still has not caught on with
anyone outside a rather small clique. I do not even have the option of doing
the work I'm being paid for in Icon -- nobody but me knows it, they won't be
able to maintain it, etc. -- so I end up doing the sorts of things Icon does
best in some other language.

How did this state of affairs come about? How could the superior technology
in Icon lose out to weaker tools like Awk or Perl? Sometimes what holds an
otherwise better product back is the lack of some small but very important
feature. Consider the 1980's battle over videotape formats. At the time,
there were two formats: VHS and Beta. The Beta tapes were more durable, and
had higher resolution, than the VHS tapes. With advantages like this, why
did VHS quickly gain the upper hand, eventually forcing Beta out of the
market? The reason was one simple feature missing from Beta tapes: long
recording times. The original Beta tapes could only hold one hour of
programming; later they came up with tapes that could record two hours of
programming. In contrast, VHS tapes could hold up to six hours of
programming, allowing one to record epic movies, sporting events, and even
movie marathons without switching tapes. Yes, tape length is just one dumb
issue to consider, but it turned out to be a very important issue to
consumers, and it resulted in the failure of the otherwise superior Beta
format.

I firmly believe that Icon is a superior language, that it can do many of
the things that languages such as Perl does, and do them better.
The reason for the wish list is that I'm wondering if there is some one
feature missing from Icon that is keeping it from taking off. I certainly do
not want to take away anything that is there. I still want Icon to have the
powerful and elegant features that we know and love.




From icon-group-sender Thu Aug  1 12:55:47 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g71Jsrw17728
    for icon-group-addresses; Thu, 1 Aug 2002 12:54:53 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 1 Aug 2002 16:57:28 +0100 (BST)
From: Hugh Sasse Staff Elec Eng <[e-mail]>
X-X-Sender: hgs@neelix
To: "Frank J. Lhota" <[e-mail]>
cc: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

On Thu, 1 Aug 2002, Frank J. Lhota wrote:

> list? Because in spite of Icon's virtues, it still has not caught on with
> anyone outside a rather small clique. I do not even have the option of doing

The same could be said of Forth, and in that case one argument
is that it is too radical:

http://www.msmisp.com/futuretest/Forth's_Dilemma.htm

this might be true for Icon too: I know I have difficulties
understanding Icon code because of its goal directed nature.
I'm still not really used to it yet.  I had the same problem
with Prolog.

Also, how OO can be done in a dynamic langauge can be seen from
Ruby.

http://www.ruby-lang.org/en/

There may be other, better examples...

        HTH
        Hugh



From icon-group-sender Fri Aug  2 07:53:00 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72EqMo14502
    for icon-group-addresses; Fri, 2 Aug 2002 07:52:22 -0700 (MST)
Message-Id: <[e-mail]>
From: "Shmuel (Seymour J.) Metz" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Thu, 01 Aug 2002 11:17:59 -0400
Mail-Copies-To: nobody
X-Cise: [e-mail]
X-CompuServe-Customer: Yes
X-Coriate: [e-mail]
X-Ecrate: tanandtanlawyers.com
X-Punge: Micro$oft
X-Sanguinate: [e-mail]
X-Terminate: SPA(GIS)
X-Tinguish: Mark Griffith <[e-mail]>
X-Treme: C&C,DWS
X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO


In <[e-mail]>, on 07/31/2002
   at 11:32 PM, ernobe <[e-mail]> said:

>As a beginner to Icon, I tend to regard it as a revolutionary
>approach to  programming,

It is, but that by itself does not make it useful in areas for which
it was not designed. I agree with Mr. Lhota's suggestions.

>considering that it is founded upon expression evaluation.

Many languages are. What is different about Icon is the backtracking
mechanism.

>This can be achieved by using the language in ways that  would make
>it more note-worthy to those using other programming languages.

Which is difficult if it lacks facilities needed for the application
areas that they are most likely to notice.

>It cannot be further enhanced by what would represent
>its degradation to the level of what other languages regard as
>essential.

You're begging the question. You've said nothing to back up a claim
that Mr. Lhota's suggestion would be a degradation of Icon.

>Furthermore, by adopting the usages of other languages, the users of
>Icon will  be thrown into the arena of issues facing the development
>of those other  languages,

What do you mean by "adopting"? Providing new language features does
not force anybody to use them.

>issues which the basic principles of Icon are so well suited to
>solve as they are.

It's precisely because they are *not* well suited that Mr. Lhota
suggested enhancements.

>I am not a computer specialist,

I am. And I agree with Mr. Lhota.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to [e-mail]



From icon-group-sender Fri Aug  2 08:02:37 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72F2QU15170
    for icon-group-addresses; Fri, 2 Aug 2002 08:02:26 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 01 Aug 2002 23:16:46 +1000
From: Bruce Gordon Rennie <[e-mail]>
X-Accept-Language: en
CC: [e-mail]
Subject: Re: Icon Wish List
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Errors-To: [e-mail]
Status: RO



Eka Laiman wrote:
>
[::]
>
> I agree with what Frank wrote. I used to write a lot of C/C++ codes but
> nowadays unless the program has be run fast and will be used often, I
> am writing ICON program most of the time. I would not like to see ICON
> becoming a "dead" language like its predecessor, SNOBOL.
>
[...]
SNOBOL 4 dead? I did hear that it was still being used to mange network
configuration files not so long ago. That may have changed recently - I have not
been in contact with the staff for a while.


--
Bruce Rennie ( from God's Own Country Downunder )
Disciple of Jesus Christ in Training

The Cross of Jesus Christ - Salvation for all men.

Song of Solomon ( Song of Songs ) - The greatest Love Story Ever
and a story for our times.

Be a GOD Chaser.



From icon-group-sender Fri Aug  2 08:05:45 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72F5fQ15522
    for icon-group-addresses; Fri, 2 Aug 2002 08:05:41 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: [e-mail]
Date: 02 Aug 2002 06:40:46 -0600
Errors-To: [e-mail]
Status: RO

I want to second Clint's comments about looking into Unicon for OOP
features and POSIX stuff.

Now why did I say that.

I believe that OOP fits a certain class (no pun intended) of programming
problems.  However, OOP also requires alot of "code" support within the
library.  I also believe that some of the concepts of OOP are in direct
contrast to the concepts of Icon - mainly that OOP wants very strict
data typing of it's objects, while Icon wants to be able to switch the
"class" of a variable around as needed.

I also believe that programmers tend to forget about the problem at hand
and program more towards trying to abstract everything out to a "class"
and instead of having something nice and readable you end up with
something like:

double dist = Math.abs( Math.sqrt( (A.x-B.x)^2 + (A.y-B.y)^2) - offset)

(note there are some features that I do like from OOP, but they were in
some languages "pre-oop" -- for example, PL/I had generics for functions
so that one could write:

procedure sqrt (x float)
...
end
procedure sqrt (x fixed bin)
...
end

As for scripting... I'm kind of wishy washy on this.  The problem with
adding in better "scripting" support is that it tends to require alot of
platform specific support.  One of the nice features of Icon is that it
is able to hold itself above the "operating system" level.

For a language to be a good scripting language it needs to be able to
interface not only with the command shell it's living in, but with any
environment.  In this case I have gotten used to Rexx.  I can use it for
command scripts, I can use it for editor scripts, I can imbed it into my
own programs.

If I were going to add scripting support into Icon, I would try to model
the interfaces off of Rexx's.



Anyway... now for my wish list...


1) Change the name.  Yes the meaning of Icon was kind of neat. However
must people out there probably think of those little images stuck on the
screen when someone mentions Icon.  My suggestion... IPL -- we get to
keep a little inside joke (IconProgrammingLanguage) -- but it gets us
away from having to reply that "No this is a programming language -- not
something about little desktop images).

2) an standardized icode format.  This would allow icode files to be
transfered from one system to another.  This actually could be done
fairly easily by inserting at the tail end of the linking phase a
translation to some standard format and then at loading phase in the
interpreter just converting back to native format.  And while we are in
there.. compress the icode file.

3) Packaging of ucode files.  I know that just dropping ucode files into
a directory is easy, but it would be nice to be able to just point to a
single file and say "here are all the procs" needed.

Cheyenne



On Thu, 2002-08-01 at 00:31, Clint Jeffery wrote:
>
> [Frank Lhota asks for OOP, a better "loadfunc()", Unicode, and scripting]
> [others have debated whether we should copy other languages, and asked for
> fstat()]
>
> As Frank is aware, if he merged Idol's OOP features into Icon as he
> suggests, and added a juicy POSIX interface with things like fstat(), he'd
> get a language called Unicon (http://unicon.sourceforge.net). Objects are
> a thing that some applications genuinely benefit from, and others don't.
> The same could be said about records, or string scanning.  Unicon is
> usable entirely without objects; it comes with an "icont" and "iconx"
> that work as in normal Icon and omit OOP features but make things
> like POSIX functions, networking, and databases accessible.
>
> I will post a detailed message on Frank's other very interesting requests
> on the Unicon group mailing list tomorrow; I already wrote it but am not
> posting it here since Icon Project are the right folks to answer requests for
> language features for Icon.  Unicon's position toward Icon Project is one of
> reverential worship and cooperation :-), and we continue to benefit from the
> improvements to the Icon code that they make.
>
> Clint [e-mail]
>
>



From icon-group-sender Fri Aug  2 08:05:57 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72F5t615558
    for icon-group-addresses; Fri, 2 Aug 2002 08:05:55 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail]
X-Newsgroups: comp.lang.icon,comp.answers,news.answers
Subject: Icon Programming Language FAQ
Date: 2 Aug 2002 07:51:04 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Archive-name: comp-lang-icon-faq
Posting-Frequency: monthly


        Frequently Asked Questions about the Icon programming language

   http://www.cs.arizona.edu/icon/faq.htm
   Last updated July 2, 2002

   Learning about Icon
   A1. What is Icon?
   A2. What is Icon good for?
   A3. What are Icon's distinguishing characteristics?
   A4. What is the Icon program library?
   A5. Where can I learn more about Icon?
   A6. How about comprehensive documentation?

   Implementations
   B1. What platforms support Icon?
   B2. How do I get started with Icon?
   B3. Is there a Unicode version of Icon?
   B4. What happened to the compiler?

   Administration
   C1. What is the Icon Project?
   C2. How often is the on-line material updated?
   C3. Where did Icon come from?
   C4. Where is Icon going?

   Support
   D1. Is there a users' group for Icon?
   D2. How do I get technical support?

   Programming
   E1. Why doesn't read() work with every?
   E2. Why doesn't string invocation such as "foo"() work?
   E3. How can I call a C function?
   E4. Can I open a bidirectional pipe?
     _________________________________________________________________

Learning about Icon

  A1. What is Icon?

   Icon is a very high level general-purpose programming language with
   extensive features for processing strings (text) and data structures.
   Icon is an imperative, procedural language with a syntax that is
   reminiscent of C and Pascal, but with semantics at a much higher
   level.

   Icon has a novel expression-evaluation mechanism that integrates
   goal-directed evaluation and backtracking with conventional control
   structures. It has a string scanning facility for pattern matching
   that avoids the tedious details usually associated with analyzing
   strings. Icon's built-in data structures include sets and tables with
   associative lookup, lists that can be used as vectors or stacks and
   queues, and records.

   Icon is a strongly, though not statically, typed language. It provides
   transparent automatic type conversion: For example, if an integer is
   used in an operation that requires a string, the integer is
   automatically converted to a string.

   Several implementations of Icon have high-level graphics facilities
   with an easily programmed window interface.

   Icon manages storage automatically. Objects are created as needed
   during program execution and space is reclaimed by garbage collection
   as needed. The sizes of strings and data structures are limited only
   by the amount of available memory.

  A2. What is Icon good for?

   As a general-purpose programming language with a large computational
   repertoire, Icon can be used for most programming tasks. It's
   especially strong at building software tools, for processing text, and
   for experimental and research applications.

   Icon is designed to make programming easy; it emphasizes the value of
   programmer's time and the importance of getting programs to work
   quickly. Consequently, Icon is used both for short, one-shot tasks and
   for very complex applications.

  A3. What are Icon's distinguishing characteristics?

     * A high-level, general-purpose programming language
     * Friendly line-oriented syntax (no semicolons needed)
     * Emphasis on programmer productivity
     * Usually interpreted

     * Evolved from programming languages (vs. scripting languages)
     * Procedural control flow plus generators and goal-directed
       evaluation

     * Values have types; variables are typeless, accept any value
     * Static scoping: global or (procedure) local
     * Automatic garbage collection

     * All integers have arbitrary precision
     * Uses strings (not chars) as basic text datatype
     * Has lists that function as arrays, queues, and stacks
     * Also has sets, tables, records (structs), reals (doubles), more
     * No second-class "primitive types"

     * Not "object-oriented" (no classes, inheritance, or instance
       methods)
     * No exception catching
     * No concurrency (no threads, monitors, semaphores, or
       synchronization)
     * Has co-expressions (coroutines)

     * Basic least-common-denominator system interface (a la ANSI C)

     * Procedural graphics (event-driven paradigm available but not
       mandated)
     * Retained windows (programs are never called to repaint)
     * Simple GUI builder that can re-edit its generated code
     * Turtle graphics package

     * Large library of contributed procedures and programs

  A4. What is the Icon program library?

   The library is a collection of programs and procedures written in
   Icon. User contributions are welcome and form a significant portion of
   the library.

   Library procedures effectively augment the built-in functions
   available to an Icon program. A wide variety of procedures currently
   exists, and most graphically-based programs are built around library
   procedures.

   The programs in the library range from simple demonstrations to handy
   tools to complex graphical applications.

   The library is a resource for both new and experienced programmers. In
   addition to their basic utility, its programs and procedures serve as
   examples of how things can be written in Icon.

  A5. Where can I learn more about Icon?

   Here are some good places to start.
     * Ralph Griswold's overview:
       http://www.cs.arizona.edu/icon/docs/ipd266.htm
     * Dave Hanson's introduction:
       http://www.cs.arizona.edu/icon/intro.htm
     * John Shipman's tutorial: http://www.nmt.edu/tcc/help/lang/icon/

  A6. How about comprehensive documentation?

   Two books specify the Icon language. The core language is covered by
   The Icon Programming Language (third edition), by Griswold and
   Griswold. Graphics facilities are described in Graphics Programming in
   Icon by Griswold, Jeffery, and Townsend. These books contain both
   tutorial and reference material. They are available from RTC Books
   (www.rtcbooks.com, search for "Icon") or from Jeffery Systems
   (www.zianet.com/jeffery/books).

   Icon's internals are detailed in The Implementation of the Icon
   Programming Language by Griswold and Griswold (Princeton, 1986, out of
   print). Although considerable changes have occurred since Version 6,
   described in the book, the basic structure is the same. Two technical
   reports, IPD112 and IPD239, describe subsequent changes.

   The Icon Programming Language Handbook, by Thomas W. Christopher, is
   available on the web at http://www.toolsofcomputing.com/IconHandbook/.

   There is a large amount of additional information at the Icon web
   site, http://www.cs.arizona.edu/icon, but there is no complete on-line
   documentation.
     _________________________________________________________________

Implementations

  B1. What platforms support Icon?

   Current implementations with graphics support are available for Unix
   and Windows. On the Macintosh, the Unix implementation runs under
   MacOS X, with graphics using XFree86. Older versions of Icon are
   available for some other systems. An alternative Java-based
   implementation for Unix, Jcon, is also available.

  B2. How do I get started with Icon?

   Version 9.4.1 of Icon for Unix can be downloaded from
   http://www.cs.arizona.edu/icon/v941/. Source and binary packages are
   available, each with the complete Icon program library.

   Version 9.3 of Icon for Windows is compatible at the source level with
   version 9.4.1. It can be downloaded from
   http://www.cs.arizona.edu/icon/v93w.htm. The Version 9.4.1 library can
   be obtained separately from http://www.cs.arizona.edu/icon/v941/.

   For older implementations, start at
   http://www.cs.arizona.edu/icon/implver.htm. Jcon is at
   http://www.cs.arizona.edu/icon/jcon/.

  B3. Is there a Unicode version of Icon?

   No. Icon is defined in terms of 8-bit characters, and changing this
   presents several design challenges that would likely break existing
   programs. Also, modifying the C implementation is probably infeasible,
   but a Unicode version of Jcon might be possible.

  B4. What happened to the compiler?

   For a while, Unix distributions included both an interpreter and a
   compiler; but the interpreter is is usually fast enough even for
   production work, and most people found that using the compiler wasn't
   worth the extra compilation time or the hassles involved. We no longer
   advertise the compiler or produce binaries for it. It is still part of
   the source code distribution, and we have not deliberately broken it,
   but we no longer support it and we cannot offer help if problems
   arise.
     _________________________________________________________________

Administration

  C1. What is the Icon Project?

   The Icon Project is a name used by the group that distributes and
   supports the Icon programming language. The project maintains the Icon
   web site at http://www.cs.arizona.edu/icon. A non-commercial
   organization, the project derives support from the University of
   Arizona, revenue from book sales, and user contributions.

  C2. How often is the on-line material updated?

   New material is added when it's available. Established implementations
   usually are updated only when there's a new version. This typically is
   every year or two. The Icon program library is updated on a similar
   schedule.

  C3. Where did Icon come from?

   Icon is the latest in a series of high-level programming languages
   designed to facilitate programming tasks involving strings and
   structures. The original language, SNOBOL, was developed at Bell
   Telephone Laboratories in the early 1960s. SNOBOL evolved into
   SNOBOL4, which is still in use. Subsequent languages were developed at
   the University of Arizona with support from the National Science
   Foundation. Although it has similar objectives and many similar
   capabilities, Icon bears little superficial resemblance to SNOBOL4.

   Icon implementations were developed by faculty, staff, and students at
   the University of Arizona, with significant contributions from
   volunteers around the world. An Icon history by Ralph and Madge
   Griswold appears in the preprints of the second History of Programming
   Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol
   28, No 3).

   The name Icon is not an acronym, nor does it stand for anything in
   particular, although the word iconoclastic was mentioned when the name
   was chosen. The name predates the now common use of icon to refer to
   small images used in graphical user interfaces. This sometimes
   misleads people into thinking that that Icon is designed to create or
   manipulate icons, but there's no good solution to that problem.

  C4. Where is Icon going?

   We continue to use Icon on a daily basis, but no significant changes
   are planned. We expect to support the Unix version for the forseeable
   future, and to distribute ports to other systems as supplied by
   volunteers.

   The Unicon project is developing an object-oriented language based on
   Icon. For more information, see http://unicon.sourceforge.net. An
   earlier object-oriented extension to Icon, Idol, can be found in the
   Icon program library.
     _________________________________________________________________

Support

  D1. Is there a users' group for Icon?

   There is no official Icon users' group, but The Icon Project maintains
   a moderated "Icon-group" electronic mailing list. To subscribe (or
   unsubscribe), send a message to [e-mail].

   There is a gateway between Icon-group and comp.lang.icon, an
   unmoderated newsgroup for discussing issues related to Icon. The
   gateway, which exchanges messages between the two systems, is
   imperfect and not under the control of the Icon Project.

   The newsgroup generally provides faster response than the mailing list
   and is less intrusive, but it sometimes suffers from inappropriate
   postings. The Icon Project usually sends its announcements and other
   messages to the mailing list.

  D2. How do I get technical support?

   The Icon Project is not a commercial organization, and its capacity
   for providing technical support is limited. Please use the appropriate
   resource when you need assistance:
     * For programming assistance, submit a query to the mailing list or
       newsgroup (see above).
     * For porting assistance or Unix problems, contact
       [e-mail].
     * For problems with the Windows implementation, contact the
       implementor, [e-mail].
     * For general information and additional documentation, visit the
       Icon web site: http://www.cs.arizona.edu/icon.
     _________________________________________________________________

Programming

  E1. Why doesn't read() work with every?

   every s := read() do {...} doesn't loop because read() produces a
   single value and then fails if resumed. Other "consumer" procedures
   such as get() and pop() work the same way. Use a while loop with these
   procedures, and save every for use with generators such as !x or
   key(T).

  E2. Why doesn't string invocation such as "foo"() work?

   String invocation works if the procedure is present; the catch is that
   the linker removes unreferenced procedures. To ensure a procedure's
   presence, reference it in the main() procedure. A simple reference
   suffices, as in refs := [foo, bar, baz]; it's not necessary to
   actually call it.

   (Why does the linker remove unreferenced procedures? Because this can
   save huge amounts of memory for programs that use the library.)

  E3. How can I call a C function?

   You can't call an arbitrary C function, but if you're willing to write
   a function to Icon's specifications, there are two approaches. Under
   Unix, which provides loadfunc(), you can load one or more functions
   from a shared library, and then treat them as if they had been written
   in Icon. Some examples can be found in the cfuncs and packs/loadfuncs
   directories of the Icon program library. The more cumbersome approach
   is to add code to the Icon interpreter and rebuild it; some hooks are
   provided for this purpose. Both approaches are discussed in Calling C
   Functions from Icon, http://www.cs.arizona.edu/icon/docs/ipd240.htm.

   The Jcon implementation allows Icon programs to call Java code that is
   written to Jcon specifications.

  E4. Can I open a bidirectional pipe?

   No, this is not possible. Although the concept is simple -- write a
   line to a program via a pipe, then read that program's output -- it
   probably wouldn't work. Most I/O libraries don't write anything to a
   pipe until they've filled a buffer, and the most likely consequence
   would be a deadlock, with each program waiting for the other to send
   more data.
     _________________________________________________________________

   This FAQ is edited by Gregg Townsend. It includes contributions from
   Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd
   Proebsting.


From icon-group-sender Fri Aug  2 12:50:38 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72JnYw09491
    for icon-group-addresses; Fri, 2 Aug 2002 12:49:34 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 2 Aug 2002 16:48:44 +0100 (BST)
From: Hugh Sasse Staff Elec Eng <[e-mail]>
X-X-Sender: hgs@neelix
To: Cheyenne Wills <[e-mail]>
cc: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

On 2 Aug 2002, Cheyenne Wills wrote:

        [Reformatted for width...]
> I believe that OOP fits a certain class (no pun intended) of
> programming problems.  However, OOP also requires alot of "code"

I don't know enough about internals to comment on this.

> support within the library.  I also believe that some of the
> concepts of OOP are in direct contrast to the concepts of Icon -
> mainly that OOP wants very strict data typing of it's objects,
> while Icon wants to be able to switch the "class" of a variable
> around as needed.

Not in all cases.  Strong typing is not necessarily part of OO, and
it can be argued that it is opposed to the OO idea of polymorphism.
In Ruby this has come up quite a bit on the list: should people
check the type of arguemnts or the methods they respond to?  The
latter is generally more highly regarded but testing each method

   if x.respond_to?(method)
      x.method(args)
   end

before use is cumbersonme.  Ruby variables have no type, and new
users sometimes complain that they can do things like

a = "hello"
a = 2

but the variable is pretty much a (dereferenced) reference, so can
"point" to anything.

So, there are ways that Icon can do this without strong typing.

>
> I also believe that programmers tend to forget about the problem
> at hand and program more towards trying to abstract everything out
> to a "class" and instead of having something nice and readable you
> end up with something like:
>
> double dist = Math.abs( Math.sqrt( (A.x-B.x)^2 + (A.y-B.y)^2) - offset)

I'd see that problem description as two problems:
  1 overgeneralisation -- in the drive for re-use
  2 poorly structured, written code.
I don't think this is a problem of OO in so far as it is a problem
generally.  Writing good code is nontrivial. :-)

        [...]
> As for scripting... I'm kind of wishy washy on this.  The problem
> with adding in better "scripting" support is that it tends to
> require alot of platform specific support.  One of the nice
> features of Icon is that it is able to hold itself above the
> "operating system" level.

I think higher levels of abstraction are generally good, but in
the daily grind of getting stuff done the ability to make effective
use of the OS is pretty important.  It has all the benefits of code
reuse, for one thing -- you're using tools with which you are
familiar.  The problem is that one model of OS doesn't fit all the
cases out there (embedded to mainframe).
>

        Hugh



From icon-group-sender Fri Aug  2 13:36:20 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72KaEA14225
    for icon-group-addresses; Fri, 2 Aug 2002 13:36:14 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 02 Aug 2002 12:22:08 -0500
From: [e-mail]
Subject: Fwd: Re: Icon Wish List
To: [e-mail], [e-mail]
Errors-To: [e-mail]
Status: RO

> Subject: Re: Icon Wish List
Date: Thu, 01 Aug 2002 23:16:46 +1000
From: XXXXXXXXXX
To: unlisted-recipients:; (no To-header on input)
Cc: [e-mail]


> [::]

>> I agree with what Frank wrote. I used to write a lot of C/C++ codes but
> nowadays unless the program has be run fast and will be used often, I
> am writing ICON program most of the time. I would not like to see ICON
> becoming a "dead" language like its predecessor, SNOBOL.

> [...]
SNOBOL 4 dead? I did hear that it was still being used to mange network
configuration files not so long ago. That may have changed recently - I have
 not been in contact with the staff for a while.

SNOBOL4 is most definitely NOT "dead"... there are quite a few of us using the
language quite happily on a daily basis!

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.




From icon-group-sender Fri Aug  2 13:59:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72KxgI16566
    for icon-group-addresses; Fri, 2 Aug 2002 13:59:42 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Fri, 2 Aug 2002 18:20:00 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <3d495127$3$fuzhry+tra$[e-mail]>,
[e-mail] says...
>
> In <[e-mail]>, on 07/31/2002
>    at 11:32 PM, ernobe <[e-mail]> said:
>
> >As a beginner to Icon, I tend to regard it as a revolutionary
> >approach to  programming,
>
> It is, but that by itself does not make it useful in areas for which
> it was not designed. I agree with Mr. Lhota's suggestions.
>
> >considering that it is founded upon expression evaluation.
>
> Many languages are. What is different about Icon is the backtracking
> mechanism.

As a computer specialist, you should know that expression evaluation and
backtracking mechanism are synonymous terms.  Other languages evaluate
statements, Icon evaluates expressions.  Other expressions are also essential,
as I pointed out.  I do not have to be a computer genius to realize that if the
language is as well-documented as it is, it will lead more beginners to study
it and more professionals to work and cooperate with it.  Without that, Icon
would be degraded, degraded to the level of all other languages, who despite
the promotion of high-flung capabilities in the literature, cannot make any
well-ordered, coherent statement of such capabilities in the documentation.
This only leads to arrogance in the promoters of such developments and the
dissipation of the efforts of their followers.



From icon-group-sender Fri Aug  2 14:00:26 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72L0GA16668
    for icon-group-addresses; Fri, 2 Aug 2002 14:00:16 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Fri, 2 Aug 2002 18:46:43 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO


>
> I firmly believe that Icon is a superior language, that it can do many of
> the things that languages such as Perl does, and do them better.
> The reason for the wish list is that I'm wondering if there is some one
> feature missing from Icon that is keeping it from taking off. I certainly do
> not want to take away anything that is there. I still want Icon to have the
> powerful and elegant features that we know and love.
>

I wish you luck in your endeavour.  Icon is superior, and I realize that
showing how superior it already is in practice will not necessarily allow it to
"take off".  It will need to advertize itself, so to speak.
     The only other computer language that I know of which uses expressions is
Terse (www.terse.com) an expression-based assembly language.  It is easier to
program in than C or Assembly.   I wonder why Icon can't become or is not
considered a more low-level language.  That would certainly raise brows.  It
would not take-off.   It would launch.


From icon-group-sender Fri Aug  2 14:00:52 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72L0lg16738
    for icon-group-addresses; Fri, 2 Aug 2002 14:00:47 -0700 (MST)
Message-Id: <[e-mail]>
From: "Boulet, Dan" <[e-mail]>
To: "'IconGroup'" <[e-mail]>,
   "'Unicon Group'"
     <[e-mail]>
Subject: dxf builder
Date: Fri, 2 Aug 2002 14:08:21 -0400
Errors-To: [e-mail]
Status: RO


Would anybody use icon procedures to write "dxf" (drawing exchange format)
files?  I've already started a library of functions for basic shapes.  I'd
be happy to develop this further if the demand exists.

Regards,

Daniel Boulet


From icon-group-sender Fri Aug  2 14:01:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72L16k16822
    for icon-group-addresses; Fri, 2 Aug 2002 14:01:06 -0700 (MST)
Message-Id: <[e-mail]>
From: Christopher Browne <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 2 Aug 2002 18:21:27 GMT
X-Draft-From: ("nnvirtual:Languages" 880)
X-Home-Page: http://www.cbbrowne.com/info/
X-Emacs-Acronym: Elsewhere Maybe Alternative Civilizations Survive
Microsoft: Where even the version numbers aren't Y2K-compliant
X-Shopping-List:
   (1) Cenozoic Snore ignorers
   (2) Economical commotions
   (3) Forensic rice
   (4) Responsible suspenders
   (5) Anxious enemas
X-Uboat-Death-Message:
   TORPEDOED BY SPACE-TIME VORTEX. TORPEDOS. SINKING. U-950.
To: [e-mail]
Errors-To: [e-mail]
Status: RO

The world rejoiced as ernobe <[e-mail]> wrote:
>> I firmly believe that Icon is a superior language, that it can do
>> many of the things that languages such as Perl does, and do them
>> better.  The reason for the wish list is that I'm wondering if
>> there is some one feature missing from Icon that is keeping it from
>> taking off. I certainly do not want to take away anything that is
>> there. I still want Icon to have the powerful and elegant features
>> that we know and love.
>
> I wish you luck in your endeavour.  Icon is superior, and I realize
> that showing how superior it already is in practice will not
> necessarily allow it to "take off".  It will need to advertize
> itself, so to speak.

> The only other computer language that I know of which uses
> expressions is Terse (www.terse.com) an expression-based assembly
> language.  It is easier to program in than C or Assembly.  I wonder
> why Icon can't become or is not considered a more low-level
> language.  That would certainly raise brows.  It would not take-off.
> It would launch.

The approach of "terse" should come as little surprise; it amounts to
saying "Can we make a smarter macro assembler?" to which the answer is
"Surely!"

The reason Icon isn't popular has little, I think, to do with its
capabilities, or in what is missing.  There are neat things in it, and
various other languages have visibly tipped their hats to Icon for
features that they have taken.  The Common Lisp "SERIES" module is a
quite ancient example.  In the last year, I have seen explicit mention
of Icon as a source of inspiration for new/planned functionality for
Perl, Python, and Ruby.

Why Icon _isn't_ popular is that there aren't popular systems out
there that use it.

Consider PHP.  By all rights, it's quite an ugly hack.  It started as
a way of embedding page counters into web pages, and has grown into a
language looking a lot like an old version of Perl.  I don't think
that at any point in time, PHP has been "better" than Icon, from a
standpoint of design elegance.  PHP became popular because it fit well
into a niche that people cared about, and which grew into a rather
larger niche.

Bringing the OO extensions of Idol back into Icon isn't going to
magically make the world say:
 "Oh, how wrong we were to not consider using Icon!"

No, the way that Icon will make more than a conceptual mark (as when
some of its features get added to Perl and Python) is if someone
builds something _useful_ in Icon that fulfils some niche.

Maybe as the implementation language for a local "web search engine,"
or of a web site analysis tool that goes off looking for problems
(broken links, bad HTML, non-portable ECMAScript, and the likes).  Or
those may be oversubscribed application areas.

The single program on the Debian Linux distribution that _depends_ on
Icon is "nowebm," a literate programming tool.  Put that up to 20 apps
depending on Icon, and people would probably start to notice.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/languages.html
The English exam was a piece  of cake---which was a bit of a surprise,
actually, because I was expecting some questions on a sheet of paper.


From icon-group-sender Fri Aug  2 14:01:23 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72L1Js16875
    for icon-group-addresses; Fri, 2 Aug 2002 14:01:19 -0700 (MST)
Message-Id: <[e-mail]>
From: "Chris Korycinski" <[e-mail]>
To: [e-mail]
Date: Fri, 2 Aug 2002 21:24:42 +0100
Subject: Re: Icon Wish List
Content-description: Mail message body
Errors-To: [e-mail]
Status: RO

On 1 Aug 2002 at 13:54, Frank J. Lhota wrote:

> I firmly believe that Icon is a superior language, that it can do many
> of the things that languages such as Perl does, and do them better.
> The reason for the wish list is that I'm wondering if there is some
> one feature missing from Icon that is keeping it from taking off.

well, I'm not sure that Icon is better than Perl. (a) it is too
specialised - calling external progs/routine is so straightforward in
Perl. Its interface with Unix means that you can just incorporate
Unix tools straight into the program. This makes it more of a general-
purpose language, inspite of its description as a scripting language.
(b) icon has no regular expressions (yes, I know they are in the
library) but just look at the ones available in Perl. They beat any
others hands down.
So Perl succeeds as a scripting language and it succeeds as a more
general-purpose language than Icon. But because Icon is part of a
side-stream, it does not mean it needs to be in a backwater. The 'one
language is a winner, so others are loosers' approach works with
little except with self-improvement/motivation books.

Icon can be both successful and a minority language. Size and success
 are not the same. Ask your local fat man.



Chris

===========================================================
Please send attachments only as plain text or .rtf files



From icon-group-sender Fri Aug  2 17:00:18 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g72NxwU05209
    for icon-group-addresses; Fri, 2 Aug 2002 16:59:58 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 2 Aug 2002 14:25:19 -0700 (PDT)
From: Eka Laiman <[e-mail]>
Subject: Re: Icon Wish List
To: [e-mail]
Errors-To: [e-mail]
Status: RO


Chris Korycinski wrote:
>well, I'm not sure that Icon is better than Perl.

It is true that ICON is not "better" in every aspect than PERL, but
the "language" scope, the true "no need to declare type", and many
other features of ICON is better than PERL. PERL likes to claim that
it does not have to do type declaration, but in actuality the "$",
"%" and "@" prefix is an "implicit" type declaration.

>(b) icon has no regular expressions (yes, I know they are in the
>library) but just look at the ones available in Perl. They beat any
>others hands down.

I cannot disagree more at this point. Try to write a "parser" in PERL!
In ICON this can be done by "string scanning" mechanism which keeps
track of "where" are currently at.

The "best" approach to writing parser (in PERL) is as suggested by
Aho, Weinberg, Kernighan in their "AWK book" - writing "compiler and
interpreter" which is to "chop off" the string prefix that has been
read.

At first I also had a difficult time trying to understand how this
string scanning mechanism works, but after reading the examples in
ICON Analyst, I will trade this with PERL's regular expression handling!

-eka-



From icon-group-sender Fri Aug  2 17:00:28 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7300Q205326
    for icon-group-addresses; Fri, 2 Aug 2002 17:00:26 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Fri, 2 Aug 2002 23:51:54 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <aieij6$1392t9$[e-mail]>, [e-mail] says...
> Maybe as the implementation language for a local "web search engine,"
>
Whatever it is, such a project would perhaps indicate what areas of the
language can be improved. (we would deduce from it how to improve the
language).  Obviously the Web presents several possibilities.  Have you heard
of Rebol? (www.rebol.com)  It could be that instead of more features being
added to it, it would be made more robust, having it on the one hand evaluate
expressions that are closer to the machine level, and on the other making it
portable accross a wide range of OS so as to make it attractive to Web server
applications.  The Rebol project is revolutionary in that "on does not surf the
Web, one scripts it", in other words, one is served computer programs from
servers, and your implementation of the language runs the program on your
machine.   Then there is the convenient messaging technology, which
incorporates URLs as basic data-types of the language, so that actually one
becomes part of an IOS (Internet Operating System).  But I think Icon could do
the same thing better, because of the ease with which it can be programmed in.
It is said somewhere in the Rebol documentation that the distinction between
data and code is illusory:  the data that is part of the language (reserved
words) is code, while data that is interpreted by the language is data.  That
is a long-winded way of saying that the language is easy to program in for
remote server applications.  Anyway, that Icon is closer to human language than
any other one is probably a safe bet, since one can't get closer to language
than by expressions that mean what they say.


From icon-group-sender Fri Aug  2 17:00:36 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7300Y605357
    for icon-group-addresses; Fri, 2 Aug 2002 17:00:34 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: [e-mail]
Date: 02 Aug 2002 16:53:10 -0600
Errors-To: [e-mail]
Status: RO

On Fri, 2002-08-02 at 12:21, Christopher Browne wrote:

>
> The reason Icon isn't popular has little, I think, to do with its
> capabilities, or in what is missing.  There are neat things in it, and
> various other languages have visibly tipped their hats to Icon for
> features that they have taken.  The Common Lisp "SERIES" module is a
> quite ancient example.  In the last year, I have seen explicit mention
> of Icon as a source of inspiration for new/planned functionality for
> Perl, Python, and Ruby.

I agree 100% with this...

>
> Why Icon _isn't_ popular is that there aren't popular systems out
> there that use it.
>
> Consider PHP.  By all rights, it's quite an ugly hack.  It started as
> a way of embedding page counters into web pages, and has grown into a
> language looking a lot like an old version of Perl.  I don't think
> that at any point in time, PHP has been "better" than Icon, from a
> standpoint of design elegance.  PHP became popular because it fit well
> into a niche that people cared about, and which grew into a rather
> larger niche.
>
> Bringing the OO extensions of Idol back into Icon isn't going to
> magically make the world say:
>  "Oh, how wrong we were to not consider using Icon!"
>

And I agree with this as well!!

> No, the way that Icon will make more than a conceptual mark (as when
> some of its features get added to Perl and Python) is if someone
> builds something _useful_ in Icon that fulfils some niche.
>

And I think that this is the crux of the problem...

We all have little quick and dirty tools that we have written.
The Library has a bunch of nice little packages as well

But what I think is really needed is something bigger...  An open source
project that uses Icon just so that it gets out and becomes visible.

Something that can show off the features of Icon.

Here are some suggestions...

A HTML optimizer -- in fact this was the subject of a programming
contest.  You feed in an HTML stream, it verifies it and optimizes it
(for example <b>something<b>yadayada</b></b> can be reduced).

A web log analyzer

A system log analyzer

A full blown macro processor (and I don't mean a simple M4 type of
processor.. go take a look at the PL/I macro facility -- you can write
full blown "functions" in the macro language complete with macro
subroutines, etc.

Cheyenne


From icon-group-sender Fri Aug  2 17:00:47 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7300jE05384
    for icon-group-addresses; Fri, 2 Aug 2002 17:00:45 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: [e-mail]
Date: 02 Aug 2002 17:00:45 -0600
Errors-To: [e-mail]
Status: RO

Actually the fact that Icon doesn't have regular expressions is a plus
from my view.

I find regular expressions to be a huge step backwards in terms of
readability and usability within a language.

With the facilities of Icon... why do you need regular expressions other
then to wean Perl/Awk/.. etc. programmers away from them.

The only thing that regular expressions has going for them is that they
are concise.  That is it.  Name one feature of regular expressions that
cannot be done with Icon's string scanning facility..


Anyway personal... pet peeve...

Cheyenne


On Fri, 2002-08-02 at 14:24, Chris Korycinski wrote:
> On 1 Aug 2002 at 13:54, Frank J. Lhota wrote:
>
> > I firmly believe that Icon is a superior language, that it can do many
> > of the things that languages such as Perl does, and do them better.
> > The reason for the wish list is that I'm wondering if there is some
> > one feature missing from Icon that is keeping it from taking off.
>
> well, I'm not sure that Icon is better than Perl. (a) it is too
> specialised - calling external progs/routine is so straightforward in
> Perl. Its interface with Unix means that you can just incorporate
> Unix tools straight into the program. This makes it more of a general-
> purpose language, inspite of its description as a scripting language.
> (b) icon has no regular expressions (yes, I know they are in the
> library) but just look at the ones available in Perl. They beat any
> others hands down.
> So Perl succeeds as a scripting language and it succeeds as a more
> general-purpose language than Icon. But because Icon is part of a
> side-stream, it does not mean it needs to be in a backwater. The 'one
> language is a winner, so others are loosers' approach works with
> little except with self-improvement/motivation books.
>
> Icon can be both successful and a minority language. Size and success
>  are not the same. Ask your local fat man.
>
>
>
> Chris
>
> ===========================================================
> Please send attachments only as plain text or .rtf files
>
>
>



From icon-group-sender Mon Aug  5 09:02:33 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75G0IA04314
    for icon-group-addresses; Mon, 5 Aug 2002 09:00:18 -0700 (MST)
Message-Id: <[e-mail]>
From: "Shmuel (Seymour J.) Metz" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Fri, 02 Aug 2002 14:36:07 -0400
Mail-Copies-To: nobody
X-Cise: [e-mail]
X-CompuServe-Customer: Yes
X-Coriate: [e-mail]
X-Ecrate: tanandtanlawyers.com
X-Punge: Micro$oft
X-Sanguinate: [e-mail]
X-Terminate: SPA(GIS)
X-Tinguish: Mark Griffith <[e-mail]>
X-Treme: C&C,DWS
X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO


In <[e-mail]>, on 08/02/2002
   at 06:20 PM, ernobe <[e-mail]> said:

>As a computer specialist, you should know that expression evaluation
>and  backtracking mechanism are synonymous terms.

No they are not.

>Other languages evaluate statements,

Some other languages. Not all.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to [e-mail]



From icon-group-sender Mon Aug  5 09:09:52 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75G9o206257
    for icon-group-addresses; Mon, 5 Aug 2002 09:09:50 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 05 Aug 2002 10:10:33 -0400
From: "Steve Graham" <[e-mail]>
To: <[e-mail]>
Subject: Re: Icon Wish List
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g75EAsw23145
Errors-To: [e-mail]
Status: RO

>>> Cheyenne Wills <[e-mail]> 08/02/02 05:53PM >>>
On Fri, 2002-08-02 at 12:21, Christopher Browne wrote:

...

> Something that can show off the features of Icon.

> Here are some suggestions...

> A HTML optimizer -- in fact this was the subject of a programming contest.  You feed in an HTML stream, it verifies it and optimizes it (for example <b>something<b>yadayada</b></b> can be reduced).

...

Maybe we should enter one or more teams into this programming contest (http://icfpcontest.cse.ogi.edu/).  This is the 5th year of the competitions, and even though I participated mostly by myself last year, it was great fun (in addition to great frustration at times).  They offer prizes ranging from $100 to $1,000, but the biggest prize would be when "the contest judges agree to state at least once during the presentation of the awards that the winning team's programming language is 'the programming tool of choice for discriminating hackers.'"  Anyway it would be some good PR.

Although I am just a middlin' Icon programmer, I have used it to good effect for utilities in the past, and think (memory fails me) that I used it for the contest last year.  I see no problem with Icon holding its own against the other entries.  I'll probably use it myself this year.

My $.02


Steve Graham



From icon-group-sender Mon Aug  5 09:09:08 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75G95w06084
    for icon-group-addresses; Mon, 5 Aug 2002 09:09:05 -0700 (MST)
Message-Id: <[e-mail]>
From: "John Sampson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Icon Wish List
Date: Sat, 3 Aug 2002 11:47:38 +0100
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Errors-To: [e-mail]
Status: RO

>
> At first I also had a difficult time trying to understand how this
> string scanning mechanism works, but after reading the examples in
> ICON Analyst, I will trade this with PERL's regular expression handling!

I would have thought Icon's string scanning did a different job from regular
expressions.

Another writer here comments in effect that the only virtue of regular
expressions is that they are terse. But if terseness is required for a
particular problem, whatever beauties a method without terseness has, they
have to be done without.

I think pattern matching was to be written up in Icon Analyst, but the
material never appeared. If it did, I would be grateful for a reference.

Regards

_John Sampson_



From icon-group-sender Mon Aug  5 09:10:13 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75GABU06395
    for icon-group-addresses; Mon, 5 Aug 2002 09:10:11 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Mon, 5 Aug 2002 16:32:03 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <[e-mail]>, [e-mail]
says...
> Can someone enlighten me on what exactly is *revolutionary* about
> Icon's approach to programming? Thanks.
>

If you take a look at the following diagram of the history of computer
languages: http://merd.net/pixel/language-study/diagram.png you will notice
that Icon is the language that has remained unchanged for the longest period of
time since its creation, which indicates how well suited it was to solve
problems which other languages needed to adopt to, and are still trying to
solve.  That is because they failed to adopt the features of Icon, which do not
exist in the languages from which it developed,  languages which continue to
influence the development of more languages.  If you look closely at the
diagram, you will notice that Icon, by it relationship to CLU and Pascal on the
one hand and to C on the other, takes the best of the Fortrean family of
languages, via Algol60.  By this means it avoided the Fortrean family which
later became mixed with the Lisp family.  Instead, it continues the line begun
with Snobol, which, compared to Lisp, may be described as human intelligence
vs. artificial intelligence.  So, since it draws from all of the existing,
significant lines of development, and makes a synthesis, Icon has every reason
to be regarded as the fifth generation language.  Future developments will
bring this out, as pointed out in my other posts.


From icon-group-sender Mon Aug  5 09:10:06 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75GA2Y06330
    for icon-group-addresses; Mon, 5 Aug 2002 09:10:02 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Mon, 5 Aug 2002 16:34:53 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <[e-mail]>, [e-mail] says...
> If you take a look at the following diagram of the history of computer
> languages: http://merd.net/pixel/language-study/diagram.png y
>

Sorry about the link, try this one:
http://merd.net/pixel/language-study/diagram.html


From icon-group-sender Mon Aug  5 09:09:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75G9cg06206
    for icon-group-addresses; Mon, 5 Aug 2002 09:09:38 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 4 Aug 2002 09:43:52 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

"Shmuel (Seymour J.) Metz" <[e-mail]> wrote in message news:<3d495127$3$fuzhry+tra$[e-mail]>...
> In <[e-mail]>, on 07/31/2002
>    at 11:32 PM, ernobe <[e-mail]> said:
>
> >As a beginner to Icon, I tend to regard it as a revolutionary
> >approach to  programming,
>
> It is, but that by itself does not make it useful in areas for which
> it was not designed. I agree with Mr. Lhota's suggestions.
>

Can someone enlighten me on what exactly is *revolutionary* about
Icon's approach to programming? Thanks.



> >considering that it is founded upon expression evaluation.
>
> Many languages are. What is different about Icon is the backtracking
> mechanism.
>
> >This can be achieved by using the language in ways that  would make
> >it more note-worthy to those using other programming languages.
>
> Which is difficult if it lacks facilities needed for the application
> areas that they are most likely to notice.
>
> >It cannot be further enhanced by what would represent
> >its degradation to the level of what other languages regard as
> >essential.
>
> You're begging the question. You've said nothing to back up a claim
> that Mr. Lhota's suggestion would be a degradation of Icon.
>
> >Furthermore, by adopting the usages of other languages, the users of
> >Icon will  be thrown into the arena of issues facing the development
> >of those other  languages,
>
> What do you mean by "adopting"? Providing new language features does
> not force anybody to use them.
>
> >issues which the basic principles of Icon are so well suited to
> >solve as they are.
>
> It's precisely because they are *not* well suited that Mr. Lhota
> suggested enhancements.
>
> >I am not a computer specialist,
>
> I am. And I agree with Mr. Lhota.
>
> --
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2, Team OS/2, Team PL/I
>
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
>
> I mangled my E-mail address to foil automated spammers; reply to
> domain Patriot dot net user shmuel+news to contact me.  Do not
> reply to [e-mail]


From icon-group-sender Mon Aug  5 13:03:00 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75K2fs00739
    for icon-group-addresses; Mon, 5 Aug 2002 13:02:41 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Mon, 05 Aug 2002 17:33:15 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

This chart does not imply that Icon has not changed since its inception in
the mid-1970's, and as one who has worked on the language's development, I
assure you that the language has had many enhancements over the years. Since
I started using Icon in the mid-1980's, I have seen the following
improvements:

- Large integers;
- Multithreaded Icon programs;
- Memory monitoring, which was later generalized to Event monitoring;
- A built-in preprocessor;
- string invokation, along with the "invokable" declaration and the "proc"
function; and
- GUI support.

Along with these changes, there were the inevitable bug fixes and
optimizations, along with various smaller improvements. The resulting
language is faster, stabler, more powerful, and easier to use than its
predecessors. None of these enhancements compromise Icon's basic strengths,
such as generators, co-expressions, and string scanning.

There have been no major changes in Icon in recent years, but this
stagnation is mostly a recent phenomenon. Throughout most of the nearly two
decades I've been following the language, it was evolving in many exciting
ways, while still retaining its core strengths.





From icon-group-sender Mon Aug  5 13:04:58 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75K4uw00967
    for icon-group-addresses; Mon, 5 Aug 2002 13:04:56 -0700 (MST)
Message-Id: <[e-mail]>
From: "Shmuel (Seymour J.) Metz" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Mon, 05 Aug 2002 13:12:27 -0400
Mail-Copies-To: nobody
X-Cise: [e-mail]
X-CompuServe-Customer: Yes
X-Coriate: [e-mail]
X-Ecrate: tanandtanlawyers.com
X-Punge: Micro$oft
X-Sanguinate: [e-mail]
X-Terminate: SPA(GIS)
X-Tinguish: Mark Griffith <[e-mail]>
X-Treme: C&C,DWS
X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO


In <[e-mail]>, on 08/04/2002
   at 09:43 AM, [e-mail] (Gene Kahn) said:

>Can someone enlighten me on what exactly is *revolutionary* about
>Icon's approach to programming? Thanks.

The expression evaluation and control structures of Icon are all
integrated with the notion of backtracking. When you evaluate an
expression, it can either return a value or fail. In general, when an
expression contains a failed subexpression, it will backtrack and
reevaluate an earlier subexpression, which in turn will either return
a new value or fail. The control structures for iteration and
selection behave somewhat differently from their equivalents in
conventional languages.

Essentially the backtracking in pattern matching has been promoted
from a niche facility to an integral part of the language. Everything
is different, even when the code superficially seems ordinary.

There may be some sample code in the FAQ to illustrate how that works.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to [e-mail]



From icon-group-sender Mon Aug  5 13:05:15 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g75K5Cc01045
    for icon-group-addresses; Mon, 5 Aug 2002 13:05:12 -0700 (MST)
Message-Id: <[e-mail]>
From: "Frank J. Lhota" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Date: Mon, 05 Aug 2002 19:18:28 GMT
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO


"Frank J. Lhota" <[e-mail]> wrote in message
news:vFy39.1699$[e-mail]...
> Since
> I started using Icon in the mid-1980's, I have seen the following
> improvements:
>
> - Large integers;
> - Multithreaded Icon programs;
> - Memory monitoring, which was later generalized to Event monitoring;
> - A built-in preprocessor;
> - string invokation, along with the "invokable" declaration and the "proc"
> function; and
> - GUI support.

I can't believe I forgot this mid-1980's enhancement: sets! Believe it or
not, the first several versions of Icon had tables, in all their glorious
generality, but no notion of sets except for csets. Also, the "delete"
function was added around the same time; in early versions of Icon, you
could add a member to a table, but you could not remove a member.




From icon-group-sender Tue Aug  6 07:07:32 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76E7G206260
    for icon-group-addresses; Tue, 6 Aug 2002 07:07:16 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Tue, 6 Aug 2002 05:09:28 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <vFy39.1699$[e-mail]>,
[e-mail] says...
> There have been no major changes in Icon in recent years, but this
> stagnation is mostly a recent phenomenon. Throughout most of the nearly two
> decades I've been following the language, it was evolving in many exciting
> ways, while still retaining its core strengths.
>

Going back to your comparison of Beta and VHS, and the superior detail that
enabled VHS to become popular, it did so because it knew what niche to fill in
the field of film recording in general.  In the same way, a language that
becomes more popular nowadays should fit a niche in the field of computers in
general.  The problem now is that such a field has changed, or rather widened,
in the last few years.  Therefore the defficiency that is being exposed in the
traditional languages and the havoc being wrought by new and often curious
languages being frantically created.  So where do we look for a niche?  The
natural development, that would have lasting consequences for any newer
language, is in the computer architecture itself, I think.  We will have to
recognize the need for a common, generally well-suited architecture, and it is
likely that this development will not occur as quickly or be as exciting as
previous developments in computing.  It may not happen for a long time yet.
The niches that could be filled are therefore not clearly defined, even
considering the wider acceptance and use of computers.  It is like saying that
during the time that VHS was adopted instead of Beta, other trademarks were
adopted by other T.V.s due to the big difference in T.V. architectures, so that
even though cable made T.V. much more popular, the difference in architectures
made it impossible to decide which film recording company was better or more
attractive.   And would there have been any reason for adopting a uniform T.V.
architecture?   Why is that a problem in computers and not in T.V.s?  Is it not
a problem after all?  Since it appears that programs written for one computer
can't be run in another, should we assume that it is because the architectures
are different, or that the language has not been implemented for that machine?
And if it is a relative issue, doesn't that say something about our ignorance
of the importance of the computer architecture in issues related to the
development of computer languages?   Such ignorance can be remedied, if in our
efforts to develop newer versions of the language we are careful to base all
our decisions on a careful analysis of how the new development in Icon would
represent the best possible development of such an addition in the context of
where it is currently represented in other languages, if that is the case.  For
example, in the case of classes, the form in which such an addition is made in
Icon should be in such a way that it represents exactly what those languages
which use classes need to make their use of classes even better.  If not, such
an addition to Icon is suspect of being rather a detraction.  So, we would need
first to decide which languages use classes in a way that can be improved on,
and whether they do in effect use classes effectively, pick one, and then see
what can be improved in its context.  Only then would we decide to add it to
Icon.  If not, we would be trying to compete, with Icon, in an Object Oriented
framework, which is not already a part of the language.


From icon-group-sender Tue Aug  6 07:10:10 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76EA8c06579
    for icon-group-addresses; Tue, 6 Aug 2002 07:10:08 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 5 Aug 2002 20:56:10 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

"Shmuel (Seymour J.) Metz" <[e-mail]> wrote in message news:<3d4eb1fb$14$fuzhry+tra$[e-mail]>...
> In <[e-mail]>, on 08/04/2002
>    at 09:43 AM, [e-mail] (Gene Kahn) said:
>
> >Can someone enlighten me on what exactly is *revolutionary* about
> >Icon's approach to programming? Thanks.
>
> The expression evaluation and control structures of Icon are all
> integrated with the notion of backtracking. When you evaluate an
> expression, it can either return a value or fail. In general, when an
> expression contains a failed subexpression, it will backtrack and
> reevaluate an earlier subexpression, which in turn will either return
> a new value or fail. The control structures for iteration and
> selection behave somewhat differently from their equivalents in
> conventional languages.
>
> Essentially the backtracking in pattern matching has been promoted
> from a niche facility to an integral part of the language. Everything
> is different, even when the code superficially seems ordinary.
>

How is this different from Prolog in ways that make Icon a better or
*revolutionary* approach to programming?

> There may be some sample code in the FAQ to illustrate how that works.
>
> --
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2, Team OS/2, Team PL/I
>
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
>
> I mangled my E-mail address to foil automated spammers; reply to
> domain Patriot dot net user shmuel+news to contact me.  Do not
> reply to [e-mail]


From icon-group-sender Tue Aug  6 07:10:31 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76EATk06631
    for icon-group-addresses; Tue, 6 Aug 2002 07:10:29 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 6 Aug 2002 16:18:28 +1200 (NZST)
From: "Richard A. O'Keefe" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

Cheyenne Wills <[e-mail]> suggests
    1) Change the name.  Yes the meaning of Icon was kind of neat. However
    must people out there probably think of those little images stuck on the
    screen when someone mentions Icon.  My suggestion... IPL -- we get to
    keep a little inside joke (IconProgrammingLanguage) -- but it gets us
    away from having to reply that "No this is a programming language -- not
    something about little desktop images).

But there is already a language family called IPL.
I'm not old enough to have _used_ IPL-V, but I am old enough to have
had an IPL-V manual in my hands.  We really don't want people thinking
that IPL (=Icon) was obsoleted by Lisp when it was IPL-V that was.



From icon-group-sender Tue Aug  6 07:11:05 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76EB3606717
    for icon-group-addresses; Tue, 6 Aug 2002 07:11:03 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Tue, 6 Aug 2002 06:10:03 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <[e-mail]>, [e-mail]
says...
> How is this different from Prolog in ways that make Icon a better or
> *revolutionary* approach to programming?
>

If you can't write in the English language, you will not be able to write, much
less understand, revolutionary new approaches to computer programming.


From icon-group-sender Tue Aug  6 07:11:16 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76EBEs06751
    for icon-group-addresses; Tue, 6 Aug 2002 07:11:14 -0700 (MST)
Message-Id: <[e-mail]>
From: Christopher Browne <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 6 Aug 2002 04:39:27 GMT
X-Draft-From: ("nnvirtual:Languages" 911)
X-Home-Page: http://www.cbbrowne.com/info/
X-Emacs-Acronym: Eventually Munches All Computer Storage
Microsoft: Making the world a better place... for Microsoft.
X-Uboat-Death-Message: SALESMEN. ANNOYED. LEAVE BOAT. U-50.
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In an attempt to throw the authorities off his trail, ernobe <[e-mail]> transmitted:
> In article <[e-mail]>, [e-mail]
> says...
>> How is this different from Prolog in ways that make Icon a better
>> or *revolutionary* approach to programming?

> If you can't write in the English language, you will not be able to
> write, much less understand, revolutionary new approaches to
> computer programming.

But seriously, how does the backtracking found in Icon differ from
Prolog in ways that make it a better or *revolutionary* approach to
programming?

I think it's a *very* good question.  I think it would be a *very*
good question even if it were presented replete with painfully awful
grammar and spelling.  (That would, more than likely, indicate that
English was not the writer's first language, not that the question was
bad.)

I think that a _partial_ "good answer" might be that Icon has a
conventional "Algol-like" syntax that provides a rather more familiar
syntax for writing imperative code.  Prolog's pretty neat when
requirements are purely about "quasi-nondeterministic search;" it's
not nearly so nice when you want to do things like:
 - Looping on input;
 - Looping pretty much anything else;
 - Doing anything imperative.

But I don't think that's necessarily a "good enough" answer to indicate
that Icon is downright "revolutionary."
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://cbbrowne.com/info/linux.html
I'M SORRY, LUSER, I CAN'T LET YOU DO THAT.  WHY DON'T YOU LIE DOWN AND
TAKE A STRESS PILL?  MY NAME IS  LM1.  I WAS  MADE AT THE LISP MACHINE
FACTORY  IN MASSACHUSETTS ON  DECEMBER 12, 1992.   MY  TEACHER WAS MR.
WINSTON.  HE TAUGHT ME A PROGRAM.  WOULD YOU LIKE TO  SEE IT?  HERE IT
IS:


From icon-group-sender Tue Aug  6 07:11:25 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76EBN206783
    for icon-group-addresses; Tue, 6 Aug 2002 07:11:23 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: "Richard A. O'Keefe" <[e-mail]>
Cc: [e-mail]
Date: 06 Aug 2002 07:26:58 -0600
Errors-To: [e-mail]
Status: RO

Wow... I forgot all about that.. I remember hearing about it..

Cheyenne..

On Mon, 2002-08-05 at 22:18, Richard A. O'Keefe wrote:
> Cheyenne Wills <[e-mail]> suggests
>     1) Change the name.  Yes the meaning of Icon was kind of neat. However
>     must people out there probably think of those little images stuck on the
>     screen when someone mentions Icon.  My suggestion... IPL -- we get to
>     keep a little inside joke (IconProgrammingLanguage) -- but it gets us
>     away from having to reply that "No this is a programming language -- not
>     something about little desktop images).
>
> But there is already a language family called IPL.
> I'm not old enough to have _used_ IPL-V, but I am old enough to have
> had an IPL-V manual in my hands.  We really don't want people thinking
> that IPL (=Icon) was obsoleted by Lisp when it was IPL-V that was.
>
>



From icon-group-sender Tue Aug  6 12:28:24 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76JQts26573
    for icon-group-addresses; Tue, 6 Aug 2002 12:26:55 -0700 (MST)
Message-Id: <[e-mail]>
To: "Richard A. O'Keefe" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Icon Wish List
Content-ID: <[e-mail]>
Date: Tue, 06 Aug 2002 16:28:37 +0200
From: "Olivier Lecarme" <[e-mail]>
Errors-To: [e-mail]
Status: RO

>>>>> On Tue, 6 Aug 2002 16:18:28 +1200 (NZST),  you said:

R> Cheyenne Wills <[e-mail]> suggests
R>     1) Change the name.  Yes the meaning of Icon was kind of neat. However
R>     must people out there probably think of those little images stuck on the
R>     screen when someone mentions Icon.  My suggestion... IPL -- we get to
R>     keep a little inside joke (IconProgrammingLanguage) -- but it gets us
R>     away from having to reply that "No this is a programming language -- not
R>     something about little desktop images).

R> But there is already a language family called IPL.
R> I'm not old enough to have _used_ IPL-V, but I am old enough to have
R> had an IPL-V manual in my hands.  We really don't want people thinking
R> that IPL (=Icon) was obsoleted by Lisp when it was IPL-V that was.

I am old enough to have used IPL-V, and even implemented it on a really
obscure computer (the memory was a 32K drum). It has not really be
obsoleted by Lisp, but rather by its own characteristics, since it was
an assembly-like language. However, its generator feature has been
obsoleted only by Icon, in my opinion.

Anyway, even if nobody more remembers of Newell, Shaw ans Simon's
language, you cannot use this name.

--


            Olivier Lecarme


From icon-group-sender Tue Aug  6 12:29:14 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76JT2A26774
    for icon-group-addresses; Tue, 6 Aug 2002 12:29:02 -0700 (MST)
Message-Id: <[e-mail]>
To: [e-mail]
From: "Alexandre E. Kopilovitch" <[e-mail]>
Date: Tue,  6 Aug 2002 19:40:21 +0400 (MSD)
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

In <[e-mail]> Christopher Browne <[e-mail]> wrote:
>But seriously, how does the backtracking found in Icon differ from Prolog

The main difference is that the backtracking in Icon is much more controllable
mechanism than in Prolog.

>in ways that make it a better or *revolutionary* approach to programming?

It isn't generally "better", much less "revolutionary", it is just well-thought
and suitable for some kind of applications, where a fine-grained control of
the backtracking is desirable.


Alexander Kopilovitch                      [e-mail]
Saint-Petersburg
Russia



From icon-group-sender Tue Aug  6 12:29:47 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g76JTZQ26830
    for icon-group-addresses; Tue, 6 Aug 2002 12:29:35 -0700 (MST)
Message-Id: <[e-mail]>
From: "Paul W. Abrahams" <[e-mail]>
To: [e-mail]
Subject: Are dynamic typing/expression evaluation orthogonal?
Date: Tue, 6 Aug 2002 13:56:30 -0400
Errors-To: [e-mail]
Status: RO

Perhaps the two most notable features of Icon are its dynamic typing (as
opposed to strong typing) and its unique and powerful approach to expression
evaluation.   I happen to disagree with dynamic typing, but I think Icon's
expression evaluation paradigm is magnificent.

So the question is this: does Icon expression evaluation depend somehow on
dynamic typing or make use of dynamic typing in an essential way?  Or are the
two concepts orthogonal?

Looking at it another way: could one build a programming language that had
strong, even Ada-ish typing, but the Icon model of expression evaluation?
Or would that be an attempt to couple two incompatible design concepts?

I hope that the discussion of this question (if there is any) doesn't get
bogged down in the question of whether strong typing is a good idea or not.

Paul Abrahams


From icon-group-sender Wed Aug  7 11:46:27 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g77Ik5o10364
    for icon-group-addresses; Wed, 7 Aug 2002 11:46:05 -0700 (MST)
Message-Id: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: RE: Are dynamic typing/expression evaluation orthogonal?
Date: Tue, 6 Aug 2002 13:33:26 -0700
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Are dynamic typing/expression evaluation orthogonal?
Thread-Index: AcI9gK+5N95+AEbVS2KguSRits6pGwAB3Omg
From: "Todd Proebsting" <[e-mail]>
To: "Paul W. Abrahams" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Aug 2002 20:33:35.0445 (UTC) FILETIME=[89ACE050:01C23D88]
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g76KXdw03460
Errors-To: [e-mail]
Status: RO

I believe dynamic typing and goal-directed evaluation are orthogonal.
After implementing an Icon compiler (Jcon), I'm now certain that there
is nothing about static typing that is counter to goal-directed
evaluation.

Todd

-----Original Message-----
From: Paul W. Abrahams [mailto:[e-mail]]
Sent: Tuesday, August 06, 2002 10:57 AM
To: [e-mail]
Subject: Are dynamic typing/expression evaluation orthogonal?


Perhaps the two most notable features of Icon are its dynamic typing (as

opposed to strong typing) and its unique and powerful approach to
expression
evaluation.   I happen to disagree with dynamic typing, but I think
Icon's
expression evaluation paradigm is magnificent.

So the question is this: does Icon expression evaluation depend somehow
on
dynamic typing or make use of dynamic typing in an essential way?  Or
are the
two concepts orthogonal?

Looking at it another way: could one build a programming language that
had
strong, even Ada-ish typing, but the Icon model of expression
evaluation?
Or would that be an attempt to couple two incompatible design concepts?

I hope that the discussion of this question (if there is any) doesn't
get
bogged down in the question of whether strong typing is a good idea or
not.

Paul Abrahams



From icon-group-sender Wed Aug  7 11:46:38 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g77Ikas10425
    for icon-group-addresses; Wed, 7 Aug 2002 11:46:36 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 6 Aug 2002 22:21:27 -0600
From: Clint Jeffery <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO


[ernobe says languages should follow computer architectures]

Another viewpoint is that languages should follow application problem
domains.  I think languages should follow both, and as far as language
design is concerned, "architectures" should include operating systems,
I/O API's, etc.

[ernobe says classes would be a detraction if not done by studying and
 improving upon other programming languages that use classes.]

Classes are not part of Icon, and probably are never going to be part of
Icon.  So aside from being too abstract, this discussion is sort of moot.

That said, then sure, ernobe states a sort of obvious truth.  One does not
add classes without studying what they are to be used for.  But, as one of
the proposers of "class" facilities for Icon, I think doing classes well
for Icon would depend more on (a) fitting Icon very naturally and well,
and (b) serving application domains where classes are used (modeling, design,
and simulation; UML for example), rather than being derivative of other
programming languages' classes.  In other words, its more important that
these hypothetical Icon classes map well from UML than that they imitate
or improve on C++ or Java, for example.

I am enjoying others' posts on these topics.

Clint


From icon-group-sender Thu Aug  8 09:32:37 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78GVas18916
    for icon-group-addresses; Thu, 8 Aug 2002 09:31:36 -0700 (MST)
Message-Id: <[e-mail]>
From: "John Sampson" <[e-mail]>
To: <[e-mail]>
Subject: Icon interpreter in Scheme
Date: Thu, 8 Aug 2002 10:37:11 +0100
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Errors-To: [e-mail]
Status: RO

Hello -

This may be old news, but I have come across a paper describing an Icon
subset interpreter written in Scheme -

cs.hamilton.edu/~bailey/pubs/techreps/CS-90-35.pdf

Regards

_John Sampson_



From icon-group-sender Thu Aug  8 13:08:46 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78K7p627346
    for icon-group-addresses; Thu, 8 Aug 2002 13:07:51 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Thu, 8 Aug 2002 19:03:53 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In article <ainjtu$1667do$[e-mail]>, [e-mail] says...
> But I don't think that's necessarily a "good enough" answer to indicate
> that Icon is downright "revolutionary."
>

Whether Icon is better than Prolog or vice-versa, it doesn't make either one
revolutionary.  Rather than using all sorts of signs to highlight the word
revolutionary in your posts, you should first find out the definition of the
word.


From icon-group-sender Thu Aug  8 13:09:22 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78K96A27561
    for icon-group-addresses; Thu, 8 Aug 2002 13:09:06 -0700 (MST)
Message-Id: <[e-mail]>
From: Bill Trost
 <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020716
X-Accept-Language: en-us, en
X-Newsgroups: comp.lang.icon
Subject: dynamically linking Icon code?
X-Complaints-To: [e-mail]
Date: Thu, 08 Aug 2002 19:00:32 GMT
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Is there any sort of facility in Icon for the dynamic linking of Icon
code? I understand there's a mechanism for linking binary code, but the
ability to link Icon libraries would be really useful to me.

Thanks,
Bill



From icon-group-sender Thu Aug  8 13:10:10 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78K9vM27747
    for icon-group-addresses; Thu, 8 Aug 2002 13:09:57 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 8 Aug 2002 11:50:54 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Christopher Browne <[e-mail]> wrote in message news:<ainjtu$1667do$[e-mail]>...

> But I don't think that's necessarily a "good enough" answer to indicate
> that Icon is downright "revolutionary."

Does Icon offer anything unique and overwhelmingly useful that other
languages don't have or do less ably? (How's that for another
convoluted question?)


Christopher Browne <[e-mail]> wrote in message news:<ainjtu$1667do$[e-mail]>...
> In an attempt to throw the authorities off his trail, ernobe <[e-mail]> transmitted:
> > In article <[e-mail]>, [e-mail]
> > says...
> >> How is this different from Prolog in ways that make Icon a better
> >> or *revolutionary* approach to programming?
>
> > If you can't write in the English language, you will not be able to
> > write, much less understand, revolutionary new approaches to
> > computer programming.
>
> But seriously, how does the backtracking found in Icon differ from
> Prolog in ways that make it a better or *revolutionary* approach to
> programming?
>
> I think it's a *very* good question.  I think it would be a *very*
> good question even if it were presented replete with painfully awful
> grammar and spelling.  (That would, more than likely, indicate that
> English was not the writer's first language, not that the question was
> bad.)
>
> I think that a _partial_ "good answer" might be that Icon has a
> conventional "Algol-like" syntax that provides a rather more familiar
> syntax for writing imperative code.  Prolog's pretty neat when
> requirements are purely about "quasi-nondeterministic search;" it's
> not nearly so nice when you want to do things like:
>  - Looping on input;
>  - Looping pretty much anything else;
>  - Doing anything imperative.
>
> But I don't think that's necessarily a "good enough" answer to indicate
> that Icon is downright "revolutionary."


From icon-group-sender Thu Aug  8 13:11:22 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78KB3E28010
    for icon-group-addresses; Thu, 8 Aug 2002 13:11:03 -0700 (MST)
Message-Id: <[e-mail]>
From: Christopher Browne <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 8 Aug 2002 19:34:05 GMT
X-Draft-From: ("nnvirtual:Languages" 623)
X-Home-Page: http://www.cbbrowne.com/info/
X-Emacs-Acronym: Emacs Makes A Computer Slow
Microsoft: World domination wasn't enough -- we had to write bad software, too!
X-Shopping-List:
   (1) Hideous spastic fiction annoyers
   (2) Ornery samples
   (3) Schizophrenic bug companions
   (4) Oratorical hatred prosecutors
X-Uboat-Death-Message:
   BOMBED BY SPACE-TIME VORTEX. UNABLE TO DIVE. SINKING. U-946.
To: [e-mail]
Errors-To: [e-mail]
Status: RO

ernobe <[e-mail]> wrote:
> In article <ainjtu$1667do$[e-mail]>, [e-mail] says...
>> But I don't think that's necessarily a "good enough" answer to indicate
>> that Icon is downright "revolutionary."

> Whether Icon is better than Prolog or vice-versa, it doesn't make
> either one revolutionary.  Rather than using all sorts of signs to
> highlight the word revolutionary in your posts, you should first
> find out the definition of the word.

Why should that be of any great importance?

The point is not to highlight that, but rather to figure out why, if
there _is_ a why, Icon should be considered important to the point of
being associated with words like "revolutionary."

I don't care about the exact term, whether it's "revolutionary,"
"splendiferously interesting," or, more pointedly, "worthwhile for
someone considering using Perl to spend a few minutes looking at."

I thought the latter was rather the point, to see if there are still
distinctive things about Icon that make it worth looking at, even for
those that would be inclined to regard it as an ancient dead language.

That Icon supports backtracking can't be _quite_ enough to deserve
interest, as there are more famous languages, such as Prolog, that
also support backtracking.

If you want to jump into some sort of Clintonian "what does 'is'
mean?" thing, that's certainly your right.  That isn't likely to lead
to any useful answers.

I'd think a more useful retort to be something like "Sure, Prolog also
supports backtracking, but who would be so stupid as to want to
develop code in Prolog?"  That's also insulting, but would at least
direct us to the question of how Prolog _differs_ from Icon, and lead
towards some sort of resolution.

But if you want to play games with dictionaries, feel free...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Signs of a Klingon Programmer  #12: "Specifications  are for the  weak
and timid!"


From icon-group-sender Thu Aug  8 16:44:58 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78NiSI05429
    for icon-group-addresses; Thu, 8 Aug 2002 16:44:28 -0700 (MST)
Message-Id: <[e-mail]>
Subject: RE: Icon Wish List
To: [e-mail]
From: [e-mail]
Date: Thu, 8 Aug 2002 15:56:51 -0500
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.9a
 |January 7, 2002) at 08/08/2002 03:57:08 PM
Errors-To: [e-mail]
Status: RO

I've been using Icon since 1985.
Why?

1. It was available for many platforms, so I had a tool
    that I could use immediately on :
      o DOS
      o VMS
      o UNIX
      o Others...

2. It was a clean language that let you write a solution
    without having to fight variable types and casting.

3. It did not require much tech support. Once you got
     it installed and had "The Icon Programming Language" book
     you were pretty well set.

In more recent years the VMS implementation kind of
died, but I wish it existed for Alpha VMS. It's big bug was inability to
handle char(255) or \xff, the highest ascii value.

Now being mostly unix, I used it as a script language.
It ran faster than shell script, and had tighter control.
But management thinks it's a niche product so I had
to convert 95% of them to posix shell script. I write posix in
icon style ;-).    However, I still use Icon in areas that
posix shell is not as well suited such as:

      parsing CGI strings in web processing
      things with time calculations
      things that use boolean sets
      X-windows graphics

On the PC platform I still use DOS incarnations of icon.
It is still great for processing files without all the procedural
overhead that comes with GUI tools. If I need Icon to
run another DOS program I still have Icon 5.9 from 1985
that fits in under 100K. Yes, it still works under the Windows XP
command prompt.

I am very happy with the language.

Chris Tenaglia, technical analyst, Johnson Controls.




From icon-group-sender Thu Aug  8 16:46:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g78Njxk05726
    for icon-group-addresses; Thu, 8 Aug 2002 16:45:59 -0700 (MST)
Message-Id: <[e-mail]>
Date: Thu, 8 Aug 2002 17:07:27 -0400 (EDT)
From: Taybin Rutkin <[e-mail]>
X-Sender: [e-mail]
To: Gene Kahn <[e-mail]>
cc: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

On 8 Aug 2002, Gene Kahn wrote:

> > But I don't think that's necessarily a "good enough" answer to indicate
> > that Icon is downright "revolutionary."
>
> Does Icon offer anything unique and overwhelmingly useful that other
> languages don't have or do less ably? (How's that for another
> convoluted question?)

If you're looking for specific features, well, they can be duplicated in
most other languages.  What I like most about Icon was that if I thought
of a coding technique, and tried it, it would just work.  There's
something about the language which just made it easier to understand how
all the parts worked together.  I think this is because it was designed so
well.  The syntax is nice (even if I still don't have all the operators
memorized).  But the deep semantics are just wonderful.

I wish I could remember an example.  I have a small website that has an
even smaller fan page about Icon; mostly small assignments I used it for
in college.  http://physics.clarku.edu/~trutkin/Icon/index.html.  It is
just the hands down, easiest language I worked with.

I had a couple complaints about it though.  I couldn't figure out how to
read or write binary files with it (is this possible?).  And I never felt
so buffered from the machine as when I was programming in Icon.  It felt
like I was in this wonderful programming enviroment except that I couldn't
get any data in unless it was created by the program.

I don't know if any language has a large number of unique and compelling
features from another language.  They influence and build upon each other
to such an extent that they share many of the good ideas.  I just found
Icon much more fun to use then Python (which I consider to be the language
most similar to it).

Taybin



From icon-group-sender Fri Aug  9 12:42:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g79Jf9Q15026
    for icon-group-addresses; Fri, 9 Aug 2002 12:41:09 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 9 Aug 2002 10:03:29 -0700 (MST)
From: Gregg Townsend <gmt>
To: icon-group
Subject: Re: dynamically linking Icon code?
Errors-To: [e-mail]
Status: RO

>  Is there any sort of facility in Icon for the dynamic linking of Icon
>  code?

Not in the standard C implementation.  The Java implementation, Jcon,
can dynamically load and link Icon procedures translated by Jcon.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA


From icon-group-sender Fri Aug  9 12:42:55 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g79JgpM15416
    for icon-group-addresses; Fri, 9 Aug 2002 12:42:51 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 9 Aug 2002 12:11:41 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Thank you, Mr. Browne, for making clear what exactly the issues are.
As to poster ernobe, I realized quickly that I would not be getting
much help from him as to whether I should give Icon a try or not, so,
after the initial query to him, I simply ignored his postings.



Christopher Browne <[e-mail]> wrote in message news:<aiuh3c$17ne15$[e-mail]>...
> ernobe <[e-mail]> wrote:
> > In article <ainjtu$1667do$[e-mail]>, [e-mail] says...
> >> But I don't think that's necessarily a "good enough" answer to indicate
> >> that Icon is downright "revolutionary."
>
> > Whether Icon is better than Prolog or vice-versa, it doesn't make
> > either one revolutionary.  Rather than using all sorts of signs to
> > highlight the word revolutionary in your posts, you should first
> > find out the definition of the word.
>
> Why should that be of any great importance?
>
> The point is not to highlight that, but rather to figure out why, if
> there _is_ a why, Icon should be considered important to the point of
> being associated with words like "revolutionary."
>
> I don't care about the exact term, whether it's "revolutionary,"
> "splendiferously interesting," or, more pointedly, "worthwhile for
> someone considering using Perl to spend a few minutes looking at."
>
> I thought the latter was rather the point, to see if there are still
> distinctive things about Icon that make it worth looking at, even for
> those that would be inclined to regard it as an ancient dead language.
>
> That Icon supports backtracking can't be _quite_ enough to deserve
> interest, as there are more famous languages, such as Prolog, that
> also support backtracking.
>
> If you want to jump into some sort of Clintonian "what does 'is'
> mean?" thing, that's certainly your right.  That isn't likely to lead
> to any useful answers.
>
> I'd think a more useful retort to be something like "Sure, Prolog also
> supports backtracking, but who would be so stupid as to want to
> develop code in Prolog?"  That's also insulting, but would at least
> direct us to the question of how Prolog _differs_ from Icon, and lead
> towards some sort of resolution.
>
> But if you want to play games with dictionaries, feel free...


From icon-group-sender Fri Aug  9 16:40:28 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g79NeDA26179
    for icon-group-addresses; Fri, 9 Aug 2002 16:40:13 -0700 (MST)
Message-Id: <[e-mail]>
From: ernobe <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Sat, 10 Aug 2002 00:28:19 +0200
X-Newsreader: MicroPlanet Gravity v2.50
To: [e-mail]
Errors-To: [e-mail]
Status: RO



OK, let's get this straight, Mr. Browne. First I was asked how Icon was
revolutionary.  Now I'm being asked how Icon is more revolutionary than Prolog.
I have already answered the first question, and I stand by it, regardless of
how you may choice to interpret the word revolutionary.  That is my
understanding of revolutionary. Therefore if you want to get my views on what
else I regard as revolutionary, such as Prolog, you would have to explain how
Prolog is more revolutionary, in the context of the reasons given to support
the view that Icon is revolutionary.


From icon-group-sender Mon Aug 12 09:03:46 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CG2Xc05216
    for icon-group-addresses; Mon, 12 Aug 2002 09:02:33 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: Icon Group <[e-mail]>
Date: 09 Aug 2002 18:14:11 -0600
Errors-To: [e-mail]
Status: RO

On Thu, 2002-08-08 at 15:07, Taybin Rutkin wrote:

>
> I had a couple complaints about it though.  I couldn't figure out how to
> read or write binary files with it (is this possible?).  And I never felt
> so buffered from the machine as when I was programming in Icon.  It felt
> like I was in this wonderful programming enviroment except that I couldn't
> get any data in unless it was created by the program.
>

probably more then anyone really wants to know... (and this is
documented in the "Icon Programming Language" book -- for the 3rd ed it
starts on page 138.

binfile := open("somefile","ur")   # Open somefile for binary reading
binofile := open("someother","uw") # Open someother file for binary
writing

txtfile := open("sometext","tr")   # Open text file for reading
txtofile := open("someothertxt","tw") # Open text file for writing

All the options are:

a - append
r - read
w - write
c - create
b - read/write
t - translated (modifier)
u - untranslated (modifier)
p - pipe (modifier) (if supported by platform)
g|x - graphics

Defaults are rt

t and u are modifiers so they are used in conjunction with the "a",
"r","w" and "b" options.

p is a modifier that can only be used by the "r" and "w" options

Translated mode basically means that on input any "line ending" is
translated to a \n and on output any \n is translated to the native line
ending (for example under MSDOS/Windows) a \n is translated to a \r\n.
The actual line end translantion happens not so much in the Icon runtime
code, but in the underlying C runtime code that is used.  Also for
translated mode any \n is "removed" from the input and added at the end
of a line for output.

Cheyenne


From icon-group-sender Mon Aug 12 09:05:30 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CG5OA05711
    for icon-group-addresses; Mon, 12 Aug 2002 09:05:24 -0700 (MST)
Message-Id: <[e-mail]>
From: Jesse Tov <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 10 Aug 2002 08:07:21 GMT
User-Agent: slrn/0.9.7.4 (Linux)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Christopher Browne <[e-mail]>:
> I'd be interested in hearing good answers to that question.

I'm new here, but since this discussion has been far from engaging,
I'll contribute what little I can.

Why is it worth knowing about Icon?  It's a combination of two main
reasons: First, it's a clean, high-level language with especially good
string handling capabilities and a reasonable general-purpose feature
set; second, it has an interesting flow control paradigm.

In many ways, Icon is comparable to other high-level, imperative,
dynamically-typed "scripting" languages such as Perl and Python.  You
can write programs at about the same level of abstraction, and like
Python it can be interpreted or byte-compiled.  It's probably easier
to learn than Perl and about the same as Python.  It doesn't have the
object oriented features of either, nor the huge library of Perl.
None of this alone is sufficient to make it noteworthy, but it's
important because this makes it considerably more familiar than
Prolog to many of us.

What's really interesting is the goal-directed evaluation
(backtracking).  This is not in itself new and unique: Prolog and
SNOBOL both had this before Icon did, and you can write backtracking
in any language.  What's neat about Icon, then, is that it provides
this built-in backtracking mechanism in a familar-seeming language.

The result is that Icon is easy to learn, and it makes easy to write
solutions for search problems.  Icon helps you think about problems
differently: you come up with a way to recognize a solution, apply it
to an expression that generates some solution space, and let Icon
search for the right result.  Of course you could write it in another
language, and it might even be more efficient, but like many
higher-level languages, Icon seems especially suitable when programmer
time is more valuable than computer time.

I wouldn't call this "revolutionary," but neither would I call it
"trivial."  I call it "cool."  If, like me, you appreciate interesting
programming languages, and want to have a variety of tools at your
disposal, you may find Icon worth learning about.

Jesse
--
"A hungry man is not a free man."         --Adlai Stevenson


From icon-group-sender Mon Aug 12 09:08:03 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CG7GE06011
    for icon-group-addresses; Mon, 12 Aug 2002 09:07:16 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gregg Townsend)
X-Newsgroups: comp.lang.icon
Subject: Icon language book available for downloading
Date: 10 Aug 2002 11:47:43 -0700
To: [e-mail]
Errors-To: [e-mail]
Status: RO

The standard reference for Icon is "The Icon Programming Language"
(third edition) by Ralph and Madge Griswold, sometimes called the
"blue book".  As its publishers have turned their attention to other
matters, the book has become increasingly difficult to find.

An on-line copy of the book has been prepared in PDF form and is
available for free downloading from
    http://www.cs.arizona.edu/icon/books.htm
The on-line copy incorporates corrections for the small number of
errors found since publication.

Printed copies are still available from sources linked on that page.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Mon Aug 12 09:20:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGKYc08264
    for icon-group-addresses; Mon, 12 Aug 2002 09:20:34 -0700 (MST)
Message-Id: <[e-mail]>
Date: Sun, 11 Aug 2002 05:31:15 -0400
From: Ian Trudel <[e-mail]>
To: [e-mail]
Subject: Calling Icon from C program [..]
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Errors-To: [e-mail]
Status: RO

Hi folks,

   I've been reading icon's mailing list lately and, of course, I've read all about the wish list thread. Among the things suggested by Frank, he wrote about better interfacing to external programs (calling C from Icon) which is kinda awkward right now in Icon. The features itself works on the platforms it's been implemented, but the interface makes it itchy to sucessfully develop your own library.

Anyway, I was searching materials for some Icon things I've got to do and I found, in IPD236, the following change (section 2.5, other changes):

      "The ability to configure Icon so that Icon procedures can
        be called from a C program has been eliminated."

Two questions rose in my mind. First, why this yet desirable feature has been pulled out? Secondly, I was rather currious about it's implementation, probably found in version 8 of the source code, but I did *not* found any icon source code archives! If someone could point me out where I can obtain, let's say, v8 of the source code, please, email me.

regards,
ian


From icon-group-sender Mon Aug 12 09:23:05 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGN2w08668
    for icon-group-addresses; Mon, 12 Aug 2002 09:23:02 -0700 (MST)
Message-Id: <[e-mail]>
From: "Shmuel (Seymour J.) Metz" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Sun, 11 Aug 2002 07:50:02 -0400
Mail-Copies-To: nobody
X-Cise: [e-mail]
X-CompuServe-Customer: Yes
X-Coriate: [e-mail]
X-Ecrate: tanandtanlawyers.com
X-Punge: Micro$oft
X-Sanguinate: [e-mail]
X-Terminate: SPA(GIS)
X-Tinguish: Mark Griffith <[e-mail]>
X-Treme: C&C,DWS
X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In <aiuh3c$17ne15$[e-mail]>, on 08/08/2002
   at 07:34 PM, Christopher Browne <[e-mail]> said:

>That Icon supports backtracking can't be _quite_ enough to deserve
>interest, as there are more famous languages, such as Prolog, that
>also support backtracking.

Prolog supports backtracking for rule matching. Does it also support
backtracking in procedural code? In Icon the backtracking is
pervasive.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to [e-mail]



From icon-group-sender Mon Aug 12 09:23:23 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGNKE08725
    for icon-group-addresses; Mon, 12 Aug 2002 09:23:20 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Icon Wish 2
Date: 11 Aug 2002 07:44:42 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

An Icon.NET or a plug-in to the Eclipse development system will give
Icon good exposure. Plus .NET will provide many libraries that Icon
may not have access to at this point. Anybody working on these
projects?


From icon-group-sender Mon Aug 12 09:23:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGNu608868
    for icon-group-addresses; Mon, 12 Aug 2002 09:23:56 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 11 Aug 2002 07:37:23 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Jesse Tov <[e-mail]> wrote in message news:<[e-mail]>...

> Icon helps you think about problems
> differently: you come up with a way to recognize a solution, apply it
> to an expression that generates some solution space, and let Icon
> search for the right result.

Can you supply a solution space (other than naturally defined
sequences and ranges, typically numbers), in particular, a set of
methods or functions that will return the results that Icon will
evaluate? That is to say, how abstract are Icon's iterators? (I
suppose one can pre-call the functions and pre-build the solution
space in an array or hash.)

> [Icon] has an interesting flow control paradigm.

Would you care to elaborate on this one? Thanks.





Jesse Tov <[e-mail]> wrote in message news:<[e-mail]>...
> Christopher Browne <[e-mail]>:
> > I'd be interested in hearing good answers to that question.
>
> I'm new here, but since this discussion has been far from engaging,
> I'll contribute what little I can.
>
> Why is it worth knowing about Icon?  It's a combination of two main
> reasons: First, it's a clean, high-level language with especially good
> string handling capabilities and a reasonable general-purpose feature
> set; second, it has an interesting flow control paradigm.
>
> In many ways, Icon is comparable to other high-level, imperative,
> dynamically-typed "scripting" languages such as Perl and Python.  You
> can write programs at about the same level of abstraction, and like
> Python it can be interpreted or byte-compiled.  It's probably easier
> to learn than Perl and about the same as Python.  It doesn't have the
> object oriented features of either, nor the huge library of Perl.
> None of this alone is sufficient to make it noteworthy, but it's
> important because this makes it considerably more familiar than
> Prolog to many of us.
>
> What's really interesting is the goal-directed evaluation
> (backtracking).  This is not in itself new and unique: Prolog and
> SNOBOL both had this before Icon did, and you can write backtracking
> in any language.  What's neat about Icon, then, is that it provides
> this built-in backtracking mechanism in a familar-seeming language.
>
> The result is that Icon is easy to learn, and it makes easy to write
> solutions for search problems.  Icon helps you think about problems
> differently: you come up with a way to recognize a solution, apply it
> to an expression that generates some solution space, and let Icon
> search for the right result.  Of course you could write it in another
> language, and it might even be more efficient, but like many
> higher-level languages, Icon seems especially suitable when programmer
> time is more valuable than computer time.
>
> I wouldn't call this "revolutionary," but neither would I call it
> "trivial."  I call it "cool."  If, like me, you appreciate interesting
> programming languages, and want to have a variety of tools at your
> disposal, you may find Icon worth learning about.
>
> Jesse


From icon-group-sender Mon Aug 12 09:25:36 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGODE08941
    for icon-group-addresses; Mon, 12 Aug 2002 09:24:13 -0700 (MST)
Message-Id: <[e-mail]>
From: Steve Wampler <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Sun, 11 Aug 2002 10:30:49 -0700
X-Complaints-To: [e-mail]
X-Accept-Language: en
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Gene Kahn wrote:
>
> Jesse Tov <[e-mail]> wrote in message news:<[e-mail]>...
>
> > Icon helps you think about problems
> > differently: you come up with a way to recognize a solution, apply it
> > to an expression that generates some solution space, and let Icon
> > search for the right result.
>
> Can you supply a solution space (other than naturally defined
> sequences and ranges, typically numbers), in particular, a set of
> methods or functions that will return the results that Icon will
> evaluate? That is to say, how abstract are Icon's iterators?

Interesting, but what's an "Icon iterator"?  Do you mean generators
or the operations that can iterate through result sequences (e.g. !).
You can certainly convert any "non-generator" function (that is one
that generates exactly one result - all functions in Icon are
generators, but many are uninteresting as generators...) into one
that generates multiple results - without having to save all the
values into a list or table first.  You can use repeated evaluation,
limitations, and co-expressions to do this.

Do you have a solution space in mind?

>
> > [Icon] has an interesting flow control paradigm.
>
> Would you care to elaborate on this one? Thanks.

I suspect he means that flow control is managed through the
behavior of the evaluation process (success and failure) instead
of through the values produced by evaluation.  That is, it's
perfectly natural to write such things as:

   if min < x < max then ...

in Icon without having to result to compilation trickery.

--
Steve Wampler -- [e-mail]
The gods that smiled on your birth are now laughing out loud.


From icon-group-sender Mon Aug 12 09:39:33 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGdS211394
    for icon-group-addresses; Mon, 12 Aug 2002 09:39:28 -0700 (MST)
Message-Id: <[e-mail]>
From: Jesse Tov <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 11 Aug 2002 21:28:46 GMT
User-Agent: slrn/0.9.7.4 (Linux)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Steve Wampler <[e-mail]>:
> Gene Kahn wrote:
>> Can you supply a solution space (other than naturally defined
>> sequences and ranges, typically numbers), in particular, a set of
>> methods or functions that will return the results that Icon will
>> evaluate? That is to say, how abstract are Icon's iterators?
>
> Interesting, but what's an "Icon iterator"?  Do you mean generators
> or the operations that can iterate through result sequences (e.g. !).
> You can certainly convert any "non-generator" function (that is one
> that generates exactly one result - all functions in Icon are
> generators, but many are uninteresting as generators...) into one
> that generates multiple results - without having to save all the
> values into a list or table first.  You can use repeated evaluation,
> limitations, and co-expressions to do this.
>
> Do you have a solution space in mind?

Well, Gene asked if one could use a set of functions.  If,
for example, you had two Icon values x and y, and a set of
functions F (stored as their names as strings, since afaik
Icon doesn't have anonymous functions [there's something for
the wishlist]), you could easily find a function f in F such
that y = f(x):
    y = (f <- !F)(x)

Here's a pretty trivial program to demonstrate this:
    # allow string-invocation of procedures
    invocable all

    procedure main (args)
        x := 2
        Y := [4, 6, 8]
        F := ["square", "cube"]

        # Find every (f, y) in F * Y s.t. y = f(x)
        every (y := !Y) = (f := !F)(x)
            do write (y, " = ", f, "(2)")
    end

    # complicated functions, here
    procedure square (n)
        return n * n
    end
    procedure cube (n)
        return n * n * n
    end

>> > [Icon] has an interesting flow control paradigm.
>>
>> Would you care to elaborate on this one? Thanks.
>
> I suspect he means that flow control is managed through the
> behavior of the evaluation process (success and failure) instead
> of through the values produced by evaluation.  That is, it's
> perfectly natural to write such things as:
>
>    if min < x < max then ...
>
> in Icon without having to result to compilation trickery.

By "interesting flow control paradigm", i just meant
goal-directed evaluation.

Icon's comparison operators can work the way they do because
of its notion of failure.  On seeing something like your
comparison expression above, someone familiar with C once
asked me, "What if x is 0 and min is negative?" but Icon
gets around that problem by not using values to represent
boolean conditions.

Jesse
--
"A hungry man is not a free man."         --Adlai Stevenson


From icon-group-sender Mon Aug 12 09:40:59 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGeuI11693
    for icon-group-addresses; Mon, 12 Aug 2002 09:40:57 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 11 Aug 2002 22:40:11 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Steve Wampler asked about the sort of solution space I have in mind.
That is to say, the value of F in Jesse's program below. In the system
I'm developing, a user interface gesture, or a process itself, may
trigger a set of processes (F). A process has preconditions (another
F), whose values may be determined by running another set of processes
(yet another F), and postconditions, whose values again may be
determined by running other processes (yaya F). At times, the
application may only be interested in the side effects of processes,
not necessarily in the values returned. For each process, the
preconditions and postconditions are read in from persistent data.

As you can see, this spawning of processes by processes can easily set
off an explosion of running processes that may consume all the
threads. I'm looking for a language (there probably isn't one) that
can help me manage such explosions, in ways that I don't even know yet
how. A deadly-embrace locator at compile time is a must. Processes
will communicate through message passing, or, through a tuplespace
(such as Jini/Javaspace -- the only reason I'm learning Java at this
point).

Ideas?
Thanks.
gk


Jesse Tov <[e-mail]> wrote in message news:<[e-mail]>...
> Steve Wampler <[e-mail]>:
> > Gene Kahn wrote:
> >> Can you supply a solution space (other than naturally defined
> >> sequences and ranges, typically numbers), in particular, a set of
> >> methods or functions that will return the results that Icon will
> >> evaluate? That is to say, how abstract are Icon's iterators?
> >
> > Interesting, but what's an "Icon iterator"?  Do you mean generators
> > or the operations that can iterate through result sequences (e.g. !).
> > You can certainly convert any "non-generator" function (that is one
> > that generates exactly one result - all functions in Icon are
> > generators, but many are uninteresting as generators...) into one
> > that generates multiple results - without having to save all the
> > values into a list or table first.  You can use repeated evaluation,
> > limitations, and co-expressions to do this.
> >
> > Do you have a solution space in mind?
>
> Well, Gene asked if one could use a set of functions.  If,
> for example, you had two Icon values x and y, and a set of
> functions F (stored as their names as strings, since afaik
> Icon doesn't have anonymous functions [there's something for
> the wishlist]), you could easily find a function f in F such
> that y = f(x):
>     y = (f <- !F)(x)
>
> Here's a pretty trivial program to demonstrate this:
>     # allow string-invocation of procedures
>     invocable all
>
>     procedure main (args)
>         x := 2
>         Y := [4, 6, 8]
>         F := ["square", "cube"]
>
>         # Find every (f, y) in F * Y s.t. y = f(x)
>         every (y := !Y) = (f := !F)(x)
>             do write (y, " = ", f, "(2)")
>     end
>
>     # complicated functions, here
>     procedure square (n)
>         return n * n
>     end
>     procedure cube (n)
>         return n * n * n
>     end
>
> >> > [Icon] has an interesting flow control paradigm.
> >>
> >> Would you care to elaborate on this one? Thanks.
> >
> > I suspect he means that flow control is managed through the
> > behavior of the evaluation process (success and failure) instead
> > of through the values produced by evaluation.  That is, it's
> > perfectly natural to write such things as:
> >
> >    if min < x < max then ...
> >
> > in Icon without having to result to compilation trickery.
>
> By "interesting flow control paradigm", i just meant
> goal-directed evaluation.
>
> Icon's comparison operators can work the way they do because
> of its notion of failure.  On seeing something like your
> comparison expression above, someone familiar with C once
> asked me, "What if x is 0 and min is negative?" but Icon
> gets around that problem by not using values to represent
> boolean conditions.
>
> Jesse


From icon-group-sender Mon Aug 12 09:41:24 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGfME11782
    for icon-group-addresses; Mon, 12 Aug 2002 09:41:22 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 12 Aug 2002 12:23:15 -0400 (EDT)
From: Taybin Rutkin <[e-mail]>
X-Sender: [e-mail]
To: Cheyenne Wills <[e-mail]>
cc: Icon Group <[e-mail]>
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

On 9 Aug 2002, Cheyenne Wills wrote:

> probably more then anyone really wants to know... (and this is
> documented in the "Icon Programming Language" book -- for the 3rd ed it
> starts on page 138.

Yeah, I've got the books.  Thanks though.

> binfile := open("somefile","ur")   # Open somefile for binary reading
> binofile := open("someother","uw") # Open someother file for binary

What I was wondering was how to just read a little of it.  Like only read
an integer, and then read the next double, and then a char.  It seemed
like all the "u" did was just ignore the "\n"s.

Taybin



From icon-group-sender Mon Aug 12 09:41:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CGfco11837
    for icon-group-addresses; Mon, 12 Aug 2002 09:41:38 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 12 Aug 2002 12:33:49 -0400 (EDT)
From: Taybin Rutkin <[e-mail]>
X-Sender: [e-mail]
To: Gregg Townsend <[e-mail]>
cc: [e-mail]
Subject: Re: Icon language book available for downloading
Errors-To: [e-mail]
Status: RO

On 10 Aug 2002, Gregg Townsend wrote:

> The standard reference for Icon is "The Icon Programming Language"
> (third edition) by Ralph and Madge Griswold, sometimes called the
> "blue book".  As its publishers have turned their attention to other
> matters, the book has become increasingly difficult to find.

I'm really glad that they did this.  I own the book, but it's the "right"
thing to do.

Taybin



From icon-group-sender Mon Aug 12 13:22:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CKMJo19648
    for icon-group-addresses; Mon, 12 Aug 2002 13:22:19 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
To: [e-mail]
Cc: [e-mail], [e-mail]
From: [e-mail]
Date: Mon, 12 Aug 2002 12:06:00 -0500
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.9a
 |January 7, 2002) at 08/12/2002 12:06:12 PM
Errors-To: [e-mail]
Status: RO

To go with the open there is also reads(f,i)
where f is the file handle and i is the number of bytes to read.
Also seek(f,i) is supposed to seek i bytes into a file f.
I believe much of this information is included in appendix D
the downloadable book.

Chris Tenaglia, technical analyst, Johnson Controls




                      trutkin@physics.
                      clarku.edu               To:      [e-mail]
                                               cc:      [e-mail]
                      08/12/2002 11:23         Subject: Re: Icon Wish List
                      AM






On 9 Aug 2002, Cheyenne Wills wrote:

> probably more then anyone really wants to know... (and this is
> documented in the "Icon Programming Language" book -- for the 3rd ed it
> starts on page 138.

Yeah, I've got the books.  Thanks though.

> binfile := open("somefile","ur")   # Open somefile for binary reading
> binofile := open("someother","uw") # Open someother file for binary

What I was wondering was how to just read a little of it.  Like only read
an integer, and then read the next double, and then a char.  It seemed
like all the "u" did was just ignore the "\n"s.

Taybin







From icon-group-sender Mon Aug 12 13:23:06 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CKN4k19773
    for icon-group-addresses; Mon, 12 Aug 2002 13:23:04 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 12 Aug 2002 10:10:00 -0700
From: Steve Wampler <[e-mail]>
X-Accept-Language: en
To: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

Jesse Tov wrote:
>
> Well, Gene asked if one could use a set of functions.  If,
> for example, you had two Icon values x and y, and a set of
> functions F (stored as their names as strings, since afaik
> Icon doesn't have anonymous functions [there's something for
> the wishlist]), you could easily find a function f in F such
> that y = f(x):

Actually, Icon has no trouble having sets of functions - I'm not
quite sure if this means "anonymous functions" or not as I've
lost track of the evolution of the term, but there is not need
for requiring the sets to contain the function names.

Try:

    procedure main()
        s := set([cube,square])
        every write(image(!s))
    end

    procedure cube(n)
       return n*square(n)
    end

    procedure square(n)
       return n*n
    end

> By "interesting flow control paradigm", i just meant
> goal-directed evaluation.

Oh, ok.  I though you had covered GDE in other comments.

--
Steve Wampler -- [e-mail]
The gods that smiled on your birth are now laughing out loud.


From icon-group-sender Mon Aug 12 13:23:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CKNdQ19914
    for icon-group-addresses; Mon, 12 Aug 2002 13:23:39 -0700 (MST)
Message-Id: <[e-mail]>
From: Christopher Browne <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: 12 Aug 2002 19:24:30 GMT
X-Draft-From: ("nnvirtual:Languages" 1060)
X-Home-Page: http://www.cbbrowne.com/info/
X-Emacs-Acronym: Ever Made A Control-key Setup?
Microsoft: With our software, there's no limit to what you can't do!
X-Shopping-List:
   (1) Jubilant hamster-lips
   (2) Flirtatious indignant remainders
   (3) Erratic emission chains
X-Uboat-Death-Message: CLICKED BY THREE DESTROYERS. SINKING. U-235.
To: [e-mail]
Errors-To: [e-mail]
Status: RO

In the last exciting episode, "Shmuel (Seymour J.) Metz" <[e-mail]> wrote::
> In <aiuh3c$17ne15$[e-mail]>, on 08/08/2002
>    at 07:34 PM, Christopher Browne <[e-mail]> said:
>
>>That Icon supports backtracking can't be _quite_ enough to deserve
>>interest, as there are more famous languages, such as Prolog, that
>>also support backtracking.
>
> Prolog supports backtracking for rule matching. Does it also support
> backtracking in procedural code? In Icon the backtracking is
> pervasive.

In Prolog, backtracking is pretty pervasive, but it doesn't really
_have_ procedural code.

The lack of "proceduralness" might well be an advantage for Icon...
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/unix.html
Signs of  a Klingon Programmer -  20. "Behold, the  keyboard of Kalis!
The greatest Klingon code warrior that ever lived!"


From icon-group-sender Mon Aug 12 16:31:41 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CNTxM22574
    for icon-group-addresses; Mon, 12 Aug 2002 16:30:00 -0700 (MST)
Message-Id: <[e-mail]>
Date: Mon, 12 Aug 2002 16:29:39 -0400 (EDT)
From: Taybin Rutkin <[e-mail]>
X-Sender: [e-mail]
To: Steve Wampler <[e-mail]>
cc: [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

On Mon, 12 Aug 2002, Steve Wampler wrote:

> Actually, Icon has no trouble having sets of functions - I'm not
> quite sure if this means "anonymous functions" or not as I've
> lost track of the evolution of the term, but there is not need
> for requiring the sets to contain the function names.

I think anonymous functions mean functions that are created during runtime
and assigned to a variable.  Which Icon can't do.  Hasn't been a problem
for me.

Taybin



From icon-group-sender Mon Aug 12 16:34:15 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CNWqk23096
    for icon-group-addresses; Mon, 12 Aug 2002 16:32:52 -0700 (MST)
Message-Id: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: RE: Icon Wish List
Date: Mon, 12 Aug 2002 13:50:33 -0700
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Icon Wish List
Thread-Index: AcJCP40fQCYv2IwnQICWUaCxnNiYPgAAhQRQ
From: "Todd Proebsting" <[e-mail]>
To: "Steve Wampler" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Aug 2002 20:50:34.0762 (UTC) FILETIME=[E7B6CEA0:01C24241]
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g7CKodw24687
Errors-To: [e-mail]
Status: RO

I'm guessing that what Jesse means by "anonymous functions" is what I'd
mean by "lambda functions."  I.e, a function whose declaration exists
inside another function and can capture enclosing state.

I've often wanted lambda functions in Icon...

Todd

-----Original Message-----
From: Steve Wampler [mailto:[e-mail]]
Sent: Monday, August 12, 2002 10:10 AM
To: [e-mail]
Subject: Re: Icon Wish List


Jesse Tov wrote:
>
> Well, Gene asked if one could use a set of functions.  If, for
> example, you had two Icon values x and y, and a set of functions F
> (stored as their names as strings, since afaik Icon doesn't have
> anonymous functions [there's something for the wishlist]), you could
> easily find a function f in F such that y = f(x):

Actually, Icon has no trouble having sets of functions - I'm not quite
sure if this means "anonymous functions" or not as I've lost track of
the evolution of the term, but there is not need for requiring the sets
to contain the function names.

Try:

    procedure main()
        s := set([cube,square])
        every write(image(!s))
    end

    procedure cube(n)
       return n*square(n)
    end

    procedure square(n)
       return n*n
    end

> By "interesting flow control paradigm", i just meant goal-directed
> evaluation.

Oh, ok.  I though you had covered GDE in other comments.

--
Steve Wampler -- [e-mail]
The gods that smiled on your birth are now laughing out loud.



From icon-group-sender Mon Aug 12 16:35:51 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7CNYSs23398
    for icon-group-addresses; Mon, 12 Aug 2002 16:34:28 -0700 (MST)
Message-Id: <[e-mail]>
Subject: Re: Icon Wish List
From: Cheyenne Wills <[e-mail]>
To: [e-mail]
Cc: [e-mail], Icon Group <[e-mail]>
Date: 12 Aug 2002 17:21:10 -0600
Errors-To: [e-mail]
Status: RO

And I think to finish out the question... reads returns a string, which
actually contains binary data.  You will have to convert the binary data
into an Icon datatype that is apporiate.  You will have to take into
consideration the "format" of the data (big-endian, number of bytes
used, etc.)  The conversion can be "messy" usually involving the ord
function.

Cheyenne


On Mon, 2002-08-12 at 11:06, [e-mail] wrote:
> To go with the open there is also reads(f,i)
> where f is the file handle and i is the number of bytes to read.
> Also seek(f,i) is supposed to seek i bytes into a file f.
> I believe much of this information is included in appendix D
> the downloadable book.
>
> Chris Tenaglia, technical analyst, Johnson Controls
>
>
>
>
>                       trutkin@physics.
>                       clarku.edu               To:      [e-mail]
>                                                cc:      [e-mail]
>                       08/12/2002 11:23         Subject: Re: Icon Wish List
>                       AM
>
>
>
>
>
>
> On 9 Aug 2002, Cheyenne Wills wrote:
>
> > probably more then anyone really wants to know... (and this is
> > documented in the "Icon Programming Language" book -- for the 3rd ed it
> > starts on page 138.
>
> Yeah, I've got the books.  Thanks though.
>
> > binfile := open("somefile","ur")   # Open somefile for binary reading
> > binofile := open("someother","uw") # Open someother file for binary
>
> What I was wondering was how to just read a little of it.  Like only read
> an integer, and then read the next double, and then a char.  It seemed
> like all the "u" did was just ignore the "\n"s.
>
> Taybin
>
>
>
>
>



From icon-group-sender Tue Aug 13 07:32:12 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7DEWAo09999
    for icon-group-addresses; Tue, 13 Aug 2002 07:32:10 -0700 (MST)
Message-Id: <[e-mail]>
From: "Jan A. Staecker" <[e-mail]>
To: "'Gene Kahn'" <[e-mail]>
Cc: <[e-mail]>
Subject: AW: Icon Wish 2
Date: Tue, 13 Aug 2002 06:44:42 +0200
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 13 Aug 2002 04:42:52.0239 (UTC) FILETIME=[E22AA5F0:01C24283]
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g7D4gxw06131
Errors-To: [e-mail]
Status: RO


Moving Icon to Icon.NET would be great!

I would be very happy
using Icon again for my business.

Your
Jan Staecker

> -----Ursprⁿngliche Nachricht-----
> Von: Gene Kahn [mailto:[e-mail]]
> Gesendet: Sonntag, 11. August 2002 16:45
> An: [e-mail]
> Betreff: Icon Wish 2
>
>
> An Icon.NET or a plug-in to the Eclipse development system
> will give Icon good exposure. Plus .NET will provide many
> libraries that Icon may not have access to at this point.
> Anybody working on these projects?
>
>



From icon-group-sender Tue Aug 13 07:31:57 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7DEVbI09976
    for icon-group-addresses; Tue, 13 Aug 2002 07:31:37 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 13 Aug 2002 11:07:46 +1200 (NZST)
From: "Richard A. O'Keefe" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Icon Wish List
Errors-To: [e-mail]
Status: RO

"Shmuel (Seymour J.) Metz" <[e-mail]> wrote:
    Prolog supports backtracking for rule matching. Does it also support
    backtracking in procedural code? In Icon the backtracking is
    pervasive.

I wrote a textbook about Prolog.  I don't know quite what you mean by
rule matching.  Quite unlike Icon or SNOBOL, where backtracking is only
available in certain contexts, Prolog has backtracking EVERYWHERE.



From icon-group-sender Tue Aug 13 12:28:40 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7DJRjw20228
    for icon-group-addresses; Tue, 13 Aug 2002 12:27:46 -0700 (MST)
Message-Id: <[e-mail]>
Date: Tue, 13 Aug 2002 10:48:05 -0700 (MST)
From: Gregg Townsend <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Calling Icon from C program [..]
Errors-To: [e-mail]
Status: RO

>  From: Ian Trudel <[e-mail]>
>
>      [quoting the Icon 9.0 documentation]
>        "The ability to configure Icon so that Icon procedures can
>          be called from a C program has been eliminated."
>
>  why this yet desirable feature has been pulled out?

It was difficult to use, and beyond an experiment around 1985
I don't anyone using or even testing it.

What probably happened (I don't truly remember) was that the code
interfered with some other work and it would have taken significant
additional effort to keep "calls from C" working -- assuming that
it still worked then, which is questionable.

---------------------------------------------------------------------------
Gregg Townsend         Staff Scientist      The University of Arizona
[e-mail]     Computer Science     Tucson, Arizona, USA



From icon-group-sender Tue Aug 13 16:44:22 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7DNi5Y29407
    for icon-group-addresses; Tue, 13 Aug 2002 16:44:05 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Date: Tue, 13 Aug 2002 13:24:50 -0700
To: [e-mail]
From: "William H. Mitchell" <[e-mail]>
Subject: Re: Icon Wish List [backtracking]
Errors-To: [e-mail]
Status: RO

At 11:07 AM 8/13/02 +1200, Richard A. O'Keefe wrote:
>
>I wrote a textbook about Prolog.  I don't know quite what you mean by
>rule matching.  Quite unlike Icon or SNOBOL, where backtracking is only
>available in certain contexts, Prolog has backtracking EVERYWHERE.

I'd say that Icon, too, has backtracking everywhere, but a number of
constructs in the language limit backtracking, when used.  You can write an
Icon program that will backtrack from within an epsilon of completion of an
arbitrary computation, assuming the proper constructs are used, such as
"suspend"ing from procedures instead of "return"ing, using reversible
assignment, using list concatenation and sections instead of
get/push/pull/, and so forth and so on.

But I'll agree that it's far more straightforward to achieve full and free
backtracking in Prolog.  My view is that in Icon you have to think to
achieve large-scale backtracking and in Prolog you have to think when you
want to avoid backtracking.



From icon-group-sender Thu Aug 15 08:43:46 2002
Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7FFg1g26589
    for icon-group-addresses; Thu, 15 Aug 2002 08:42:01 -0700 (MST)
Message-Id: <[e-mail]>
From: Hrvoje Blazevic <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Thu, 15 Aug 2002 02:31:48 +0200
X-Complaints-To: [e-mail]
User-Agent: Pan/0.11.2 (Unix)
X-Comment-To: "ernobe" <[e-mail]>
To: [e-mail]
Errors-To: [e-mail]
Status: RO

On Fri, 02 Aug 2002 18:46:43 +0200, ernobe wrote:

> I wish you luck in your endeavour.  Icon is superior, and I realize that
> showing how superior it already is in practice will not necessarily
> allow it to "take off".  It will need to advertize itself, so to speak.
>      The only other computer language that I know of which uses
>      expressions is
> Terse (www.terse.com) an expression-based assembly language.  It is
> easier to program in than C or Assembly.   I wonder why Icon can't
> become or is not considered a more low-level language.  That would
> certainly raise brows.  It would not take-off.   It would launch.

I must be missing something here. Icon (and terse) the only languages
using expressions? How about Scheme -- or for that matter the whole
functional camp?