home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group88b.txt
< prev
next >
Wrap
Text File
|
1989-01-01
|
286KB
|
7,466 lines
From icon-group-request Fri Jun 3 04:00:30 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 04:00:30 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 3 Jun 88 04:00:21 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA05804; Fri, 3 Jun 88 02:52:02 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Jun 88 22:11:22 GMT
From: ncc!lyndon@uunet.uu.net (Lyndon Nerenberg)
Organization: Nexus Computing Inc.
Subject: Address for ordering Icon tape wanted
Message-Id: <10263@ncc.Nexus.CA>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
Could someone at Arizona please email me the address (and prices
if you have them) for ordering the Icon tape? Thanks.
--
{alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA
From DSCARGO@CIM-VAX.HONEYWELL.COM Fri Jun 3 06:48:57 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 06:48:57 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu; Fri, 3 Jun 88 06:48:51 MST
Received: by CIM-VAX id <0000161E071@CIM-VAX.HONEYWELL.COM> ;
Fri, 3 Jun 88 08:47:04 CDT
Date: Fri, 3 Jun 88 08:43:11 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@CIM-VAX.HONEYWELL.COM>
Subject: Macintosh version of Icon
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880603084311.0000161E071@CIM-VAX.HONEYWELL.COM>
Is there a Macintosh version of Icon? If there is, where can I get it?
I'm doing some stuff the non-WYSIWYG text processing. I'm looking at some
software that provides a split-screen psuedo-WYSIWYG interface and produces
Standardized Generalized Markup Language (SGML) output. I'm also using
Textures, the TeX implementation for the Mac from Addison-Wesley and Kellerman
& Smith. I'd like to investigate translating SGML to TeX for actual
formatting, and Icon seems like it would be a good tool to use to do it.
dsc (DSCARGO@CIM-VAX.HONEYWELL.COM)
From sboisen@REGULUS.BBN.COM Fri Jun 3 07:19:31 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 07:19:31 MST
Message-Id: <8806031419.AA08135@megaron.arizona.edu>
Received: from REGULUS.BBN.COM by megaron.arizona.edu; Fri, 3 Jun 88 07:19:27 MST
To: icon-group@arizona.edu
Subject: icon-mode for GNU Emacs?
Date: Fri, 3 Jun 88 10:11:18 EDT
From: sboisen@REGULUS.BBN.COM
Sender: sboisen@REGULUS.BBN.COM
Does anybody have a functional icon-mode for GNU Emacs? I'm thoroughly
addicted to indentation helps and all the rest, but hacking c-mode to
do Icon hasn't turned out to be as easy as i thought it might. Any
help appreciated..
........................................
Sean Boisen -- sboisen@bbn.com
BBN Labs, Inc.
Disclaimer: these opinions void where prohibited by lawyers.
From sunquest!whm Fri Jun 3 17:44:50 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 17:44:50 MST
Received: by megaron.arizona.edu; Fri, 3 Jun 88 16:49:39 MST
Date: Fri, 3 Jun 88 16:39:58 MST
From: "Bill Mitchell" <sunquest!whm>
Message-Id: <8806032339.AA12639@sunquest>
Received: by sunquest; Fri, 3 Jun 88 16:39:58 MST
To: arizona!icon-group
Subject: Unofficial Sun-4 Icon fixes
A little twiddling is needed to make Icon 7.0 work on a Sun-4. Cut on the
indicated line below and put the contents in a script in the top-level Icon
directory (/usr/icon or whatever) and run it. It creates a sun4 config from
the sun3 config.
Once you've run the script, type "make Configure name=sun4" and you should
be ready to go. You can read the details below on the state of things or
"make Status name=sun4" after you've run the script.
Bill Mitchell
------ cut here ------
#!/bin/csh -f
cd config/unix
rm -rf sun4
echo Removing old sun4 config...
mkdir sun4
cd sun3
echo Copying sun3 config to sun4...
tar crf - . | (cd ../sun4; tar xf -)
cd ../sun4
echo Editing files...
cp ../Common/rswitch.c .
ed - iconx.hdr <<XXX
/ROVER/s/rover.s/rover.c/
w
q
XXX
ed - define.h <<XXX
\$a
#define NoOver 1
.
/MaxHdr/s/2000/2560/
w
q
XXX
cat >status <<XXX
Last update: Fri Jun 3 16:18:50 MST 1988
Current
-------
Built and tested on a Sun-4/280 running Sys4-3.2.
Co-expressions and overflow checking aren't implemented. (N.B.: If NoCoexpr
is defined, the value of MaxStatSize that is used (500) is too small and
core dumps during startup result. Since there's no easy way to specify a
smaller MaxStatSize via the config stuff, the simplest solution is to let the
co-expression code be compiled in: it results in a sufficiently large value
of MaxStatSize.)
There's some sort of floating point problem, apparently related to output
formatting, but it hasn't been investigated. (Values like 2.0 often come out
as 2.93434e-323, as if the integer part is correct, but the fraction is thought
to be a very small, but non-zero number.)
Personalized interpreters and the Icon Program Library pass their tests.
Variant translators core dump immediately; this has not been investigated.
The tests for the save() function were missing from the distribution, but
a simple test of save() worked.
-O4 optimization has been seen to work, but currently -O is used. (Note that
with itran/code.c, -O4 will produce a 10Mb core dump; -O2 works for it.) On
a single measured case, -O4 produced a 10% speedup over -O.
Future
------
Historically speaking, I've always been unable to leave stuff like this alone
until it's completely working, so fixes for the floating point, co-expressions,
overflow checking, and the variant translators will probably appear sooner or
later, but not necessarily in that order. However, don't hold your breath.
Bill Mitchell
Sunquest Information Systems
Tucson AZ
arizona!sunquest!whm
XXX
echo Done!
From sunquest!whm Fri Jun 3 18:07:42 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 18:07:42 MST
Received: by megaron.arizona.edu; Fri, 3 Jun 88 18:07:40 MST
Date: Fri, 3 Jun 88 18:01:14 MST
From: "Bill Mitchell" <sunquest!whm>
Message-Id: <8806040101.AA12928@sunquest>
Received: by sunquest; Fri, 3 Jun 88 18:01:14 MST
To: arizona!icon-group
Subject: Unofficial Sun-4 Icon fixes
A little twiddling is needed to make Icon 7.0 work on a Sun-4. Cut on the
indicated line below, remove the leading Xs, and put the contents in a
script in the top-level Icon directory (/usr/icon or whatever) and run it.
It creates a sun4 config from the sun3 config.
Once you've run the script, type "make Configure name=sun4" and you should
be ready to go. You can read the details below on the state of things or
"make Status name=sun4" after you've run the script.
Bill Mitchell
p.s.
Sorry about the repeat, the first message got truncated by a bogus mailer.
------ cut here ------
X#!/bin/csh -f
Xcd config/unix
Xrm -rf sun4
Xecho Removing old sun4 config...
Xmkdir sun4
Xcd sun3
Xecho Copying sun3 config to sun4...
Xtar crf - . | (cd ../sun4; tar xf -)
Xcd ../sun4
Xecho Editing files...
Xcp ../Common/rswitch.c .
Xed - iconx.hdr <<XXX
X/ROVER/s/rover.s/rover.c/
Xw
Xq
XXXX
Xed - define.h <<XXX
X\$a
X#define NoOver 1
X.
X/MaxHdr/s/2000/2560/
Xw
Xq
XXXX
Xcat >status <<XXX
XLast update: Fri Jun 3 16:18:50 MST 1988
X
XCurrent
X-------
X
XBuilt and tested on a Sun-4/280 running Sys4-3.2.
X
XCo-expressions and overflow checking aren't implemented. (N.B.: If NoCoexpr
Xis defined, the value of MaxStatSize that is used (500) is too small and
Xcore dumps during startup result. Since there's no easy way to specify a
Xsmaller MaxStatSize via the config stuff, the simplest solution is to let the
Xco-expression code be compiled in: it results in a sufficiently large value
Xof MaxStatSize.)
X
XThere's some sort of floating point problem, apparently related to output
Xformatting, but it hasn't been investigated. (Values like 2.0 often come out
Xas 2.93434e-323, as if the integer part is correct, but the fraction is thought
Xto be a very small, but non-zero number.)
X
XPersonalized interpreters and the Icon Program Library pass their tests.
X
XVariant translators core dump immediately; this has not been investigated.
X
XThe tests for the save() function were missing from the distribution, but
Xa simple test of save() worked.
X
X-O4 optimization has been seen to work, but currently -O is used. (Note that
Xwith itran/code.c, -O4 will produce a 10Mb core dump; -O2 works for it.) On
Xa single measured case, -O4 produced a 10% speedup over -O.
X
XFuture
X------
X
XHistorically speaking, I've always been unable to leave stuff like this alone
Xuntil it's completely working, so fixes for the floating point, co-expressions,
Xoverflow checking, and the variant translators will probably appear sooner or
Xlater, but not necessarily in that order. However, don't hold your breath.
X
XBill Mitchell
XSunquest Information Systems
XTucson AZ
Xarizona!sunquest!whm
XXXX
Xecho Done!
---- the end ----
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Sun Jun 5 10:03:40 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 5 Jun 88 10:03:40 MST
Received: from [128.135.12.98] by megaron.arizona.edu; Sun, 5 Jun 88 10:03:22 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA22531; Sun, 5 Jun 88 12:07:43 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA15971; Sun, 5 Jun 88 11:56:37 CDT
Date: Sun, 5 Jun 88 11:56:37 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8806051656.AA15971@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: coroutines
I have a strange situation come up where I can't seem to stop a string of
filters from resuming.
What I am doing is reading the standard input, and then doing various things
to it that aren't necessary to enumerate. The general form of my program is:
global Filter2, Filter3
procedure main()
Filter1 := create filterit1(create trim(!&input),Filter2)
Filter2 := create filterit2(Filter1,Filter3)
Filter3 := create filterit3(Filter2,&main)
while write(@Filter3)
end
procedure filterit1(in,out)
while line := @in do {
# do something to line
line @ out
}
end
etc....
This all worked fine - until I wanted Filter2 to stop program execution when
a certain string was found. Maybe it was silly, but I thought that simply
having the procedure filterit2 fail when it encountered that string would be
sufficient. The trouble is that the program then went into a loop, with
filterit1() being repeatedly resumed. The program didn't want to terminate
until the standard input was exhausted. To put it differently, filterit2
failed, hence Filter2 failed with respect to the next filter. Somehow, though,
the first filter kept getting activated. Gads! What am I doing wrong.
I tried to use a simply return to &source, but this didn't work, either. What
am I misunderstanding?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Sun Jun 5 14:56:38 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 5 Jun 88 14:56:38 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu; Sun, 5 Jun 88 14:56:30 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA24614; Sun, 5 Jun 88 17:01:08 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA16346; Sun, 5 Jun 88 16:49:57 CDT
Date: Sun, 5 Jun 88 16:49:57 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8806052149.AA16346@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: coroutines
Re my query about how to cut out of a series of coexpressions daisy chained
together as filters, Steve Wampler wrote:
To stop the program, you could just issue a stop() call, but I suspect
you might want to do an @&main. The problem you're having has to
do with the control flow sequence through the co-expressions. Briefly
put, I suspect that the source for Filter2 is Filter1, and the source
for Filter1 is Filter2 (or something similar). Thus there is no
direct way out of the cycle out of the control flow. I'd have to see
more of the actual code to be of much help on this, however.
The code I posted actually summarizes the 1000-line program quite well. It's
like the example given in Griswold & Griswold of coroutine programming, except
that there are more filters.
The trouble is that I don't want to swing back to &main. Nor do I want to
simply quit the program.
global Filter2, Filter3
procedure main()
Filter1 := create filterit1(create trim(!&input),Filter2)
Filter2 := create filterit2(Filter1,Filter3)
Filter3 := create filterit3(Filter2,&main)
while write(@Filter3)
end
procedure filterit1(in,out)
while ( @in @ out )
end
procedure filterit2(in,out)
while line := @in do {
if match("end",line) then fail
line @ out
}
end
procedure filterit3(in,out)
while ( @in @ out )
"EOF" @ out
end
This is an absurdly honed-down version. But what I want it to do is break
the coroutine chain when a line beginning with the word "end" is found.
I want it to translate into failure of "@in" in filterit3(in,out). So I
don't want to do either of the things suggested above, namely 1) stop exe-
cution, or 2) return immediately to &main. You'll notice that this pro-
gram does what you might expect it to; at least its output is correct. The
problem is that it reads everything on the standard input, even after I've
found my "end". Sure, I can replace "...then fail" above with "then stop(
"EOF")" and all will be well. This isn't terribly symmetrical, though, and
in the larger program I'm working on, it actually ends up being quite opaque.
Is there a better way to do this?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From naucse!sbw Mon Jun 6 07:35:01 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 6 Jun 88 07:35:01 MST
Received: by megaron.arizona.edu; Mon, 6 Jun 88 07:34:59 MST
Date: Mon, 6 Jun 88 07:20:09 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8806061420.AA06973@naucse>
To: arizona!goer@sophist.uchicago.edu
Subject: Re: coroutines
Cc: arizona!icon-group
Hmmm, now I'm confused. What version of Icon are you running? Under
v7, the latest program you sent (with the 'fail' in filterit2()) seems
to work the way you say you want it to. In particular, the input file:
this is
a
test
end
of
the
world
produces the output file:
this is
a
test
EOF
To show that it isn't reading any more input after encountering a
line beginning with 'end', here is the same output, run with &trace
set:
main()
co.icn: 6 | main; #1 : &null @ #4
co.icn: 5 | filterit3(co-expression #3,co-expression #1)
co.icn: 21 | | filterit3; #4 : &null @ #3
co.icn: 4 | | filterit2(co-expression #2,co-expression #4)
co.icn: 14 | | | filterit2; #3 : &null @ #2
co.icn: 3 | | | filterit1(co-expression #5,co-expression #3)
co.icn: 10 | | | | filterit1; #2 : &null @ #5
co.icn: 3 | | | | main; #5 returned "this is" to #2
co.icn: 10 | | | | filterit1; #2 : "this is" @ #3
co.icn: 16 | | | | filterit2; #3 : (variable = "this is") @ #4
co.icn: 21 | | | | filterit3; #4 : "this is" @ #1
this is
co.icn: 6 | | | | main; #1 : &null @ #4
co.icn: 21 | | | | filterit3; #4 : &null @ #3
co.icn: 14 | | | | filterit2; #3 : &null @ #2
co.icn: 10 | | | | filterit1; #2 : &null @ #5
co.icn: 3 | | | | main; #5 returned "a" to #2
co.icn: 10 | | | | filterit1; #2 : "a" @ #3
co.icn: 16 | | | | filterit2; #3 : (variable = "a") @ #4
co.icn: 21 | | | | filterit3; #4 : "a" @ #1
a
co.icn: 6 | | | | main; #1 : &null @ #4
co.icn: 21 | | | | filterit3; #4 : &null @ #3
co.icn: 14 | | | | filterit2; #3 : &null @ #2
co.icn: 10 | | | | filterit1; #2 : &null @ #5
co.icn: 3 | | | | main; #5 returned "test" to #2
co.icn: 10 | | | | filterit1; #2 : "test" @ #3
co.icn: 16 | | | | filterit2; #3 : (variable = "test") @ #4
co.icn: 21 | | | | filterit3; #4 : "test" @ #1
test
co.icn: 6 | | | | main; #1 : &null @ #4
co.icn: 21 | | | | filterit3; #4 : &null @ #3
co.icn: 14 | | | | filterit2; #3 : &null @ #2
co.icn: 10 | | | | filterit1; #2 : &null @ #5
co.icn: 3 | | | | main; #5 returned "end" to #2
co.icn: 10 | | | | filterit1; #2 : "end" @ #3
co.icn: 15 | | | filterit2 failed
co.icn: 4 | | | main; #3 failed to #2
co.icn: 11 | | filterit1 failed
co.icn: 3 | | main; #2 failed to #3
co.icn: 4 | | main; #3 failed to #4
co.icn: 22 | | filterit3; #4 : "EOF" @ #1
EOF
co.icn: 6 | | main; #1 : &null @ #4
co.icn: 23 | filterit3 failed
co.icn: 5 | main; #4 failed to #1
co.icn: 7 main failed
Finally, as a reference aid, here is the source code, annotated with
line numbers:
1 global Filter2, Filter3
2 procedure main()
3 Filter1 := create filterit1(create trim(!&input),Filter2)
4 Filter2 := create filterit2(Filter1,Filter3)
5 Filter3 := create filterit3(Filter2,&main)
6 while write(@Filter3)
7 end
8
9 procedure filterit1(in,out)
10 while ( @in @ out )
11 end
12
13 procedure filterit2(in,out)
14 while line := @in do {
15 if match("end",line) then fail
16 line @ out
17 }
18 end
19
20 procedure filterit3(in,out)
21 while ( @in @ out )
22 "EOF" @ out
23 end
Perhaps this short program doesn't accurately model the behavior of
the big one? If the short program doesn't work for you as it does
for me, could you send me the output of the program:
procedure main()
write(&version)
end
Thanks.
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Mon Jun 6 15:19:18 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 6 Jun 88 15:19:18 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu; Mon, 6 Jun 88 15:19:10 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA17735; Mon, 6 Jun 88 16:46:55 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA18422; Mon, 6 Jun 88 16:35:21 CDT
Date: Mon, 6 Jun 88 16:35:21 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8806062135.AA18422@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: better model
Here is a real model of the program I've been using. Some have been confused
by the inaccurate model I posted earlier. It worked. So does this one. I.e.
it works as expected, at least from the standpoint of its output. However, it
doesn't behave as I might expect (granted, I am not an expert).
global Filter2, Filter3
procedure main()
Filter1 := create filterit1(create !&input,Filter2)
Filter2 := create filterit2(Filter1,Filter3)
Filter3 := create filterit3(Filter2,&main)
while write(@Filter3)
end
procedure filterit1(in,out)
every ( GetLines(in) @ out )
end
procedure GetLines(in)
while line := @in
do suspend line
end
procedure filterit2(in,out)
while line := @in do {
CheckIfEnd(line) | fail
writeout(line,out)
}
end
procedure CheckIfEnd(s)
s == "end" & fail
return
end
procedure filterit3(in,out)
while ( @in @ out )
end
procedure writeout(line,out)
line @ out
end
Try running this through
this is a test
testing...
testing...
end
done testing!!!
done testing!!!
done.
Like I said before, it doesn't fail when or how I "expect" it to....
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET Tue Jun 7 03:41:23 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 03:41:23 MST
Received: from [192.12.141.129] by megaron.arizona.edu; Tue, 7 Jun 88 03:41:15 MST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA21227; Tue, 7 Jun 88 06:39:14 EDT
Received: by mcvax.cwi.nl; Tue, 7 Jun 88 11:43:27 +0200 (MET)
Received: from mirsa.inria.Fr by inria.inria.fr; Tue, 7 Jun 88 10:45:58 +0200 (MET)
Message-Id: <8806070845.AA01433@inria.inria.fr>
Posted: Tue, 7 Jun 88 10:44:37 -0100
Date: Tue, 7 Jun 88 10:44:37 -0100
Posted-Date: Tue, 7 Jun 88 10:44:37 -0100
From: olivier lecarme <mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
To: sboisen@regulus.bbn.com
Cc: icon-group@arizona.edu
In-Reply-To: sboisen@REGULUS.BBN.COM's message of Fri, 3 Jun 88 10:11:18 EDT <8806031419.AA08135@megaron.arizona.edu>
Subject: icon-mode for GNU Emacs?
I have exactly the same need as you, and the same difficulties (disgust
?) with C programming...
From mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET Tue Jun 7 04:01:09 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 04:01:09 MST
Received: from uunet.UU.NET by megaron.arizona.edu; Tue, 7 Jun 88 04:01:02 MST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA19266; Tue, 7 Jun 88 05:46:38 EDT
Received: by mcvax.cwi.nl; Tue, 7 Jun 88 01:31:50 +0200 (MET)
Received: from mirsa.inria.Fr by inria.inria.fr; Mon, 6 Jun 88 11:32:42 +0200 (MET)
Message-Id: <8806060932.AA20441@inria.inria.fr>
Posted: Mon, 6 Jun 88 10:22:23 -0100
Date: Mon, 6 Jun 88 10:22:23 -0100
Posted-Date: Mon, 6 Jun 88 10:22:23 -0100
From: olivier lecarme <mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
To: icon-group@arizona.edu
Subject: Icon pretty-printer
Several persons asked me for the Icon pretty-printer. Since it will be
the result of a student project, it is not yet completed, and maybe it
will have to be somewhat improved after the students departure. I will
take the Icon community informed about the progression of this project.
Olivier Lecarme / University of Nice
From sboisen@RIGEL.BBN.COM Tue Jun 7 05:29:32 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 05:29:32 MST
Message-Id: <8806071228.AA01615@megaron.arizona.edu>
Received: from RIGEL.BBN.COM by megaron.arizona.edu; Tue, 7 Jun 88 05:28:58 MST
To: icon-group@arizona.edu
Subject: Icon mode for GNU
Date: Tue, 7 Jun 88 8:22:37 EDT
From: sboisen@RIGEL.BBN.COM
Sender: sboisen@RIGEL.BBN.COM
Thanks to Steve Wampler for sending this along to me: a few others
have asked if i got any response, so here it is. The only bug i've
found so far is admittedly minor: indent-new-comment-line adds an
extra space at the left (in contrast to the behavior of the same in
Lisp mode, at least on my system). Otherwise it looks great.
........................................
Sean Boisen -- sboisen@bbn.com
BBN Labs, Inc.
Disclaimer: these opinions void where prohibited by lawyers.
---------- cut here ----------
;; Icon code editing commands for Emacs
;; Derived from c-mode.el 15-Apr-88 Chris Smith convex!csmith
;; Copyright (C) 1988 Free Software Foundation, Inc.
;; This file is part of GNU Emacs.
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY. No author or distributor
;; accepts responsibility to anyone for the consequences of using it
;; or for whether it serves any particular purpose or works at all,
;; unless he says so in writing. Refer to the GNU Emacs General Public
;; License for full details.
;; Everyone is granted permission to copy, modify and redistribute
;; GNU Emacs, but only under the conditions described in the
;; GNU Emacs General Public License. A copy of this license is
;; supposed to have been given to you along with GNU Emacs so you
;; can know your rights and responsibilities. It should be in a
;; file named COPYING. Among other things, the copyright notice
;; and this notice must be preserved on all copies.
(defvar icon-mode-abbrev-table nil
"Abbrev table in use in Icon-mode buffers.")
(define-abbrev-table 'icon-mode-abbrev-table ())
(defvar icon-mode-map ()
"Keymap used in Icon mode.")
(if icon-mode-map
()
(setq icon-mode-map (make-sparse-keymap))
(define-key icon-mode-map "{" 'electric-icon-brace)
(define-key icon-mode-map "}" 'electric-icon-brace)
(define-key icon-mode-map "\e\C-h" 'mark-icon-function)
(define-key icon-mode-map "\e\C-a" 'beginning-of-icon-defun)
(define-key icon-mode-map "\e\C-e" 'end-of-icon-defun)
(define-key icon-mode-map "\e\C-q" 'indent-icon-exp)
(define-key icon-mode-map "\177" 'backward-delete-char-untabify)
(define-key icon-mode-map "\t" 'icon-indent-command))
(defvar icon-mode-syntax-table nil
"Syntax table in use in Icon-mode buffers.")
(if icon-mode-syntax-table
()
(setq icon-mode-syntax-table (make-syntax-table))
(modify-syntax-entry ?\\ "\\" icon-mode-syntax-table)
(modify-syntax-entry ?# "<" icon-mode-syntax-table)
(modify-syntax-entry ?\n ">" icon-mode-syntax-table)
(modify-syntax-entry ?$ "." icon-mode-syntax-table)
(modify-syntax-entry ?/ "." icon-mode-syntax-table)
(modify-syntax-entry ?* "." icon-mode-syntax-table)
(modify-syntax-entry ?+ "." icon-mode-syntax-table)
(modify-syntax-entry ?- "." icon-mode-syntax-table)
(modify-syntax-entry ?= "." icon-mode-syntax-table)
(modify-syntax-entry ?% "." icon-mode-syntax-table)
(modify-syntax-entry ?< "." icon-mode-syntax-table)
(modify-syntax-entry ?> "." icon-mode-syntax-table)
(modify-syntax-entry ?& "." icon-mode-syntax-table)
(modify-syntax-entry ?| "." icon-mode-syntax-table)
(modify-syntax-entry ?\' "\"" icon-mode-syntax-table))
(defconst icon-indent-level 4
"*Indentation of Icon statements with respect to containing block.")
(defconst icon-brace-imaginary-offset 0
"*Imagined indentation of a Icon open brace that actually follows a statement.")
(defconst icon-brace-offset 0
"*Extra indentation for braces, compared with other text in same context.")
(defconst icon-continued-statement-offset 4
"*Extra indent for lines not starting new statements.")
(defconst icon-continued-brace-offset 0
"*Extra indent for substatements that start with open-braces.
This is in addition to icon-continued-statement-offset.")
(defconst icon-auto-newline nil
"*Non-nil means automatically newline before and after braces,
and after colons and semicolons, inserted in C code.")
(defconst icon-tab-always-indent t
"*Non-nil means TAB in Icon mode should always reindent the current line,
regardless of where in the line point is when the TAB command is used.")
(defun icon-mode ()
"Major mode for editing Icon code.
Expression and list commands understand all Icon brackets.
Tab indents for Icon code.
Paragraphs are separated by blank lines only.
Delete converts tabs to spaces as it moves back.
\\{icon-mode-map}
Variables controlling indentation style:
icon-tab-always-indent
Non-nil means TAB in Icon mode should always reindent the current line,
regardless of where in the line point is when the TAB command is used.
icon-auto-newline
Non-nil means automatically newline before and after braces
inserted in Icon code.
icon-indent-level
Indentation of Icon statements within surrounding block.
The surrounding block's indentation is the indentation
of the line on which the open-brace appears.
icon-continued-statement-offset
Extra indentation given to a substatement, such as the
then-clause of an if or body of a while.
icon-continued-brace-offset
Extra indentation given to a brace that starts a substatement.
This is in addition to icon-continued-statement-offset.
icon-brace-offset
Extra indentation for line if it starts with an open brace.
icon-brace-imaginary-offset
An open brace following other text is treated as if it were
this far to the right of the start of its line.
Turning on Icon mode calls the value of the variable icon-mode-hook with no args,
if that value is non-nil."
(interactive)
(kill-all-local-variables)
(use-local-map icon-mode-map)
(setq major-mode 'icon-mode)
(setq mode-name "Icon")
(setq local-abbrev-table icon-mode-abbrev-table)
(set-syntax-table icon-mode-syntax-table)
(make-local-variable 'paragraph-start)
(setq paragraph-start (concat "^$\\|" page-delimiter))
(make-local-variable 'paragraph-separate)
(setq paragraph-separate paragraph-start)
(make-local-variable 'indent-line-function)
(setq indent-line-function 'icon-indent-line)
(make-local-variable 'require-final-newline)
(setq require-final-newline t)
(make-local-variable 'comment-start)
(setq comment-start "# ")
(make-local-variable 'comment-end)
(setq comment-end "")
(make-local-variable 'comment-column)
(setq comment-column 32)
(make-local-variable 'comment-start-skip)
(setq comment-start-skip "# *")
(make-local-variable 'comment-indent-hook)
(setq comment-indent-hook 'icon-comment-indent)
(run-hooks 'icon-mode-hook))
;; This is used by indent-for-comment
;; to decide how much to indent a comment in Icon code
;; based on its context.
(defun icon-comment-indent ()
(if (looking-at "^#")
0 ;Existing comment at bol stays there.
(save-excursion
(skip-chars-backward " \t")
(max (1+ (current-column)) ;Else indent at comment column
comment-column)))) ; except leave at least one space.
(defun electric-icon-brace (arg)
"Insert character and correct line's indentation."
(interactive "P")
(let (insertpos)
(if (and (not arg)
(eolp)
(or (save-excursion
(skip-chars-backward " \t")
(bolp))
(if icon-auto-newline
(progn (icon-indent-line) (newline) t)
nil)))
(progn
(insert last-command-char)
(icon-indent-line)
(if icon-auto-newline
(progn
(newline)
;; (newline) may have done auto-fill
(setq insertpos (- (point) 2))
(icon-indent-line)))
(save-excursion
(if insertpos (goto-char (1+ insertpos)))
(delete-char -1))))
(if insertpos
(save-excursion
(goto-char insertpos)
(self-insert-command (prefix-numeric-value arg)))
(self-insert-command (prefix-numeric-value arg)))))
(defun icon-indent-command (&optional whole-exp)
(interactive "P")
"Indent current line as Icon code, or in some cases insert a tab character.
If icon-tab-always-indent is non-nil (the default), always indent current line.
Otherwise, indent the current line only if point is at the left margin
or in the line's indentation; otherwise insert a tab.
A numeric argument, regardless of its value,
means indent rigidly all the lines of the expression starting after point
so that this line becomes properly indented.
The relative indentation among the lines of the expression are preserved."
(if whole-exp
;; If arg, always indent this line as Icon
;; and shift remaining lines of expression the same amount.
(let ((shift-amt (icon-indent-line))
beg end)
(save-excursion
(if icon-tab-always-indent
(beginning-of-line))
(setq beg (point))
(forward-sexp 1)
(setq end (point))
(goto-char beg)
(forward-line 1)
(setq beg (point)))
(if (> end beg)
(indent-code-rigidly beg end shift-amt "#")))
(if (and (not icon-tab-always-indent)
(save-excursion
(skip-chars-backward " \t")
(not (bolp))))
(insert-tab)
(icon-indent-line))))
(defun icon-indent-line ()
"Indent current line as Icon code.
Return the amount the indentation changed by."
(let ((indent (calculate-icon-indent nil))
beg shift-amt
(case-fold-search nil)
(pos (- (point-max) (point))))
(beginning-of-line)
(setq beg (point))
(cond ((eq indent nil)
(setq indent (current-indentation)))
((eq indent t)
(setq indent (calculate-icon-indent-within-comment)))
((looking-at "[ \t]*#")
(setq indent 0))
(t
(skip-chars-forward " \t")
(if (listp indent) (setq indent (car indent)))
(cond ((and (looking-at "else\\b")
(not (looking-at "else\\s_")))
(setq indent (save-excursion
(icon-backward-to-start-of-if)
(current-indentation))))
((or (= (following-char) ?})
(looking-at "end\\b"))
(setq indent (- indent icon-indent-level)))
((= (following-char) ?{)
(setq indent (+ indent icon-brace-offset))))))
(skip-chars-forward " \t")
(setq shift-amt (- indent (current-column)))
(if (zerop shift-amt)
(if (> (- (point-max) pos) (point))
(goto-char (- (point-max) pos)))
(delete-region beg (point))
(indent-to indent)
;; If initial point was within line's indentation,
;; position after the indentation. Else stay at same point in text.
(if (> (- (point-max) pos) (point))
(goto-char (- (point-max) pos))))
shift-amt))
(defun calculate-icon-indent (&optional parse-start)
"Return appropriate indentation for current line as Icon code.
In usual case returns an integer: the column to indent to.
Returns nil if line starts inside a string, t if in a comment."
(save-excursion
(beginning-of-line)
(let ((indent-point (point))
(case-fold-search nil)
state
containing-sexp
toplevel)
(if parse-start
(goto-char parse-start)
(setq toplevel (beginning-of-icon-defun)))
(while (< (point) indent-point)
(setq parse-start (point))
(setq state (parse-partial-sexp (point) indent-point 0))
(setq containing-sexp (car (cdr state))))
(cond ((or (nth 3 state) (nth 4 state))
;; return nil or t if should not change this line
(nth 4 state))
((and containing-sexp
(/= (char-after containing-sexp) ?{))
;; line is expression, not statement:
;; indent to just after the surrounding open.
(goto-char (1+ containing-sexp))
(current-column))
(t
;; Statement level. Is it a continuation or a new statement?
;; Find previous non-comment character.
(if toplevel
(progn (icon-backward-to-noncomment (point-min))
(if (icon-is-continuation-line)
icon-continued-statement-offset 0))
(if (null containing-sexp)
(progn (beginning-of-icon-defun)
(setq containing-sexp (point))))
(goto-char indent-point)
(icon-backward-to-noncomment containing-sexp)
;; Now we get the answer.
(if (icon-is-continuation-line)
;; This line is continuation of preceding line's statement;
;; indent icon-continued-statement-offset more than the
;; first line of the statement.
(progn
(icon-backward-to-start-of-continued-exp containing-sexp)
(+ icon-continued-statement-offset (current-column)
(if (save-excursion (goto-char indent-point)
(skip-chars-forward " \t")
(eq (following-char) ?{))
icon-continued-brace-offset 0)))
;; This line starts a new statement.
;; Position following last unclosed open.
(goto-char containing-sexp)
;; Is line first statement after an open-brace?
(or
;; If no, find that first statement and indent like it.
(save-excursion
(if (looking-at "procedure\\s ")
(forward-sexp 3)
(forward-char 1))
(while (progn (skip-chars-forward " \t\n")
(looking-at "#"))
;; Skip over comments following openbrace.
(forward-line 1))
;; The first following code counts
;; if it is before the line we want to indent.
(and (< (point) indent-point)
(current-column)))
;; If no previous statement,
;; indent it relative to line brace is on.
;; For open brace in column zero, don't let statement
;; start there too. If icon-indent-level is zero,
;; use icon-brace-offset + icon-continued-statement-offset instead.
;; For open-braces not the first thing in a line,
;; add in icon-brace-imaginary-offset.
(+ (if (and (bolp) (zerop icon-indent-level))
(+ icon-brace-offset icon-continued-statement-offset)
icon-indent-level)
;; Move back over whitespace before the openbrace.
;; If openbrace is not first nonwhite thing on the line,
;; add the icon-brace-imaginary-offset.
(progn (skip-chars-backward " \t")
(if (bolp) 0 icon-brace-imaginary-offset))
;; here we are
(current-indentation))))))))))
(defun icon-is-continuation-line ()
(let* ((ch (preceding-char))
(ch-syntax (char-syntax ch)))
(if (eq ch-syntax ?w)
(assoc (buffer-substring
(progn (forward-word -1) (point))
(progn (forward-word 1) (point)))
'(("do") ("dynamic") ("else") ("initial") ("link")
("local") ("of") ("static") ("then")))
(not (memq ch '(0 ?\; ?\} ?\{ ?\) ?\] ?\" ?\' ?\n))))))
(defun icon-backward-to-noncomment (lim)
(let (opoint stop)
(while (not stop)
(skip-chars-backward " \t\n\f" lim)
(setq opoint (point))
(beginning-of-line)
(if (and (search-forward "#" opoint 'move)
(< lim (point)))
(forward-char -1)
(setq stop t)))))
(defun icon-backward-to-start-of-continued-exp (lim)
(if (memq (preceding-char) '(?\) ?\]))
(forward-sexp -1))
(while (icon-is-continued-line)
(end-of-line 0))
(beginning-of-line)
(if (<= (point) lim)
(goto-char (1+ lim)))
(skip-chars-forward " \t"))
(defun icon-is-continued-line ()
(save-excursion
(end-of-line 0)
(icon-is-continuation-line)))
(defun icon-backward-to-start-of-if (&optional limit)
"Move to the start of the last ``unbalanced'' if."
(or limit (setq limit (save-excursion (beginning-of-icon-defun) (point))))
(let ((if-level 1)
(case-fold-search nil))
(while (not (zerop if-level))
(backward-sexp 1)
(cond ((looking-at "else\\b")
(setq if-level (1+ if-level)))
((looking-at "if\\b")
(setq if-level (1- if-level)))
((< (point) limit)
(setq if-level 0)
(goto-char limit))))))
(defun mark-icon-function ()
"Put mark at end of Icon function, point at beginning."
(interactive)
(push-mark (point))
(end-of-icon-defun)
(push-mark (point))
(beginning-of-line 0)
(beginning-of-icon-defun))
(defun beginning-of-icon-defun ()
"Go to the start of the enclosing procedure; return t if at top level."
(interactive)
(if (re-search-backward "^procedure\\s \\|^end[ \t\n]" (point-min) 'move)
(looking-at "e")
t))
(defun end-of-icon-defun ()
(interactive)
(if (not (bobp)) (forward-char -1))
(re-search-forward "\\(\\s \\|^\\)end\\(\\s \\|$\\)" (point-max) 'move)
(forward-word -1)
(forward-line 1))
(defun indent-icon-exp ()
"Indent each line of the Icon grouping following point."
(interactive)
(let ((indent-stack (list nil))
(contain-stack (list (point)))
(case-fold-search nil)
restart outer-loop-done inner-loop-done state ostate
this-indent last-sexp
at-else at-brace at-do
(opoint (point))
(next-depth 0))
(save-excursion
(forward-sexp 1))
(save-excursion
(setq outer-loop-done nil)
(while (and (not (eobp)) (not outer-loop-done))
(setq last-depth next-depth)
;; Compute how depth changes over this line
;; plus enough other lines to get to one that
;; does not end inside a comment or string.
;; Meanwhile, do appropriate indentation on comment lines.
(setq innerloop-done nil)
(while (and (not innerloop-done)
(not (and (eobp) (setq outer-loop-done t))))
(setq ostate state)
(setq state (parse-partial-sexp (point) (progn (end-of-line) (point))
nil nil state))
(setq next-depth (car state))
(if (and (car (cdr (cdr state)))
(>= (car (cdr (cdr state))) 0))
(setq last-sexp (car (cdr (cdr state)))))
(if (or (nth 4 ostate))
(icon-indent-line))
(if (or (nth 3 state))
(forward-line 1)
(setq innerloop-done t)))
(if (<= next-depth 0)
(setq outer-loop-done t))
(if outer-loop-done
nil
(if (/= last-depth next-depth)
(setq last-sexp nil))
(while (> last-depth next-depth)
(setq indent-stack (cdr indent-stack)
contain-stack (cdr contain-stack)
last-depth (1- last-depth)))
(while (< last-depth next-depth)
(setq indent-stack (cons nil indent-stack)
contain-stack (cons nil contain-stack)
last-depth (1+ last-depth)))
(if (null (car contain-stack))
(setcar contain-stack (or (car (cdr state))
(save-excursion (forward-sexp -1)
(point)))))
(forward-line 1)
(skip-chars-forward " \t")
(if (eolp)
nil
(if (and (car indent-stack)
(>= (car indent-stack) 0))
;; Line is on an existing nesting level.
;; Lines inside parens are handled specially.
(if (/= (char-after (car contain-stack)) ?{)
(setq this-indent (car indent-stack))
;; Line is at statement level.
;; Is it a new statement? Is it an else?
;; Find last non-comment character before this line
(save-excursion
(setq at-else (looking-at "else\\W"))
(setq at-brace (= (following-char) ?{))
(icon-backward-to-noncomment opoint)
(if (icon-is-continuation-line)
;; Preceding line did not end in comma or semi;
;; indent this line icon-continued-statement-offset
;; more than previous.
(progn
(icon-backward-to-start-of-continued-exp (car contain-stack))
(setq this-indent
(+ icon-continued-statement-offset (current-column)
(if at-brace icon-continued-brace-offset 0))))
;; Preceding line ended in comma or semi;
;; use the standard indent for this level.
(if at-else
(progn (icon-backward-to-start-of-if opoint)
(setq this-indent (current-indentation)))
(setq this-indent (car indent-stack))))))
;; Just started a new nesting level.
;; Compute the standard indent for this level.
(let ((val (calculate-icon-indent
(if (car indent-stack)
(- (car indent-stack))))))
(setcar indent-stack
(setq this-indent val))))
;; Adjust line indentation according to its contents
(if (or (= (following-char) ?})
(looking-at "end\\b"))
(setq this-indent (- this-indent icon-indent-level)))
(if (= (following-char) ?{)
(setq this-indent (+ this-indent icon-brace-offset)))
;; Put chosen indentation into effect.
(or (= (current-column) this-indent)
(progn
(delete-region (point) (progn (beginning-of-line) (point)))
(indent-to this-indent)))
;; Indent any comment following the text.
(or (looking-at comment-start-skip)
(if (re-search-forward comment-start-skip (save-excursion (end-of-line) (point)) t)
(progn (indent-for-comment) (beginning-of-line))))))))))
From ihnp4!ihuxy!nowlin Tue Jun 7 14:41:36 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 14:41:36 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <8806072141.AA04747@megaron.arizona.edu>
Received: by megaron.arizona.edu; Tue, 7 Jun 88 14:41:35 MST
Received: by ihnp4.ATT.COM id AA24607; 7 Jun 88 09:23:16 CDT (Tue)
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Tue 07 Jun 1988 09:18 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Icon has its place
Ua-Message-Id: <post.nowlin.Tue 07 Jun 1988 08:25 CDT>
End-Of-Protocol:
Content-Length: 1668
I noticed this little message fly by this morning and couldn't let it go
without comment.
> From: olivier lecarme <ihnp4!arizona!mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
> Subject: icon-mode for GNU Emacs?
>
> I have exactly the same need as you, and the same difficulties (disgust
> ?) with C programming...
Icon is just one of many programming languages. It is by far my favorite.
Any new projects I start I try to do in Icon, but Icon is not suited for
some projects. If Icon could do everything Icon would be written in Icon.
It's written in C. Don't disparage other languages because they aren't as
easy to program in as Icon.
Computer languages have their niches just like living things. As the
natural environment changes new niches are created and new species evolve
to fill those niches. Todays computing environments are changing and the
need for a language like Icon is obvious. That won't make other languages
extinct. Their niches still exist and Icon can't compete with them in
their niches for a number of reasons.
I see the main niche for Icon as a UNIX language that falls between shell
and C in terms of power and ease of use. It's string handling capabilities
make it a good candidate for the kinds of work that are frequently done
with UNIX tools like sed and grep and with some of the more arcane UNIX
languages like awk, lex and yacc. The main concern over using Icon in some
of these applications is its execution speed. It's a valid concern.
How about some comments from others on areas where Icon can hold its own
with more traditional languages and areas where Icon just can't compete.
Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)
From R.J.Hare@EDINBURGH.AC.UK Tue Jun 14 13:05:14 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 14 Jun 88 13:05:14 MST
Message-Id: <8806142005.AA19540@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu; Tue, 14 Jun 88 13:05:11 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Tue, 14 Jun 88 12:56 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6009; Tue,
14 Jun 88 16:10:18 BST
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 6003; Tue, 14
Jun 88 16:10:12 BS
Date: 14 Jun 88 16:09:12 bst
From: R.J.Hare@EDINBURGH.AC.UK
Subject: Icon V7
To: icon-group@arizona.edu
Via: UK.AC.ED.EMAS-C; 14 JUN 88 16:10:09 BST
Comments: This one seems to have fallen down a black hole somewhere, so I'll
try again
Roger Hare.
Message-ID: <14 Jun 88 16:09:12 bst 340171@EMAS-C>
--- Forwarded message:
Subject: Icon V7
From: R.J.Hare <ERCY02@uk.ac.edinburgh.emas-c>
Date: 19 May 88 11:38:42 bst
To: icon-group%edu.arizona@rl.earn
Msg ID: <19 May 88 11:38:42 bst 340257@EMAS-C>
A few observations/queries re Icon V7 if I may:
1) DOS version works fine
2) VMS version - tape was v difficult to read but we managed eventually
3) DOS version behaves as V6 when using ICONT, namely routine names and sizes
are displayed at the terminalas they are translated, VMS version does not
appear to do this, which is a bit disconcerting (it took me a couple of
hours digging and delving - see below) before I realised that the brute
actually *was* working. Is there any way of switching on this informative
monologue when using ICONT on VMS? (I have read the instructions, but
couldn't find anything about this - maybe I missed it?)
4) As a result of V7 (apparently) not working, I first tried to re-link the
whole system as described in the docs, and got a message relating to VMS's
inability to find file RROOT:[V33]RSWITCH.OBJ, which in fact was present
(as far as I could see) as file [ERCY02.ICON.V7.SRC.ICONX]RSWITCH.OBJ (I
have my Icon material in the directory [ERCY02.ICON]. When I tried to
rebuild from scratch using @MAKE, I got a message relating to the inability
of the system to find file RROOT:[V33]INPUTFILE.C, which also seemed to be
present as [ERCY02.ICON.V7.SRC.ICONX]INPUTFILE.C. Subsequent to this, of
course, I discovered that the system was working albeit silently, but it
would be nice to know what is happening here?
5) Once I discovered that V7 was working, I did the tests (maybe I should have
done those first!) @TEST and @IPLTEST and both worked.
Any comments/advice about the 'silence' of ICONT on VMS would be appreciated.
Many thanks, and apologies in advance, if all this is in the documentation and
I just missed it.
Roger Hare
--- End of forwarded message
From gmt Tue Jun 14 16:16:09 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 14 Jun 88 16:16:09 MST
Date: Tue, 14 Jun 88 16:16:07 MST
From: "Gregg Townsend" <gmt>
Message-Id: <8806142316.AA07367@megaron.arizona.edu>
Received: by megaron.arizona.edu; Tue, 14 Jun 88 16:16:07 MST
In-Reply-To: <8806142005.AA19540@megaron.arizona.edu>
To: icon-group
Subject: Silent translation under VMS
[ R. J. Hare wonders why Icon V7 under VMS doesn't display a commentary while
translating, as does DOS Icon and as did V6 under VMS. ]
Actually, I didn't realize that it didn't. It's supposed to, and we didn't
make any deliberate changes there. I logged into the nearest VMS machine,
typed "icont file.icn", and got the commentary as expected.
So then I tried some other experiments and found out a couple of ways to
lose the commentary:
(1) If you "DEFINE/USER SYS$ERROR filename", the file gets only the
"Translating:" and "Linking:" messages; the detailed commentary
giving procedure names is lost. Those two messages aren't issued
for "icont -c", so you don't see anything in that case. This probably
has something to do with the C library's implementation of vfork.
(2) If you give a flag such as "-Sg100", and forget to quote it, it's
interpreted as "-s" which silences the commentary. The "g100"
part is ignored (yes, that's a bug).
To summarize: the commentary is supposed to be there, but there are at
least two simple ways to lose it inadvertently.
As for the build problems referencing RROOT:[V33], I'm at a loss to explain
those. The default directory is supposed to be [...V7.SRC.ICONX] at the
time RSWITCH.OBJ is used, and it's referenced without a directory spec.
[If you're interested in pursuing this further I'll try to help; but I'd
suggest mailing to icon-project instead of icon-group, because the whole
mailing list probably doesn't want to hear all the gory details.]
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@Arizona.EDU 110 57 16 W / 32 13 45 N / +758m
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Fri Jun 24 19:18:58 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 24 Jun 88 19:18:58 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu; Fri, 24 Jun 88 19:18:47 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA00973; Fri, 24 Jun 88 21:13:48 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA04660; Fri, 24 Jun 88 21:11:48 CDT
Date: Fri, 24 Jun 88 21:11:48 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8806250211.AA04660@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: Snobol vs. Icon
I keep hearing about the wonderful translation, parsing, and concording
programs that can be done using Snobol4. Is anyone doing this sort of
thing in Icon yet? Planning to?
In my case, Icon has become my natural language processing tool *par
excellance*. Usually, I use it to normalize and parse biblical Hebrew.
I also use it for complicated searches - ones that are difficult to do
using regular expressions.
I am just curious about whether anyone else is doing this sort of thing.
As I mentioned, most folks that I know in the Humanities don't know about
Icon. Some know/use Snobol. I want to find out if anyone out there
is doing things in Icon.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From icon-group-request Fri Jun 24 23:43:41 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 24 Jun 88 23:43:41 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 24 Jun 88 23:43:31 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA13125; Fri, 24 Jun 88 10:45:39 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Jun 88 17:05:28 GMT
From: orion!ics.uci.edu!nagel@ucsd.edu (Mark Nagel)
Organization: University of California, Irvine - Dept. of ICS
Subject: need sun4 rswitch.c help
Message-Id: <723@orion.cf.uci.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
Hi there. I am attempting to create the config directory for v7 Icon for the
Sun 4 SPARC architecture. I have gotten almost everything to work including
overflow detection, but I can't seem to get the coexpression stuff to work
correctly. Is there anyone out there who has done this? Maybe someone out
there can tell me I'm wasting my time and that you can't move the stack
around on the SPARC? Anyway, please email me any suggestions/answers if
you can.
--
Mark D. Nagel
Department of Information and Computer Science, UC Irvine
nagel@ics.uci.edu (ARPA) I'm not a graduate student,
{sdcsvax|ucbvax}!ucivax!nagel (UUCP) but I play one on TV...
From GGRCS@UNO.BITNET Mon Jun 27 02:32:31 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 27 Jun 88 02:32:31 MST
Message-Id: <8806270932.AA26548@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu; Mon, 27 Jun 88 02:32:29 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Mon, 27 Jun 88 02:28 MST
Date: Mon, 27 Jun 88 04:12 CDT
From: GGRCS@UNO.BITNET
Subject: ICON group subscription
To: icon-group@arizona.edu
X-Original-To: icon-group@arizona.edu
Dear Sirs,
I would like to become a member of any ICON-related user/discussion
groups that are available.
Thanks,
Golden Richard III
CS Dept. @ University of New Orleans
Net address: GGRCS @ UNO.BITNET
From UNOCC07%zeus@crcvms.unl.edu Tue Jul 5 12:25:54 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 5 Jul 88 12:25:54 MST
Message-Id: <8807051504.AA13951@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.3) via SMTP
id AA13951; Tue, 5 Jul 88 08:04:12 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Tue, 5 Jul 88 07:52 MST
Date: Sun, 3 Jul 88 18:53 CDT
From: "Many people would rather die than think; in fact, most do."
<UNOCC07%zeus@crcvms.unl.edu>
Subject: Tables referenced by lists
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
Consider the following (very) short program:
procedure main()
t := table()
t[[2,3]] := "Hi there"
write("this is it :",t[[2,3]],".")
end
It's output is:
this is it :.
Why? [2,3] is not the same list as [2,3] in the 4th line? If not, what can
I do about it? I suppose I could convert it to a string... that would work,
but I'm not sure I understand why indexing the table by a string would
work (in the case of literals) but not a list...?
I'm confused, I guess. :-)
-/ Dave Caplinger /---------------+--------------------------------------------
Microcomputer Specialist | Internet: unocc07%zeus.dnet@fergvax.unl.edu
Campus Computing | uucp: uunet!mcmi!unocss!dent
University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1
Omaha, NE 68182 | (Last Resort: dc3a+@andrew.cmu.edu)
From gudeman Thu Jul 7 10:20:37 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 7 Jul 88 10:20:37 MST
Date: Thu, 7 Jul 88 10:18:02 MST
From: "David Gudeman" <gudeman>
Message-Id: <8807071718.AA27618@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59/MRM1.4)
id AA27618; Thu, 7 Jul 88 10:18:02 MST
To: UNOCC07%zeus@crcvms.unl.edu
Cc: icon-group@arizona.edu
In-Reply-To: <8807051504.AA13951@megaron.arizona.edu>
Subject: Tables referenced by lists
>Date: Sun, 3 Jul 88 18:53 CDT
>From: <UNOCC07%zeus@crcvms.unl.edu>
>
>Consider the following (very) short program:
>
>procedure main()
> t := table()
> t[[2,3]] := "Hi there"
> write("this is it :",t[[2,3]],".")
>end
>
>It's output is:
>
>this is it :.
>
>Why? [2,3] is not the same list as [2,3] in the 4th line?...
That's a fun one isn't it? The problem is that Icon treats strings
and lists differently. A string in Icon is a fixed object. For
example:
s1 := "abc"
s2 := s1
s1[1] := "x"
write(s1,s2)
writes out `xbcabc'. When you executed s1[1] := "x", you didn't
actually change the string "abc" into the string "xbc", what you
really did was create a new string "xbc" and assign that string to s1.
Other variables that have the value "abc" are not changed. Since
strings are fixed in Icon, we also say that all strings that look the
same _are_ the same. So it is always true that "abc" === "abc".
Lists are not fixed. For example:
L1 := [1,2,3]
L2 := L1
L1[1] := 9
every writes(!L1)
every writes(!L2)
writes out `923932'. The execution of L1[1] := 9 changed both L1 and
L2 because it actually changed the list [1,2,3] into the list [9,2,3].
But if you had written:
L1 := [1,2,3]
L2 := [1,2,3]
you certainly don't want the expression L1[1] := 9 to change L2! L1
and L2 are two _different_ lists that just happen to contain the same
elements. So that's the difference that causes problems with table
references, whenever you write "abc" you always get the same string,
but whenever you write [1,2,3] you always get a _different_ list. So
change your example to
procedure main()
t := table()
L := [2,3]
t[L] := "Hi there"
write("this is it :",t[L],".")
end
And you will get the output `this is it :Hi there.' as you expected.
Since I only wrote [2,3] once, there is only one list [2,3] so the
table reference works. What was happening before was that you were
putting the string "Hi there" into the table with the key [2,3], and
then trying to access it with a _different_ list that also happened to
look like [2,3].
One more thing, I sort of lied when I said that every time you write
[1,2,3] you get a new list. If you write an expression like:
repeat {
x := [1,2]
<do something with x>
}
x will be a new list every time through the loop. The truth is that
every time an expression like [1,2] is _executed_ you get a new list.
From UNOCC07%zeus@crcvms.unl.edu Wed Jul 13 15:49:27 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 15:49:27 MST
Message-Id: <8807132249.AA14193@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
id AA14193; Wed, 13 Jul 88 15:49:24 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 13 Jul 88 14:30 MST
Date: Wed, 13 Jul 88 15:36 CDT
From: "Many people would rather die than think; in fact, most do."
<UNOCC07%zeus@crcvms.unl.edu>
Subject: Some idle speculation...
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
An idle speculation...
-- Fair Warning: This is entirely speculation, is not necessarily
intended to resemble anything, etc etc. Laugh if you wish. :-)
If Icon were to operating system "x" as C is to UNIX, what would operating
system "x" be like? Would it be worth it? Regardless of my meager knowledge
of Icon, let me speculate "just for laughs". There isn't much traffic in
the icon group now anyway. :-)
Icon for Systems Programming:
Since I don't do systems programming, it's hard for me to say
just what is and isn't necessary (or simply convenient) to
accomplish any system programming "goals" effectively, but I'd
hazard a guess that Icon can indeed accomplish a large subset
of what C can do, excluding bitfields and unions. Should Icon
have these types of functions? But then, the Macintosh (shudder!)
operating system was originally written entirely in Pascal of
all things, and Icon can certainly accomplish anything Pascal
can. So, let's assume that using Icon for operating system
development is at least feasible. Let us also assume for simplicity
that we have a machine that will run icode directly, analogous to
Wirth's Lilith (sp?) machine (which runs either Pascal or Modula 2,
I don't remember).
Hypothetical Operating System (HOS):
I would assume that the primary purpose of an operating system
would be (at it's simplest) a file structure and control
operations for manipulating "files", and (more complex)
process structure and control. (But since I haven't actually
designed my own operating system, etc etc. :-)
Some basic file manipulation examples for HOS might be:
copy file1[4:-4] ||file2
Which, I suppose, might take everything in file1 starting at
the 4th line/record until the 4th line/record from the end and
append it to file2. Syntax of course is negotiable. :-)
print (file1 | defaultfile)
Which might print file1 or the defualt file, as you might expect.
What Conclusion? :
Anyway, I haven't really thought about it much, but figured it
might be entertaining to ponder this for a while. I think it all
started when I was sitting in CS-2980, "C Programming" when I
was regretting knowning Icon already :-) because of things like
C's " b = 4 " returning 1 instead of 4 when used in a test...
But anyway... what do you think? Ponder, duscuss, ignore, flame, etc...
-/ Dave Caplinger /---------------+--------------------------------------------
Microcomputer Specialist | Internet: unocc07%zeus.dnet@fergvax.unl.edu
Campus Computing | uucp: uunet!mcmi!unocss!dent
University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1
Omaha, NE 68182 | (Last Resort: dc3a+@andrew.cmu.edu)
From UNOCC07%zeus@crcvms.unl.edu Wed Jul 13 17:50:35 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 17:50:35 MST
Message-Id: <8807140050.AA21092@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
id AA21092; Wed, 13 Jul 88 17:50:33 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 13 Jul 88 16:38 MST
Date: Wed, 13 Jul 88 17:52 CDT
From: "Many people would rather die than think; in fact, most do."
<UNOCC07%zeus@crcvms.unl.edu>
Subject: Possible Icon Addition?
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
This is in no way related to that last posting...
I was wondering, would it be reasonable to want a facility in Icon for
sharing variables between two or more procedures? I'm thinking of something
like:
procedure something()
local x,y
static x
common y with other1,other2
...
end
where "other1", and "other2" are procedures elsewhere in either the same
file or a file linked in via "link ufile".
I suppose that "other1" and "other2" would have to have similar statements
specifying a variable "y" shared with the other two routines... But there's
no reason that "x" can't be a static variable common to four routines that
all might need to see it but without the calling routine having to set up
co-routines, global variables, etc.
No, no, don't tell me... is this similar to "Object-Oriented", or even just
a facet of it? Either way, I certainly think it would be usefull.
-/ Dave Caplinger /---------------+--------------------------------------------
Microcomputer Specialist | Internet: unocc07%zeus.dnet@fergvax.unl.edu
Campus Computing | uucp: uunet!mcmi!unocss!dent
University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1
Omaha, NE 68182 | (Last Resort: dc3a+@andrew.cmu.edu)
From sunquest!whm Wed Jul 13 18:46:48 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 18:46:48 MST
Received: by megaron.arizona.edu (5.59/MRM1.4)
id AA24787; Wed, 13 Jul 88 18:46:47 MST
Date: Wed, 13 Jul 88 18:41:59 MST
From: "Bill Mitchell" <sunquest!whm>
Message-Id: <8807140141.AA23718@sunquest>
Received: by sunquest; Wed, 13 Jul 88 18:41:59 MST
To: arizona!icon-group
Subject: Re: Possible Icon Addition?
It looks like what you're wanting is a way to have several procedures share
data, but you don't want to clutter up the name space with more global
variables.
There's been talk in the past about ways to do this, including something
like C's "static" globals, which are only known in the current file, but
although C's facility works ok in practice, some persons would prefer a
solution that isn't based on files.
I think it would be pretty simple to implement a C-like solution (I'd guess
2-3 man days counting ground work, implementation, and documentation), but I
don't know that there's much Icon Project time for such excursions. I'd rather
have a simple-minded facility to use now and then possibly convert to a more
robust facility at some point in the future than to have no facility at all.
Bill Mitchell
Sunquest Information Systems, Tucson, AZ
sunquest!whm@arizona.edu
uunet!sunquest!whm
{allegra,cmcl2,noao}!arizona!sunquest!whm
From icon-group-request Thu Jul 14 22:38:05 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 22:38:05 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59/MRM1.4) via SMTP
id AA15717; Thu, 14 Jul 88 22:37:51 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA27445; Thu, 14 Jul 88 21:36:53 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 14 Jul 88 23:07:22 GMT
From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: Possible Icon Addition?
Message-Id: <5295@ihlpf.ATT.COM>
References: <8807140050.AA21092@megaron.arizona.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
In article <8807140050.AA21092@megaron.arizona.edu> UNOCC07%zeus@crcvms.unl.EDU ("Many people would rather die than think; in fact, most do.") writes:
>I was wondering, would it be reasonable to want a facility in Icon for
>sharing variables between two or more procedures?
This is definitely something that would be handy! All too often I either
have to use a lot of globals or pass a list of the stuff I want a few
procedures to share.
The 'C' mechanism (variables declared 'static' in a file but not inside a
function declaration can only be seen within that file) would be an
adequate way of doing this, but I would prefer one which wasn't based on
files and one that looks a little more like it fits in Icon (although I
can't think of a better way right now).
--
_ __ NEVIN J. LIBER ..!att!ihlpf!nevin1 (312) 979-????
' ) ) You are in a little maze of twisty
/ / _ , __o ____ email paths, all different.
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
From icon-group-request Thu Jul 14 22:39:21 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 22:39:21 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59/MRM1.4) via SMTP
id AA15861; Thu, 14 Jul 88 22:39:05 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA27377; Thu, 14 Jul 88 21:33:52 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 14 Jul 88 23:02:16 GMT
From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: Some idle speculation...
Message-Id: <5294@ihlpf.ATT.COM>
References: <8807132249.AA14193@megaron.arizona.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
In article <8807132249.AA14193@megaron.arizona.edu> UNOCC07%zeus@crcvms.unl.EDU ("Many people would rather die than think; in fact, most do.") writes:
|Icon for Systems Programming:
| Since I don't do systems programming, it's hard for me to say
| just what is and isn't necessary (or simply convenient) to
| accomplish any system programming "goals" effectively, but I'd
| hazard a guess that Icon can indeed accomplish a large subset
| of what C can do, excluding bitfields and unions.
There is no need to have unions in Icon, since variables are allowed to
take on any value. And you can do bitfields if you're clever. :-)
| But then, the Macintosh (shudder!)
| operating system was originally written entirely in Pascal of
| all things, and Icon can certainly accomplish anything Pascal
| can.
Wasn't it done in an object-oriented version of Pascal (help, Darin :-))?
Icon does not (yet) have object-oriented extensions.
|Hypothetical Operating System (HOS):
| Some basic file manipulation examples for HOS might be:
| copy file1[4:-4] ||file2
| Which, I suppose, might take everything in file1 starting at
| the 4th line/record until the 4th line/record from the end and
| append it to file2. Syntax of course is negotiable. :-)
| print (file1 | defaultfile)
| Which might print file1 or the defualt file, as you might expect.
It seems to me that you would like to use Icon as a shell-type language.
For me, most of the stuff I use to write in sh I now right in Icon because
it is a LOT easier.
|What Conclusion? :
| I think it all
| started when I was sitting in CS-2980, "C Programming" when I
| was regretting knowning Icon already :-) because of things like
| C's " b = 4 " returning 1 instead of 4 when used in a test...
C's " b = 4" returns 4, not 1, when used as a test (in an 'if' statement).
Did you mean the '==' operator (and I thought Icon's operators were
confusing :-))?
|But anyway... what do you think? Ponder, duscuss, ignore, flame, etc...
As a shell language, Icon is preferable to anything else I use now. But
until some object-oriented extensions come along for Icon, I would prefer
to use a language like C++ for systems programming. (But for everything
else, Icon all the way! :-) :-))
--
_ __ NEVIN J. LIBER ..!att!ihlpf!nevin1 (312) 979-????
' ) ) You are in a twisty little maze of
/ / _ , __o ____ email paths, all different.
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
From rich%sendai.uucp@umix.cc.umich.edu Thu Jul 14 23:03:07 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 23:03:07 MST
Received: from a.cc.umich.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
id AA17225; Thu, 14 Jul 88 23:03:01 MST
Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
id AA18189; Fri, 15 Jul 88 02:00:02 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA19640; Fri, 15 Jul 88 02:11:44 EDT
Date: Fri, 15 Jul 88 02:11:44 EDT
From: rich%sendai.uucp@umix.cc.umich.edu
Message-Id: <8807150611.AA19640@umix.cc.umich.edu>
To: UNOCC07%zeus%crcvms.unl.edu%umix.uucp@umix.cc.umich.edu
Cc: icon-group%arizona.edu%umix.uucp@umix.cc.umich.edu
In-Reply-To: "Many people would rather die than think; in fact, most do."
's message of Wed, 13 Jul 88 17:52 CDT <8807140050.AA21092@megaron.arizona.edu>
Subject: Possible Icon Addition?
Reply-to: rich@sendai.UUCP
>From arizona.edu!icon-group-sender Wed Jul 13 21:01:54 1988 remote from umix
Date: Wed, 13 Jul 88 17:52 CDT
From: "Many people would rather die than think; in fact, most do."
<umix!crcvms.unl.edu!zeus!UNOCC07>
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
This is in no way related to that last posting...
I was wondering, would it be reasonable to want a facility in Icon for
sharing variables between two or more procedures? I'm thinking of something
like:
Well...
Common blocks seem pretty unstructured and counter intuitive.
But if you want a useful speculation, consider how you'd modify the
language to take into account symmetric parallel processors. Do you
program at the processor level and pass messages? Or pipeline the
interpreter? Or can you find a way to really co- the co-expressions?
Or something else I haven't thought of?
xoxorich.
From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Fri Jul 15 11:12:43 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 11:12:43 MST
Received: from a.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
id AA27147; Fri, 15 Jul 88 11:12:11 MST
Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
id AA19914; Fri, 15 Jul 88 14:08:35 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA03414; Fri, 15 Jul 88 14:20:28 EDT
Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 15 Jul 88 14:04:58 EDT
Date: Fri, 15 Jul 88 12:25:42 EDT
From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
To: icon-group@arizona.edu
Message-Id: <70024@Wayne-MTS>
Subject: Error in V7 MS-DOS documentation
Note, friends: the "line number table" parameter in Sec. 6.2 of the Icon
MS-DOS V7 documentation is erroneously printed as "l" when it should
be "n". That's one of the parameters used with "-S" to set table sizes during
compilation and linking.
Paul Abrahams
From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Fri Jul 15 11:12:44 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 11:12:44 MST
Received: from a.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
id AA27148; Fri, 15 Jul 88 11:12:17 MST
Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
id AA19910; Fri, 15 Jul 88 14:08:16 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA03404; Fri, 15 Jul 88 14:20:10 EDT
Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 15 Jul 88 14:04:40 EDT
Date: Fri, 15 Jul 88 12:24:12 EDT
From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
To: icon-group@arizona.edu
Message-Id: <70022@Wayne-MTS>
Subject: Sharing variables among procedures
The C scheme is really not adequate for sharing variables among procedures,
at least when those procedures are being used as coexpressions and more than
one activation of a particular coexpression can exist at once. This is not
just theory; it occurred in a rather complex Icon program that I wrote to do a
real, useful task (a prototype document formatter).
Paul Abrahams
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Fri Jul 15 15:36:33 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 15:36:33 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.5) via SMTP
id AA17760; Fri, 15 Jul 88 15:36:25 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA27659; Fri, 15 Jul 88 17:35:23 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA08268; Fri, 15 Jul 88 17:28:59 CDT
Date: Fri, 15 Jul 88 17:28:59 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8807152228.AA08268@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: object-oriented extensions, variable scoping
I'd love to have some message-passing capability in Icon. But someone is
going to have to do some very careful thinking as to how this could be done
in a distinctly Iconish manner. Then someone is going to have to do a lot
of work incorporating it into the existing (already quite large) framework.
If we don't watch out, we'll have a monster on our hands, like Common Lisp.
As for variables, and sharing them among procedures: My hope is that we
introduce dynamic variables based on the current &level of the current acti-
vation branch. That way procedure X and all procedures called by X would
automatically have access to variables defined as "dynamic" in procedure
X. Yes, I know that this might introduce bad side-effects, and encourage slop-
py programming. But heh, the more tightly controlled a programmer is by
the lang., the less clever, and at times clear, he/she can be. At some point,
you gotta put the discipline in the programmer's head, rather than ram it
down his throat by introducing pedantic restraints in the programming language
itself.
One other thing I'd love is the ability to specify static typing of variables.
Wouldn't it be nice to be able to tell Icon that a certain variable is/will
always be an integer. This could lead to some useful error-checking. But
better than this, it would allow increased speed, and better handling of
storage. Just a thought. I wouldn't consider this feature necessary. Really
it's the message-passing and dynamic variables that would be nice.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From icon-group-request Fri Jul 15 17:41:48 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 17:41:48 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
id AA27130; Fri, 15 Jul 88 17:41:33 MST
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA17940; Fri, 15 Jul 88 17:20:33 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 Jul 88 22:11:53 GMT
From: cjeffery@arizona.edu (Clinton Jeffery)
Organization: U of Arizona CS Dept, Tucson
Subject: Re: Sharing variables among procedures
Message-Id: <6274@megaron.arizona.edu>
References: <70022@Wayne-MTS>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
From article <70022@Wayne-MTS>, by Paul_Abrahams%Wayne-MTS@um.cc.umich.EDU:
> The C scheme is really not adequate for sharing variables among procedures,
> at least when those procedures are being used as coexpressions and more than
> one activation of a particular coexpression can exist at once.
For what its worth, I concur. However, instead of just knocking an inadequate
idea, I would appreciate it if Paul would give us a feel for what kind of
scoping mechanism it would take to make him happy (leaving feasibility aside
for a moment). My own gut feeling is that coexpressions need a *different*
mechanism for sharing data than the more mundane case, and maybe if the C
scheme would be adequate 98% of the time, and only take a day or so,
it would be worth doing. Maybe.
--
| Clint Jeffery, University of Arizona Department of Computer Science
| cjeffery@arizona.edu -or- {ihnp4 noao allegra cmcl2}!arizona!cjeffery
--
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Sun Jul 17 19:04:38 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 17 Jul 88 19:04:38 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.5) via SMTP
id AA28479; Sun, 17 Jul 88 19:04:31 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA28625; Sun, 17 Jul 88 21:03:33 CDT
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA11542; Sun, 17 Jul 88 20:57:03 CDT
Date: Sun, 17 Jul 88 20:57:03 CDT
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8807180157.AA11542@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: scoping
I quote Clint Jeffery:
Maybe if the C scheme would be adequate 98% of the time,
and only take a day or so, it would be worth doing. Maybe.
Underscore the maybe? After all, by the time the ball gets rolling,
and people have set up all their libraries and programs according to a
new scheme, we will have built up a tremendous amount of inertia.
Then, when a new, better scheme is introduced, it will have to be
back-compatible (thus adding to the size of Icon), and any problems
that existed with the first scheme will become all the more in-
grained. Better to think things through from the ground up, and
implement when a clean, Iconish scheme has been worked out. (Easy
for me to say, huh...).
Or is this silly? Is the partial, immediate solution better?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
From @NSS.Cs.Ucl.AC.UK,@cs.qmc.ac.uk:gcj@maths.qmc.ac.uk Mon Jul 18 08:25:53 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 18 Jul 88 08:25:53 MST
Received: from NSS.CS.UCL.AC.UK by megaron.arizona.edu (5.59-1.5) via SMTP
id AA24706; Mon, 18 Jul 88 08:25:29 MST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04113; 18 Jul 88 15:53 BST
Received: from qmcms.maths.qmc.ac.uk by csvax.cs.qmc.ac.uk id a019008;
18 Jul 88 16:22 BST
From: Gordon Joly <gcj%maths.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 18 Jul 88 16:16:06 BST
Message-Id: <10235.8807181516@qmcms.maths.qmc.ac.uk>
To: icon-group@arizona.edu
Subject: ICON Logo.
Liked the new ICON logo in the newsletter; had the "look and
feel" of the SUN Microsystems logo. C u in court;--) !!
From wunder@sde.hp.com Mon Jul 18 13:33:33 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 18 Jul 88 13:33:33 MST
Received: from hp-sde.sde.hp.com by megaron.arizona.edu (5.59-1.5) via SMTP
id AA10617; Mon, 18 Jul 88 13:33:22 MST
Received: from liberator.sde.hp.com (orac) by hp-sde ; Mon, 18 Jul 88 13:33:08 pdt
Received: by hpsdel ; Mon, 18 Jul 88 13:30:55 pdt
Date: Mon, 18 Jul 88 13:30:55 pdt
From: Walter Underwood <wunder@sde.hp.com>
Message-Id: <8807182030.AA01512@liberator.sde.hp.com>
To: icon-group@arizona.edu
In-Reply-To: Richard Goerwitz's message of Sun, 17 Jul 88 20:57:03 CDT <8807180157.AA11542@sophist.uchicago.edu>
Subject: scoping
This is a shot inthe dark, but ...
Co-expressions seem very similar to the delay and force constructs in
Scheme. Scheme is lexically scoped and seems to deal well with delay
and force. Perhaps we can learn something there?
wunder
From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Wed Jul 20 11:08:03 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 11:08:03 MST
Received: from [35.1.1.10] by megaron.arizona.edu (5.59-1.5) via SMTP
id AA20505; Wed, 20 Jul 88 11:07:53 MST
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA17878; Wed, 20 Jul 88 14:17:07 EDT
Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Wed, 20 Jul 88 14:02:15 EDT
Date: Wed, 20 Jul 88 12:39:40 EDT
From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
To: icon-group@arizona.edu
Message-Id: <71102@Wayne-MTS>
Subject: Sharing variables among procedures
Here is a sketch of a powerful yet simple scheme of sharing variables
among procedures (maybe it's nothing more than abstract data types under a
different name).
A module consists of a collection of named variables, a collection of
procedures, and some startup code (no nesting of modules allowed, at least for
now). An Icon program consists of a collection of modules, procedures, and
global variables. A module, like an expression, can be subjected to the @
operator, producing an instantiated module. When a module is instantiated,
its startup code is executed. Procedure p of instantiated module m is
referred to as m.p. The procedures within a module can refer to the variables
of that module.
The degenerate case is where each module is instantiated exactly once, at the
start of the program, and no module has any startup code. In this case each
module is much like a C file, except that references to its procedures require
name qualification.
An instantiated module is destroyed when it becomes inaccessible, according to
the general principles of garbage collection.
I assume that the variables of a module are inaccessible outside of that
module, but it is just as easy to make them accessible if that is preferred.
The internal representation of a module is (obviously) a record containing the
values of its variables.
I hope to talk about some ideas relating to this at the workshop next week.
Paul Abrahams
From icon-group-request Wed Jul 20 23:14:44 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 23:14:44 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
id AA27332; Wed, 20 Jul 88 23:14:29 MST
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA06673; Wed, 20 Jul 88 22:11:52 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Jul 88 22:44:57 GMT
From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: Sharing variables among procedures
Message-Id: <5359@ihlpf.ATT.COM>
References: <70022@Wayne-MTS>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
In article <70022@Wayne-MTS> Paul_Abrahams%Wayne-MTS@um.cc.umich.EDU writes:
>The C scheme is really not adequate for sharing variables among procedures,
Just wondering: what was it about the C scheme that made it inadequate for Icon
(I know that it doesn't really fit in with the Icon way of things but it seems to
me that you could get by with the C scheme)?
>at least when those procedures are being used as coexpressions and more than
>one activation of a particular coexpression can exist at once.
Using the C scheme, the shared variables should appear to be globals for the
coexpression. Or did you want a new set of shared variables for each activation
of a coexpression?
--
_ __ NEVIN J. LIBER ..!att!ihlpf!nevin1 (312) 979-????
' ) ) You are in a twisty maze of little
/ / _ , __o ____ email paths, all different.
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
From icon-group-request Wed Jul 20 23:22:38 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 23:22:38 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
id AA27782; Wed, 20 Jul 88 23:21:58 MST
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA06729; Wed, 20 Jul 88 22:13:41 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Jul 88 23:05:33 GMT
From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: object-oriented extensions, variable scoping
Message-Id: <5363@ihlpf.ATT.COM>
References: <8807152228.AA08268@sophist.uchicago.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
In article <8807152228.AA08268@sophist.uchicago.edu> goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) writes:
>As for variables, and sharing them among procedures: My hope is that we
>introduce dynamic variables based on the current &level of the current acti-
>vation branch. That way procedure X and all procedures called by X would
>automatically have access to variables defined as "dynamic" in procedure
>X.
I don't know about this. This is only good in languages like Pascal and Modula-2
where the scope of a variable can be determined by just looking at the source for
a program. I also think that this might be signifcantly slower than the current
mechanism (no dynamic variables), since a lookup in a symbol table would be
required for all variables not declared as local, and symbol table maintenance
would need to be done on each call/suspend/return. I think that, due to
generators, the symbol table might need to be part of the frame.
>Yes, I know that this might introduce bad side-effects, and encourage slop-
>py programming.
One of the side effects is that routine A could declare a dynamic variable X, and
a routine B could also declare a dynamic variable X, and if they both call C
which uses a dynamic variable X, trace back is very difficult.
This type of scoping mechanism (dynamic variables with automatic access by called
routines) would lead to very hard to follow code; I don't think it would be
suitable for Icon.
>One other thing I'd love is the ability to specify static typing of variables.
>Wouldn't it be nice to be able to tell Icon that a certain variable is/will
>always be an integer. This could lead to some useful error-checking. But
>better than this, it would allow increased speed, and better handling of
>storage.
I don't think it would lead to increased speed (unless you're talking about
adding some 'optimized' opcodes to the icode language). From an implementation
point of view, however, this does not seem very difficult to implement. All that
would need to be done (I think) is to add another flag to the variable descriptor
which, if set, means that the type of the variable cannot be changed. The flag
need only be checked during an assignment operation.
The only thing is, I would want to have the &null value to be part of every type
(not easy to implement), since most of the time I use &null to indicate that a
variable has not been used yet or that it contains no useful data.
--
_ __ NEVIN J. LIBER ..!att!ihlpf!nevin1 (312) 979-????
' ) ) You are in a twisty maze of little
/ / _ , __o ____ email paths, all different.
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Thu Jul 21 15:21:32 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 21 Jul 88 15:21:32 MST
Received: from umix.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
id AA10259; Thu, 21 Jul 88 15:21:23 MST
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA09335; Thu, 21 Jul 88 17:06:12 EDT
Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Thu, 21 Jul 88 14:02:03 EDT
Date: Thu, 21 Jul 88 12:49:34 EDT
From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
To: icon-group@arizona.edu
Message-Id: <71410@Wayne-MTS>
Subject: Modules versus C scoping
There are several reasons why I would not want to see the C scoping rules
incorporated into Icon:
(1) The rules themselves are awkward even in C. The C Standards Committee had
a hard time figuring out what the rules for externs really ought to be. There
are several odd, nasty cases that were treated differently by different
implementors.
(2) The notion of a file as a scoping unit might make sense in the Unix
environment, although I'm not convinced even of that. Outside of Unix, it
makes hardly any sense at all. Files are really an operating system concept,
not a programming language concept.
(3) The notion of naming modules when you reference their entities, as you do
in my module scheme, clearly establishes the owner of a variable. Confusion
about such ownership is one of the problems that C has with its scoping rules
for globals.
(4) I have found it useful to have multiple activations of a procedure
that shares variables with other procedures, implying one set of shared
variables per activation. The module scheme handles this nicely; the C scheme
doesn't handle it at all. Interestingly, allowing nested procedures also
achieves sharing as long as there is only one active process. Nested
procedures work even in the presence of recursion. They don't exist in either
Icon or C, but they do exist in Pascal and in most Algol 60 descendants.
(5) Using the C scheme as a stopgap will preclude doing something better later
on, as others have pointed out.
Paul Abrahams
From kwalker Thu Jul 21 15:29:08 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 21 Jul 88 15:29:08 MST
Date: Thu, 21 Jul 88 15:29:05 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8807212229.AA10902@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5)
id AA10902; Thu, 21 Jul 88 15:29:05 MST
In-Reply-To: <5363@ihlpf.ATT.COM>
To: icon-group
Subject: Re: object-oriented extensions, variable scoping
> Date: 20 Jul 88 23:05:33 GMT
> From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704a-Liber)
>
> In article <8807152228.AA08268@sophist.uchicago.edu>
> goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) writes:
>
> >As for variables, and sharing them among procedures: My hope is that we
> >introduce dynamic variables ...
>
> ...
>
> I also think that this might be signifcantly slower than the current
> mechanism (no dynamic variables), since a lookup in a symbol table would be
> required for all variables not declared as local, and symbol table maintenance
> would need to be done on each call/suspend/return. I think that, due to
> generators, the symbol table might need to be part of the frame.
I think you can get by without a real symbol table. By link time you
should be able to identify all dynamic variables. You can allocate and
access them like global variables, with maintenance done at each
call/suspend/return as you suggest. This maintenance consists of saving
the old value upon entering a procedure and supplying the appropriate new
value, and then the reversing the processs upon leaving a procedure (with
a suspend you have to save the new value in case of a resumption).
This is similar to what is done in SNOBOL4 (and some Lisps, where it is
call "shallow binding"), though SNOBOL4 needs a real symbol table but does
not have to deal with generators. It is also similar to what is done with
&subject and &pos in string scanning.
You can also do a form of "deap binding" where you do put a symbol table
in each procedure frame and search backwards through the frames until you
find the variable you what. However, that would be rather expensive.
> >One other thing I'd love is the ability to specify static typing of
> >variables.
> >Wouldn't it be nice to be able to tell Icon that a certain variable is/will
> >always be an integer. This could lead to some useful error-checking. But
> >better than this, it would allow increased speed, and better handling of
> >storage.
>
> I don't think it would lead to increased speed (unless you're talking about
> adding some 'optimized' opcodes to the icode language).
More likely you would want to do it in a compiler to get speed advantages.
> The only thing is, I would want to have the &null value to be part of every
> type
> (not easy to implement), since most of the time I use &null to indicate that a
> variable has not been used yet or that it contains no useful data.
Good point! You would definitly have to deal with the initial value
problem.
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {allegra|noao}!arizona!kwalker
From DSCARGO@cim-vax.HONEYWELL.COM Mon Jul 25 06:34:21 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 25 Jul 88 06:34:21 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5) via SMTP
id AA15439; Mon, 25 Jul 88 06:34:13 MST
Received: by cim-vax id <0000021E081@cim-vax.HONEYWELL.COM> ;
Mon, 25 Jul 88 08:32:51 CDT
Date: Mon, 25 Jul 88 08:19:01 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Piping between Icon routines
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880725081901.0000021E081@cim-vax.HONEYWELL.COM>
Someone earlier asked the question about what an operating system based on
Icon would be like; likewise the question of encapsulation arose. I was
thinking about MS-DOS command interpreters recently; I occurred to me to
wonder how hard it would be for the Icon interpreter to handle command lines
where Icon programs were connected by their own pipe operations.
In other words, the Icon interpreter would get a command like
"a | b | c" <in >out
with the requirement that a, b, and c are Icon programs that would be
communicating via a pipe style mechanism. The communication would be one
directional. While parallelism might be possible (if the interpreter were
upgraded to handle simultaneous processes?), sequential operation would be
OK for most things.
This gives a certain amount of encapsulation; programs compiled and linked
separately are indeed still separate. I could see adding an EXPORTED or
EXTERNAL or COMMON data type that would survive between programs (for strictly
sequential operation) or be dynamically shared (for concurrent operation).
The weaknesses of this are many. My main reason for wanting it would be to
exploit the similarity to UNIX pipes: the ability to construct new tools by
composing sequences of simpler tools. It also avoids (potentially) the
overhead of loading the Icon interpreter repeated in order to run a sequence
of Icon progams.
The restriction to strictly sequential operations is a large one, but it
might provide a way to experiment until something more general evolves. As
long as shared variable symantics are NOT introduced, it doesn't introduce
any radical features (at least that I can see).
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From DSCARGO@cim-vax.HONEYWELL.COM Fri Jul 29 14:36:25 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 29 Jul 88 14:36:25 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5) via SMTP
id AA12189; Fri, 29 Jul 88 14:36:17 MST
Received: by cim-vax id <00000E5D0B1@cim-vax.HONEYWELL.COM> ;
Fri, 29 Jul 88 16:34:35 CDT
Date: Fri, 29 Jul 88 16:34:04 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Icon teaching aids
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880729163404.00000E5D0B1@cim-vax.HONEYWELL.COM>
I'm going to be presenting an Icon overview and extremely short course
(1 hour overview, 1-2 hours basics) to a group of already skilled programmers.
I was wondering if anybody had suggestions for what material to cover, in
what order. Also, if anybody had any training experiences they are willing
to relate, or training materials they are willing to share, I'd like to hear
what they have to say.
We are going to be using the VAX/VMS implementation. We will largely be using
Icon for "data laundry" applications, as well a program analysis.
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From DSCARGO@cim-vax.HONEYWELL.COM Fri Aug 5 13:23:58 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 5 Aug 88 13:23:58 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA06863; Fri, 5 Aug 88 13:23:41 MST
Received: by cim-vax id <00001B55071@cim-vax.HONEYWELL.COM> ;
Fri, 5 Aug 88 15:22:07 CDT
Date: Fri, 5 Aug 88 15:14:22 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: table entry value list
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880805151422.00001B55071@cim-vax.HONEYWELL.COM>
One of the Icon users at my site asked me for the best way to get the
list of entry values associated with a table. !t will return the list
of assigned values. Sorting will create a list (or lists) containing
entry and assigned values. What's the best way to get the list (or set)
of entry values? (An extension allowing conversion of a table to a set
might be useful. Such as s:= domain(t) returns the set of entry values
and s := range(t) returns the set of assigned values. Does that sound
useful?)
From kwalker Fri Aug 5 15:29:52 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 5 Aug 88 15:29:52 MST
Date: Fri, 5 Aug 88 15:27:36 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8808052227.AA13363@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA13363; Fri, 5 Aug 88 15:27:36 MST
In-Reply-To: <880805151422.00001B55071@cim-vax.HONEYWELL.COM>
To: DSCARGO@cim-vax.HONEYWELL.COM, icon-group@arizona.edu
Subject: Re: table entry value list
At present, the only way to get the entry values of a table
is to sort the table and extract them from the resulting list.
We recognize that a better way would be useful. There are several
possible approaches and we haven't decided which is best. Thanks
for your suggestion.
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {allegra|noao}!arizona!kwalker
From DSCARGO@cim-vax.HONEYWELL.COM Mon Aug 8 06:51:31 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 06:51:31 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA16936; Mon, 8 Aug 88 06:51:23 MST
Received: by cim-vax id <00000267071@cim-vax.HONEYWELL.COM> ;
Mon, 8 Aug 88 08:50:00 CDT
Date: Mon, 8 Aug 88 08:41:25 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Most thoughts on tables
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880808084125.00000267071@cim-vax.HONEYWELL.COM>
While thinking over the problem of getting the list of entry values for a
table, it occurred to me to wonder if you had considered implementing bags.
(Bags are like sets except they all multiple instances of the same value.)
Tables could then be considered as a mapping from a set to a bag; it would
then be natural to be able to look at them separately by mapping the domain
of the table into a set and the range of a table into a bag. A bag should
also be relatively easy to map into a set if unique values are required.
Syntactically, bags could be made identical to sets (provided the operators
don't get too overloaded in the process).
I was also wondering about the unary ? operator. This is the equivalent of
"drawing (a random element) with replacement." Is there an easy way to do
drawing without replacement? There a classes of probability problems that
would be much easier to code if drawing without replacement was simple. I
suppose in most cases, shuffling a list and then "getting" elements off the
front of it is equivalent, but I wasn't sure.
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From sboisen@PEBBLES.BBN.COM Mon Aug 8 08:42:09 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 08:42:09 MST
Message-Id: <8808081541.AA21970@megaron.arizona.edu>
Received: from PEBBLES.BBN.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA21970; Mon, 8 Aug 88 08:41:56 MST
To: icon-group@arizona.edu
Date: Mon, 8 Aug 88 11:30:30 EDT
From: sboisen@PEBBLES.BBN.COM
Sender: sboisen@PEBBLES.BBN.COM
I though i'd pass along the following for those of you who don't
follow these newsgroups. Richard O'Keefe is, by the way, very highly
respected in Prolog circles (rightly so in my opinion), so at least
with respect to Prolog he almost certainly knows what he's talking about.
----------------------------------------------------------------------
From: ok@quintus
Newsgroups: comp.lang.prolog,comp.lang.misc
Subject: Is ICON higher level than Prolog?
Date: 8 Aug 88 03:23:37 GMT
Reply-To: ok@quintus ()
Organization: Quintus Computer Systems, Inc.
ICON (described in "The ICON Programming Language", Griswold & Griswold,
Prentice-Hall, 1983) is a descendant of SNOBOL. It has a fairly
conventional syntax, but adds backtracking, strings, hash tables,
and pattern-matching (patterns are not a data type as in SNOBOL, but
you can do most of the same sorts of things).
Version 7 of ICON (the current one) is implemented (in C and YACC) as
a compiler which produces abstract instructions which are then interpreted
by another C program. This is rather like the Berkeley Pascal "pi"
compiler and "px" interpreter.
Version 5 of ICON (the one described in the book) had two implementations
sharing a common front end: an "abstract instruction" version, and one
which produced native code. However, the book says that "a difference of
5% to 10%" in speed between "compiled" and "interpreted" versions was
typical. So the ICON group decided that it wasn't worth maintaining the
native-code version any longer.
What I'd like to understand is why the difference was so slight.
Let's put it in context (bigger numbers mean faster, each language's
C-coded interpreter set to 1):
1 Pascal, Berkeley "pi" + "px"
36 Pascal, Berkeley "pc" -- my measurement on a SUN-3
1 Prolog, WAM emulated in C
2 Prolog, WAM emulated in assembly code
4 Prolog, WAM macro-expanded and peephole-optimised to native code
1.0 ICON, Version 5 "icont" + "iconx"
1.1 ICON, Version 5 "iconc"
It's a long time since I was sure of my facts about Berkeley Pascal, but
I don't recall the abstract instructions as being designed for particularly
fast emulation, or the compiler as doing much optimisation. I suspect that
a ratio of 4 to 10 for "simple-minded native code" -vs- "good C emulator"
should be more typical of Pascal.
So why is the ICON ratio so low?
It could be that the emulator was unusually good, or the compiler unusually
bad, or it could be something about the language. To put _that_ in
context, I decided to take a Prolog program and recode it in ICON. Since
I happened to have it handy, I used the "darlington-to-workington" example
on page 163 of the 3rd edition of Clocksin & Mellish (section 7.9).
The total times to find all shortest paths from each town were
original Prolog version 4.8 seconds
ICON version 6.2 seconds
comparable Prolog version 0.5 seconds
ohe original Prolog version is the one which appears in Clocksin & Mellish.
It uses "findall", which is a fairly expensive operation, and uses a
quadratic algorithm for finding the shortest element of a list.
The ICON version, not being able to backtrack over a Prolog-like data base,
backtracks over a vector of triples, but is otherwise determinate.
The second Prolog version is much closer to the ICON version in structure.
The ICON version suffers from not having lists (in the sense of Prolog and
Lisp). Instead it has extensible vectors (and calls them lists). This is
a neat idea, but the overheads of the ICON implementation are high. So I
declared a "pair" record type (pair(Cost,Path) in ICON corresponding to
Cost-Path in Prolog) and a "cons" record type (cons(Head,Tail) in ICON
corresponding to [Head|Tail]) in Prolog. Allow a factor of 3 for the
size of the data structures (ICON data structures taking up a lot of
memory), and a factor of 2 to allow for the fact that the ICON emulator
is coded in C and the Quintus Prolog emulator isn't, and we're looking
at a ratio of about 2 to 1 between ICON and Prolog [on _this_ task, as
coded by me, running on a Sun-3/50, & other context].
The bottom line of this comparison is that the ICON interpreter doesn't seem
to be especially good or especially bad. If ICON were like Prolog, we
would expect about a factor of 4 between the speed of interpreted code and
the speed of native code. That fact that this was _not_ observed suggests
that either the compiler or the language was the problem.
It's worth drawing a distinction between polymorphic languages like ML
and typed Prolog, and languages with overloading, like PL/I and ICON.
An example of a polymorphic operation is:
-- len: * list -> int
++ len nil = 0
++ len H.T = 1 + len T
which computes the length of a list, be the type of the elements what it may.
An example of an overloaded operation is:
*X
which yields: the cardinality of a character set, the cardinality of a
(general) set, the length of a string, the length of a vector, the
number of fields in a record, &c, each of which is a different machine-
level operation. Similarly (courtesy of automatic run-time coercion),
X||Y (string concatenation) does not correspond to a single operation either.
So I _think_ the low ratio for ICON wasn't do to the compiler either, but
to the fact that there is so little that the compiler can do.
Would anyone who understands (I have the ICON Implementation book, but have
not finished it yet and still can't pretend to understand) the ICON
implementation care to comment on this?
[I'm quite happy with ICON's speed: it's quite a bit faster than AWK....]
........................................
Sean Boisen -- sboisen@bbn.com
BBN Systems and Technologies Corporation, Cambridge MA
Disclaimer: these opinions void where prohibited by lawyers.
From ralph Mon Aug 8 08:59:41 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 08:59:41 MST
Date: Mon, 8 Aug 88 08:59:38 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8808081559.AA22804@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA22804; Mon, 8 Aug 88 08:59:38 MST
To: icon-group@arizona.edu, sboisen@PEBBLES.BBN.COM
Subject: Speed of the Icon compiler and interpreter
In-Reply-To: <8808081541.AA21970@megaron.arizona.edu>
The small amount of difference in speed between the Version 5 Icon
interpreter and compiler is largely due to the fact that Icon programs
spend most of their time in the run-time system ("library routines")
rather than in the code generated for the program itself.
That is, the code generated for an Icon program consists mostly of
calls of library routines. This includes time consuming high-level
operations like table look-up. A significant amount of time also
is spent in storage management, which again is not done directly in the
generated code.
There's also a semantic trap here. Folks tend to take the words
"compiler" and "interpreter" in a naive way. Note that in both the
Version 5 compiler and interpreter, a lot of time is spent in compiled
code -- not code generated by the program, but code in the run-time system.
In fact, the "compiler" just maps the virtual-machine instructions
generated from the source program into naive assembly-langeuage code that
mirrors the code interpreted in the interpreter. So what you save by compiling
is mostly the instruction decoding that the interpreter performs.
A lot of implementations of high-level languages really are hybrids. For
example, the SPITBOL implementation of SNOBOL4 generates fast, compiled
code. However, some sophisticated operations are implemented by modifying
the in-memory code. It's hard to know how to characterize such an
implementation in the simple compiler/interpreter view.
From R.J.Hare@EDINBURGH.AC.UK Mon Aug 8 19:31:38 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 19:31:38 MST
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA23532; Mon, 8 Aug 88 19:31:37 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Mon, 8 Aug 88 19:09 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1430; Mon,
08 Aug 88 14:25:40 BST
Date: 08 Aug 88 14:26:04 bst
From: R.J.Hare@EDINBURGH.AC.UK
Subject: Sorting
To: icon-group@arizona.edu
Via: 000015001003.FTP.MAIL; 8 AUG 88 14:25:33 BST
Message-Id: <08 Aug 88 14:26:04 bst 340343@EMAS-A>
This may be a silly question, but at the moment I can't think of a simple
answer.
How do I sort using two keys with Icon? I want to sort a word list by
frequency, and, within groups of words with the same frequency of occurrence,
sort the words alphabetically - a standard word list in fact. Is it possible
to do this using the Icon 'sort' function?
Thanks
Roger Hare.
From DSCARGO@cim-vax.HONEYWELL.COM Tue Aug 9 06:45:35 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 9 Aug 88 06:45:35 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA17256; Tue, 9 Aug 88 06:45:28 MST
Received: by cim-vax id <0000083F071@cim-vax.HONEYWELL.COM> ;
Tue, 9 Aug 88 08:43:36 CDT
Date: Tue, 9 Aug 88 08:41:03 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Sorting on two keys
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880809084103.0000083F071@cim-vax.HONEYWELL.COM>
I guess I'd attack your two key sorting problem by creating a temporary
list made by converting your counts to strings, right justifying them so
that they sort properly into lexical order, append the words left justified
so that THEY sort properly into lexical order, and the sort the result.
Your keys would be of fixed width, so it would be easy to slice them back
off again.
dsc
From icon-group-request Wed Aug 10 04:51:25 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 04:51:25 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA13281; Wed, 10 Aug 88 04:51:12 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
id AA22179; Wed, 10 Aug 88 04:14:28 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 Aug 88 22:40:52 GMT
From: hall!pmk@umn-cs.arpa (Peter Klausler)
Organization: Cray Research, Inc., Mendota Heights, MN
Subject: Acquiring icon for Sun-3
Message-Id: <8421@hall.cray.com>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I would like to use icon for some rapid prototyping work on a Sun-3/50
workstation. My systems adminstrator has promised to bring icon up
on our machines if I can tell him where he can get it, preferably
via anonymous FTP.
Any information regarding availability of icon for the Sun would be
greatly appreciated. Please respond by mail; I'm sure that this group
gets more than enough postings like this one.
- Peter Klausler @ Cray Research compiler development (612) 681-5828
From kwalker Wed Aug 10 09:27:51 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 09:27:51 MST
Date: Wed, 10 Aug 88 09:27:47 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8808101627.AA04281@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA04281; Wed, 10 Aug 88 09:27:47 MST
In-Reply-To: <880808084125.00000267071@cim-vax.HONEYWELL.COM>
To: icon-group@arizona.edu
Subject: Re: Most thoughts on tables
> Date: Mon, 8 Aug 88 08:41:25 CDT
> From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
>
> While thinking over the problem of getting the list of entry values for a
> table, it occurred to me to wonder if you had considered implementing bags.
A list can be thought of as a bag with ordering. Are there operations
missing from lists that should be included with bags?
> I was also wondering about the unary ? operator. This is the equivalent of
> "drawing (a random element) with replacement." Is there an easy way to do
> drawing without replacement?
Here is a procedure that does drawing without replacement on sets:
procedure draw_from_set(s)
local elem
elem := ?s | fail
delete(s, elem)
return elem
end
Of course it doesn't work if you need multiple occurances of a value. You
could put the values in records to make each occurance "unique":
record bucket(value)
procedure rand(s)
local elem
elem := ?s | fail
delete(s, elem)
return elem.value
end
Though this is prehaps getting awkward.
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {allegra|noao}!arizona!kwalker
From andrey Wed Aug 10 14:01:24 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 14:01:24 MST
Date: Wed, 10 Aug 88 14:01:21 MST
From: "Andrey K. Yeatts" <andrey>
Message-Id: <8808102101.AA16422@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA16422; Wed, 10 Aug 88 14:01:21 MST
To: icon-group
Subject: ordering info
Here's one for the icon-project. I thought you folks also
saw icon-group-requests.
From sendai!rich@umix.cc.umich.edu Thu Jul 28 02:14:53 1988
Date: Thu, 28 Jul 88 04:43:09 edt
From: sendai!rich@umix.cc.umich.edu
Message-Id: <8807280843.AA04436@oxtrap.UUCP>
To: oxtrap!icon-group-request@arizona.edu
Subject: tape ordering info
Reply-To: oxtrap!rich@umix.cc.umich.edu
Status: RO
What was that address and price again for the current Icon tape? And
can you tell me the current list of machines believed to work? I'm
interested in sun3's (and which os version), general berkeley (really
sequent dynix), mips, for starters. (I *will* order a tape. I just
want to know how much and where to send my check.)
From @CUNYVM.CUNY.EDU:NETWORK@FRSAC11.BITNET Wed Aug 10 14:49:17 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 14:49:17 MST
Message-Id: <8808102148.AA19115@megaron.arizona.edu>
Received: from cunyvm.cuny.edu by megaron.arizona.edu (5.59-1.5/6) via SMTP
id AA19115; Wed, 10 Aug 88 14:48:26 MST
Received: from FRSAC11.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5548; Wed, 10 Aug 88 12:13:11 EDT
Date: Wed, 10 Aug 88 18:12:50 GMT
To: icon-group@arizona.edu
From: NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Icon's lack of speed
I may be wrong, but this is what I think.
About Icon's execution speed:
Fact #1:Icon is written in a highly portable fashion.
Fact #2:Icon is an experimental language, subject to quite fast evolution.
From #1 and #2, plus reading the book on Icon implementation, one can
deduce a few other:
Fact #3.1 The Virtual Machine instruction set is of the high level type.
(Type checking, etc are done at run time, and do not appear explicitly
in VM instructions)
Fact #3.2 Itran is very simple, translating Icon source statement into
VM instructions in a very straight forward way. No optimisations.
Fact #3.3 The VM is a pure stack machine, no register.
Fact #3.4 There is no immediate operand to the VM instructions.
Fact #3.5 The internal data representation is not optimal in space
or time, but is portability oriented.
All the above are allowing the success of the facts #1 and #2:
1. The portability. (Icon's implementation is relying on the bare minimum
from a particular type of CPU, word representation, etc)
2. The ease of evolution of the language. (Itran and the VM instruction
set are indeed very simple.)
I have been looking at Lisp interpreters and compilers for quite some years
now, and in this particular domain we know:
1. Very efficient compilers do exist now. (Orbit, sometime faster than
C, on a Sun (The quality of C on a Sun is an other problem...))
2. Type inferencing is important for the above.
3. The evaluator MUST NOT generate memory allocations and garbage collections
for its own use.
(Lisp's Eval used to "cons" a lot for its own use, to manage variable
binding, lexical environment, etc. It is not true of modern Lisps)
(In my benchmark of a Scheme interpreter lately, the execution profile
was showing 50% of the runt time spent in memeory management, just
because this Scheme used A-List to store lexical environment...)
4. Operand and function call's parameter passing is a lot more efficient
if done through "registers" than on a stack.
5. Internal data representations have a great influence on the speed.
What I think about all this applied to Icon:
1. Without lowering the level of the VM instructions set it will be
difficult to improve the execution speed.
(To have type checking at compile time rather than
execution time, when possible)
2. Either Itran must be brought up to date, in term of compilation
and optimization craft, or an optimizing phase must follow it, with
the VM instruction set suitably modified.
3. The need to call runtime routines is the same in Icon and Lisp,
Lisp succeeded in improving dramatically the speed, I see no reason
for Icon to fail there, but as far as I know no real effort have been
put in this direction, human ressources are limited, and are currently
used on other aspect of the Icon project. This is a legitimate
choice made by the Icon devellopers.
I strongly support my opinion that lack of speed is not a fate of the
Icon language itself, but only of this current implementation.
4. an immediate speed increase may be obtained by implementing immediate
operand in most arithmetic oerations. (removal of one type checking,
removal of the memory allocation for the "int n" VM instruction,
removal of some garbage collection burdain, etc.)
This can be done by:
1- Adding new VM instructions for integer arithmetics and comparisons.
(No big deal to add instructions in Ilink and Iconx)
2- Without modifying Itran, make a filter on the Icode that generate
new instructions, when immediate operands are present.
(No big deal either, in Icon or C)
5. Further speed increased will be gained by making a separation
between type checking, type coercion and operations; implying
a "smart" Itran, with flow analysis and type inferencing, among
other... Adding registers to the VM, and using them. (algorithms
to have an optimal use of machine registers are now in common use)
This would be a major undertaking, a LOT of work, looking at what
has been done with Lisp/Scheme, we are talking about years of work...
Sorry for my poor English wording, my mother language is still French.
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
From gudeman Wed Aug 10 18:46:42 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 18:46:42 MST
Date: Wed, 10 Aug 88 18:46:40 MST
From: "David Gudeman" <gudeman>
Message-Id: <8808110146.AA29744@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA29744; Wed, 10 Aug 88 18:46:40 MST
To: icon-group
In-Reply-To: <8808101627.AA04281@megaron.arizona.edu>
Subject: Bags in Icon
Tables lend themselves to a convenient representation for bags. Use
the following translation:
b := new_bag --> b := table(0)
add x to b --> b[x] +:= 1
remove one x from b --> if b[x] > 0 then b[x] -:= 1
# here is a place where it would be nice if
# Icon comparisons produced variables. Then
# you could write (0 < b[x]) -:= 1
remove all x from b --> b[x] := 0
is x a member of b? --> b[x] > 0
how many x in b? --> b[x]
This isn't as good as having real bags, but it works.
From kwalker Thu Aug 11 13:40:41 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 11 Aug 88 13:40:41 MST
Date: Thu, 11 Aug 88 13:40:39 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8808112040.AA10703@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.5/6)
id AA10703; Thu, 11 Aug 88 13:40:39 MST
To: icon-group
Subject: Re: Icon's lack of speed
I find Jean-Pierre Dumas's analysis of Icon's lack of speed interesting
and tend to agree with his conclusions. Some of the current research
here at the Icon Project is attacking several of the points he brings up.
Rather than increase the opportunity for optimization by lowering the
level of a Virtual Maching instruction set implemented by an
interpreter, we are producing executable code (there are currently some
prototype compilers written mostly in Icon that are producing code). This
eliminates the overhead of interpreting operation codes; this overhead
is not large, but could increase with a lower level instruction set where
more operations are needed to accomplish the same thing. We are producing
C code. C is in fact a much lower level instruction set than the current
i-code, and gives us lots of opportunities for optimization. Assembler
code would give us several more opportunities for optimization (for
example in the area of call stack manipulation), but is more work
to deal with and is not very portable. The model for code generation
is based on work that Janalee O'Bagy has done for her Ph.D dissertation.
My main area of research has been type inference in Icon with the
goal of eliminating most of the run-time type checking. There is
a prototype inferencing system, but it is not yet being used in a
compiler.
Developing a "register" based execution model turns out to be a
little trickier than one might expect. Because of failure and
resumption, intermediate values may be reused several times. It
requires some analysis to determine their maximum lifetime (in
the stack model their lifetime is extended by copying portions of
the stack when the values need to be preserved). I have solved this
problem and we do plan to use such a model. However, the "registers"
are temporary variables rather than real machine registers. We
would have to produce assembler code to use machine registers and
we might have to change the representation of values. The work I
have done is only the first step in the area of register allocation.
The point about generating code to use an "immediate operand" is a
good one! I'll have to think about how that fits into the code
generation scheme we are devising.
It looks like the main area we are not addressing is the internal
representation of data structures. We have discussed this some, but
so far not much concrete work has been done on it. A major problem
with producing efficient representations is the generality of
Icon's data structures. The information from type inferencing could
be used to tailor data representations to particular uses. This has
been done for SETL (is it done for Lisp?), but is definitely "future
work" for Icon.
There is one area for optimization of Icon that Jean-Pierre Dumas
missed, though a person familiar with Prolog optimizations might
have guessed it. That has to do with recognizing "deterministic"
expressions, that is ones that never generate values, and eliminating
the overhead associated with maintaining the state of goad-directed
evaluation in those places. Janalee has investigated these optimizations.
Because of Icon's generators and its unique control structures these
turn out to be quite different from Prolog optimizations. Most Icon
programs have lots of these deterministic expressions and Janalee has
been able to significantly reduce the overhead associated with control
flow in Icon.
Note:
The primary motivation for developing a compiler is research. It
is much too early to know whether this research will produce
anything that is distributable. Those of you waiting for such
a compiler shouldn't hold your breath.
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {allegra|noao}!arizona!kwalker
From icon-group-request Mon Aug 22 12:39:23 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 12:39:23 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
id AA00674; Mon, 22 Aug 88 12:38:05 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
id AA24854; Sun, 21 Aug 88 21:26:01 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Aug 88 03:11:41 GMT
From: cs.utexas.edu!ut-emx!mic@husc6.harvard.edu (Mic (... K[a-z]+) Kaczmarczik)
Organization: UT Austin Computation Center, User Services Unix Support Group
Subject: Icon version 7 for an Encore running UMAX 4.2?
Message-Id: <5270@ut-emx.UUCP>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I'm thinking of trying to build Icon version 7 on an Encore Multimax
running UMAX 4.2, a variant of 4.2 BSD. Has anyone out there tried
this?
Thanks in advance,
Mic Kaczmarczik mic@emx.utexas.edu
UT Austin Computation Center MIC@UTAIVC.BITNET
--
Mic Kaczmarczik If you drink, don't drill.
UT Austin Computation Center -- Matt Groening
mic@emx.utexas.edu
MIC@UTAIVC.BITNET
From icon-group-request Mon Aug 22 13:54:05 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 13:54:05 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
id AA04547; Mon, 22 Aug 88 13:53:42 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
id AA08556; Mon, 22 Aug 88 13:24:18 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Aug 88 19:39:46 GMT
From: mccarrol@topaz.rutgers.edu (Mark C. Carroll <mccarrol@topaz.rutgers.edu>)
Organization: Rutgers Univ., New Brunswick, N.J.
Subject: Logical Expressions
Message-Id: <Aug.22.15.39.41.1988.5141@topaz.rutgers.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I have a problem that I think is probably due to a misunderstanding of
something simple in Icon, and I'd appreciate any help anyone could
give me.
What I'm trying to do is locate an instance of a structure in a list.
The structure is a record, with 7 fields. I know 4 of the fields,
and I need to find the structure which matches the 4 fields I know.
I can't figure out how to write a simple compare that will success
if and only if those four fields match. I can't find any way to do
a simple "If this AND this then ...". I don't have a copy of the
Icon book, and the overview and source code that I have don't mention
anything like this.
Also, if anyone can give me information on a good book about icon,
I'd appreciate it. I need enough info to get a bookstore to orderit..
Thanks,
-Mark
--
/ <MC>=Mark Craig Carroll || "Old Soldiers never die \
| **Temporary Hippy for August** \/ |
| mccarrol@topaz.rutgers.edu /\ Young ones do" |
\ ...backbone!rutgers!topaz!mccarrol || -unknown /
From att!ihnp4!ihuxy!nowlin Mon Aug 22 15:14:30 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 15:14:30 MST
Message-Id: <8808222214.AA08523@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.6/8)
id AA08523; Mon, 22 Aug 88 15:14:28 MST
Received: by att.ATT.COM (smail2.5 - att-ih)
id AA07608; 22 Aug 88 16:35:35 CDT (Mon)
From: ihnp4!ihuxy!nowlin
Received: by ihnp4.ATT.COM id AA21462; 22 Aug 88 16:35:16 CDT (Mon)
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Mon 22 Aug 1988 16:35 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: Logical Expressions
Ua-Message-Id: <post.nowlin.Mon 22 Aug 1988 16:14 CDT>
End-Of-Protocol:
Content-Length: 2170
> What I'm trying to do is locate an instance of a structure in a list.
> The structure is a record, with 7 fields. I know 4 of the fields,
> and I need to find the structure which matches the 4 fields I know.
>
> I can't figure out how to write a simple compare that will success
> if and only if those four fields match. I can't find any way to do
> a simple "If this AND this then ...". I don't have a copy of the
> Icon book, and the overview and source code that I have don't mention
> anything like this.
> --
> / <MC>=Mark Craig Carroll || "Old Soldiers never die \
> | **Temporary Hippy for August** \/ |
> | mccarrol@topaz.rutgers.edu /\ Young ones do" |
> \ ...backbone!rutgers!topaz!mccarrol || -unknown /
Given the lack of a real example I took a shot at this anyway. Try this
little program which contains an example list of records and a simple "if"
statement to test the first four fields against constant values. It uses
goal directed evaluation to do so. The key is the initial assignment
statement inside the logical expression.
##########################################################################
record voter(rep,dem,lib,con,name,j2,j3)
procedure main()
l1 := []
put(l1,voter("yes","no","maybe","maybe","Lynn","?","?"))
put(l1,voter("no","no","maybe","maybe","Rose","?","?"))
put(l1,voter("no","no","no","yes","John","?","?"))
put(l1,voter("maybe","maybe","maybe","maybe","Joe","?","?"))
put(l1,voter("no","yes","yes","no","Sue","?","?"))
put(l1,voter("yes","no","no","yes","Hank","?","?"))
if v := !l1 &
v.rep == "maybe" &
v.dem == "maybe" &
v.lib == "maybe" &
v.con == "maybe" then
write("It looks like ",v.name," is undecided.")
else
write("It looks like nobody is undecided.")
end
##########################################################################
Notice that since this is an "if" it will only find the first record with
four initial matching fields. This expression could be written to find
all of the matches with an "every".
Jerry Nowlin
(...!att!ihuxy!nowlin)
From DSCARGO@cim-vax.HONEYWELL.COM Tue Aug 23 09:28:20 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 23 Aug 88 09:28:20 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.6/8) via SMTP
id AA17916; Tue, 23 Aug 88 09:28:08 MST
Received: by cim-vax id <0000082D081@cim-vax.HONEYWELL.COM> ;
Tue, 23 Aug 88 11:26:52 CDT
Date: Tue, 23 Aug 88 11:03:24 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Mouse Interface of MS-DOS using Int86(a)
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880823110324.0000082D081@cim-vax.HONEYWELL.COM>
Has anybody built a Microsoft Mouse interface using the Int86(a) function
covered under IPD32a, Additional Functions for MS-DOS Icon? The C Users
Journal, Sept/Oct 1988, pages 88-90 has a mouse interface using Turbo C.
The tricky parts appear to be getting values of the segment registers
(so that valid inputs can be provided to Int86) and mapping a new graphics
image onto the mouse cursor, which requires putting the address of an
array in DX and the data segment address in ES.
Icon is high level enough to make handling some structures straight
forward, but arranging for bit map images to be in exactly the right
places and pointed to the right way looks tricky (and perhaps not possible).
GetSpace, Peek, and Poke are probably adequate for putting values into
known locations, but it's not clear that the address returned by GetSpace
is compatible with DX.
This is probably bending what Icon and the Additional Functions were intended
for, but as long as it looked possible, I thought it can't hurt to ask.
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From ralph Tue Aug 23 09:54:22 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 23 Aug 88 09:54:22 MST
Date: Tue, 23 Aug 88 09:52:30 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8808231652.AA19007@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.6/8)
id AA19007; Tue, 23 Aug 88 09:52:30 MST
To: DSCARGO@cim-vax.HONEYWELL.COM, icon-group@arizona.edu
Subject: Re: Mouse Interface of MS-DOS using Int86(a)
In-Reply-To: <880823110324.0000082D081@cim-vax.HONEYWELL.COM>
We have some screen/window functions for MS-DOS Icon, but no mouse
interface that I know of. What we have consists of contributions
to the Icon program library and will be included in the next
release of the library.
However, the design of Int86 isn't really satisfactory. It takes a
9-element list as its argument and returns another 9-element list.
Constructing two lists for every call of Int86 causes heavy memory
throughput and it's slow.
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {allegra|noao|ihnp4}!arizona!ralph
From icon-group-request Thu Aug 25 10:37:19 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 25 Aug 88 10:37:19 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
id AA12008; Thu, 25 Aug 88 10:36:57 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA19304; Thu, 25 Aug 88 09:37:15 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 Aug 88 13:01:33 GMT
From: astroatc!tenaglia@speedy.cs.wisc.edu (Chris Tenaglia)
Organization: Astronautics Technology Cntr, Madison, WI
Subject: Re: Logical Expressions
Message-Id: <1163@astroatc.UUCP>
References: <Aug.22.15.39.41.1988.5141@topaz.rutgers.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I am a heavy user of ICON, and I've tried just about everything
once. The ICON PROGRAMMING LANGUAGE does a fairly good job of
describing the language to a programmer type person. I have heard
of other books in the making that may cater more to people in the
humanities.
I use ICON on VAX VMS and MS-DOS. If care is taken, totally
portable programs can be written.
In response to an article concerning the use of records I'd like to
offer a few tips. ICON records are a little tricky. I think of them
as a means of declaring user define data types. They must always be
declared near the beginning of a file. Usually before for the
globals. They are global in scope and external to all procedures.
Here's a sample declaration...
#BEGINNING OF FILE
record article(name,date,title,desc,page)
global this,that,etc,...
procedure main(param)
...
To store a bunch of records for use, I prefer a list. The database
is stored in a file. A non-printing character is used delimit the
individual fields. The fields are loaded into the database using a
technique something like the following...
database := list()
temp := list()
chars := &cset -- '\377'
in := open("zine.dat")
every line := !in do
{
temp := []
line ? while tab(upto(chars)) do put(temp,tab(many(chars)))
put(database,article(temp[1],temp[2],temp[3],temp[4],temp[5]))
}
The list database is filled with elements of type article. Each
field of the record is filled with a string. The article records
can be walked through with a generator. Therefore to illustrate a
multifield lookup on a list of records here's a sample that might
get you started in the right direction.
every tuple := !database do
{
if (tuple.name == field1) &
(tuple.date == field2) &
(find(field3,tuple.desc)) then found(tuple)
...
}
Notice the use of & for a logical and. Likewise | would be used for
logical or. Both ~ and not can be used for negation.
Here tuple gets loaded with article records from database. The
type of tuple I think is "record" or "article". The type of a data
element such as tuple.name is string. To rewrite the database to a
file I might use a routine something like ...
if changes = 0 then stop("Exit. No changes made.")
out := open("zine.dat","w")
a := "\377"
count := 0
while items := pop(database) do
{
write(out,items.name,a,items.date,a,items.title,a,
items.desc,a,items.page)
count +:= 1
}
close(out)
write("\n",count," records stored.")
I hope this may be of use. I'm looking for easy graphics routines
that do TEKTRONIX 4014 or 4105 protocols or REGIS graphics. Anyone
care to post anything? I'm mostly interested in simple primitives
such as line(x1,y1,x2,y2,b), dot(x,y), color(c), circle(x,y,r),
fill(x,y). Thanx loads...
Yours truly,
Chris Tenaglia
Astronautics Corporation of America
4115 N. Teutonia Avenue
Milwaukee, Wi 53209 USA
(414) 447-8200 X-450
From kwalker Thu Aug 25 12:05:52 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 25 Aug 88 12:05:52 MST
Date: Thu, 25 Aug 88 12:05:47 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8808251905.AA20784@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.6/8)
id AA20784; Thu, 25 Aug 88 12:05:47 MST
In-Reply-To: <1163@astroatc.UUCP>
To: icon-group@arizona.edu
Subject: Re: Logical Expressions
> Date: 25 Aug 88 13:01:33 GMT
> From: astroatc!tenaglia@speedy.cs.wisc.edu (Chris Tenaglia)
...
> In response to an article concerning the use of records I'd like to
> offer a few tips. ICON records are a little tricky. I think of them
> as a means of declaring user define data types. They must always be
> declared near the beginning of a file. Usually before for the
> globals.
The important point is that they cannot be declared inside a procedure.
You can think of record, global, and procedure declarations as all being
at the same "level" with the restriction that they cannot be nested. I
know of no reason why they must be declared at the beginning of the file,
but I find it to be a good programming convention and will join with
Chris in recommending it.
...
> Both ~ and not can be used for negation.
Yes, but it should be pointed out that they are used as negation in
very different ways. "not" is an operator (or, perhaps more correctly,
a control structure), as in
if not (s == "end") then ...
while ~ is used as part of on operator, as in
if s ~== "end" then ...
When ~ is used as an operator it means cset compliment, which is
somewhat different from negation. Consider the meaning of
if not upto('b', "aaabaaa") then ...
The then clause will not be executed because the string contains b. Now
consider
if upto(~'b', "aaabaaa") then ...
The then clause will be executed because the string contains a character
other than b.
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {allegra|noao}!arizona!kwalker
From DSCARGO@cim-vax.HONEYWELL.COM Wed Aug 31 06:56:53 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 31 Aug 88 06:56:53 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.6/8) via SMTP
id AA09600; Wed, 31 Aug 88 06:56:37 MST
Received: by cim-vax id <00001218081@cim-vax.HONEYWELL.COM> ;
Wed, 31 Aug 88 08:54:40 CDT
Date: Wed, 31 Aug 88 08:43:25 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: trimming revisited
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880831084325.00001218081@cim-vax.HONEYWELL.COM>
I realize that what I want (discussed below) could be implemented in many
ways, but I'm interested in feedback from others about the need. I'm
finding in many cases that the trim function isn't quite flexible enough
for what I need. On some other systems I've used, there are three trimming
functions: a left trim, a right trim, and a both trim. The right trim removes
trailing whitespace from the right end. (This is the one most similar to
trim.) The left trim removes leading whitespace from the left end. The
both trim removes both leading and trailing whitespace. I've often found
that (because it's easy to write and understand) that I'm using something like
line := trim(reverse(trim(reverse(read())))) in order to read lines with
whitespace removed. I'd much rather use something like line := btrim(read()))
and I expect that it would perform somewhat better.
In some respects, trim is the flipside of right, which pads a string on the
right. There are no trimming functions that correspond to left and center.
Just as a left trim and both trim can be built out of trim, left and center
could be built out of right. There is no logical necessity for adding
left and both trim, but it would make several of my programming tasks
somewhat easier.
Anybody else have similar needs?
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From att!ihlpe!orf Wed Aug 31 08:04:04 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 31 Aug 88 08:04:04 MST
From: att!ihlpe!orf
Message-Id: <8808311504.AA12203@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.6/8)
id AA12203; Wed, 31 Aug 88 08:04:02 MST
Received: by att.ATT.COM (smail2.5 - att-cb)
id AA29545; 31 Aug 88 10:42:56 EDT (Wed)
Message-Version: 2
>To: /addr=arpa!cim-vax.HONEYWELL.COM!DSCARGO,
/addr=att!arizona!icon-group
Date: Wed 31 Aug 1988 09:45 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: ihlpe!orf
To: att!arizona!icon-group
Cc: arpa!cim-vax.HONEYWELL.COM!DSCARGO
Subject: Re: trimming revisited
Ua-Message-Id: <post.orf.Wed 31 Aug 1988 09:15 CDT>
End-Of-Protocol:
Content-Length: 602
>...
>could be built out of right. There is no logical necessity for adding
>left and both trim, but it would make several of my programming tasks
>somewhat easier.
>
>Anybody else have similar needs?
>
>David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
>
I have personally noticed a simliar need, and agree with David that a more
generalized trim() (upward compatible -> add an argument) would be useful.
I often write scanning expressions - simply to trim leading whitespace. A
built-in function would be nice.
O. Rick Fonorow
AT&T Bell Labs
IW 2B-462
(312) 979-7173
...!att!ihlpe!orf
From irv@aramis.rutgers.edu Wed Aug 31 15:49:34 1988
Received: from ARAMIS.RUTGERS.EDU by megaron.arizona.edu (5.59-1.6/10) via SMTP
id AA05244; Wed, 31 Aug 88 15:49:34 MST
Received: by aramis.rutgers.edu (5.59/1.15)
id AA21069; Wed, 31 Aug 88 18:46:44 EDT
Date: Wed, 31 Aug 88 18:46:44 EDT
From: irv@aramis.rutgers.edu (Irving N. Rabinowitz)
Message-Id: <8808312246.AA21069@aramis.rutgers.edu>
To: icon-group@arizona.edu
Subject: Change of addess
An apology for sending this far and wide, but I don't have the correct
address for making address changes.
My address used to be
rabinowitz@rutgers.edu
and is now
rabinowitz@aramis.rutgers.edu
Please continue me on the distribution. Thanks.
--Irv (rabinowitz@aramis.rutgers.edu)
From icon-group-request Mon Sep 5 20:22:44 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/11) via SMTP
id AB23549; Mon, 5 Sep 88 20:22:44 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA17221; Mon, 5 Sep 88 19:48:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Sep 88 01:57:18 GMT
From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Organization: Teknowledge, Inc., Palo Alto CA
Subject: whatever happened to Rebus?
Message-Id: <24781@teknowledge-vaxc.ARPA>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
Is Rebus(*) still under development or were its lessons folded back into Icon
and Rebus itself abandoned?
Mike Khaw
* - R. E. Griswold, "Rebus - A SNOBOL4/Icon Hybrid", _SIGPLAN_Notices_,
v20#2, Feb. 1985, pp 7-16.
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
From ralph Mon Sep 5 20:40:39 1988
Date: Mon, 5 Sep 88 20:40:39 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8809060340.AA23974@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.6/11)
id AA23974; Mon, 5 Sep 88 20:40:39 MST
To: icon-group@arizona.edu, mkhaw@teknowledge-vaxc.arpa
Subject: Re: whatever happened to Rebus?
In-Reply-To: <24781@teknowledge-vaxc.ARPA>
There was not enough interest in Rebus for us to continue to
support it. Every so often we get an inquirey, but we're
devoting most of our resources to supporting Icon now.
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {allegra|noao|uunet}!arizona!ralph
From DSCARGO@cim-vax.HONEYWELL.COM Thu Sep 8 06:38:53 1988
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/12) via SMTP
id AA18485; Thu, 8 Sep 88 06:38:53 MST
Received: by cim-vax id <0000116D071@cim-vax.HONEYWELL.COM> ;
Thu, 8 Sep 88 08:37:32 CDT
Date: Thu, 8 Sep 88 08:26:23 CDT
From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
Subject: Customizing Icon for VMS
To: icon-group@arizona.edu
X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
Message-Id: <880908082623.0000116D071@cim-vax.HONEYWELL.COM>
Where I am at inside of Honeywell we are looking at Icon as a kind of Swiss
Army knife. There are some things we would like it to do that it doesn't now,
and that aren't particularly real language changes that we'd like to make some
other things easier. I'm just trying to get a feel for how many Icon users
have made their own changes and how hard (or easy) it's been.
The change we have uppermost in mind right now is to build a data base query
interface into Icon. (In particular, we are looking at interfacing with
INGRES.) I expect what we would want (and here I'm interested in other
opinions) is a function that accepts a couple of character strings (a query
string and a data base specification string) and then acts as a generator
returning records from the specified data base that match the specified query.
A generator can return 0 or more records in a natural way, matching the way
a relational query can return 0 or more records. Actually, I expect the
returned result would be a list instead of a record because a record must be
predeclared, and a generator would more naturally return a list.
Is the Icon implementation book an adequate guide for making this kind of
change? Is a more general data base interface something that is in the
current direction of Icon research? Is it something other users see as a
current or future need?
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
From ralph Thu Sep 8 07:38:51 1988
Date: Thu, 8 Sep 88 07:38:51 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8809081438.AA20209@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/12)
id AA20209; Thu, 8 Sep 88 07:38:51 MST
To: DSCARGO@cim-vax.HONEYWELL.COM
Subject: Re: Customizing Icon for VMS
Cc: icon-group
In-Reply-To: <880908082623.0000116D071@cim-vax.HONEYWELL.COM>
Quite a few folks have made changes to the Icon language. Some of
these have been quite extensive.
Obviously, we don't hear about everything. But from I've seen, my
impression is that the kinds of things you're thinking about are
feasible, provided you're willing to invest some time in understanding
the implementation.
The implementation book and a supplementary report provide most of
what you need to know. What else is needed is study of the source code
and learning what the parts are, where to find things, and probably
detailed study of the parts you need to change/interface.
There is one general problem with making significant modifications to Icon:
it may be impractical to back them in to new versions of the language.
For this reason, if you decide to undertake the project you describe,
you should at least get the most recent version of the source from us
(not the version in our present distribution). We're working on a
new release of the source, which will probably be identified as Version 7.5.
We don't have a firm release date yet, but I'd expect late this fall or
early next year.
As to your question about whether we're planning to add features to
interface database systems, the answer is no. We do not have any present
plans for major changes to the language. We're always willing to
consider adding things others do, but they need to be of general
interest and applicability and also to fit our idea of what language
features are appropriate for Icon
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {allegra|noao|uunet}!arizona!ralph
From att!ihlpe!orf Thu Sep 8 19:20:59 1988
From: att!ihlpe!orf
Message-Id: <8809090220.AA04462@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/12)
id AA04462; Thu, 8 Sep 88 19:20:59 MST
Received: by att.ATT.COM (smail2.5 - att-ih)
id AA01450; 8 Sep 88 18:42:13 CDT (Thu)
Message-Version: 2
>To: /addr=att!arizona!icon-group,
/addr=arpa!cim-vax.HONEYWELL.COM!DSCARGO
Date: Thu 08 Sep 1988 18:32 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: ihlpe!orf
To: arpa!cim-vax.HONEYWELL.COM!DSCARGO
Cc: att!arizona!icon-group
Subject: Re: Customizing Icon for VMS
Ua-Message-Id: <post.orf.Thu 08 Sep 1988 18:11 CDT>
End-Of-Protocol:
Content-Length: 3023
>The change we have uppermost in mind right now is to build a data base query
>interface into Icon. (In particular, we are looking at interfacing with
>INGRES.) I expect what we would want (and here I'm interested in other
>opinions) is a function that accepts a couple of character strings (a query
>string and a data base specification string) and then acts as a generator
>returning records from the specified data base that match the specified query.
>A generator can return 0 or more records in a natural way, matching the way
>a relational query can return 0 or more records. Actually, I expect the
>returned result would be a list instead of a record because a record must be
>predeclared, and a generator would more naturally return a list.
>
>Is the Icon implementation book an adequate guide for making this kind of
>change? Is a more general data base interface something that is in the
>current direction of Icon research? Is it something other users see as a
>current or future need?
>
>David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
>
Well, if you come up with a "neat" way to add a lot of functionality (the
existing choices seem to be between adding a large number of new built-in
functions versus some smaller number with more "meaningful" arguments) Please
let me (and the icon-project) know!
We (Jerry Nowlin and I) have looked at doing what you seem to want to do
for interfacing Icon to a standard windowing interface. We were looking
at adding scores of new built-in functions (or passing string arguments
to some generic function) and neither way was particularly appealing, i.e.
the "single generic" function turned into a large case/switch stmt. Adding
30+ new functions wasn't any more appealing...
So to get back to your qestion. What you seem to want to do can be handled
through the existing "PI" (personalized interpreter) mechanism. The Implement.
book is an excellent reference. I recommend looking at the existing
implementation's built-in functions, and finding the ones that are the
closet to what you want to do. (Your function sounds analogus to
the built-in "find" function, so I'd start there.) There is a man page
and TR88-7 describing how to build the personalized interpreter after you
have written you functions.
My only other advice, based on some extensive prototyping experience with
Icon, is to build your proposed system first entirely in Icon. That is,
write Icon procedures that do what you propose (use open(..,"p") or system()
functions inside your procedures) and what you learn may surpise you. You
may find your "Icon" system performs adequately for most applications. Or,
you may discover that you only have to write a small number of C "library"
functions that can be called via popen/system to get the performance you
want. In other words, I'd try prototyping the system entirely in Icon
before trying to maintain what amounts to a separate version of the
language.
O. R. Fonorow
IW 2B-462 x7173
ihlpe!orf
From att!ihuxy!nowlin Thu Sep 8 20:09:17 1988
From: att!ihuxy!nowlin
Message-Id: <8809090309.AA07361@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/12)
id AA07361; Thu, 8 Sep 88 20:09:17 MST
Received: by att.ATT.COM (smail2.5 - att-ih)
id AA06145; 8 Sep 88 21:53:41 CDT (Thu)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Thu 08 Sep 1988 21:55 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Re: Customizing Icon for VMS
Ua-Message-Id: <post.nowlin.Thu 08 Sep 1988 21:29 CDT>
End-Of-Protocol:
Content-Length: 1465
> ... things easier. I'm just trying to get a feel for how many Icon users
> have made their own changes and how hard (or easy) it's been.
>
> The change we have uppermost in mind right now is to build a data base query
> interface into Icon. (In particular, we are looking at interfacing with
> INGRES.) ...
>
> David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
I hope I left enough here for people to understand that the original mail
was about modifying Icon itself to do database queries. Something like a
new built-in function was what the posting suggested. Maybe I'm
overlooking some criteria for this database interface that people with more
experience in databases can see, but why not write the database query code
in Icon and just include it in a library of ucode?
I've worked with a couple of other people on a database report generator
for a PC based database program that is used extensively to produce
contracts for athletic referees. I've also written database manipulation
routines in Icon to interface with the Unity database system that runs on
UNIX. Why can't you just do the same kind of thing for your application?
I hate to see people continue to think that Icon is great but that they
have to modify it to do what they really want. There's an awful lot you
can do directly with Icon in its latest incarnation. Database applications
are definitely within it's scope.
Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)
From UNOCC07%zeus@crcvms.unl.edu Thu Sep 8 21:52:18 1988
Message-Id: <8809090452.AA24750@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/12) via SMTP
id AA24750; Thu, 8 Sep 88 21:52:18 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Thu, 8 Sep 88 21:29 MST
Date: Thu, 8 Sep 88 22:58 CDT
From: "Some people would rather die than think; In fact, most do."
<UNOCC07%zeus@crcvms.unl.edu>
Subject: vt100 text-windows for Icon...
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
I have a "package" (suitable for "link"ing) of text-windowing routines
for Icon, using vt100-specific escape codes and the like. (Though I
imagine that they would easily converted to ANSI for MS-DOS...) The
source file is probably a bit too large to just post straight to the
group, especially when only a fraction of the readers might be interested,
so I'm offering to mail it to anyone that wants it.
Included in the package, I'll include a sample program that uses the
routines (the program is a MORE-like text-viewer, inspired by the MS-DOS
LIST shareware utility), to show you an actual use for them all. The
windowing routines are not machine-specific (just terminal-specific), but
one function used in the sample program, readc(), is.
I'm using Icon version 7, on a VAX 8650 running VMS 4.7. readc() is a
function to asynchronously read a single character from the keyboard
buffer (and echo it to the screen). I haven't played with MS-DOS Icon
much at all, but I would guess that getch() does pretty much the same
thing. (correct me if I'm wrong...) Installing it is a bit more complex
but if you're interested, I'd be perfectly willing to send it to you as
well. (And if you're running VMS, I'll even throw in TERMLOCK, which
was recently posted to comp.os.vms... [plug, plug] :-)
Well, there it is. Free for the asking. :-) This could even be related
to the current discussion, I guess, since the routines (except readc())
are written in Icon, not added to the language...
-/ Dave Caplinger /---------------+-----------------------------------------
Microcomputer Specialist | Internet: unocc07%zeus@crcvms.unl.edu
Campus Computing | uucp: uunet!btni!unocss!dent
University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1
Omaha, NE 68182 | (Last Resort: dc3a+@andrew.cmu.edu)
From UNOCC07%zeus@crcvms.unl.edu Fri Sep 9 11:34:07 1988
Message-Id: <8809091834.AA25258@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/12) via SMTP
id AA25258; Fri, 9 Sep 88 11:34:07 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Fri, 9 Sep 88 11:05 MST
Date: Fri, 9 Sep 88 12:57 CDT
From: "Some people would rather die than think; In fact, most do."
<UNOCC07%zeus@crcvms.unl.edu>
Subject: Re: vt100 text windows
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
Good grief! I had no idea I was going to get this many requests!
Let me explain a few things about the routines though; some of you may be
reading more into it than is actually there. Basically, this routines just
draw boxes, while keeping a copy of the text "underneath" the boxes. Since
there is no across-the-board asynchronous single-key read routine for Icon,
the window routines cannot restrict input to the boundries of a window, nor
do they make sure that anything you print to a window does not write past
the boundaries of the window. But, since vt-100's only have an 80x25 array
(or 132x25) of characters, I did not see this as a problem. Actually, using
my basic routines, it would not be particularly difficult to make a package
that would impose those kinds of restructions, but this one isn't it.
A few other things that windows.icn won't do:
- Windows cannot overlap.
- Windows cannot be scrolled seperately from other windows.
(although VIEW does use scrolling...)
Basically, I just don't want people to have high hopes that are suddenly
shattered when the routines actually arrive at their site. I've been pretty
disappointed by some public-domain software myself. That's not to
say that I think the routines are /bad/, just very basic. (What more could
I really do with just vt-100 codes and no assembly language SMG$ routines or
other machine-specific code?)
In any case, I'm still of course entertaining the requests of anyone that
wants the package. :-)
-/ Dave Caplinger /---------------+-----------------------------------------
Microcomputer Specialist | Internet: unocc07%zeus@crcvms.unl.edu
Campus Computing | uucp: uunet!btni!unocss!dent
University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1
Omaha, NE 68182 | (Last Resort: dc3a+@andrew.cmu.edu)
From icon-group-request Thu Sep 15 10:58:36 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/12) via SMTP
id AA06913; Thu, 15 Sep 88 10:58:36 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA15078; Thu, 15 Sep 88 01:00:27 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 Sep 88 04:23:03 GMT
From: att!ihuxz!dutler@ucbvax.Berkeley.EDU (Stan Dutler)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: escaped characters in literal strings
Message-Id: <3340@ihuxz.ATT.COM>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I am writing a scanner for a compiler class. One of the tokens
is a literal string that is defined as the same as the ICON
literal string. This means that escaped characters (i.e.,\",\t...)
must be converted to the appropriate character. Is there a
builtin function that will do this simply or will I need to
resort to a good old case statement? Thanks in advance for
any help.
--
Stan Dutler There ya go man, Keep as cool as ya can
..ihnp4!ihuxz!dutler Face piles of trials with smiles
From icon-group-request Thu Sep 15 22:22:37 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/12) via SMTP
id AA14712; Thu, 15 Sep 88 22:22:37 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA07480; Thu, 15 Sep 88 20:59:40 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 16 Sep 88 00:33:16 GMT
From: vu-vlsi!sword@psuvax1.cs.psu.edu (David Talmage)
Organization: Villanova Univ. EE Dept.
Subject: reading and writing heterogeneous lists
Message-Id: <1888@vu-vlsi.Villanova.EDU>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
While working on other things, I've had the need for a library of
procedures that read, write, and pretty print lists, sets, and tables.
I've found an elegant solution that uses the call-by-string-value
feature of Icon. From a software engineering point of view, it's not
such a good thing, I suppose, because it could be difficult to
determine from a source listing what exactly is happening. I solicit
your opinions on this and, if there is sufficient interest and we all
agree that it is a good thing, will post my library of heterogeneous
I/O procedures to comp.sources.misc.
Briefly, to write a list, I write the number of elements in the list,
followed by an ordered pair: the type of an element followed by the
actual element.
To recreate the list from a file, I read the number of elements, make
a list that big, and read each ordered pair: the type of an element
followed by the element.
My procedures expect the procedures that read and write single
elements of the various types to behave in a similar manner.
To write a list I use a procedure much like this:
procedure write_list( ListFile, List )
local ListElement
local write_ListElement
write( ListFile, *List ) #How big is it?
every ListElement := !List do {
write( ListFile, type( ListElement )
write_ListElement := "write_" || type( ListElement )
#
# This is the important line. It's a call by string value, calling
# a procedure to write one entity of the same type as ListElement.
#
write_ListElement( ListFile, ListElement )
}
return
end # write_list
procedure read_list( ListFile )
local NewList
local NewListSize
local NewListElement
local read_NewListElement
NewList := list( NewListSize := integer( read( ListFile ) ) )
every NewListElement := 1 to NewListSize do {
read_NewListElement := "read_" || read( ListFile )
#
# This is the important line. It's a call by string value, calling
# a procedure to read one entity of some type as directed by one line
# of ListFile.
#
NewList[ NewListElement ] := read_NewListElement( ListFile )
}
return NewList
end # read_list
I've thought of changing (write|read)_<type> to (write|read)_Element,
as below:
procedure write_Element( ElementFile, Element )
write( ElementFile, type( Element ) )
return ( case type( Element ) of
"integer" : write( ElementFile, Element )
"real" : write( ElementFile, Element )
"string" : write( ElementFile, Element )
"cset" : write( ElementFile, Element )
"list" : write_list( ElementFile, Element )
"set" : write_set( ElementFile, Element )
"table" : write_table( ElementFile, Element )
end # case
)
end # write_Element
and requiring each user to write his or her own procedure
write_Element but I find this an ugly solution. Read_Element would be
a similar case.
Your comments?
Regards,
David W. Talmage
Villanova University
talmage@excalibur.UUCP, sword@vu-vlsi.UUCP, talmage@vuvaxcom.BITNET
From att!ihuxy!nowlin Fri Sep 16 06:19:55 1988
From: att!ihuxy!nowlin
Message-Id: <8809161319.AA03857@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/12)
id AA03857; Fri, 16 Sep 88 06:19:55 MST
Received: by att.ATT.COM (smail2.5 - att-ih)
id AA25645; 16 Sep 88 07:18:03 CDT (Fri)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Fri 16 Sep 1988 07:19 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Re: reading and writing heterogeneous lists
Ua-Message-Id: <post.nowlin.Fri 16 Sep 1988 06:54 CDT>
End-Of-Protocol:
Content-Length: 1936
> While working on other things, I've had the need for a library of
> procedures that read, write, and pretty print lists, sets, and tables.
>
> ...
>
> David W. Talmage
> Villanova University
> talmage@excalibur.UUCP, sword@vu-vlsi.UUCP, talmage@vuvaxcom.BITNET
I hope the original mail was received since I didn't include much of it
here. I'd have to have a better understanding of why you need this library
before I could see why you'd bother. This seems like a lot of work for
nothing. With the possible exception of strings that contain newlines
(which you'd have to deal with anyway) why not just write one element per
line and then read the elements back in inside put() until you hit EOF.
The writing code should be obvious. I'd use something like this, modeled
after the procedure in the original message, to read:
procedure read_list( ListFile )
local NewList
NewList := []
every put(NewList,!ListFile)
return NewList
end # read_list
With automatic type conversion, the routines that use the data in NewList
as specific types should be able to handle converting it from a string.
Icon makes handling "heterogeneous" data very simple. Maybe you should
state the justification for going to all this work.
> ... From a software engineering point of view, it's not
> such a good thing, I suppose, because it could be difficult to
> determine from a source listing what exactly is happening...
The ability to comment your code voids this statement. You did a good job
of commenting the expressions that were a little obscure and that's what
you should do. There's no excuse for using misdirection and not explaining
it, but I don't see any reason to avoid the new features of a language just
because they're tricky to understand. I like your procedures. I just
don't see a need for them.
I hope this doesn't sound too critical. I'm cranky this morning.
Jerry Nowlin
(...!att!ihuxy!nowlin)
From icon-group-request Fri Sep 30 05:26:22 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA05870; Fri, 30 Sep 88 05:26:22 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00442; Fri, 30 Sep 88 03:22:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 30 Sep 88 07:55:04 GMT
From: cjeffery@arizona.edu (Clinton Jeffery)
Organization: U of Arizona CS Dept, Tucson
Subject: Sets of sets membership test!
Message-Id: <7244@megaron.arizona.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
OK, here's a fun one: the problem is to test whether a set S1
(elements are all integers) is "equivalent" to any member of
set S2 (a set of sets of integers). Linear search is too slow;
and I would rather not recode S2 as some sort of binary tree.
Any good suggestions? Am I missing a common Icon idiom?
Any help appreciated!
Thanks,
--
| Clint Jeffery, University of Arizona Department of Computer Science
| cjeffery@arizona.edu -or- {noao allegra cmcl2}!arizona!cjeffery
--
From att!ihlpe!orf Tue Oct 4 05:37:03 1988
From: att!ihlpe!orf
Message-Id: <8810041237.AA25375@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA25375; Tue, 4 Oct 88 05:37:03 MST
Received: by att.ATT.COM (smail2.6 - att-cb)
id AA26764; 1 Oct 88 13:13:03 EDT (Sat)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Sat 01 Oct 1988 12:15 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: ihlpe!orf
To: att!arizona!icon-group
Subject: Re: challenge
Ua-Message-Id: <post.orf.Sat 01 Oct 1988 12:01 CDT>
End-Of-Protocol:
Content-Length: 1130
> OK, here's a fun one. The problem is to test whether a set S1 (elements
> are all integers) is "equivalent" to any member of set S2 (a set of sets of
> integers). Linear search is too slow and I would rather not recode S2 as
> some sort of binary tree. Any good suggestions? Am I missing a common
> Icon idiom?
I haven't tested this extensively, but I think the following procedure is one
answer to the icon-group mail. It assumes that s1 is a set, and s2 is a set
of sets. (I'm not sure I understand the comment about a "linear search
being too slow"? Goal-directed evaluation, left to itself, can be
combinatorial (I wish I could spell), can't it?? Anyway, the idea is
if two sets are the same size, and their intersection is the same size, then
they are identical sets...
# The procedure suceeds if s1 has the same members as one of s2's sets.
# Succeed if s1 is a member of s2 member sets
procedure common(s1,s2)
dynamic mset # member set of s2
if *(mset := !s2) = *s1 &
*(mset ** s1) = *s1 then return
fail
end
p.s. you can eliminate the mset variable -- but I didn't like all the
parenthesis...
From icon-group-request Mon Oct 10 01:30:02 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA22036; Mon, 10 Oct 88 01:30:02 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA15623; Mon, 10 Oct 88 00:55:25 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Oct 88 17:47:38 GMT
From: grand.UUCP!day@uunet.uu.net (Dave Yost)
Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA
Subject: Announcing Eiffel language mailing list
Message-Id: <434@grand.UUCP>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
Announcing a mailing list for discussion
of the Eiffel object-oriented language
and environment.
To subscribe, please email the following
form including any comments you wish:
==============================
To: eiffel-notes-request@grand.COM
Subject: new subscription
[ x ] I will indicate my choices like this with an x.
[ ] Add our address to the mailing list.
Domain address: eiffel-notes@hostname.domainlist
Uucp address: uunet!...!hostname!eiffel-notes
Initial number of users who will receive eiffel-notes
at our site: ___
[ ] We have an Eiffel compiler.
[ ] I have read Object-oriented Software Construction by Bertrand Meyers.
[ ] I would vote for a comp.lang.eiffel newsgroup.
[ ] I would vote for a comp.lang.oop newsgroup (covering all oo languages).
From R.J.Hare@EDINBURGH.AC.UK Wed Oct 12 13:03:52 1988
Message-Id: <8810122003.AA08119@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA08119; Wed, 12 Oct 88 13:03:52 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 12 Oct 88 13:04 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0983; Wed,
12 Oct 88 09:10:15 BST
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 0982; Wed, 12
Oct 88 09:10:15 BS
Date: 12 Oct 88 09:10:58 bst
From: R.J.Hare@EDINBURGH.AC.UK
Subject: Book on ICON (32)
To: icon-group@arizona.edu
Reply-To: Willard McCarty <MCCARTY@VM.EPAS.UTORONTO.CA>
Via: 000015001003.FTP.MAIL; 12 OCT 88 9:10:13 BST
Comments: This
Thanks.
Roger Hare.
Message-ID: <12 Oct 88 09:10:58 bst 340611@EMAS-A>
--- Forwarded message:
Subject: Book on ICON (32)
From: Willard McCarty <MCCARTY@CA.UTORONTO.EPAS.VM>
Date: Sun, 9 Oct 88 14:47:09 EDT
Sender: HUMANIST Discussion <HUMANIST@EARN.UTORONTO>
Reply to: Willard McCarty <MCCARTY@CA.UTORONTO.EPAS.VM>
To: Roger Hare <r.j.hare@UK.AC.EDINBURGH>
Via: UK.AC.EARN-RELAY ; (to uk.ac.edinburgh.emas-a) 10 Oct 88 08:44:58 bs
Msg ID: <sent 9 Oct 88 14:47:09 EDT via EARN>
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7087; Mon, 10
Oct 88 08:43:51 BS
Received: by UKACRL (Mailer X1.25) id 7023; Mon, 10 Oct 88 08:43:49 BS
Humanist Mailing List, Vol. 2, No. 219. Sunday, 9 Oct 1988.
Date: Sat, 08 Oct 88 09:57:25 CDT
From: "Eric Johnson Liberal Arts DSC Madison, SD 57042" <ERIC@SDNET>
Subject: Icon language and new book
Prentice Hall is about to publish a new book on the Icon Programming
language: ICON PROGRAMMING FOR HUMANISTS by Alan Corre. It may be exactly
the book that Lou and Sebastian seek: programming in Icon for humanists
who do not have a background in computer science.
Icon has received a good deal of attention recently. Paul Abrahams,
ACM President, has said
I think of Icon as being like a fine small French restaurant that
not many people know about, where the clientele is loyal and
appreciative, the chef is devoted to producing creative cuisine
of the highest quality, and the assistant chefs are themselves
talented and devoted to their craft. Icon is a language where
everything fits together, and its design is enhanced by careful
attention to small details. . . . (Proceedings of the Third
International Conference on Symbolic and Logical Computing, p. 17)
-- Eric Johnson (ERIC@SDNET)
--- End of forwarded message
From R.J.Hare@EDINBURGH.AC.UK Wed Oct 12 23:26:58 1988
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA07351; Wed, 12 Oct 88 23:26:58 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 12 Oct 88 23:28 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0285; Thu,
13 Oct 88 06:59:23 BST
Date: 13 Oct 88 07:00:08 bst
From: R.J.Hare@EDINBURGH.AC.UK
Subject: Icon Book
To: icon-group@arizona.edu
Via: 000015001003.FTP.MAIL; 13 OCT 88 6:59:21 BST
Message-Id: <13 Oct 88 07:00:08 bst 340690@EMAS-A>
The comment I prepended to the HUMANIST message relating to the book about
Icon appears to have been garbled, so for the benefit of anyone who is
wondering what it is all about, this message appeared on the HUMANIST
bulletin board a few days ago and may be of interest to readers of the
Icon bulletin board.
Roger Hare.
From icon-group-request Fri Oct 14 07:08:07 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA05035; Fri, 14 Oct 88 07:08:07 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA15070; Fri, 14 Oct 88 06:34:11 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Oct 88 22:31:24 GMT
From: grand!day@uunet.uu.net (Dave Yost)
Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA
Subject: Announcing Eiffel language mailing list
Message-Id: <440@grand.UUCP>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
Announcing a mailing list for discussion
of the Eiffel object-oriented language
and environment.
In case you haven't heard of Eiffel, it is a strongly-typed,
Object-oriented general purpose programming language with
emphasis on compile-time checking. It has generic types
(often caled parameterized types), multiple inheritance,
incrementally-garbage-collected automatic storage, and
exception handling. Eiffel is a recent design, not an
extension of any previous language. It is described in
this book:
Object-oriented Software Construction
by Bertrand Meyer
Prentice Hall, 1988
International Series in Computer Science
ISBN 0-13-629049-3 hardcover
ISBN 0-13-629031-0 paperback (apparently
won't be available in the US)
To subscribe, please email the following
form including any comments you wish.
Special Instructions:
If you can, please set up an eiffel-notes alias
on your system so we can add that to our list
instead of adding individual user names.
==============================
To: eiffel-notes-request@grand.COM
Subject: new subscription
[ x ] I will indicate my choices like this with an x.
[ ] Add our address to the mailing list.
[edit one or both of the following to reflect your address]
Domain address: eiffel-notes@hostname.domainlist
Uucp address: uunet!...!hostname!eiffel-notes
Initial number of users who will receive eiffel-notes
at our site: ___
[ ] We have an Eiffel compiler.
[ ] I have read Object-oriented Software Construction by Bertrand Meyer.
[ ] I would vote for a comp.lang.eiffel newsgroup.
[ ] I would vote for a comp.lang.oop newsgroup (covering all oo languages).
From icon-group-request Sat Oct 15 10:00:54 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA01816; Sat, 15 Oct 88 10:00:54 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA21405; Tue, 11 Oct 88 21:30:11 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Oct 88 15:55:43 GMT
From: mcvax!hp4nl!mhres!jv@uunet.uu.net (Johan Vromans)
Organization: Multihouse NV, the Netherlands
Subject: Icon for HP9000/320
Message-Id: <2481@mhres.mh.nl>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
I am looking for the configuration files for Icon
version 6 on HP9000/320 running HP-UX. I have it running already,
but I am not sure my home-brew configuration files are optimal.
Also, I'm looking for the HP9000/320 version of rswitch.s and
rover.s.
Thanks in advance.
Johan Vromans @ Multihouse
--
Johan
From LIBCAT@IUBACS.BITNET Wed Oct 19 00:18:33 1988
Message-Id: <8810190718.AA16570@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA16570; Wed, 19 Oct 88 00:18:33 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 19 Oct 88 00:16 MST
Date: Wed, 19 Oct 88 00:36 EST
From: LIBCAT@IUBACS.BITNET
Subject: today, tomorrow, and yesterday
To: icon-group@arizona.edu
X-Original-To: icon-group@arizona.edu, LIBCAT
This is very minor problem but any help would be greatly
appreciated. We are using ICON as the user interface for a small
in-house BBS. The function (&dateline) is being used for the log,
etc. The problem is that it consistently reports today as yesterday.
When DOS reports that: Current date is Tue 10-18-1988, the
program below:
procedure main ()
write (&date)
write (&dateline)
write (&version)
write (&host)
end
yields:
1988/10/17
Monday, October 17, 1988 1:24 am
Icon Version 7.0. January 16, 1988.
MS-DOS (ER) ex Lattice C Version 3.2
At first I thought this might just be a quirk in the IBM Model
30 we are using for the BBS, but my Taiwan clone at home reports the
same thing. I set the clock ahead so that the BBS has the correct
date, but now the rest of the software thinks it's tomorrow.
----------------------------------------------------------------------
Jon LaCure Arpanet : libcat@gold.iubacs.indiana.edu
Indiana University Library Bitnet : libcat@iubacs
Bloomington, IN 47401 Voice : (812) 335-7511
----------------------------------------------------------------------
From ralph Wed Oct 19 04:43:45 1988
Date: Wed, 19 Oct 88 04:43:45 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8810191143.AA25099@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA25099; Wed, 19 Oct 88 04:43:45 MST
To: LIBCAT@IUBACS.BITNET
Subject: Re: today, tomorrow, and yesterday
Cc: icon-group
In-Reply-To: <8810190718.AA16570@megaron.arizona.edu>
The date problem is in the run-time library for MS-DOS Lattice C, which was
used to compile the version of Icon you're running. (Leap year caused the
trouble.)
If you can use the FR (rather than ER) version of Icon compiled under
Microsoft C that comes on the same Version 7.0 distribution, your problem
will go away.
Alternatively, you can get the recently released Version 7.5 of Icon
for MS-DOS from us, which uses a later version of the Lattice C compiler
with the problem fixed. Ordering information is the same as for the
7.0 version. (Send e-mail to icon-project@arizona.edu if you need
more information.)
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao|uunet}!arizona!ralph
From icon-group-request Wed Oct 26 06:40:08 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA28137; Wed, 26 Oct 88 06:40:08 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA20617; Wed, 26 Oct 88 00:10:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 Oct 88 05:52:34 GMT
From: chiba!khb@sun.com (Keith Bierman - Sun Tactical Engineering)
Subject: ----------------------------- call for votes --------------
Message-Id: <74718@sun.uucp>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
----------------------------------------------------------------------------
****************************************************************************
CALL FOR VOTES
----------------------------------------------------------------------------
****************************************************************************
Comp.lang.sigplan --- a moderated newsgroup sponsored by the ACM.
SIGPLAN is the ACM's special interest group on computer languages. The
forum will focus on issues which are of "general" interest.
This is merely a pointer. The "real" call for votes is located in News.groups.
Those who wish to vote yes can skip reading news.groups and simply
send mail to sigplan@iuvax.cs.indiana.edu. The SUBJECT should be YES.
Those not in favor should read the real call for votes before casting
a vote.
Thanks for your support.
Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus
From dscargo%ccsvax.decnet@cim-vax.honeywell.com Thu Oct 27 07:02:27 1988
Message-Id: <8810271402.AA16740@megaron.arizona.edu>
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA16740; Thu, 27 Oct 88 07:02:27 MST
Date: 27 Oct 88 08:48:00 CDT
From: "CCSVAX::DSCARGO" <dscargo%ccsvax.decnet@cim-vax.honeywell.com>
Subject: Icon 7.5
To: "icon-group" <icon-group@arizona.edu>
Mention has been made of Icon 7.5, but not of what differentiates it from
Icon version 7. Could the developers elaborate on that difference,
please?
DSCARGO@CIM-VAX.HONEYWELL.COM
From James.Price.Salsman@cat.cmu.edu Sat Oct 29 12:35:23 1988
Received: from CAT.CMU.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA25689; Sat, 29 Oct 88 12:35:23 MST
Received: from CAT.CMU.EDU by CAT.CMU.EDU; 29 Oct 88 15:33:21 EDT
To: icon-group@arizona.edu
Subject: I cant generate your docs...
Date: Sat, 29 Oct 88 15:33:15 EDT
Message-Id: <2371.594156795@CAT.CMU.EDU>
From: James Salsman <James.Price.Salsman@CAT.CMU.EDU>
Dear Project,
I am having some trouble generating some of your tech reports...
TR 83-3f: There is a graph at the bottom of page 9 that my version
of psroff won't print.
TR 86-13: uses the "bmac" package which we don't have.
TR 88-8: also uses "bmac."
Could you either mail me the (Apple LaserWriter) PostScript for these
reports, or possibly leave the PostScript in an ftp directory on
ARIZONA.EDU ? If you mail the p.s., please check to see that there
are no high-bit-set charectors, as our mail reciever will strip
them.
Thanks for your help.
:James
From ralph Sat Oct 29 13:11:12 1988
Date: Sat, 29 Oct 88 13:11:12 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8810292011.AA27351@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA27351; Sat, 29 Oct 88 13:11:12 MST
To: James.Price.Salsman@CAT.CMU.EDU, icon-group@arizona.edu
Subject: Re: I cant generate your docs...
In-Reply-To: <2371.594156795@CAT.CMU.EDU>
I'll see about generating PostScript and levaing it in our FTP
area.
We're adding other things there as well, and now's a good time.
i'll let you know when it's done.
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao|uunet}!arizona!ralph
From sboisen@REGULUS.BBN.COM Tue Nov 1 13:56:18 1988
Message-Id: <8811012056.AA23649@megaron.arizona.edu>
Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA23649; Tue, 1 Nov 88 13:56:18 MST
To: icon-group@arizona.edu
Subject: anybody have a regexp matcher for Icon?
From: Sean Boisen <sboisen@REGULUS.BBN.COM>
Sender: sboisen@REGULUS.BBN.COM
Reply-To: sboisen@bbn.com
Date: Tue, 1 Nov 88 15:48:37 EST
All:
I often find myself looking for the following sort of
tool: let's say i have textual data in multi-line blocks, and if a
certain string occurs somewhere in that block, i want to output the
block. This arises frequently enough that i _really_ wish i had some
way of looking for a regular expression in the block: sort of a block-
(rather than line-)oriented grep, so that i don't have to hack up a
new little program each time i want to look for a new string. Has
anybody else out there ever wanted such a thing (and, even better,
written it?). I guess what i'd really like is some procedure which,
given a string and a regular expression, can tell me if the regexp is
matched anywhere in the string (regexp_find(s1,s2) ?). This looks like
enough of an undertaking that i'm not going to try it until i've
shopped around a little....
........................................
Sean Boisen -- sboisen@bbn.com
BBN Systems and Technologies Corporation, Cambridge MA
Disclaimer: these opinions void where prohibited by lawyers.
From gmt Wed Nov 2 09:31:29 1988
Date: Wed, 2 Nov 88 09:31:29 MST
From: "Gregg Townsend" <gmt>
Message-Id: <8811021631.AA17309@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA17309; Wed, 2 Nov 88 09:31:29 MST
In-Reply-To: <8811012056.AA23649@megaron.arizona.edu>
To: sboisen@bbn.com
Subject: Re: anybody have a regexp matcher for Icon?
Cc: icon-group
...i _really_ wish i had some
way of looking for a regular expression in the block: sort of a block-
(rather than line-)oriented grep...
It's not Icon, but the latest version of the Unix utility "awk" has some
facilities for handling multiline records. These are described in "The AWK
Programming Language" (by Aho, Kernighan, & Weinberger, Addison-Wesley, 1988).
New Awk is available for some number of bucks from the AT&T Toolchest; for
more info call (201)522-6900 with a 1200 baud modem and login as "guest" with
no password.
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@Arizona.EDU 110 57 16 W / 32 13 45 N / +758m
From alk@ux.acss.umn.edu Wed Nov 2 12:41:02 1988
Message-Id: <8811021941.AA29504@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA29504; Wed, 2 Nov 88 12:41:02 MST
Return-Path: alk@ux.acss.umn.edu
Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Wed, 2 Nov 88 12:22 MST
Received: from ux.acss.umn.edu by UMNACVX.BITNET; Wed, 2 Nov 88 13:06 CST
Date: Wed, 2 Nov 88 13:05:11 CST
From: alk@ux.acss.umn.edu
Subject: Re: anybody have a regexp matcher for Icon?
Sender: alk@ux.acss.umn.edu
To: gmt@arizona.edu, sboisen@bbn.com
Cc: icon-group@arizona.edu
If you're goning to resort to awk, why not get GNU awk (FREE and fast) from the
GNU pro
the GNU project. It's probably availiable for anonymous ftp from p
prep.ai.mit.edu.
if not, it's also on the most recent (i think) DECUS tapes, or could be
ordered from the GNU project on tape for a copying fee.
Or I could put it up here on request, I s'poze.
From att!ihuxy!nowlin Thu Nov 3 04:48:57 1988
From: att!ihuxy!nowlin
Message-Id: <8811031148.AA04485@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA04485; Thu, 3 Nov 88 04:48:57 MST
Received: by att.ATT.COM (smail2.6 - att-ih)
id AA07608; 2 Nov 88 16:51:39 CST (Wed)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Wed 02 Nov 1988 16:53 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Re: an Icon regexp matcher
Ua-Message-Id: <post.nowlin.Wed 02 Nov 1988 16:41 CST>
End-Of-Protocol:
Content-Length: 889
> From: Sean Boisen <sboisen@REGULUS.BBN.COM>
> Date: Tue, 1 Nov 88 15:48:37 EST
>
> I often find myself looking for the following sort of
> tool: ...
> ... I guess what i'd really like is some procedure which,
> given a string and a regular expression, can tell me if the regexp is
> matched anywhere in the string (regexp_find(s1,s2) ?). ...
I have a version of grep written in Icon. I haven't bothered to look it
over much in the last two years since it was written but it still works
just like the UNIX grep for the set of tests I ran it through. I'm sure
there are bugs in it since the test suite is fairly simple in scope but
they're probably obscure. This program isn't in the format of the
procedure mentioned above but could be modified without to much trouble.
If anyone wants it email me. If there are enough requests I'll post it.
Jerry Nowlin
(...!att!ihuxy!nowlin)
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Thu Nov 3 19:07:46 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA18800; Thu, 3 Nov 88 19:07:46 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA01660; Wed, 2 Nov 88 17:28:05 CST
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA01195; Wed, 2 Nov 88 17:18:21 CST
Date: Wed, 2 Nov 88 17:18:21 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8811022318.AA01195@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: icon-grep
I think the fellow who posted might have wanted a real Icon-grep.
I've implemented an icon-grep using control backtracking, and
utilizing coexpressions to create matching procedures at run-
time. It's slow, and I dare not post it for that reason. If
someone has implemented a more elegant version of an icon-grep,
I wonder if he or she might post it.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From alk@ux.acss.umn.edu Fri Nov 4 19:53:59 1988
Message-Id: <8811050253.AA08563@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA08563; Fri, 4 Nov 88 19:53:59 MST
Return-Path: alk@ux.acss.umn.edu
Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Wed, 2 Nov 88 15:56 MST
Received: from ux.acss.umn.edu by UMNACVX.BITNET; Wed, 2 Nov 88 16:49 CST
Date: Wed, 2 Nov 88 16:52:26 CST
From: alk@ux.acss.umn.edu
Subject: Re: anybody have a regexp matcher for Icon?
Sender: alk@ux.acss.umn.edu
To: alk@ux.acss.umn.edu, gmt@arizona.edu, sboisen@bbn.com
Cc: icon-group@arizona.edu
or better yet, get gawk from simtel20.arpa: pd2:<UNIX-C.GNU>GAWK.TAR-Z
thats the ticket
From ralph Sun Nov 6 07:42:00 1988
Date: Sun, 6 Nov 88 07:42:00 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8811061442.AA14202@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA14202; Sun, 6 Nov 88 07:42:00 MST
To: icon-group
Subject: Sequent Symmetry
Does anyone have Version 7 of Icon running on a Sequent Symmetry?
If so, we'd like to get a copy of the configuration files for a
potential user.
Thanks.
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao|uunet}!arizona!ralph
From icon-group-request Sun Nov 6 11:05:07 1988
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA18978; Sun, 6 Nov 88 11:05:07 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03676; Sun, 6 Nov 88 07:27:56 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for icon-group@arizona.edu (icon-group@arizona.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 5 Nov 88 23:26:50 GMT
From: grand!day@uunet.uu.net (Dave Yost)
Organization: Grand Software, Inc., Los Angels, CA 213-650-1089
Subject: Re: anybody have a regexp matcher for Icon?
Message-Id: <445@grand.UUCP>
References: <8811012056.AA23649@megaron.arizona.edu>
Sender: icon-group-request@arizona.edu
To: icon-group@arizona.edu
In article <8811012056.AA23649@megaron.arizona.edu> sboisen@bbn.com writes:
>All:
> I often find myself looking for the following sort of tool:
>...
>given a string and a regular expression, can tell me if the regexp is
>matched anywhere in the string (regexp_find(s1,s2) ?).
I too would like to see a built-in (and therefore reasonably fast)
function such as you suggest.
There are 2 or 3 freely-avaliable C regex matching routines
available. I wish someone would glue one of them into Icon.
Perhaps you could get someone who knows the ropes to build you
a stub/prototype inside Icon, and then you could go about making
it really work, with the Implementation of Icon book at your side.
--dave yost
From att!ihuxy!nowlin Sun Nov 6 14:55:41 1988
From: att!ihuxy!nowlin
Message-Id: <8811062155.AA25172@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA25172; Sun, 6 Nov 88 14:55:41 MST
Received: by att.ATT.COM (smail2.6 - att-ih)
id AA28287; 6 Nov 88 15:50:20 CST (Sun)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Sun 06 Nov 1988 15:53 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Icon Grep (igrep)
Ua-Message-Id: <post.nowlin.Sun 06 Nov 1988 15:50 CST>
End-Of-Protocol:
Content-Length: 8638
I received quite a few requests for the Icon grep I had and since I
haven't been able to return mail to several of them I'll just post the
program here. If you test it and find any problems try to let me know
so I can fix them. Thanks.
Jerry Nowlin
(...!att!ihuxy!nowlin)
# This program simulates the UNIX grep command. It recognizes the following
# special (magic) characters:
#
# ^ - matches if the following pattern is at the beginning of a line
# $ - matches if the preceding pattern is at the end of a line
# . - matches any single character
# + - matches from 1 to any number of occurrences of the previous
# character
# * - matches from 0 to any number of occurrences of the previous
# character
# \ - escapes the special meaning of any special characters
# recognized by this program
#
# A pair of square brackets containing other characters means that any of the
# enclosed characters should be matched. A range of characters like '[a-z]'
# will match any of the ASCII characters between 'a' and 'z'. If the initial
# character inside the square brackets is a '^' then the sequence matches
# any characters except the ones enclosed in the square brackets.
#
# The pattern given is broken up into parts that can be matched independent
# of each other. Then the initial list of partial patterns is optimized.
# each partial pattern has a procedure associated with it that will be used
# in the matching phase of the program to match the pattern.
#
# While parsing the pattern there is the concept of a next string matching
# procedure and a next character matching procedure. These change from one
# partial pattern to the next depending on the content of the previous
# and the current partial pattern.
# pattern records contain a procedure and a pattern
record patrec(proc,arg)
procedure main(args)
# the usage message
usage := "Usage: igrep pattern [ file ... ]"
# the special and non-special characters
magic := '^$.+*[\\'
mundane := ~magic
# a string of all ASCII characters
astr := string(&ascii)
# the first program argument must be the pattern
pattern := get(args) | stop("I at least need a pattern\n",usage)
# initialize the initial pattern list
initpat := []
# initialize the next string procedure and the next cset procedure
nexts := paststring
nextc := pastcset
# parse each character in the pattern one at a time
# (slow but easier for '+' and '*')
pattern ? while ch := move(1) do case ch of {
# the beginning of line character
"^": {
# if this is the first character of the pattern
# it's special
if pos(2) then {
nexts := match
nextc := any
# if plus or star are the second characters
# and carat is the first then just match them
if ch := move(1) == ("+" | "*") then
put(initpat,patrec(nexts,ch))
# if carat isn't the first character just match it
} else {
put(initpat,patrec(nexts,"^"))
}
}
# the end of line character
"$": {
# if this is the last character of the pattern
# it's special
if pos(0) then {
put(initpat,patrec(pos,0))
# if dollar isn't the last character just match it
} else {
put(initpat,patrec(nexts,"$"))
}
}
# the match any character character
".": {
put(initpat,patrec(nextc,&ascii))
nexts := match
nextc := any
}
# the 1 to any number of previous characters character
"+": {
# if this is the first character of the pattern
# it's not special so just match it
if pos(2) then {
put(initpat,patrec(nexts,"+"))
# otherwise it's special
} else {
initpat[-1].proc := plus
nexts := match
nextc := any
}
}
# the 0 to any number of previous characters character
"*": {
# if this is the first character of the pattern
# it's not special so just match it
if pos(2) then {
put(initpat,patrec(nexts,"*"))
# otherwise it's special
} else {
initpat[-1].proc := star
nexts := match
nextc := any
}
}
# the escape other characters character
"\\": {
# if the next character is a special character
# match it and skip the backslash
if any(magic,&subject[&pos]) then {
put(initpat,patrec(nexts,move(1)))
# if the next character isn't special match backslash
} else {
put(initpat,patrec(nexts,"\\"))
}
}
# the match enclosed characters character
"[": {
inside := ''
lastc := "["
ch := move(1)
# if supposed to match everything but the inside cset
if ch == "^" then {
notin := 1
ch := move(1)
# if supposed to match the inside cset
} else notin := 0
# parse the inside cset characters
repeat {
case ch of {
# we're done
"]": break;
# we're in a range
"-": {
# if the dash is at the end
# or beginning of the inside
# cset just match a dash
if (lastc == "[") |
(&subject[&pos] == "]")
then {
lastc := "-"
inside ++:= cset(lastc)
# otherwise match the range
# of ascii characters between
# the last and next characters
# (indent violated here)
} else
inside ++:= cset(astr[upto(lastc,astr)+1:upto(lastc := move(1),astr)+1])
}
# just take the next character
"\\": {
lastc := move(1)
inside ++:= cset(lastc)
}
default: {
lastc := ch
inside ++:= cset(lastc)
}
}
# break if we ran out of characters
if not (ch := move(1)) then break;
}
# check for mismatched brackets
if pos(0) & ch ~== "]" then
stop("Mismatched brackets '",pattern,"'")
# if the first character was a '^' complement
# the inside cset
if notin = 1 then inside := ~inside ** &ascii
put(initpat,patrec(nextc,inside))
}
# mundane characters are just added to the pattern
default: {
put(initpat,patrec(nexts,ch))
nexts := match
nextc := any
}
} # bottom of parse the pattern
# initialize the flag for being in a literal string
instring := 0
# initialize the final pattern list
finalpat := []
# go through the initial patterns and optimize them by making
# consecutive literal strings into single literal strings
every pat := !initpat do {
# if this pattern is a literal string
if type(pat.arg) == "string" &
pat.proc === (match | paststring) then {
# if the last pattern was a literal string add this
# pattern to it
if instring = 1 then {
finalpat[-1].arg ||:= pat.arg
# if the last wasn't a literal string start a literal
# string with this pattern
} else {
put(finalpat,pat)
instring := 1
}
# if this pattern is a special pattern add it as is
} else {
put(finalpat,pat)
instring := 0
}
}
# if trace is on print the final pattern records for debugging
if &trace ~= 0 then
every m := !finalpat do write(image(m.proc),": ",image(m.arg))
# trick the program into using standard input if no files were passed
if *args = 0 then args := [&null]
# the rest of the command arguments are files to search for the pattern
every file := !args do {
if \file then in := open(file) | stop("I can't open '",file,"'")
else in := &input
if *args = 1 then file := "" else file ||:= ":"
while line := !in do {
# scan the line for the pattern
line ? {
# if the pattern is found print the line
if found := rematch(finalpat,1) then
write(file,line)
}
}
close(in)
}
end
# pats is the list of procedures and partial patterns to match and pind is
# the index in the list to start matching on
procedure rematch(pats,pind)
# if pind is beyond the end of pats suspend with an empty string
if pind > *pats then suspend ""
# otherwise suspend with the current procedure invoked on the current
# pattern concatenated with the rematch of the next procedure and
# pattern pair (recursive)
else suspend tab(pats[pind].proc(pats[pind].arg)) ||
rematch(pats,pind+1)
end
# match partial patterns generated by the '+' special character
procedure plus(c)
# the loop is so that the longest possible pattern will be matched
suspend (many(c) to &pos+1 by -1)
end
# match partial patterns generated by the '*' special character
procedure star(c)
# the loop is so that the longest possible pattern will be matched
suspend (many(c) to &pos+1 by -1) | &pos
end
# match the shortest possible string up to and including the cset passed
procedure pastcset(c)
while tab(upto(c)) do {
suspend any(c)
move(1)
}
end
# match the shortest possible string up to and including the string passed
procedure paststring(c)
while tab(find(c)) do {
suspend match(c)
=c
}
end
From MANTEL@zeus.unl.edu Mon Nov 7 07:54:09 1988
Message-Id: <8811071454.AA27122@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA27122; Mon, 7 Nov 88 07:54:09 MST
Received: from crcvms.unl.edu by rvax.ccit.arizona.edu; Mon, 7 Nov 88 07:34 MST
Date: Sun, 6 Nov 88 20:35 CST
From: MANTEL@zeus.unl.edu
Subject: Help, please . . .
To: icon-group@arizona.edu
X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
In the July 1985 issue of Byte Magazine, Ralph Griswold (in an interview)
mentioned that "people in industry are using Icon for VLSI layout." Could you
please supply me with a starting point to digging up references in journals or
magazines on such usage? Journal names, or names of people doing this sort
of thing? I've looked, but evidently not in the right places yet . . .
General problem: I'm trying to find applications that are non-numeric, and
non-linguistic. (I already have plenty of examples of those two categories.)
For example, what about applications written in Icon using group theory for
chemistry applications? Seems like a natural possibility, but I haven't
found any. I suspect that articles about that exist, but "Icon" may not be
in the title or listed as a keyword. Same for applications in graph theory,
genetics, etc. Is there a bibliography of applications somewhere?
Thanks in advance for your time and effort. I appreciate the help.
From ralph Tue Nov 8 04:47:20 1988
Date: Tue, 8 Nov 88 04:47:20 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8811081147.AA28711@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA28711; Tue, 8 Nov 88 04:47:20 MST
To: icon-group
Subject: Version 7 Icon configurations for UNIX systems
We're in the process of updating our source-code release for
Icon. This will bring it to Version 7.5 (the changes are
mostly in the implementation, not the language itself).
For the UNIX release, we'd like to include configuration files
for as many systems as possible. We have configuration files
for Version 7 Icon for the following systems:
AT&T 3B2 Sequent Balance 8000
AT&T 3B20 Sequent Symmetry
AT&T 3B4000 Siemens MX500
Convex C-1/2 Sun-2 Workstation
Encore Sun-3 Workstation
HP 9000/320 Sun-3 with 68881
IBM PS/2 (XENIX 386) Sun-4 Workstation
IBM RT Workstation (AIX) UNIX-PC/3B1
IBM XT/AT (XENIX 286) VAX-11 (BSD)
Microport V/386 VAX-11 (System V)
VAX-11 (Ultrix)
If you have configuration files for a system that is not on this
list, we would appreciate your sending them to us.
You can send them any way that's convenient for you. What's worked
best in the past has been electronic mail with the files packaged
using shar. Things like cpio or tar piped though btoa or uuencode
also work.
Please address any questions to me, not icon-group.
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao}!arizona!ralph
From wgg@june.cs.washington.edu Mon Nov 14 14:04:07 1988
Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA21183; Mon, 14 Nov 88 14:04:07 MST
Received: by june.cs.washington.edu (5.59/6.13+)
id AA22448; Mon, 14 Nov 88 12:11:50 PST
Date: Mon, 14 Nov 88 12:11:50 PST
From: wgg@june.cs.washington.edu (William Griswold)
Return-Path: <wgg>
Message-Id: <8811142011.AA22448@june.cs.washington.edu>
To: icon-group@arizona.edu
Subject: Improving Table Performance
I have been experimenting with implementing Icon tables (and sets)
using ``dynamic hashing'' in order to achieve true linear-time insert
and lookup performance in tables. Dynamic hashing is a technique
that dynamically expands or contracts a hash table (i.e., the number
or ``buckets'' it has) in proportion to the number of elements in the
table. By assuring that the number of buckets and the number of
elements is related by a constant factor (and assuring even element
distribution) linear-time performance can be achieved. The table
expansion is acheived by a dynamically-sized-array datatype; this
introduces an extra level of indirection in accessing elements.
The results of my implementation were very positive. For a small
overhead (say, 5% in time on small tables, 10% in space), uniform table
element access is acheived for any size table. I'm hoping to cut
out more of the time overhead.
I was inspired to attempt this by some data-intensive applications that
were running slowly due to poor table performance (as shown below, this
is only an issue for rather large tables). The final inspiration came
from the April 1988 CACM article "Dynamic Hash Tables" by Per-Ake Larson.
TEST RESULTS
------------
For comparison, hear are some results from running a test program.
The program inserts random integers into a table at increments of
powers of 2, checking at each power how long 500 lookups are
taking for each of the ``Test integers''. HEAPSIZE is 3000000,
STRSIZE is 2000000, Sun3, Unix. I get pretty wide variations in
runtimes for these programs (+-5%), so I can only say these are
representative. First the run on old iconx, then under my version:
OLD ICONX:
Test integers are: 1528858604, 108158591, 1572747416, 169761597, 651873887,
899332472, 1088491433, 673419496, 879469459, 450641070.
tab size look time*500 time/size total runtime
1 516 516.0 516
2 550 275.0 1066
4 550 137.5 1616
8 517 64.625 2150
16 517 32.3125 2683
32 550 17.1875 3250
64 633 9.890625 3883
128 500 3.90625 4416
256 567 2.21484375 5033
512 650 1.26953125 5833
1024 617 0.6025390625 6750
2048 867 0.4233398438 8333
4096 1150 0.2807617188 11000
8192 1550 0.1892089844 16166
16384 2750 0.1678466797 30383
32768 5200 0.1586914063 77850
MY ICONX:
Test integers are: 1528858604, 108158591, 1572747416, 169761597, 651873887,
899332472, 1088491433, 673419496, 879469459, 450641070.
tab size look time*500 time/size total runtime
1 534 534.0 550
2 516 258.0 1066
4 567 141.75 1633
8 583 72.875 2216
16 534 33.375 2750
32 584 18.25 3350
64 567 8.859375 3933
128 600 4.6875 4550
256 600 2.34375 5233
512 583 1.138671875 5966
1024 617 0.6025390625 6883
2048 600 0.29296875 8066
4096 600 0.146484375 9850
8192 634 0.07739257813 12850
16384 567 0.03460693359 18233
32768 600 0.01831054688 30550
The ``turnover'' point is somewhere around 500-1000 elements.
The results are similar for a similar program using words from
/usr/dict/words.
On a ``real program'' (grouping words in /usr/dict/words by cset
equivalence) I got a 25% improvement in the running time. This
program is I/O intensive, and uses lots of cset conversions and
auxiliary tests. Performance was helped *substantially* in both
programs (I think more than the new hashing algorithm could) by
generously allocated memory space, as indicated above.
EXTRA FOR EXPERTS
-----------------
The details of the algorithm can be found in the article cited above
(which is the implementation I faithfully applied). Below I discuss
changes to the Icon element-hashing function.
I reimplemented the hash functions for strings and csets, which had
poor distributions under the scheme I was using, although they worked
fine under the old implementation. The reasons that the old hash
functions did not work so well in my implementation is simple: my
tables are not necessarily of fixed (small) size, and are not of
prime size. Hence hash values under my implementation need to large,
and must be scrambled by something other than the bucket-assignment
``mod'' operation. The distributions now appear to be very good,
judging from the profiling I've done.
For strings, the function now is:
for (j = (j <= 10) ? j : 10 ; j > 0; j--)
{
hashval += *s++ & 0377; /* WGG - is the mask necessary anymore? */
hashval *= 37; /* WGG - new; better distribution, larger numbers */
}
hashval += StrLen(*dp);
hashval = AbsHash(hashval); /* WGG - new; abs value - cannot be neg */
For csets it is:
bitarr = BlkLoc(*dp)->cset.bits + (CsetSize-1);
for (j = 0; j < CsetSize; j++)
{
/* WGG - loop body was: i ^= BlkLoc(*dp)->cset.bits[j]; */
hashval += AbsHash(*bitarr--); /* WGG - AbsHash necessary? */
hashval *= 37; /* WGG - better distribution */
}
hashval += BlkLoc(*dp)->cset.size; /* WGG - include size */
hashval = AbsHash(hashval) % 1048583; /* WGG - scramble */
Clearly, for tables containing values of these types, some of the
performance loss for smaller tables could be in these hash functions
(which could be cleaned-up, as noted in the comments), although it's
more likely hidden in the extra level of indirection in the table
implementation.
STATUS
------
The implementation as it stands is not complete. I have not implemented
the contraction part of the algorithm for tables, and the set implementation
is not quite finished.
Bill Griswold
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Wed Nov 16 08:31:17 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA17345; Wed, 16 Nov 88 08:31:17 MST
Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
id AA11820; Wed, 16 Nov 88 09:32:02 cst
Return-Path: <goer>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA00651; Tue, 15 Nov 88 20:29:21 CST
Date: Tue, 15 Nov 88 20:29:21 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8811160229.AA00651@sophist.uchicago.edu>
To: willr@ncsa.uiuc.edu
Subject: Re: humanist network
Cc: icon-group@arizona.edu
That was pretty funny. Fiction writer?
No, actually there are many people who are linguists, archeologists,
sociologists, or whatever, who use the computer for database and other
such work. I use Icon for low-level linguistic analysis in Near Eastern
languages and literatures. If you are involved in the humanities, you
might want to contact Willard McCarty at MCCARTY@UTOREPAS.bitnet; he
is the one that monitors the group.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Wed Nov 16 14:29:30 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA04641; Wed, 16 Nov 88 14:29:30 MST
Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
id AA16763; Wed, 16 Nov 88 15:30:49 cst
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA01730; Wed, 16 Nov 88 15:22:25 CST
Date: Wed, 16 Nov 88 15:22:25 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8811162122.AA01730@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: fiction writer
I don't mean to make fun of anyone when I said that the mention
of a fiction writer was funny on the Icon newsgroup. I had mis-
read the note. Fiction-writing is certainly no more or less noble
an occupation than any other. Writing actually carries a certain
mystique about it that makes it seem very attractive to outsiders.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From hdan@sleepy.cc.utexas.edu Thu Nov 17 17:35:59 1988
Received: from emx.utexas.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA15626; Thu, 17 Nov 88 17:35:59 MST
Received: by emx.utexas.edu (5.54/5.51)
id AA12702; Thu, 17 Nov 88 18:36:07 CST
Date: Thu, 17 Nov 88 18:34:42 CST
From: hdan@sleepy.cc.utexas.edu (Dan Higdon)
Posted-Date: Thu, 17 Nov 88 18:34:42 CST
Message-Id: <8811180034.AA21854@sleepy.cc.utexas.edu>
Received: by sleepy.cc.utexas.edu (5.51/5.51)
id AA21854; Thu, 17 Nov 88 18:34:42 CST
To: icon-group@arizona.edu
Subject: Icon program example
#
# NOTE:
# This is a simple course scheduling program (for students)
# I have found it useful (that's why I wrote it), and I hope other
# Icon users might also. I am providing this source for use and
# reference only, you do not have permission to sell it
# or any program derived from this source!
# I would be interested in any comments/ideas you have.
# You can reach me on ARPANET or indirectly through the icon-project
# mailing list.
#
#
# The latest incarnation of...
# Dan Higdon's Scheduling Program!
# April 20, 1988
# By Dan Higdon
# in Icon Version 7.0
#
# ARPANET address: hdan@sleepy.cc.utaxas.edu
#
#
# This is an attempt to bring a bit of user-
# friendliness to the recursive-backtracked
# class scheduling algorithm I have traditionally
# been using. This ICON version of the scheduler
# will use the same tried and true PROLOG based
# algorithm that my other scheduler uses,
# only adapted to ICON's special abilities.
#
# The icon scheduler will attempt to preserve
# the "declarativeness" of this scheduler as much as possible.
# Now for the program...
#######################################################################
#
# Variables
#
#
# classdb is a table of lists of times.
# times are keyed on class names.
#
global classdb, # The class database
width, # Default width of field
shade, # Default "spongy" character
military, # Whether or not to display military
number, # Whether or not to number each schedule
title, # The title line
plot, # Plot to screen?
nonotes, # Suppress the .n field?
outfile, # File handle, output to file?
fwrite, # Write to file?
saturday # Print saturday column?
#
# The class type
#
record class (name, # Class name
day, # Set of days
times, # Class times
unum, # Unique number
notes, # Extra information
shade, # Shade character
lab) # The optional lab class
#######################################################################
#
# The scheduler
#
#
# In order to preserve the backtracking idea, schedule is
# a generator which generates the possible schedules at
# that level of recursion.
#
# clist is a list of class names
#
# The algorithm is as follows:
# If clist is null, return an empty schedule list
# with no chance of more "generating"
# otherwise,
# Generate every remaining schedule and do the following with each:
# get the class name
# Generate every non-null and unconflicting time for each class and
# push it onto the list
# suspend this schedule, then pop the entry
#
procedure schedule (clist)
local t, schedl, cl
if *clist = 0 then return clist
every schedl <- schedule (clist[2:0]) &
t <- !classdb[clist[1]] &
nonConflicting (t,schedl) &
(/t.lab | nonConflicting (\t.lab,schedl))
do {
cl := ([t,\t.lab] | [t])
suspend if *schedl = 0 then cl
else cl ||| schedl
}
end
#
# Detect conflicts in schedule times
#
# This routine fails if there IS a conflict in the time
# specified and the schedule list supplied. The algorithm
# checks each element of the list against the supplied time
# and returns successfully iff a match is not found
#
procedure nonConflicting (t,l)
local lt
every lt := !l do
if (*(t.day ** lt.day) ~= 0) & SameTime(t.times,lt.times) then fail
return # Everything works
end
#
# Check for overlapping times.
#
procedure SameTime (x,y)
if x[1] = y[1] | # If same start
(y[1] < x[1] < y[2]) | # or overlapping
(x[1] < y[1] < x[2])
then return
end
#######################################################################
#
# Input routines
#
#
# The comment stripper & detabber
#
procedure strip (s)
return detab (trim(s[1:find (";",s) | 0]))
end
#
# The preprocessor.
# This routine is responsible for processing the "dot"
# commands. Any dot commands are interpreted and
# all other lines are passed through
#
procedure preproc (s)
local command, arg, lab
if *s = 0 | s[1] ~== "." then return s
s ? {
command := map(tab(upto (' ') | 0),&lcase,&ucase)
tab (many (' '))
arg := tab (0)
}
case command of {
".WIDTH": if not (width := integer (arg)) then
stop ("Invalid width ",arg)
".SHADE": if not (shade := arg[1:2]) then
stop ("Invalid shade character ",arg)
".MILITARY": military := 1
".NUMBER": number := 1
".TITLE": title := arg
".PLOT": plot := plotclass
".OUTFILE": {
if not (outfile := open (arg,"w")) then
stop ("Invalid filename ",arg)
fwrite := writeclass
}
".SATURDAY": saturday := "Sat"
".LAB": {
lab := linetrans (" " || arg)
classdb[lab.name][1].lab := lab
lab.name ||:= " l"
}
".NONOTES": nonotes := 1
default: stop ("Error, ", command, " not recognized")
}
return ""
end
#
# The class time translater
#
# This procedure translates times in the line format:
# "[classname] mtwthf h:mm [h:mm] [notes]"
# Each element of the line must be separated by spaces
# This format was chosen for readability. Spacing is free-format.
# ex: "cs410 mwf 1:00 2:00"
#
# The classname is returned if successful
#
procedure linetrans (string)
local day, s, e, c, n, notes, i, nxt, unum
static name, space
initial space := ' '
string ? {
n := tab (upto (space)) # name = 1st word
tab (many (space)) # Skip any spaces following
day := tab (upto (space)) # day = next word
tab (many (space)) # skip to next field
start := tab (upto (space) | 0) # start = upto blank or EOS
tab (many (space)) # skip leading blanks
nxt := tab (upto (space) | 0) # get end time or EOS
if find (":",nxt) then {
etime := nxt
tab (many (space))
nxt := tab (upto (space) | 0)
} else {
etime := ""
}
if nxt == ".n" | nxt == ".N" then { # Option
tab (many (space))
notes := tab (0)
unum := ""
} else {
unum := nxt
tab (find (".n" | ".N"))
tab (upto (space))
tab (many (space))
notes := tab (0)
}
}
if n ~== "" then name := n # Allow for assumed name
if i := find ("th",day) then day[i:i+1] := ""
s := toMilitary (start)
e := toMilitary (etime) | stdtime (cset(day),s)
return class (name,cset(day),[s,e],unum,notes,shade,&null)
end
#
# Return the standard end time for the given day.
# MWF classes are 1 hr long, others 1:30.
#
procedure stdtime (day,start)
local c
c := start
if *(day ** 'mwfs') = 0 then c +:= 50
c +:= 100
return c
end
#######################################################################
#
# Output routines
#
#
# The outclass driver routine
#
procedure outclass (l,count)
(\plot) (l,count)
(\fwrite) (l,count)
end
#
# Display the class in a nice format
# I hope to make this more "graphic" in the future.
#
procedure plotclass (l,count)
local w,c
if \saturday then
w := width*6
else
w := width*5
clrscrn()
gotoxy (10,1)
write (center (if \number then title || " " || count
else title,
w))
DayLabel()
TimeLabel()
every c := !l do place (c)
gotoxy (1,25)
writes ("Hit any key for next schedule, <shift>+<PrtScr> to print, or <ESC> to exit.")
if ord (getch()) = 27 then stop ("\nProgram terminated by user")
return
end
#
# Position the class name at the proper location
# on the screen "grid"
#
procedure place (class)
local day, od, ot, ote, shades
shades := repl (class.shade,width-2)
every day := !class.day do {
if day == "s" & /saturday then return
od := (find(day,"mtwhfs") - 1)*width + 9
ot := class.times[1]/50 - 13
ote := class.times[2]/50 - 14
gotoxy (od, ot)
writes (center (class.name,width))
if /nonotes & class.notes ~== "" then {
ot +:= 1
gotoxy (od,ot)
writes (center (class.notes,width))
}
every gotoxy (od,ot+1 to ote) do
writes (center (shades,width))
}
end
#
# Produce the output for the Day display
#
procedure DayLabel()
writes (" ")
every writes (
center ("Mon" | "Tue" | "Wed" | "Thu" | "Fri" | \saturday, width))
write()
end
#
# Produce the output for the time labels
#
procedure TimeLabel ()
if \military then {
every write (" ", 8 to 9,":00\n")
every write (10 to 18,":00\n")
} else {
every write (" ",8 to 9,":00am\n")
every write (10 to 11,":00am\n")
write ("12:00pm\n")
every write (" ",1 to 6,":00pm\n")
}
end
#
# Write the classes to the tty style file specified
#
procedure writeclass (l,count)
local c
write (outfile,"\n",title," ",(\number,count) | "")
write (outfile,left ("Name",width),
" Days "," From "," To ","Unique ","Notes")
write (outfile,repl("=",47+width))
every c := !l do write (outfile,
left (c.name,width)," ",
left (toDays (c.day),8),
left (toStandard (c.times[1]),9),
left (toStandard (c.times[2]),9),
left (c.unum,8),
c.notes)
write (outfile)
end
#
# Output the titlescreen
#
procedure titlescreen ()
clrscrn()
write()
write (center ("Sched-Tool Course Scheduling Tool",79),
center ("Student Edition",79),
center ("Version 1.1 Copywrite (c) 1988 Dan Higdon",79),"\n")
end
#######################################################################
#
# Utilities
#
#
# Convert a time into a military decimal notation
#
procedure toMilitary (t)
local mt
if *t = 0 then fail
mt := (t ? tab(upto (':')))
if mt < 8 then {
mt +:= 12
}
mt *:= 100
if find(":3",t) then mt +:= 50
return mt
end
#
# Convert military integer to a string
#
procedure toStandard (m)
local hr, min, sh
hr := m/100
if (m - hr*100) = 0 then
min := ":00"
else
min := ":30"
if /military & hr > 12 then hr -:= 12
if hr < 10 then
sh := " " || string (hr)
else
sh := string (hr)
return sh || min
end
#
# Convert a set of days into a string of days
# in the appropriate order and form
#
procedure toDays (days)
local sd, d
sd := ""
d := ""
every d ||:= !days
if find ("m",d) then
sd ||:= "m"
if find ("t",d) then
sd ||:= "t"
if find ("w",d) then
sd ||:= "w"
if find ("h",d) then
sd ||:= "th"
if find ("f",d) then
sd ||:= "f"
if find ("s",d) then
sd ||:= "s"
return sd
end
#######################################################################
#
# The main procedure
#
procedure main (argv)
local classes, ct, c, count, buf
initial {
classdb := table()
classes := list()
width := 10
shade := "#"
title := "Possible Schedule"
}
titlescreen()
if \argv[1] then {
if not (find (".",argv[1])) then argv[1] ||:= ".sch"
buf := open (argv[1],"r")
write (center ("Reading in file: " || argv[1], 80))
}
if /buf then {
write("\n")
write (center ("Error in opening data file. Aborting",80))
exit (1);
}
while ct := preproc(strip(read(buf))) do {
if *ct > 0 then {
c := linetrans (ct)
(/classdb[c.name] := [c]) | push (classdb[c.name], c)
(c.name == !classes)|(/classes := [c.name])|push (classes,c.name)
}
}
close (buf)
count := 0
write ("\n",center ("Working...",80),"\n")
every outclass (schedule (classes), count +:= 1)
if count = 0 then write ("No schedule possible. Exiting.")
else write ("\nNo more schedules. Exiting.")
end
#
# An ANSI screen library
#
# High-level names for the low-level ANSI routines.
# If your system terminal doesn't support ANSI, you will
# have to re-implement these two routines, which should be
# pretty easy...
# You should use OS calls if possible in your implementation.
#
#
# Move cursor to x,y
#
procedure gotoxy (x,y)
writes (char(27), "[", y, ";", x, "H")
return
end
#
# Clear the text screen
#
procedure clrscrn()
writes (char(27), "[2J")
return
end
############################################################################
-End of program. Cut here-
Use from here on as a datafile. Pass name on command line
############################################################################
;
; This is a sample input file. It displays some of the
; functions that this program supports. It produces
; a "table" of possible schedules (assuming you have implemented
; the cursor control codes for the main program...)
;
.title Dan Higdon -- Spring 1989 -- Schedule
;
; GER507 - German 5 hrs.
; LIN340 - Linguistics 3 hrs.
; CS352 - Computer Architecture 3 hrs.
; CS345 - Programming Languages 3 hrs.
; PED105M - Fencing 1 hrs.
; --------
; 15 hrs.
;
.width 12 ; Set the width of the columns
.number ; Append schedule number (in sequence) to title
.plot ; Produce visual output
; .NoNotes ; Suppress .n field in visual output
; .outfile dans89.txt ; Create table output to fname
;
; Classes
;
; Foreign Language
GER507 mtwthf 9:00 10:00 30085 .n Jes A307A
mtwthf 10:00 11:00 30090 .n Jes A307A
mtwthf 11:00 12:00 30095 .n Jes A307A
mtwthf 12:00 1:00 30100 .n Jes A307A
mtwthf 1:00 2:00 30105 .n Jes A307A
mtwthf 2:00 3:00 30110 .n Jes A307A
mtwthf 3:00 4:00 30115 .n Jes A307A
; Linguistics 340 Automata Theory
LIN340 mwf 2:00 3:00 33225 .n Cal 100
; Computer Science - Computer Systems Architecture
CS352 tth 2:00 3:30 43170 .n Tay 2.106
.lab w 4:00 5:30 ; Lab section for CS352
; Computer Science - Programming Languages
CS345 mwf 9:00 10:00 43150 .n Wel 2.310
; Fencing
.shade ! ; Shade set to '!' for fencing only!
PED105M mw 10:00 11:30 09275 .n BEL 302
tth 12:30 2:00 09280 .n BEL 302
mw 1:00 2:30 09285 .n BEL 302
mw 2:00 3:30 09290 .n BEL 302
tth 2:00 3:30 09295 .n BEL 302
From att!ihuxy!nowlin Wed Nov 23 05:52:34 1988
From: att!ihuxy!nowlin
Message-Id: <8811231252.AA13136@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA13136; Wed, 23 Nov 88 05:52:34 MST
Received: by att.ATT.COM (smail2.6 - att-cb)
id AA15795; 23 Nov 88 07:47:00 EST (Wed)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Wed 23 Nov 1988 06:47 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Icon Regular Expressions
Ua-Message-Id: <post.nowlin.Wed 23 Nov 1988 06:40 CST>
End-Of-Protocol:
Content-Length: 9945
I posted a version of grep a while back that had some regular expression
procedures incorporated in it. I mentioned that I'd try to generalize them
when I had time. I didn't really have time but I did it anyway because it
was interesting. Attached is a set of procedures that should be commented
well enough to explain themselves. I'll post a new grep main procedure that
uses these routines separately. Any comments or suggestions are welcome.
Jerry Nowlin
(...!att!ihuxy!nowlin)
================================ cut here ===================================
# This set of Icon procedures implements regular expression matching
# for use in the context of string scanning. The regular expressions
# recognized by these procedures can contain the following special (magic)
# characters:
#
# ^ - matches if the following pattern is at the beginning of a line
# $ - matches if the preceding pattern is at the end of a line
# . - matches any single character
# [] - matches any of the characters enclosed by square brackets
# + - matches from 1 to any number of occurrences of the previous
# character
# * - matches from 0 to any number of occurrences of the previous
# character
# \ - escapes the special meaning of any special characters
# recognized by this program
#
# A pair of square brackets can enclose a range specification, like '[a-z]',
# in which case any of the ASCII characters between 'a' and 'z' will be
# matched. If the initial character inside square brackets is a '^' then
# the matching pattern will be the complement of (any characters except)
# the ones enclosed in the square brackets. For example, '[^a-z0-9]' will
# match any characters except lower case letters and digits.
# A regular expression record contains a procedure and a pattern argument
# that the procedure will be invoked on.
record rerec(proc,arg)
# This procedure implements a regular expression version of "find". This
# is an incomplete implementation since it only works in the context of
# string scanning.
procedure refind(re)
savepos := &pos
if s := regexpmatch(re,1) then {
found := &pos - *s
&pos := savepos
suspend found
}
end
# This procedure implements a regular expression version of "match". This
# is an incomplete implementation since it only works in the context of
# string scanning.
procedure rematch(re)
savepos := &pos
if s := regexpmatch(re,1) then {
found := &pos
&pos := savepos
if found-savepos = *s then suspend found
}
end
# This procedure does the recursive matching for all the elements of a
# regular expression list. Re is the list of regular expression records to
# match and i is the index in the list to start matching on. This procedure
# assumes it is invoked in the context of string scanning.
procedure regexpmatch(re,i)
# If i is beyond the end of re a match was found so suspend with an
# empty string to end the recursion.
if i > *re then suspend ""
# Otherwise, suspend with the current re.procedure invoked on the
# current re. pattern concatenated with the rematch of the next
# re.procedure and re.pattern pair.
else suspend tab(re[i].proc(re[i].arg)) || regexpmatch(re,i+1)
end
# This procedure compiles a lists of regular expression records from the
# regular expression passed in s. If the second argument is not null it
# will invoke a dump of the final regular expression list before the
# procedure returns it.
#
# The regular expression given in s is broken up into a list of partial
# patterns that can be matched independent of each other. Then this
# initial list of partial patterns is optimized. Each partial pattern has
# a procedure associated with it that will be used to match it.
#
# While parsing the partial patterns there is the concept of a next string
# matching procedure and a next character matching procedure. These change
# from one partial pattern to the next depending on the content of the
# previous and the current partial patterns.
procedure recomp(s,debug)
static magic, mundane, ascii
initial {
magic := '^$.+*[\\'
mundane := ~magic
ascii := string(&ascii)
}
# Initialize the temporary regular expression list.
retmp := []
# Initialize the next string procedure and the next cset procedure.
ns := paststring
nc := pastcset
# Parse each character in the pattern one at a time. (This is slow
# but needed for the '+' and '*' magic characters.)
s ? while c := move(1) do case c of {
# The beginning of line character.
"^": {
# If this is the first character of the pattern
# it's special.
if pos(2) then {
ns := match
nc := any
# If plus or star are the second characters
# and carat is the first then just match them.
if c := move(1) == ("+" | "*") then
put(retmp,rerec(ns,c))
}
# If carat isn't the first character just match it.
else put(retmp,rerec(ns,"^"))
}
# The end of line character.
"$": {
# If this is the last character of the pattern
# it's special.
if pos(0) then put(retmp,rerec(pos,0))
# If dollar isn't the last character just match it.
else put(retmp,rerec(ns,"$"))
}
# The match any character character.
".": {
put(retmp,rerec(nc,&ascii))
ns := match
nc := any
}
# The 1 to any number of previous characters character.
"+": {
# If this is the first character of the pattern
# it's not special so just match it.
if pos(2) then put(retmp,rerec(ns,"+"))
# Otherwise it's special.
else {
retmp[-1].proc := plus
retmp[-1].arg := cset(retmp[-1].arg)
ns := match
nc := any
}
}
# The 0 to any number of previous characters character.
"*": {
# If this is the first character of the pattern
# it's not special so just match it.
if pos(2) then put(retmp,rerec(ns,"*"))
# Otherwise it's special.
else {
retmp[-1].proc := star
retmp[-1].arg := cset(retmp[-1].arg)
ns := match
nc := any
}
}
# The escape other characters character.
"\\": {
# If the next character is a special character
# match it and skip the backslash.
if any(magic,&subject[&pos]) then
put(retmp,rerec(ns,move(1)))
# If the next character isn't special match backslash.
else put(retmp,rerec(ns,"\\"))
}
# The match enclosed characters character.
"[": {
inside := ''
lastc := "["
c := move(1)
# If the complement character is the first one in
# the brackets.
if c == "^" then {
notin := 1
c := move(1)
}
# Otherwise the first character is not special.
else notin := 0
# Parse the inside cset characters.
repeat {
case c of {
# The closing bracket means we're done.
"]": break;
# The dash means we're in a range.
"-": {
# If the dash is at the end
# or beginning of the inside
# cset just match a dash.
if (lastc == "[") |
(&subject[&pos] == "]")
then {
lastc := "-"
inside ++:= cset(lastc)
}
# Otherwise match the range
# of ascii characters between
# the previous and
# following characters.
else
# The current indent is violated by this and the next line.
inside ++:= cset(ascii[upto(lastc,ascii)+1:upto(lastc := move(1),ascii)+1])
}
# A backslash means take the next
# character regardless.
"\\": {
lastc := move(1)
inside ++:= cset(lastc)
}
# The default is to add the
# character to the inside cset.
default: {
lastc := c
inside ++:= cset(lastc)
}
}
# If we ran out of characters break.
if not (c := move(1)) then break;
}
# This is a check for mismatched brackets.
if pos(0) & c ~== "]" then
stop("Mismatched brackets '",s,"'")
# If the complement flag is set complement the
# inside cset.
if notin = 1 then inside := ~inside ** &ascii
# Add this record to the regular expression list.
put(retmp,rerec(nc,inside))
}
# Mundane characters are just added to the list.
default: {
put(retmp,rerec(ns,c))
ns := match
nc := any
}
} # The bottom of parse the pattern loop.
# Initialize the flag for being in a literal string.
instring := 0
# Initialize the final regular expression list.
re := []
# Go through the initial patterns and optimize them by making
# consecutive literal strings into single literal strings.
every r := !retmp do {
# If this record contains a literal string.
if type(r.arg) == "string" &
r.proc === (match | paststring) then {
# If the last record was a literal string add this
# record to it.
if instring = 1 then {
re[-1].arg ||:= r.arg
}
# If the last record wasn't a literal string start
# a literal string with this record.
else {
put(re,r)
instring := 1
}
}
# If this record contains a special pattern add it as is.
else {
put(re,r)
instring := 0
}
}
# If the second argument was passed print a dump of the regular
# expression list.
if \debug then {
write("\nRegular Expression Record Dump (",*re,"):")
every m := !re do write("\t",image(m.proc),": ",image(m.arg))
write()
}
# Return the list of regular expression records.
return re
end
# Match partial patterns generated by the '+' magic character.
procedure plus(c)
# The loop is so that the longest possible pattern will be matched.
suspend (many(c) to &pos+1 by -1)
end
# Match partial patterns generated by the '*' magic character.
procedure star(c)
# The loop is so that the longest possible pattern will be matched.
suspend (many(c) to &pos+1 by -1) | &pos
end
# Match the shortest possible string up to and including the cset passed.
procedure pastcset(c)
while tab(upto(c)) do {
suspend any(c)
move(1)
}
end
# Match the shortest possible string up to and including the string passed.
procedure paststring(c)
while tab(find(c)) do {
suspend match(c)
=c
}
end
From att!ihuxy!nowlin Wed Nov 23 06:05:12 1988
From: att!ihuxy!nowlin
Message-Id: <8811231305.AA13932@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA13932; Wed, 23 Nov 88 06:05:12 MST
Received: by att.ATT.COM (smail2.6 - att-cb)
id AA15853; 23 Nov 88 07:53:55 EST (Wed)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Wed 23 Nov 1988 06:54 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: new Icon grep
Ua-Message-Id: <post.nowlin.Wed 23 Nov 1988 06:48 CST>
End-Of-Protocol:
Content-Length: 1236
Here's a new Icon grep main procedure that uses the regular expression
matching procedures posted earlier.
Jerry Nowlin
(...!att!ihuxy!nowlin)
================================ cut here ===================================
procedure main(a)
# the usage message
usage := "Usage: igrep pattern [ file ... ]"
# the first program argument must be the pattern
pattern := get(a) | stop("I at least need a pattern\n",usage)
# compile the pattern into a regular expression list
re := recomp(pattern)
# trick the program into using standard input if no files were passed
if *a = 0 then a := [&null]
# the rest of the arguments are files to search through
every f := !a do {
# if the file isn't null try to open it
if \f then in := open(f) | stop("I can't open '",f,"'")
# otherwise use standard input
else in := &input
# if there is only one file skip printing the file name
if *a = 1 then f := ""
# otherwise tack on a colon
else f ||:= ":"
# read all the lines
every l := !in do {
# scan the line for the pattern
l ? {
# if the pattern is found print the line
if refind(re) then write(f,l)
}
}
# close the input file is one was opened
if in ~=== &input then close(in)
}
end
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Wed Nov 23 16:06:54 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA15351; Wed, 23 Nov 88 16:06:54 MST
Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
id AA11091; Wed, 23 Nov 88 17:08:26 cst
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA01571; Wed, 23 Nov 88 16:59:33 CST
Date: Wed, 23 Nov 88 16:59:33 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8811232259.AA01571@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: Huffmon encoded text
Say I have a tree all stored for a Huffmon encoded text. Making
such a tree is no problem. What I'm wondering about is how, in
Icon, one might best go about actually encoding or decoding the
text. I've not used the bit-manipulating features of Icon much,
and I'm just wondering if anyone has already done this (and dis-
covered how Icon best handles the task).
Feeling ignorant : desiring enlightenment on this subject....
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From att!ihuxy!nowlin Mon Nov 28 13:43:34 1988
From: att!ihuxy!nowlin
Message-Id: <8811282043.AA28606@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA28606; Mon, 28 Nov 88 13:43:34 MST
Received: by att.ATT.COM (smail2.6 - att-cb)
id AA13083; 28 Nov 88 15:40:15 EST (Mon)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Mon 28 Nov 1988 14:40 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: co-expressions for regular expressions.
Ua-Message-Id: <post.nowlin.Mon 28 Nov 1988 14:05 CST>
End-Of-Protocol:
Content-Length: 962
Gang,
There hasn't been a lively discussion in this group for some time.
Maybe I can plant the seed. I posted some regular expression code last
week and have since thought about some alternative solutions.
I was weaned on a version of Icon that didn't support co-expressions and as
a result I don't usually think of problems in terms that lend themselves to
co-expression solutions. Is there a way to use co-expressions, instead of
records containing a procedure and an argument for that procedure, in the
code I posted? This code was thoroughly commented and someone who knows
co-expressions better than I do can perhaps look into this.
Other questions are whether or not co-expressions would be faster than the
current method and if generation and goal directed evaluation could be used
in a more elegant way if the algorithm used co-expressions? I'm never
completely happy when I have to use subscripts. Thanks.
Jerry Nowlin
(...!att!ihuxy!nowlin)
From sboisen@REGULUS.BBN.COM Wed Nov 30 14:15:14 1988
Message-Id: <8811302115.AA24243@megaron.arizona.edu>
Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA24243; Wed, 30 Nov 88 14:15:14 MST
To: icon-group@arizona.edu
Subject: problems with tables of tables
From: Sean Boisen <sboisen@REGULUS.BBN.COM>
Sender: sboisen@REGULUS.BBN.COM
Reply-To: sboisen@bbn.com
Date: Wed, 30 Nov 88 16:05:26 EST
Here's a problem i ran into today: i found a work-around, but it
bothers me that i couldn't solve it the concise and elegant way i
wanted to (and that i'm accustomed to having Icon provide me with).
Imagine an application where you want to build a table, and the value
of each entry in the table is itself another table. For example,
you're going through a numbered list of sentences, some of which have "bad"
words (definition of bad is irrelevant here), and you want a list of
all the "bad" words, each followed by the sentences it occurs in. My
idea was to have a master table, whose entries would be "bad" words:
then the value of each entry would be itself a table, with entries
being the sentence number and values the sentence text. So i tried a
piece of code something like this (irrelevant details omitted):
procedure main()
initial master := table(table())
while (line := read()) do
{
# imagine some code here that assigns to sentence and number
# .....
if bad-word := get_bad_word(line) then
{
sentence_table := master[bad_word]
sentence_table[number] := sentence
master[bad_word] := sentence_table
}
}
end
The idea is that master[bad_word] should produce a table, which is
assigned to sentence_table: you then play with that, and assign the
new one back to master[bad_word] (since only assignments "grows" a
table). This doesn't work, however: the best was i can describe the
failure is that sentence_table maintains the same value across
different values of bad_word, in other words it accumulates ALL
sentences, not just those specific to this particular bad_word. Am i
missing something really obvious? If there is no previous entry for
bad_word in master, shouldn't the assignment to sentence_table produce
an empty table instead of the same one as for some other value of
bad_word?
(by the way, the workaround i used was to keep a separate table of
"found" bad_words, and if the bad_word wasn't there, explicitly assign
a new table to sentence_table, i.e.
sentence_table := table()
This seemed to accomplish what i wanted, but less elegantly)
Thanks for your collegiality,
Sean
........................................
Sean Boisen -- sboisen@bbn.com
BBN Systems and Technologies Corporation, Cambridge MA
Disclaimer: these opinions void where prohibited by lawyers.
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Wed Nov 30 22:20:33 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA17432; Wed, 30 Nov 88 22:20:33 MST
Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
id AA11671; Wed, 30 Nov 88 23:22:25 cst
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA09107; Wed, 30 Nov 88 23:13:04 CST
Date: Wed, 30 Nov 88 23:13:04 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8812010513.AA09107@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: problems with tables of tables
I could let the big guns take this one, I suppose, and be safe.
But the answer seems obvious to me, so I'll offer some free
advice. The problem with saying:
master := table(table())
is that table() does not produce a table per se. One of the nice
things about Icon is that it takes care of pointers to structures
for you. The sometimes inconvenient byproduct of this convenience
is that, whether you know it or not, table() returns a pointer to
a structure. That means that every time you pull out an entry value
by saying:
sentence_table := master[bad_word]
you are yanking out a pointer to the same table. So no matter how
many entries you add to however many keys, you'll just be adding to
the one table, since all of your values are really pointers to the
same table. Sound confusing? Let's put it simply: If you ask Icon
to initialize all values in a table to "table()", you are saying
"Please initialize all values in the table you are creating to the
result of the expression 'table().' Since "table()" creates a table,
and produces that table (i.e. a pointer to that table), every value
in your table is automatically initialized with that pointer to the
one table!
Fix: Initialize entries to the default (&null, I believe), and then
every time you find a new bad_word, check to see if its value in the
table is &null. If so, add a copy of an empty table to the table
("copy(table())"). That will be unique. Also, please don't try
master := table(copy(table()))
or you'll be in for the same problem you started with. I'm afraid that
a copy of a table is as unique as the original table. You need to add
a new table each time you encounter a new bad_word.
Did this help? Would any of the wizards care to add anything?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From att!ihuxy!nowlin Thu Dec 1 07:33:37 1988
From: att!ihuxy!nowlin
Message-Id: <8812011433.AA03187@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA03187; Thu, 1 Dec 88 07:33:37 MST
Received: by att.ATT.COM (smail2.6 - att-cb)
id AA26757; 1 Dec 88 09:30:00 EST (Thu)
Message-Version: 2
>To: /addr=att!arizona!icon-group
Date: Thu 01 Dec 1988 08:30 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: att!arizona!icon-group
Subject: Re: problems with tables of tables
Ua-Message-Id: <post.nowlin.Thu 01 Dec 1988 07:31 CST>
End-Of-Protocol:
Content-Length: 2828
> From: Sean Boisen <sboisen@REGULUS.BBN.COM>
>
> ...
> My idea was to have a master table, whose entries would be "bad" words:
> then the value of each entry would be itself a table, with entries
> being the sentence number and values the sentence text. So i tried a
> piece of code something like this (irrelevant details omitted):
>
> procedure main()
>
> initial master := table(table())
This line creates a table called master with the property that every new
entry value will be initialized to a pointer to the same table. That's why
this happens:
> ... This doesn't work, however: the best was i can describe the
> failure is that sentence_table maintains the same value across
> different values of bad_word, in other words it accumulates ALL
> sentences, not just those specific to this particular bad_word.
The initial assignment in this group just points sentence_table at this
shared table. That's why any given bad_word entry value generates the
same results as another. In fact, if this worked the way you wanted, the
final assignment back to the master table would be redundant.
> sentence_table := master[bad_word]
> sentence_table[number] := sentence
> master[bad_word] := sentence_table
The workaround you used looks like the best way to do what you want and
isn't less elegant as far as I can tell.
> (by the way, the workaround i used was to keep a separate table of
> "found" bad_words, and if the bad_word wasn't there, explicitly assign
> a new table to sentence_table, i.e.
> sentence_table := table()
> This seemed to accomplish what i wanted, but less elegantly)
I'd try using a set of bad words instead of a table and then you can just
test to see if you've created a table for a given bad word by using the
member() built-in function. For example, I took the original code posted
and came up with the following program. I added some extra code to make it
functional since I don't like to post things I haven't actually run. I
hope this helps.
procedure main()
master := table()
bad_set := set([])
number := 0
while (line := read()) do
{
# I imagined this code to assign to sentence and number
number +:= 1
sentence := line
if bad_word := get_bad_word(line) then
{
if not member(bad_set,bad_word) then
master[bad_word] := table() & insert(bad_set,bad_word)
master[bad_word][number] := sentence
}
}
# added this to test
every bw := !bad_set do {
write("Bad Word: ",bw)
every s := !sort(master[bw]) do
write(" sentence ",right(s[1],3)," = '",s[2],"'")
}
end
# added this to test
procedure get_bad_word(l)
static words
initial words := &ucase ++ &lcase ++ &digits
l ? {
tab(upto(words))
w := tab(many(words))
}
return \w
end
Jerry Nowlin
(...!att!ihuxy!nowlin)
From sboisen@REGULUS.BBN.COM Thu Dec 1 07:58:10 1988
Message-Id: <8812011458.AA03618@megaron.arizona.edu>
Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA03618; Thu, 1 Dec 88 07:58:10 MST
To: goer <@bbn.com:goer@sophist.uchicago.edu>
Cc: icon-group@arizona.edu
In-Reply-To: Richard Goerwitz's message of Wed, 30 Nov 88 23:13:04 CST <8812010513.AA09107@sophist.uchicago.edu>
Subject: problems with tables of tables
From: Sean Boisen <sboisen@REGULUS.BBN.COM>
Sender: sboisen@REGULUS.BBN.COM
Reply-To: sboisen@bbn.com
Date: Thu, 1 Dec 88 9:49:14 EST
I'm glad the answer was obvious to Richard: it certainly wasn't to
me! If i've understood his explanation correctly the following rewrite
of the original should work:
procedure main()
initial master := table(table())
while (line := read()) do
{
# imagine some code here that assigns to sentence and number
# .....
if bad-word := get_bad_word(line) then
{
#### previously: sentence_table := master[bad_word]
sentence_table := ( \master[bad_word] | table() )
sentence_table[number] := sentence
master[bad_word] := sentence_table
}
}
end
I haven't actually tried this, but it looks superficially correct
given Richard's comments.
Two last points:
i've used table() instead of copy(table()), mostly because i couldn't
see what the extra copy would buy me (have i missed the point here?
would it be different if i used something like table([]) or table(0)
instead?).
extra credit for you conciseness fanatics, can the three lines inside
the 'if' be combined somehow?
Thanks for the help,
Sean
........................................
Sean Boisen -- sboisen@bbn.com
BBN Systems and Technologies Corporation, Cambridge MA
Disclaimer: these opinions void where prohibited by lawyers.
From R.J.Hare@EDINBURGH.AC.UK Thu Dec 1 12:54:37 1988
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA15977; Thu, 1 Dec 88 12:54:37 MST
Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Tue, 29 Nov 88 10:12 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 4375; Tue,
29 Nov 88 16:58:11 GMT
Date: 29 Nov 88 16:58:56 gmt
From: R.J.Hare@EDINBURGH.AC.UK
Subject: writing the name of an open file to another file
To: icon-group@arizona.edu
Via: 000015000048.FTP.MAIL; 29 NOV 88 16:58:07 GMT
Message-Id: <29 Nov 88 16:58:56 gmt 340785@EMAS-A>
I want to write the name of one file to another file, ie: I have something
like:
write(file1,s1,s2,s3,s4,file2,s5,s6,s7...)
The problem is that at the time of writing, file2 is open, so that instead of
the *name* of file2 being written to file1, followed by s5, etc., I am getting
s5, etc. written to file2.
Does anyone have any idea how I can do this without closing file2 prior
to the write statement?
Thanks.
Roger Hare.
From ralph Thu Dec 1 13:12:27 1988
Date: Thu, 1 Dec 88 13:12:27 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8812012012.AA17300@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA17300; Thu, 1 Dec 88 13:12:27 MST
To: R.J.Hare@EDINBURGH.AC.UK, icon-group@arizona.edu
Subject: Re: writing the name of an open file to another file
In-Reply-To: <29 Nov 88 16:58:56 gmt 340785@EMAS-A>
A value of type file in Icon has no specific relationship to the string
name of the file you used to create it. The thing to do is to keep
both the name and the file around. If you don't know what they are
specifically, you could use a table to look up the name, given the file.
In the simple case, do something like
file := open(filename, ...)
and do
write(s1,s2, ...,filename, ...)
In the case you don't know specifically what the name of the file is,
do
filetable := table()
.
.
.
file := open(filename, ...)
filetable[file] := filename
.
.
.
write(s1,s2, ...,filetable[file], ...)
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao}!arizona!ralph
From gudeman Thu Dec 1 13:58:05 1988
Date: Thu, 1 Dec 88 13:58:05 MST
From: "David Gudeman" <gudeman>
Message-Id: <8812012058.AA19836@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA19836; Thu, 1 Dec 88 13:58:05 MST
To: icon-group@arizona.edu
In-Reply-To: <8812012012.AA17300@megaron.arizona.edu>
Subject: getting the name of a file
Ralph suggested that if you want to know the name of a file, you can
keep it around in a table or a seperate variable. This is the most
efficient way to handle the problem, but there is a way to get the
name of a file if you haven't kept track of it:
f := open(fname, mode)
write(image(f)[6:-1])
will write out fname.
If a file f has been created with open(), then the expression image(f)
will produce the string "file(fname)", where fname is the name of the
file. This doesn't work for the built-in files: &input, et. al., so
you may want to include a check for those.
From kwalker Thu Dec 1 14:57:32 1988
Date: Thu, 1 Dec 88 14:57:32 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <8812012157.AA24031@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/14)
id AA24031; Thu, 1 Dec 88 14:57:32 MST
In-Reply-To: <8812011458.AA03618@megaron.arizona.edu>
To: icon-group
Subject: Re: problems with tables of tables
> From: Sean Boisen <sboisen@REGULUS.BBN.COM>
> Date: Thu, 1 Dec 88 9:49:14 EST
>
> I'm glad the answer was obvious to Richard: it certainly wasn't to
> me!
You have just run into one of the classical Icon programming errors. For
those of us who have made the mistake ourselves and seen others make it,
it has become easy to spot.
> procedure main()
>
> initial master := table(table())
you want
master := table()
or if you want to be explicit about the default value
master := table(&null)
[rest of program deleted]
> i've used table() instead of copy(table()), mostly because i couldn't
> see what the extra copy would buy me (have i missed the point here?
You are correct; the copy is not needed.
> extra credit for you conciseness fanatics, can the three lines inside
> the 'if' be combined somehow?
when faced with this problem, I use code something like
/master[bad_word] := table()
master[bad_word][number] := sentence
With strategically placed parentheses and an alternation, I belive this
can be combined on one line, but I wouldn't call it good programming
style. Does anyone see an elagant "one liner"?
Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker
From @uxc.cso.uiuc.edu:willr@ncsa.uiuc.edu Thu Dec 1 15:18:51 1988
Received: from UXC.CSO.UIUC.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA25393; Thu, 1 Dec 88 15:18:51 MST
Received: from pluto.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP
(5.60+/IDA-1.2.5) id AA25446; Thu, 1 Dec 88 16:17:29 CST
Return-Path: <willr@ncsa.uiuc.edu>
Received: by pluto.ncsa.uiuc.edu (4.0/NCSA-1.2)
id AA01345; Thu, 1 Dec 88 16:20:22 CST
Date: Thu, 1 Dec 88 16:20:22 CST
From: willr@ncsa.uiuc.edu (Will Ridenour)
Message-Id: <8812012220.AA01345@pluto.ncsa.uiuc.edu>
To: icon-group@arizona.edu
Subject: writing a file name to another file
Cc: willr@pluto.ncsa.uiuc.edu
:Date: 29 Nov 88 16:58:56 gmt
:From: R.J.Hare@EDINBURGH.AC.UK
:Subject: writing the name of an open file to another file
:
:I want to write the name of one file to another file, ie: I
:have something like:
:
:write(file1,s1,s2,s3,s4,file2,s5,s6,s7...)
:
:The problem is that at the time of writing, file2 is open,
:so that instead of the *name* of file2 being written to
:file1, followed by s5, etc., I am getting s5, etc. written
:to file2.
:
:Does anyone have any idea how I can do this without
:closing file2 prior to the write statement?
:
:Thanks.
:
:Roger Hare.
please don't be offended. this is rather like asking "is is plugged in?"
but any successful troubleshooter checks the plug first and the power
switch next.
the question is where does the variable file2 come from? If it's a
string like file2 := "foo" then someone else will have to check the
power switch for you.
but if the value for file2 came from something like:
file2 := open("foo","rw") then the value of your variable file2 is not
a filename at all but a file descriptor (pointer/handle, whatever). &
my understanding of icon is that if you pass write() a file descriptor
it will try to write something to that file.
otherwise unless there is something i don't know about icon (& there
is a lot) your example should work as you intended.
will ridenour
national center for supercomputing applications
University of Illinois
Champaign, Illinois willr@ncsa.uiuc.edu (internet) 792@ncsavmsa (bitnet)
From nolan@umbc3.UMD.EDU Tue Dec 6 20:34:57 1988
Received: from umbc3.umd.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
id AA20175; Tue, 6 Dec 88 20:34:57 MST
Received: by umbc3.UMD.EDU (5.54/umd.04)
for icon-group@arizona.edu id AA04939; Tue, 6 Dec 88 22:33:01 EST
Date: Tue, 6 Dec 88 22:33:01 EST
From: Mr. John Nolan (NSA) <nolan@umbc3.UMD.EDU>
Message-Id: <8812070333.AA04939@umbc3.UMD.EDU>
To: icon-group@arizona.edu
Subject: Some Icon problems with SunOS 4.0
I just tried to recompile Icon Version 7 on a Sun 3/280 under SunOS 4.0
and ran into 2 problems.
Firstly, the value of MaxHdr (in define.h) had to be increased to 20000
in order not to get completely fatal run time errors.
Secondly, several tests (i.e. expr74, expr76, expr79, and expr11) have
one line which gives incorrect results.
Since SunOS 4.0 has been shown to be brain damaged enough to prompt Sun
to bring out a SunOS 4.0.1 (containing mostly bug fixes), I am not
quite worried about these problems (yet), but subtle bugs in code that
you are running may be explained by the above. Please note that these
problems do not appear when running SunOS 3.5. Also the source is original
version7 source and may have been fixed in the new Version 7.5.
I will (soon) install the new OS and will report results. If anyone has
a temporary workaround, please let me know.
John Nolan
nolan@umbc3.umd.edu
From dscargo@cim-vax.honeywell.com Thu Dec 8 08:46:46 1988
Message-Id: <8812081546.AA21978@megaron.arizona.edu>
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA21978; Thu, 8 Dec 88 08:46:46 MST
Date: 7 Dec 88 14:48:00 CST
From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
Subject: Binary input for Icon
To: "icon-group" <icon-group@arizona.edu>
Having gotten to the point where I like to used Icon for everything, I've
wondered about using Icon for doing things like reading TIFF and various
flavors of PAINT file formats. What I don't know is how to read binary files,
especially files containing 1 byte, 2 byte, and 4 byte integer quantities.
This may be another dumb idea on my part. Has there been any thought
given to reading files containing only binary and no character data? (I
suppose I'm trying to avoid learning to write C programs, where I've got to
allocate memory and manage pointers myself.)
I suppose I could write an Icon program that does a binary to hex conversion,
and then uses that as input to another program, but I'd rather avoid that.
I suppose I'd like to have binary objects that are indexed only by integer
indices. To create TIFF files, having the ability to do sublists, sorting
(of binary data), and concatenation of binary objects would be very handy.
David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
From gmt Fri Dec 9 13:45:10 1988
Date: Fri, 9 Dec 88 13:45:10 MST
From: "Gregg Townsend" <gmt>
Message-Id: <8812092045.AA03853@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/15)
id AA03853; Fri, 9 Dec 88 13:45:10 MST
To: icon-group
Subject: Re: Binary input for Icon
Icon doesn't provide specific functions for binary input or output.
It can be done on most systems using other builtin functions, though
it is a bit tedious.
The builtin function reads(f,i) reads exactly n bytes from file f,
giving no special interpretation to newlines or nulls or anything else.
Ord(s) converts a byte to its integer value, and multibyte integers
can be built using ishift(i,j) and ior(i,j).
Output can be done similarly, breaking integers into 8-bit values using
ishift(i,j) and iand(i,16rFF), then converting to character using char(i).
seek(f,i) will also be useful for reading TIFF files; keep in mind that
Icon numbers the bytes of a file beginning at 1 and not 0.
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@Arizona.EDU 110 57 16 W / 32 13 45 N / +758m
From sunquest!whm Wed Dec 14 21:56:52 1988
Received: by megaron.arizona.edu (5.59-1.7/15)
id AA12192; Wed, 14 Dec 88 21:56:52 MST
Date: Wed, 14 Dec 88 21:54:01 MST
From: "Bill Mitchell" <sunquest!whm>
Message-Id: <8812150454.AA25146@sunquest>
Received: by sunquest; Wed, 14 Dec 88 21:54:01 MST
To: arizona!icon-group
Subject: Re: Binary input for Icon
I once did some lobbying for ord() and char() to be able to handle multibyte
quantities, but I was unable to generate any support for my position. I still
think it makes sense.
--------------------------------------------------------------------
Bill Mitchell whm@sunquest.com
Sunquest Information Systems sunquest!whm@arizona.edu
Tucson, AZ {arizona,uunet}!sunquest!whm
602-885-7700
From alk@ux.acss.umn.edu Thu Dec 15 00:12:15 1988
Message-Id: <8812150712.AA18448@megaron.arizona.edu>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA18448; Thu, 15 Dec 88 00:12:15 MST
Return-Path: alk@ux.acss.umn.edu
Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Thu, 15 Dec 88 00:14 MST
Received: from ux.acss.umn.edu by UMNACVX.BITNET; Thu, 15 Dec 88 01:04 CST
Date: Thu, 15 Dec 88 1:06:48 CST
From: alk@ux.acss.umn.edu
Subject: Re: Re: Binary input for Icon
Sender: alk@ux.acss.umn.edu
To: icon-group@arizona.edu
Well, M. Mitchell, here's one voice of support for your position.
--------------
Anthony L. Kimball, U of Mn Academic Computing Services and Systems.
alk@ux.acss.umn.edu alk@UMNACVX
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Thu Dec 15 09:16:37 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA10076; Thu, 15 Dec 88 09:16:37 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA14349; Thu, 15 Dec 88 10:19:28 CST
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA02852; Thu, 15 Dec 88 10:09:11 CST
Date: Thu, 15 Dec 88 10:09:11 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8812151609.AA02852@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: char(), ord()
Let's think about this.
Just how would one go about constructing a char() or ord()
that handled whole strings? First of all, it would need to
be a generator, that is, if we desire self-consistency within
the language. It would be kind of like:
every ord(!s)
Instead, you'd write -
every ord(s)
The problem is that ord() acts logically on one character.
It's not like find() or upto(), but rather like any(). And
it makes little sense to make an any() that hops through strings,
one character at a time. If it did, you'd have to use limit-
ation expressions every time you wanted to check the first char-
acter in a line!
I suppose one could have char() or ord() return several words
at once, all jammed together. I.e. it could return the binary
value of strings, with the bits strung out into one long chain.
But isn't this a bit exotic, especially since most people are
going to be using the data one char or word at a time? And besides,
what would the type of the result be? Would it be a huge in-
teger? A string? And what of the reverse? If you go from binary
to character, where do you divide bits? I mean, how does Icon
know that the machine it's running on has a sixteen or thirty-two
bit word? This whole idea seems a bit outlandish to me. And since
it's no trouble to write "every ord(!s)" instead of "every ord(s)",
why change things - especially when one logically expects ord() and
char() to operate on short integers and characters individually?
Actually, now that I think about it, there have been times where
I would have liked to manipulate long strings of 0's and 1's
(e.g. when decoding Huffmon-encoded materials). Maybe this will
seem silly, but I would have liked the R one uses in specifying
radix literals to act like an infix operator, so I could convert
integers to base two, and then ask Icon to convert the result to
a string.
I do hope that some of the icon-project folks will enlighten me
on some of these points, since I am probably only demonstrating
ignorance here.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From sunquest!whm Thu Dec 15 11:26:33 1988
Received: by megaron.arizona.edu (5.59-1.7/15)
id AA19584; Thu, 15 Dec 88 11:26:33 MST
Date: Thu, 15 Dec 88 11:23:44 MST
From: "Bill Mitchell" <sunquest!whm>
Message-Id: <8812151823.AA27228@sunquest>
Received: by sunquest; Thu, 15 Dec 88 11:23:44 MST
To: arizona!icon-group
Subject: Re: char(), ord()
For strings that represent more bits than Icon can hold in an integer,
multibyte char() and ord() are hard to imagine; I was thinking in terms
of char and ord handling 2- and 4-byte quantities. So for example, ord("ABCD")
would return an integer and char(ord("ABCD"),4) would return "ABCD". One
problem is how to deal with the byte ordering differences in little-endian
and big-endian machines. The thing that seems most natural to me is to
have char() and ord() do what's natural on a machine by machine basis.
For example, on the VAX, ord("\x00\x00\x00\x01") would return 16777216, but
on the Sun it would return 1.
An optional argument could be used to explicitly specify big- or little-endian
interpretation.
I think this is a natural extension of char and ord and a big time-saver:
you need 10 procedure calls of ord, ior, and ishift (according to my count)
to do the equivalent of ord("ABCD").
From munck@mbunix.mitre.org Mon Dec 19 15:05:19 1988
Received: from MBUNIX.MITRE.ORG by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA18194; Mon, 19 Dec 88 15:05:19 MST
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
To: ICON-Group@arizona.edu
Reply-To: munck@mbunix.mitre.org, munck@MITRE.ARPA
Return-Receipt-To: munck@mbunix.mitre.org
Subject: ICON as user customization language
Date: Mon, 19 Dec 88 17:04:42 EST
Message-Id: <8632.598572282@mbunix>
From: Bob Munck <munck@mbunix.mitre.org>
After two decades, I'm interested in continuing the Hypertext work
we started at Brown. In particular, I want to look into hypertext-like
asynchronous teleconferencing over the Internet. As an enthusastic user
of Final Word/SPRINT, I'm much taken with the idea of building interactive
systems around an underlying and user-accessible programming language,
in the way that the original EMACS was built around LISP and SPRINT is
built around <strange internal language>.
It seems to me that ICON would be ideal as the internal language of
a hypertext system, since most of the work is character processing. Has
ICON ever been used this way? That is, I'd implement the hypertext
support in ICON, but also allow users to modify and add to the program.
The structure would probably involve attaching routines to individual
key-presses, as in EMACS. I'd appreciate any comments on the idea
and pointers to existing work.
-- Bob <Munck@mitre.org>, ..!linus!munck,
-- MITRE Corporation, 617/271-3671
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Thu Dec 22 21:33:54 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA13040; Thu, 22 Dec 88 21:33:54 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA26752; Thu, 22 Dec 88 22:37:10 CST
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA02158; Thu, 22 Dec 88 22:26:26 CST
Date: Thu, 22 Dec 88 22:26:26 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8812230426.AA02158@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: move(1) vs. |move(1)
(Naive?) question: Why are
while move(1) do { ...
and
every |move(1) do {
not equivalent?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From ralph Thu Dec 22 22:20:25 1988
Date: Thu, 22 Dec 88 22:20:25 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8812230520.AA14228@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/15)
id AA14228; Thu, 22 Dec 88 22:20:25 MST
To: goer@sophist.uchicago.edu, icon-group@arizona.edu
Subject: Re: move(1) vs. |move(1)
In-Reply-To: <8812230426.AA02158@sophist.uchicago.edu>
The argument of while is "bounded" -- suspended generators
are discarded.
If that sounds mystical, don't be put down. Your question
touches the heart of expression evaluation in Icon. Described
properly (which I'm not prepared to do here), it's all "obvious".
Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 6609 ralph@Arizona.EDU {uunet|allegra|noao}!arizona!ralph
From ralph Fri Dec 23 05:27:52 1988
Date: Fri, 23 Dec 88 05:27:52 MST
From: "Ralph Griswold" <ralph>
Message-Id: <8812231227.AA25510@megaron.arizona.edu>
Received: by megaron.arizona.edu (5.59-1.7/15)
id AA25510; Fri, 23 Dec 88 05:27:52 MST
To: goer@sophist.uchicago.edu
Subject: Re: move(1) vs. |move(1)
Cc: icon-group
In-Reply-To: <8812230535.AA02229@sophist.uchicago.edu>
The information is in the Icon book, but not in a very obvious way.
The point is this: move(1) increments &pos, but it suspends (like
find(s)). It does this not so that it can produce another result if it's
resumed (there is only one way to increment &pos by 1), -- but rather to
restore &pos to its previous position (data backtracking). See p. 126 in
the Icon book.
On other hand, the control clause of while-do is bounded (that particular
term is not used in the Icon book -- see p. 119). In a bounded expression,
suspended generators are discarded, once a result is produced. Thus, in
while move(1) do ...
the change to &pos by move(1) is irreversible, since move(1) can't be resumed.
In every-do, on the other hand, the control clause is not bounded -- in fact,
the control clause must be able to generate a sequence of results for every-do
to have the effect it does. Thus, in
every |move(1) do ...
move(1) is resumed after the do clause is evaluated. It restores &pos, and
then repeated alternation causes move(1) to be evaluated again, with the same
value of &pos as before -- an endless loop.
The problem in understanding this probably is not in what while-do does --
most folks find that to be what they expect. It's in every-do that the
problem with understanding arises. A simple prescription that will do
for most cases is "don't use every-do in string scanning". That may keep you
out of trouble, but a deeper understanding of expression evalation in
Icon will show you both why you usually don't want to use every-do in
string scanning and also why you sometimes might want to.
Quiz: Assuming s := "Hello world!", what does the following expression
write?
every write(s ? move(1 to 10))
cd
From @sphinx.uchicago.edu:goer@sophist.uchicago.edu Fri Dec 23 08:20:44 1988
Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA01434; Fri, 23 Dec 88 08:20:44 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
id AA05554; Fri, 23 Dec 88 09:24:09 CST
Return-Path: <goer@sophist.uchicago.edu>
Received: by sophist.uchicago.edu (3.2/UofC3.0)
id AA02632; Fri, 23 Dec 88 09:13:23 CST
Date: Fri, 23 Dec 88 09:13:23 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Message-Id: <8812231513.AA02632@sophist.uchicago.edu>
To: icon-group@arizona.edu
Subject: matching expressions
The real key to my understanding the difference between
while move(1)
and
every |move(1)
was the realization that move(1) acts like the matching expressions des-
cribed on page 158-9 in the Icon book. In other words, one of the things
it does is to restore &pos to its original value if resumed. In the ex-
pression
every |move(1)
move(1) is repeatedly resumed. And each time this happens, the value of
&pos is restored. Hence an infinite loop results. With while move(1),
on the other hand, no resumption occurs. As Ralph Griswold explained it,
the result sequence is discarded, and &pos keeps its new value.
As for what
every write("Hello world." ? move(1 to 10))
does, we just note that "every" wants a result sequence. The result se-
quence of "1 to 10" is the integers from 1 to 10. Since move() will in
fact restore &pos to 1 each time it is resumed for another result, the
effect will be to write out "Hello world."[1:1] then "Hello world."[1:2],
and so on, up to "Hello world."[1:10].
Many thanks to Icon's creator, Ralph Griswold, for the reply. I had
thought that I had gotten the while/every difference nailed down. This one
really crept up on me! I hope that this brief exchance has helped others
out there who have gotten similarly befuddled.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
rutgers!oddjob!gide!sophist!goer
From @multimax.encore.com:pierson@mist.encore.com Wed Dec 28 13:22:53 1988
Received: from MULTIMAX.ENCORE.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
id AA09020; Wed, 28 Dec 88 13:22:53 MST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00293; Wed, 28 Dec 88 15:21:38 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA10030; Wed, 28 Dec 88 15:21:36 EST
Message-Id: <8812282021.AA10030@mist.>
To: icon-group@arizona.edu
Subject: Unix V7.5 Release Doc Bugs
Date: Wed, 28 Dec 88 15:21:34 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Hi folks,
I snarfed the 7.5 release from arizona.edu and started by printing
the docs (using psroff). The following problems showed up
immediately:
"s.cov" is missing.
This causes a troff fatal error.
TR88-6, TR88-7, TR88-41:
troff: Can't open /usr/lib/font/devpsc/M.out
TR88-8
troff: Can't open /usr/lib/font/devpsc/ZI.out
Many copies of these messages, but they all print anyway.
Can you suggest substitute fonts? What are these fonts
anyway?
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@multimax.encore.com