jiml@uwmacc.UUCP (Jim Leinweber) (01/17/85)
Some enquiries about SNOBOL under Unix have surfaced recently in
net.wanted and net.lang. I don't personally know of a SNOBOL
implementation, but there is a wonderful grandchild of SNOBOL running
under Unix, namely Icon. A recent version runs under V7 and BSD 4.?
on PDP11/70's and Vaxen; earlier versions run on many others as well.
Icon is an offspring of the same Ralph Griswold of SNOBOL fame, and can
be described in an oversimplified way as `SNOBOL meets structured
programming'. It has untyped variables, associative tables, automatic
storage assignment and reclamation, and string scanning operations,
much in the manner of SNOBOL. It also has lists with flexible access,
records, and modern control structures, such as recursion, procedures,
nesting loops, IF's, etc.
In place of SNOBOL's pattern matching operations, failure-driven
alternation and co-expressions (co-routines which can pass and return
values) are provided as additional control structures. These are
completely integrated into the language, and have *great* expressive
power.
The result is programs 5% the size of comparable ones in, say, Pascal;
but with more power and much better readibility than SNOBOL. I prefer
Icon to PROLOG too.
For more information, try /usr/src/new/icon on BSD 4.2 systems, or
icon-project@arizona.UUCP (via gi, mcnc, ucbvax, utah-cs)
icon-project.arizona@rand-relay (CS-NET, ARPA)
A book `The Icon Programming Language', by Ralph & Madge Griswold,
is available from Prentice-Hall.
Jim Leinweber
UUCP: ...!{allegra,ihnp4,seismo,...}!uwvax!uwmacc!jiml
ARPA: uwmacc!jiml@wisc-rsch.arpa
POST: MACC, UW-Madison, 1210 W. Dayton St., Madison, Wi, 53706david@ukma.UUCP (David Herron, NPR Lover) (01/24/85)
If Icon is a successor, then why did you use a -- operator? :-)
ndiamond@watdaisy.UUCP (Norman Diamond) (01/25/85)
> If Icon is a successor, then why did you use a -- operator? :-)
Don't forget that (Icon--) has the same value as (Icon), and it is a worthy
successor. After a while, as language design continues to improve, Icon's
relative worth will decline; hence the value of Icon should decrease after
sufficient usage. (:-)++)
-- Norman Diamond
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa
"Opinions are those of the keyboard, and do not reflect on me or higher-ups."joe@petsd.UUCP (Joe Orost) (01/29/85)
Icon looks good, so we got the distribution tape. The trouble is that the
"interpreter" is written in VAX assembly code - not "C". Does anybody have
a copy of the "interpreter" written in "C"?
regards,
joe
--
Full-Name: Joseph M. Orost
UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe
US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724
Phone: (201) 870-5844
Location: 40 19'49" N / 74 04'37" Wasente@Cascade.ARPA (02/06/85)
I've been doing a little programming in Icon lately and I might me tempted to call it a worthy successor to APL with all those confusing operators. The worst part seems to be the operator precedence--you have to parenthesize everything since it's impossible to remember all the precedence levels and they aren't at all intuitive. I'd have much preferred just a few levels of precedence in addition to the ones we all know and love, and then putting the unusual operators together in them. I wouldn't really call it "Snobol meets structured programming," because I find I do things quite differently than I do in Snobol. After I've used it a little more I'll be able to give a real opinion on the language; all I can say now is "Hard to learn." -paul asente asente@cascade.ARPA decwrl!glacier!cascade!asente
chris@byucsa.UUCP (Chris J. Grevstad) (02/06/85)
<>
We are running ICON here (4.2BSD) and it compiles abysmally slow!
We use it for our programming languages class.
--
Chris Grevstad
{ihnp4,noao,mcnc,utah-cs}!arizona!byucsa!chris
If things don't change they will probably remain the same.whm@arizona.UUCP (Bill Mitchell) (02/06/85)
> > We are running ICON here (4.2BSD) and it compiles abysmally slow! > We use it for our programming languages class. > > Chris Grevstad > {ihnp4,noao,mcnc,utah-cs}!arizona!byucsa!chris Your comment is a little vague, but a couple of comments are in order. First of all, if you're using the Icon compiler, throw it away. UNIX Icon was first implemented as a compiler, turning Icon programs into assembly language that was then assembled and linked against a huge run-time library. It worked, but was very slow. In response to this problem, the compiler was cloned and turned into an interpretive system in which the Icon translator and linker produce an interpretable file that the Icon interpreter can run to effect program execution. The Icon interpreter is probably an order of magnitude faster than the compiler wrt. to producing an executable unit and program execution is usually no worse than 10% slower. About a year ago, the maintenance overhead for the compiler began to outweigh the benefits and the compiler was deleted from the distribution. The Icon system on 4.2bsd has both the compiler and the interpreter, but there's really no reason to even think about using the compiler if you're using it for a programming languages class. (The only good reason to use the compiler is to incorporate C subroutines and the current release of Icon has an alternate means of doing this.) If you're already using the interpreter and used the term "compiles" to mean the production of the interpretable file, I have fewer answers. We've improved the speed of the system a bit since the 4.2 release, but it's not a lot faster. I *think* the current speed of the translator is about 50 lines/second on a 780 and while that's not smoking, I don't think it's much worse than the C compiler. And after all, it's only the first implementation; give us a break! Bill Mitchell Icon Project The University of Arizona whm.arizona@csnet-relay {ihnp4,noao,mcnc,utah-cs}!arizona!whm p.s. The proper way to spell Icon is I-c-o-n, not I-C-O-N.