From icon-group-sender Thu Aug 18 20:53:54 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 05:34:01 MST To: icon-group-l@cs.arizona.edu Date: 18 Aug 1994 20:53:54 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <331aci$gn3@baskerville.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Subject: A small but (hopefully) helpful utility Errors-To: icon-group-errors@cs.arizona.edu Today, I decided to start my own personl library of icon routines. This change introduced a bug: all of a sudden, I was getting an "undeclared identifier" error on a call to one of my library routines. After much checking of environment variables and directory contents, it occurred to me that my library code might just be shadowed by an "official" library file. Sure enough, that was the case. So I wrote the appended little program to check where a particular library file is. Usage is wil (wil == Which Icon Library). Names should be as they appear in the link statement (ie, no trailing .u1, .u2, or .icn). The program will then print out where it finds each name (including multiple occurrences. Bugs: this will break on file names with white spaces in them, and is Un*x-specific. Feel free to let me know if you find any other problems... $define SPACES ' \t\n\r\v' procedure search( path, names ) local f, name if path[-1] ~== "/" then path ||:= "/" every name := !names do { if f := open(path || name || ".u1", "r") then { write( path || name ) close(f) } } return end procedure main( args ) local IPATH IPATH := \getenv("IPATH") | stop( "Can't read IPATH environment variable" ) IPATH ? { while tab(upto(~SPACES)) do search( tab(many(~SPACES)), args ) } search( ".", args ) end From icon-group-sender Fri Aug 19 05:47:30 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 05:35:49 MST Date: Fri, 19 Aug 1994 05:47:30 -0600 (CST) From: Chris Tenaglia | 456-8765 Subject: Re: Simple syntax? A definition? To: mslamm@pluto.mscc.huji.ac.il Cc: icon-group@cs.arizona.edu Message-Id: <01HG2Z73GWN68WVZ0T@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"mslamm@pluto.mscc.huji.ac.il" X-Vms-Cc: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu Around 1985 I had developed a plain language operating system for an IBM 360/20 compatible. I had just read an Apple Computer user interface guide about the goal of a good user interface is not fewer keystrokes, but rather brain strokes. Apple was thinking MAC but I was thinking PLOS. The command line was everything. Instead of learning menus, transaction numbers, or flagging options you just had to memorize a group of applicable sentences. Each program was responsible for parsing the command line. For example the backup command was SAVE. Here are some samples: SAVE ALL TO TAPE 1 * FULL BACKUP SAVE SOME TO TAPE 2 * INCREMENTAL BACKUP SAVE ALL FROM TAPE 2 * FULL RESTORE SAVE 6400 TO 10000 FROM TAPE 1 * SELECTIVE RESTORE (NO FILE SYSTEM YET) Easy to parse. Easy to remember. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)456-8765 | tenaglia@mis.mcw.edu > From: IN%"mslamm@pluto.mscc.huji.ac.il" 18-AUG-1994 17:50:28.18 > To: IN%"icon-group-l@cs.arizona.edu" > Subj: Simple syntax? A definition? > Following the recent thread on perl vs. Icon, and posts about UNIX > *tools* I started thinking on how one can define what are the good > qualities a synatx should have. > It appears to me that what counts is simplicity. A simple syntax would be > one that can easaly be built (NOT parsed) by programs (so that the > language can be used as a tool interface). It would also be easy for > humans (that's us!) to learn and use. > Does anyone have suggestions on how to define this in a more mathematical > or precise way? I thought about YACC clauses/sentence. But I am not sure > it's enough because the YACC approach narrows you down to LALR. > I thought one criterion can be PROXIMITY - that is that semantically > related elements should be near each other. Any others? > Ehud Lamm == mslamm@pluto.mscc.huji.ac.il "My home is not a page!" From icon-group-sender Fri Aug 19 09:32:45 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 07:25:38 MST To: icon-group-l@cs.arizona.edu Date: 19 Aug 1994 09:32:45 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <332c9t$7it@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: <331aci$gn3@baskerville.cs.arizona.edu> Subject: Re: A small but (hopefully) helpful utility Errors-To: icon-group-errors@cs.arizona.edu In article <331aci$gn3@baskerville.cs.arizona.edu>, Dave Schaumann wrote: IPATH ? { while tab(upto(~SPACES)) do search( tab(many(~SPACES)), args ) } search( ".", args ) end Don't icont and iconc search the cwd ('.') first? There's another bug... Nick From icon-group-sender Fri Aug 19 13:35:02 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 07:25:58 MST To: icon-group-l@cs.arizona.edu Date: Fri, 19 Aug 1994 13:35:02 GMT From: mcarroll@watson.ibm.com (Mark Chu-Carroll) Message-Id: Organization: IBM T.J. Watson Research Sender: icon-group-request@cs.arizona.edu References: <330a3u$3vq@shum.cc.huji.ac.il> Subject: Re: Simple syntax? A definition? Errors-To: icon-group-errors@cs.arizona.edu >>>>> "Zvi" == Zvi Lamm writes: In article <330a3u$3vq@shum.cc.huji.ac.il> mslamm@pluto.cc.huji.ac.il (Zvi Lamm) writes: Zvi> Following the recent thread on perl vs. Icon, and posts about Zvi> UNIX *tools* I started thinking on how one can define what are Zvi> the good qualities a synatx should have. It appears to me that Zvi> what counts is simplicity. A simple syntax would be one that can Zvi> easaly be built (NOT parsed) by programs (so that the language Zvi> can be used as a tool interface). It would also be easy for Zvi> humans (that's us!) to learn and use. Zvi> Does anyone have suggestions on how to define this in a more Zvi> mathematical or precise way? I thought about YACC Zvi> clauses/sentence. But I am not sure it's enough because the YACC Zvi> approach narrows you down to LALR. Zvi> I thought one criterion can be PROXIMITY - that is that Zvi> semantically related elements should be near each other. Any Zvi> others? I've been thinking about this somewhat lately, because my dissertation work involves adding parallel programming constructs to sequential languages, and I want to do so in a *clear* way. The things that I've come up with so far are: <1> Unambiguous - for a human reader, it helps a *lot* if there's only one correct reading of an element. <2> Orthogonal - different constructs should look different. (closely related to <1>. If I look at a construct, I should be able to tell what it does with minimal knowledge about context. if x = a is an assignment statement, then x=a shouldn't also be a comparison in a different context.) <3> Minimal - the less "noise" there is in the syntax the better. (ie, COBOL is *bad*, because it's very hard to isolate the meaningful text from all of the excess garbage.) <4> Proximity - I agree with you, it's very important that related elements be near each other. <5> Seperation - clauses should be visibly seperated. (This applies to things like the different branches of an if statement. Lisp style if's can be bad, because it's hard to see where the "then" part ends and the "else" part begins. <6> Legible - using a large number of bizzare symbols makes a program much harder to read. (Look at a one-liner in APL, compared to a program in J with the primitives aliased to english words. Both can provide a beautiful, elegant solution to a problem. But almost anyone can read the J program given a 5 minute introduction to the language, and the APL program can take an expert time to decode.) From icon-group-sender Fri Aug 19 17:44:37 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 08:57:15 MST Date: Fri, 19 Aug 1994 17:44:37 +0300 (WET) From: Zvi Lamm Subject: Backtracking and reversible assigment To: icon-group@cs.arizona.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Can anyone explain+give a usefull example of the use of <- and complex backtracking in general? (Only examples in Icon will be accepted here..) From icon-group-sender Fri Aug 19 14:45:16 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 08:57:50 MST To: icon-group-l@cs.arizona.edu Date: Fri, 19 Aug 1994 14:45:16 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: <330a3u$3vq@shum.cc.huji.ac.il> Subject: Re: Simple syntax? A definition? Errors-To: icon-group-errors@cs.arizona.edu Zvi Lamm (mslamm@pluto.cc.huji.ac.il) wrote: : Following the recent thread on perl vs. Icon, and posts about UNIX : *tools* I started thinking on how one can define what are the good : qualities a synatx should have. : It appears to me that what counts is simplicity. A simple syntax would be : one that can easaly be built (NOT parsed) by programs (so that the : language can be used as a tool interface). It would also be easy for : humans (that's us!) to learn and use. : Does anyone have suggestions on how to define this in a more mathematical : or precise way? I thought about YACC clauses/sentence. But I am not sure : it's enough because the YACC approach narrows you down to LALR. I don't know how to define simplicity in a language. But I would really like to know how far out on the complexity end of that scale C++ falls. While considering and comparing the complexity of languages, you might also want to think about the complexity of built in functions, the number and complexity of operators, and the complexity of any commonly used libraries. For example, the standard C library is extensive, but any given part of it seems reasonably easy to learn. In contrast, I find C++ class libraries very complex, not just because they are large, but because of the connections (subclassing, overloaded functions, virtual pure functions that *must* be implemented, etc.) One aspect of Icon's complexity is in its rich set of operators and built in functions. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Fri Aug 19 17:49:25 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 08:57:31 MST Date: Fri, 19 Aug 1994 17:49:25 +0300 (WET) From: Zvi Lamm Subject: Simple synatx To: icon-group@cs.arizona.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu I was thinking about a mechanical way to decide between to synatxes which one is simpler. The idea is to make the definition as precise as possible, and see what we can learn. Do you think this is at all possible? What bothers me is the differance between the way a computer parses and the way people do. This raises the question - simple synatx for whom? *Ehud Lamm* From icon-group-sender Fri Aug 19 10:19:34 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 08:58:13 MST Date: Fri, 19 Aug 94 10:19:34 CDT From: "Richard L. Goerwitz" Message-Id: <9408191519.AA08912@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: wil Errors-To: icon-group-errors@cs.arizona.edu Why not just use a shell script or something? You get wild cards that way and other natural byproducts of doing things in a Unix-like manner: : #! /bin/sh # # Simple shell script to locate Icon source and object files # if test .$1 = . then echo "`basename $0`: no filename!" exit 2 fi bname=`basename $1 .icn` for i in ${IPATH:-'.'} $LPATH do if test -f ${i}/${bname}.u1 then ls ${i}/${bname}.u1 exit 0 fi if test -f ${i}/${bname}.icn then ls ${i}/${bname}.icn exit 0 fi done exit 1 From icon-group-sender Fri Aug 19 09:10:09 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 09:32:07 MST Date: Fri, 19 Aug 94 09:10:09 PDT From: kwalker@sirtur.premenos.com (Ken Walker) Message-Id: <9408191610.AA01868@sirtur.premenos.com> To: icon-group@cs.arizona.edu Subject: Re: Simple synatx X-Sun-Charset: US-ASCII Content-Length: 949 Errors-To: icon-group-errors@cs.arizona.edu > Date: Fri, 19 Aug 1994 17:49:25 +0300 (WET) > From: Zvi Lamm > > I was thinking about a mechanical way to decide between to synatxes which > one is simpler. The idea is to make the definition as precise as > possible, and see what we can learn. > Do you think this is at all possible? What bothers me is the differance > between the way a computer parses and the way people do. This raises the > question - simple synatx for whom? > > *Ehud Lamm* That's a good question. If you are really interested in what constitutes a simple syntax for people, you should not try to define it. You should define how people react to a simple syntax. From there you can form hypotheses about the characterists of a simple syntax, and, if you are into human factors research, you can perform experiments to test you hypotheses. (I'm not into human factors research so I'll stick to unsubstantiated speculation :-). Ken From icon-group-sender Fri Aug 19 11:28:50 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 09:32:37 MST Date: Fri, 19 Aug 94 11:28:50 CDT From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9408191628.AA29236@runner.utsa.edu> To: kohl@nova.umd.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (message from John Kohl on Thu, 18 Aug 1994 16:03:41 -0400 (EDT)) Subject: Re: Graphic Icon on PCs? Content-Length: 635 Errors-To: icon-group-errors@cs.arizona.edu John Kohl writes: Does the graphics version of Icon work on X-servers on PCs? An Icon *client* running on a platform for which Icon supports X (mainly UNIX and VMS boxes) should work with any X server that has a valid network connection and can run other X clients where Icon would run. I know of no one who was ported Icon's X support to run clients locally on a PC operating system other than UNIX. Theoretically Icon could be built for Desqview/X (for example), but we don't have the software or human resources to do it. Clint Jeffery cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Fri Aug 19 10:05:22 1994 Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 10:35:12 MST Date: Fri, 19 Aug 1994 10:05:22 +0700 From: swampler@noao.edu Message-Id: <9408191705.AA24746@orpheus.gemini.edu> Subject: Re: Backtracking and reversible assigment To: icon-group@cs.arizona.edu Content-Length: 3786 Errors-To: icon-group-errors@cs.arizona.edu You wrote: >>Can anyone explain+give a usefull example of the use of <- and complex >>backtracking in general? (Only examples in Icon will be accepted here..) >> Hmmm, by useful, I assume you're ruling out the 8-queens program in the Icon book (also found in the IPL)? I don't know if I can provide much - I think that you mean 'data backtracking' when you say 'complex' backtracking (since that's what <- provides). Most problems that are usefully attacked with data backtracking tend to be fairly complex (otherwise, it's often easy to find some other approach that's not much more difficult to use - simple problems tend to have simple solutions). What <- gives you is the ability to 'roll-back' when backtracking decisions that were made during the 'forward-tracking' - something that's common. It generally takes thinking in terms of backtracking to see where it's really useful. Here's an example (in Icon!) of a course scheduling algorithm originally written by Dan Higdon at the Univ. of Texas, and slightly modified by me to handle courses at my 'old' school. As it uses recursion, control backtracking, and data backtracking, I'd have to say it probably qualifies as 'complex', and it's definitely been found to be useful! (I'm also a bit reluctant to post this as an isolated piece of code - it's part of a much larger program that allows students to experiment with schedules, so there are parts here that take quite a bit of context... The procedure generates successive schedules (it can indeed, produce all possible schedules from a set of courses, if you keep resuming it...)) Anyway (warning - non-trivial code follows - on the other hand, try coding this up in C!): # # The algorithm is as follows: # If the course set is empty, return that empty set # otherwise, # Generate every remaining schedule and do the following with each: # get the course name and remove it from the course set # Generate every non-null and unconflicting time for each class, as # well as any possible unconflicting labs for that class, then: # insert it (and the lab) into the set # suspend this schedule # procedure schedule (cs) # input is a set of desired classes local t, schedl, class, tlab if *cs = 0 then return cs delete(cs,class := ?cs) # pick a desired class at random every schedl := schedule(cs) & # first schedule all *other* classes, # then try and fit this one (and lab) freespace(t := !classdb[class]) & nonConflicting(t, schedl) & (/t.lab | nonConflicting(tlab <- !\t.lab,schedl)) do { # found room, add it (and lab) to schedule suspend set([t, \tlab] | [t])\1 ++ schedl } end Control backtracking is used to 'go back and try another one' if either: (1) there is no room in that particular class (2) that class conflicts with already scheduled classes (3) that course has a required lab that can't fit into the schedule The use here of data backtracking, in: tlab <- !\t.lab is to restore the initial value of tlab (&null, since it's a local variable) if none of the available labs for this course can be fit into the schedule. freespace() checks a class to see if there are any available seats left, with !classdb[class] producing all sections of that class... nonConflicting() checks to be sure the section doesn't overlap with an already scheduled class. The /t.lab | nonConflicting(...) avoids calling nonConflicting is there is no lab for that course, without failing. The set([t, \tlab] | [t])\1 ++ schedl adds either a pair (if there was a lab), or a single (if not) to the schedule. The limitation prevents backtracking from generating both! -- Steve Wampler swampler@gemini.edu Gemini Project (under AURA) From icon-group-sender Mon Aug 22 12:08:36 1994 Received: by cheltenham.cs.arizona.edu; Mon, 22 Aug 1994 13:04:18 MST To: icon-group-l@cs.arizona.edu Date: Mon, 22 Aug 94 12:08:36 EDT From: dburton@salzo.cary.nc.us (David Burton) Message-Id: <21VgRc6w165w@salzo.Cary.NC.US> Organization: SalzoBoard BBS * 919-481-3787 Sender: icon-group-request@cs.arizona.edu References: <330a3u$3vq@shum.cc.huji.ac.il> Subject: Re: Simple syntax? A definition? Errors-To: icon-group-errors@cs.arizona.edu mslamm@pluto.cc.huji.ac.il (Zvi Lamm) writes: > It appears to me that what counts is simplicity. Agreed. > A simple syntax would be > one that can easaly be built (NOT parsed) by programs ^^^^^^^^^^^^ No. Any language is easily emitted by programs. A simple syntax must also be easily parsed. > It would also be easy for > humans (that's us!) to learn and use. Right. And that means excluding things that add to the learning curve but do nothing for the expressive power of the language: like precedence, and (less importantly) multiple, independent global name spaces. The language should also be easy to read; that is, easy for a human to parse, as well as for a machine. > Does anyone have suggestions on how to define this in a more mathematical > or precise way? For readability, it should be top-down recursive-descent (LL) parsable. > I thought about YACC clauses/sentence. But I am not sure > it's enough because the YACC approach narrows you down to LALR. The problem is not that YACC parsability limits what you can parse, but, rather, that it does not limit it ENOUGH! A simple language is not just LR or LALR parsable, it is also LL parsable. Otherwise, the reader of the language has to "look ahead" and read language tokens without/before knowing what is being specified. Out of consideration for the *humans* that have to read and write the languages, no language should be designed that is not LL (top-down) parsable. -Dave Burton For my PGP public key, finger dburton@cybernetics.net From icon-group-sender Tue Aug 23 22:46:00 1994 Received: by cheltenham.cs.arizona.edu; Tue, 23 Aug 1994 16:37:38 MST Date: 23 Aug 94 22:46 GMT From: NOR0048@applelink.apple.com (HoyskoleData,Oslo,NO,IER) Subject: ProIcon 2.0 and LF chars To: ICON-GROUP@cs.arizona.edu Message-Id: <777682525.3038677@AppleLink.Apple.COM> Errors-To: icon-group-errors@cs.arizona.edu Re: ProIcon 2.0 and Line Feed characters I've just started doing some simple programming projects in ProIcon 2.0 on my Macintosh LC (w/7.1) and IIci (w/7.0). Different kinds of text file conversion was what I planned to use ProIcon for in the beginning. Now I've just got my first BIG surprise: An expression like writes(outFile,"\x0A") turns out to write a Carriage Return character instead of a Line Feed! Using "^J" instead of "\x0A" makes no difference. As far as I can see, the translation of hex 0A into 0D takes place during run-time. That \n should produce a CR on a Mac is quite natural, but not at all being able to write LF's to a text file is hard to accept, especially if you deal with cross-platform text conversion. Does anybody know how to solve this? Is it possible to patch the run-time code without loosing the CR's you normally expect from \n and "write"? If you have an answer or comment, I would be very pleased if you could email it to this address: Nor0048@applelink.apple.com, since I have no personal Internet address at the moment. (I expect to get one in a couple of weeks.) Sincerely, Jon Kleiser Oslo, Norway From icon-group-sender Tue Aug 23 22:46:00 1994 Received: by cheltenham.cs.arizona.edu; Tue, 23 Aug 1994 16:43:22 MST Date: 23 Aug 94 22:46 GMT From: NOR0048@applelink.apple.com (HoyskoleData,Oslo,NO,IER) Subject: ProIcon 2.0 and LF chars To: ICON-GROUP@cs.arizona.edu Message-Id: <777682525.3038677@AppleLink.Apple.COM> Errors-To: icon-group-errors@cs.arizona.edu Re: ProIcon 2.0 and Line Feed characters I've just started doing some simple programming projects in ProIcon 2.0 on my Macintosh LC (w/7.1) and IIci (w/7.0). Different kinds of text file conversion was what I planned to use ProIcon for in the beginning. Now I've just got my first BIG surprise: An expression like writes(outFile,"\x0A") turns out to write a Carriage Return character instead of a Line Feed! Using "^J" instead of "\x0A" makes no difference. As far as I can see, the translation of hex 0A into 0D takes place during run-time. That \n should produce a CR on a Mac is quite natural, but not at all being able to write LF's to a text file is hard to accept, especially if you deal with cross-platform text conversion. Does anybody know how to solve this? Is it possible to patch the run-time code without loosing the CR's you normally expect from \n and "write"? If you have an answer or comment, I would be very pleased if you could email it to this address: Nor0048@applelink.apple.com, since I have no personal Internet address at the moment. (I expect to get one in a couple of weeks.) Sincerely, Jon Kleiser Oslo, Norway From icon-group-sender Tue Aug 23 16:46:59 1994 Received: by cheltenham.cs.arizona.edu; Tue, 23 Aug 1994 16:47:14 MST Date: Tue, 23 Aug 1994 16:46:59 MST From: "Ralph Griswold" Message-Id: <199408232346.AA12612@cheltenham.cs.arizona.edu> To: NOR0048@applelink.apple.com Subject: Re: ProIcon 2.0 and LF chars Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu Icon uses the C I/O library. In the default file mode, there is translation of input and output files so that internal routines always see the same thing regardless of platform. This is not ProIcon nor Macintosh specific. It's more of a problem under MS-DOS, where a line terminator consists of two characters. What you want to do is use the second argument to open (see the ProIcon manual, page 11-58). open(s, "t"), the default mode, does translation. open(s, "u") does not. The "u" mode is necessary for binary files, but can be used for text files. The only problem is that there's no way to read standard input or write standard output in untranslated mode. From icon-group-sender Wed Aug 24 13:41:50 1994 Received: by cheltenham.cs.arizona.edu; Wed, 24 Aug 1994 08:26:50 MST To: icon-group-l@cs.arizona.edu Date: Wed, 24 Aug 1994 13:41:50 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Aug24.134150.20381@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu Reply-To: goer@midway.uchicago.edu Subject: lexical analyzer for Icon Errors-To: icon-group-errors@cs.arizona.edu A while back I wrote a parser generator for Icon (which, by the way, I'll be happy to offer the latest, least buggy :-) version of to any- one who asks). I've been meaning to write a lexical analyzer of some kind as well, but just haven't gotten around to it. Has anyone else done this already? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Aug 26 14:19:04 1994 Received: by cheltenham.cs.arizona.edu; Fri, 26 Aug 1994 12:26:48 MST To: icon-group-l@cs.arizona.edu Date: Fri, 26 Aug 1994 14:19:04 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: <1994Aug24.134150.20381@midway.uchicago.edu> Subject: Re: lexical analyzer for Icon Errors-To: icon-group-errors@cs.arizona.edu Richard L. Goerwitz (goer@quads.uchicago.edu) wrote: : A while back I wrote a parser generator for Icon (which, by the way, : I'll be happy to offer the latest, least buggy :-) version of to any- : one who asks). I've been meaning to write a lexical analyzer of some : kind as well, but just haven't gotten around to it. Has anyone else : done this already? I wrote an Icon program that generates an Icon program which is a recursive descent parser. I also have a version of it which generates C code (but this one is a little bit specialized for a specific project). You're welcome to them, if they are of interest. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Sun Aug 28 21:04:37 1994 Received: by cheltenham.cs.arizona.edu; Sun, 28 Aug 1994 18:06:55 MST To: icon-group-l@cs.arizona.edu Date: Sun, 28 Aug 1994 21:04:37 GMT From: Lexigen@world.std.com (Michael Sikillian) Message-Id: Organization: The World Public Access UNIX, Brookline, MA Sender: icon-group-request@cs.arizona.edu Subject: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu I have been writing some cataloguing and index applications in a PC database program. I know icon has been out there for a while and have an intuition that it probably could do this easier than the db. Is icon a viable language, or just some grand experiment? Is it a fringe type thing with a cult following, or a real tool? Thanks Michael Sikillian Lexigen Software From icon-group-sender Mon Aug 29 09:13:12 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 09:07:56 MST To: icon-group-l@cs.arizona.edu Date: 29 Aug 1994 09:13:12 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <33smt8$meg@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article , Michael Sikillian wrote: >I have been writing some cataloguing and index applications in a PC >database program. I know icon has been out there for a while and >have an intuition that it probably could do this easier than the db. >Is icon a viable language, or just some grand experiment? >Is it a fringe type thing with a cult following, or a real tool? In my view Icon is a language that has a lot of potential, but is still some development away from becoming good enough for large applications. Some of the features it needs but sorely lacks are: 1) separate compilation, preferably into a language other than C (the code produced by the Icon compiler in an effort to do things C was not meant to is awful); 2) support for multiple different kinds of tables so that table interfaces to database files can be implemented (think of perl); 3) a better Icon-C calling interface (the C-Icon calling ability should be put back in as well). That's just to start, but it is that not much, not when compared with the positively huge strides that have been made since version 6. I for one would like to volunteer some time an effort to that end, since Icon is one of my favourite languages. For the moment I only use it for small tasks. On the other hand, Icon's graphics facilities are great and only getting better (there's even a GUI building tool of sorts [vib]); for your needs, Icon might be good enough, so I can only encourage you to check it out and make your call. >Thanks >Michael Sikillian >Lexigen Software Nick From icon-group-sender Mon Aug 29 14:19:28 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 09:08:20 MST To: icon-group-l@cs.arizona.edu Date: Mon, 29 Aug 1994 14:19:28 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Michael Sikillian (Lexigen@world.std.com) wrote: : I have been writing some cataloguing and index applications in a PC : database program. I know icon has been out there for a while and : have an intuition that it probably could do this easier than the db. : Is icon a viable language, or just some grand experiment? : Is it a fringe type thing with a cult following, or a real tool? I use it under OS/2. I write mostly code generators. Compiling Icon programs is fast and the Icon language is powerful. I like it. I'm still receiving periodic source code updates (source code for the implementation of Icon itself); last one was dated 6/10/94. Seems alive and well to me. You can also subscribe to a newsletter. Send email to icon-project@cs.arizona.edu. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Mon Aug 29 15:49:25 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 11:29:14 MST To: icon-group-l@cs.arizona.edu Date: 29 Aug 1994 15:49:25 GMT From: ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <33t025$ba5@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Michael Sikillian (Lexigen@world.std.com) wrote: : I have been writing some cataloguing and index applications in a PC : database program. I know icon has been out there for a while and : have an intuition that it probably could do this easier than the db. : Is icon a viable language, or just some grand experiment? : Is it a fringe type thing with a cult following, or a real tool? It is, in my humble opinion, a real tool. I do all data analyses and text processing with Icon programs, and I get an instant nightmare if I even consider writing these programs in other languages. Also, I have made simulation model prototypes in Icon. If I need *really* high performance, I often generate C with Icon programs. I can then change the neat Icon code and still generate dirty (fast) C code without having to maintain the C code itself. Icon is also used a lot in language research. The well known CELEX linguistic database was built up using Icon programs, for instance. Also, look at the amount of supported platforms. What cult-language is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? So, to wrap up, I think you should seriously consider seeing it as a real tool. Jan From icon-group-sender Mon Aug 29 14:45:39 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 12:18:02 MST To: icon-group-l@cs.arizona.edu Date: 29 Aug 1994 14:45:39 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <33tacj$pen@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.leidenuniv.nl> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33t025$ba5@highway.leidenuniv.nl>, Jan-Peter de Ruiter wrote: >It is, in my humble opinion, a real tool. I do all data analyses >and text processing with Icon programs, and I get an instant >nightmare if I even consider writing these programs in other >languages. Also, I have made simulation model prototypes in Icon. Yes, and I should correct my previous statement: I use it for small tasks because I don't have lots of data to analyse, but do some bit of systems programming, for which Icon is not suited very well just yet... (One of my dreams is to write an httpd in Icon...) >Also, look at the amount of supported platforms. What cult-language >is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? This, along with its graphics libraries, and its language features (backtracking, generators and such) is what makes Icon such a great language. It'll only get better. >Jan Nick From icon-group-sender Mon Aug 29 19:38:47 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 14:21:59 MST To: icon-group-l@cs.arizona.edu Date: Mon, 29 Aug 1994 19:38:47 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Aug29.193847.26131@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu Reply-To: goer@midway.uchicago.edu Subject: Icon-Based Parser Generator posted to alt.sources Errors-To: icon-group-errors@cs.arizona.edu I got a number of requests for the Icon-based parser generator I mentioned in a posting (asking about something else - lexical analyzers). Decided simply to post it to alt.sources rather than mail out separate copies. Might be of general interest, anyway. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Aug 29 22:35:12 1994 Received: by cheltenham.cs.arizona.edu; Mon, 29 Aug 1994 19:21:58 MST To: icon-group-l@cs.arizona.edu Date: Mon, 29 Aug 1994 22:35:12 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Aug29.223512.12423@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: , <33smt8$meg@ios.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Binary file I/O for non-character data would be nice. Or, alternatively, functions akin to Perl's pack()/unpack(). I have several Perl scripts I would happily move to Icon if I didn't have to manipulate C (short) and (long) values in native format (no, I don't get to set the format of the files). ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh From icon-group-sender Mon Aug 29 23:46:57 1994 Received: by cheltenham.cs.arizona.edu; Tue, 30 Aug 1994 05:15:04 MST To: icon-group-l@cs.arizona.edu Date: 29 Aug 1994 23:46:57 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <33ua3h$51h@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: , <33smt8$meg@ios.com>, <1994Aug29.223512.12423@kf8nh.wariat.org> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Aug29.223512.12423@kf8nh.wariat.org>, Brandon S. Allbery wrote: >Binary file I/O for non-character data would be nice. Or, alternatively, >functions akin to Perl's pack()/unpack(). I have several Perl scripts I would >happily move to Icon if I didn't have to manipulate C (short) and (long) >values in native format (no, I don't get to set the format of the files). I thought reads() was meant to be used for binary data, am I wrong? If characters in Icon can be treated as plain bytes then pack()/unpack() type procedures could be built upon reads()/writes(). >++Brandon >-- >Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org >Linux development: iBCS2, JNOS, MH >Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh Nick From icon-group-sender Tue Aug 30 11:33:50 1994 Received: by cheltenham.cs.arizona.edu; Tue, 30 Aug 1994 06:44:54 MST To: icon-group-l@cs.arizona.edu Date: Tue, 30 Aug 1994 11:33:50 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Aug30.113350.5310@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: <33smt8$meg@ios.com>, <1994Aug29.223512.12423@kf8nh.wariat.org>, <33ua3h$51h@ios.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33ua3h$51h@ios.com>, nmw@ios.com (Nick Williams) says: +--------------- | In article <1994Aug29.223512.12423@kf8nh.wariat.org>, | Brandon S. Allbery wrote: | >Binary file I/O for non-character data would be nice. Or, alternatively, | >functions akin to Perl's pack()/unpack(). I have several Perl scripts I would | | I thought reads() was meant to be used for binary data, am I wrong? If | characters in Icon can be treated as plain bytes then pack()/unpack() | type procedures could be built upon reads()/writes(). +------------->8 You can, and I have --- and as a result I have *one* (and only one, until the situation is resolved) program which uses reads() and translates C (long)s into a form Icon can internalize. And if I ever decide to move the program from SCO to Solaris it's going to have to be rewritten because the endianness is different between them. (And again, htonl() is not an option.) And then there's the question of binary floating point format... ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh From icon-group-sender Tue Aug 30 14:09:40 1994 Received: by cheltenham.cs.arizona.edu; Tue, 30 Aug 1994 08:23:17 MST To: icon-group-l@cs.arizona.edu Date: Tue, 30 Aug 1994 14:09:40 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Aug30.140940.5002@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.leidenuniv.nl>, <33tacj$pen@ios.com> Reply-To: goer@midway.uchicago.edu Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33tacj$pen@ios.com> nmw@ios.com (Nick Williams) writes: > >Yes, and I should correct my previous statement: I use it for small >tasks because I don't have lots of data to analyse, but do some bit of >systems programming, for which Icon is not suited very well just yet... >(One of my dreams is to write an httpd in Icon...) Just yet? That's funny. I feel quite the opposite. I dread the kitchen sink mentality - turning Icon into a heap of platform-specific extensions geared for things that C and PERL already do much better. Fight feeping creaturism! -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Aug 30 12:06:06 1994 Received: by cheltenham.cs.arizona.edu; Tue, 30 Aug 1994 11:26:38 MST To: icon-group-l@cs.arizona.edu Date: 30 Aug 1994 12:06:06 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <33vlde$95i@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: <33t025$ba5@highway.leidenuniv.nl>, <33tacj$pen@ios.com>, <1994Aug30.140940.5002@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Aug30.140940.5002@midway.uchicago.edu>, Richard L. Goerwitz wrote: >In article <33tacj$pen@ios.com> nmw@ios.com (Nick Williams) writes: >> >>Yes, and I should correct my previous statement: I use it for small >>tasks because I don't have lots of data to analyse, but do some bit of >>systems programming, for which Icon is not suited very well just yet... >>(One of my dreams is to write an httpd in Icon...) >Just yet? >That's funny. I feel quite the opposite. I dread the kitchen sink >mentality - turning Icon into a heap of platform-specific extensions >geared for things that C and PERL already do much better. I could deal with loadfunc really (as one of the examples in the IPL demonstrates), but some things (setenv() comes to mind...) should be standard. If the presence of more system dependent features makes Icon programs non-portable, then they can be put in separate libraries along with LARGE warnings in the documentation; if someone uses them and gets stuck with non-portable code, then so be it, after all, they'd have seen the warnings. As for C and Perl, I love C, and hate Perl, but Icon can save me a lot of work if I can use it instead of C for certain problems. >Fight feeping creaturism! >-- > -Richard L. Goerwitz goer%midway@uchicago.bitnet > goer@midway.uchicago.edu rutgers!oddjob!ellis!goer Nick PS: let's not deteriorate into a comp.lang.lisp style language war. From icon-group-sender Wed Aug 31 06:36:27 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 07:18:54 MST To: icon-group-l@cs.arizona.edu Date: Wed, 31 Aug 1994 06:36:27 GMT From: lwall@netlabs.com (Larry Wall) Message-Id: <1994Aug31.063627.13092@netlabs.com> Organization: NetLabs, Inc. Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.LeidenUniv.nl> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33t025$ba5@highway.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) writes: : Also, look at the amount of supported platforms. What cult-language : is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? Um, Perl is on all those platforms. And on the Amiga I'm typing on. I suspect the same is true for REXX, and it's pretty close to true for Tcl and Python. I'll bet you can find Lisp on all those machines too, and if that isn't a cult language, I don't know what is... Larry Wall lwall@netlabs.com From icon-group-sender Wed Aug 31 11:32:41 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 07:19:31 MST To: icon-group-l@cs.arizona.edu Date: Wed, 31 Aug 1994 11:32:41 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Aug31.113241.18378@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.leidenuniv.nl> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33t025$ba5@highway.leidenuniv.nl>, ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) says: +--------------- | Also, look at the amount of supported platforms. What cult-language | is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? +------------->8 APL. (You asked...) ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh From icon-group-sender Wed Aug 31 08:56:04 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 07:19:16 MST To: icon-group-l@cs.arizona.edu Date: 31 Aug 1994 08:56:04 GMT From: ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <341gj4$kte@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.LeidenUniv.nl>, <1994Aug31.063627.13092@netlabs.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Larry Wall (lwall@netlabs.com) wrote: : In article <33t025$ba5@highway.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) writes: : : Also, look at the amount of supported platforms. What cult-language : : is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? : Um, Perl is on all those platforms. And on the Amiga I'm typing on. : I suspect the same is true for REXX, and it's pretty close to true for : Tcl and Python. I'll bet you can find Lisp on all those machines : too, and if that isn't a cult language, I don't know what is... : Larry Wall : lwall@netlabs.com Well, apart from Perl, of course, I wouldn't say any of the languages you mentioned is a true "cult language". ;-) Jan From icon-group-sender Wed Aug 31 13:22:49 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 07:19:49 MST To: icon-group-l@cs.arizona.edu Date: 31 Aug 1994 13:22:49 GMT From: ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <342079$pgg@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.leidenuniv.nl>, <1994Aug31.113241.18378@kf8nh.wariat.org> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Brandon S. Allbery (bsa@kf8nh.wariat.org) wrote: : In article <33t025$ba5@highway.leidenuniv.nl>, ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) says: : +--------------- : | Also, look at the amount of supported platforms. What cult-language : | is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? : +------------->8 : APL. (You asked...) Ok, ok, I see. I had the wrong idea of a "cult language". I never considered APL to be a cult language. If Perl, Lisp and APL are cult languages, I concede: Icon is a cult language as well. Jan From icon-group-sender Wed Aug 31 14:01:11 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 08:24:50 MST To: icon-group-l@cs.arizona.edu Date: Wed, 31 Aug 1994 14:01:11 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Aug31.140111.22639@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: <33tacj$pen@ios.com>, <1994Aug30.140940.5002@midway.uchicago.edu>, <33vlde$95i@ios.com> Reply-To: goer@midway.uchicago.edu Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <33vlde$95i@ios.com> nmw@ios.com (Nick Williams) writes: > >>That's funny. I feel quite the opposite. I dread the kitchen sink >>mentality - turning Icon into a heap of platform-specific extensions >>geared for things that C and PERL already do much better. > >I could deal with loadfunc really (as one of the examples in the IPL >demonstrates), but some things (setenv() comes to mind...) should be >standard. If the presence of more system dependent features makes Icon >programs non-portable, then they can be put in separate libraries along >with LARGE warnings... Sounds perfectly ghastly - using Icon for something it wasn't really intended. The most that I personally would like to see is a solution to the problem of calling C functions from Icon. At least this would let each language do what it does without interference from the other. Trouble is that the memory management would, at times, conflict (e.g. if malloc is called). Of course all of this is predicated on resources, and right now the Icon Project seems absorbed in graphics extensions (which is great). If improvements are to be made to Icon's C calling interface, this will need to come from outside, at least for now. >PS: let's not deteriorate into a comp.lang.lisp style language war. :-) -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Aug 31 19:56:17 1994 Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 15:05:15 MST To: icon-group-l@cs.arizona.edu Date: Wed, 31 Aug 1994 19:56:17 GMT From: Lexigen@world.std.com (Michael Sikillian) Message-Id: Organization: The World Public Access UNIX, Brookline, MA Sender: icon-group-request@cs.arizona.edu References: <1994Aug30.140940.5002@midway.uchicago.edu>, <33vlde$95i@ios.com>, <1994Aug31.140111.22639@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu To all who gave me advice about ICON, THANK YOU! I would like to download the latest info from their ftp site Can anyone tell me where the ftp site is? Thanks Michael From icon-group-sender Fri Sep 2 10:12:19 1994 Received: by cheltenham.cs.arizona.edu; Fri, 2 Sep 1994 11:43:59 MST To: icon-group-l@cs.arizona.edu Date: 2 Sep 1994 10:12:19 -0700 From: tanksley@coyote.csusm.edu (Billy Tanksley) Message-Id: <347mdj$hmq@coyote.csusm.edu> Organization: California State University San Marcos Sender: icon-group-request@cs.arizona.edu References: <33t025$ba5@highway.leidenuniv.nl>, <33tacj$pen@ios.com>, <1994Aug30.140940.5002@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Aug30.140940.5002@midway.uchicago.edu> goer@midway.uchicago.edu writes: >That's funny. I feel quite the opposite. I dread the kitchen sink >mentality - turning Icon into a heap of platform-specific extensions >geared for things that C and PERL already do much better. Well, I agree with your fear of platform-specifisity, but _standard_ extensions are needed. Just look at Forth-- it's been around for a long time, and is difficult entirely because of its lack of standard features. Every time a Forth programmer needs a feature, he/she writes it himself, completely differently than another would have. It's a pain-- don't saddle yourselves with those difficulties. -Billy Paladin (for PC-Geos) From icon-group-sender Fri Sep 2 10:17:16 1994 Received: by cheltenham.cs.arizona.edu; Fri, 2 Sep 1994 11:44:26 MST To: icon-group-l@cs.arizona.edu Date: 2 Sep 1994 10:17:16 -0700 From: tanksley@coyote.csusm.edu (Billy Tanksley) Message-Id: <347mms$5cm@coyote.csusm.edu> Organization: California State University San Marcos Sender: icon-group-request@cs.arizona.edu References: , <33t025$ba5@highway.LeidenUniv.nl>, <1994Aug31.063627.13092@netlabs.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Aug31.063627.13092@netlabs.com> lwall@netlabs.com (Larry Wall) writes: >In article <33t025$ba5@highway.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) writes: >: Also, look at the amount of supported platforms. What cult-language >: is supported for Dos, Mac, Unix, OS/2, Windows, VMS, and more? >Um, Perl is on all those platforms. And on the Amiga I'm typing on. >I suspect the same is true for REXX, and it's pretty close to true for >Tcl and Python. I'll bet you can find Lisp on all those machines >too, and if that isn't a cult language, I don't know what is... You completely missed the most widespread cult language-- Forth. (A cult language is one where all the users are brainwashed, right? That's Forth.) Forth happens EVERYWHERE, from embedded controllers to windoze NT. >Larry Wall -Billy Paladin (for PC Geos) : test ( -- ) forth you love if honk else null then emit ; From icon-group-sender Fri Sep 2 15:55:03 1994 Received: by cheltenham.cs.arizona.edu; Fri, 2 Sep 1994 14:15:13 MST To: icon-group-l@cs.arizona.edu Date: 2 Sep 1994 15:55:03 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <347vun$qkb@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: <1994Aug30.140940.5002@midway.uchicago.edu>, <33vlde$95i@ios.com>, <1994Aug31.140111.22639@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Aug31.140111.22639@midway.uchicago.edu>, Richard L. Goerwitz wrote: >In article <33vlde$95i@ios.com> nmw@ios.com (Nick Williams) writes: >>I could deal with loadfunc really (as one of the examples in the IPL >>demonstrates), but some things (setenv() comes to mind...) should be >>standard. If the presence of more system dependent features makes Icon >>programs non-portable, then they can be put in separate libraries along >>with LARGE warnings... >Sounds perfectly ghastly - using Icon for something it wasn't really >intended. What was Icon intended for then? Is it supposed to allow highly portable programming by putting huge restrictions on what Icon programmers can do? I bet not (why else would there be a preprocessor?, or &features for that matter?). Frankly, Icon needs better access to system dependent features (how dependent is setenv anyways? not much more than is getenv, and that is already part of the standard set of functions), after all, I don't always wish to write portable code because, after all, there are some large differences between the various OS's that Icon runs under (some irreconciliable, or which mean one OS is a much better choice for a certain type of applications [e.g. Unix is better than DOS if you want to write and run servers and still be able to use the machine for other things]). Forcing programmers to go hack the RTL code from which icont and iconc are made or to write C function wrappers to system routines (plus Icon wrappers as well), then relink the relevant libraries and executables (or use loadfunc()) just to make them think twice before they use a system dependent function is CRAZY! If the reason that is the way things are has more to do with the fact that Icon is still being developed, then fine, but it is something that ought to change. Besides, Icon could turn out to be useful for more than just processing text (why are graphics facilities would have been added otherwise?). > The most that I personally would like to see is a solution >to the problem of calling C functions from Icon. At least this would >let each language do what it does without interference from the other. >Trouble is that the memory management would, at times, conflict (e.g. >if malloc is called). So perhaps Icon should provide a replacement for malloc for C functions linked or loaded in (a malloc() that allocates space that is not subject to garbage collection!, and a free() too of course). >Of course all of this is predicated on resources, and right now the >Icon Project seems absorbed in graphics extensions (which is great). >If improvements are to be made to Icon's C calling interface, this will >need to come from outside, at least for now. Indeed, and why are they putting in graphics extensions? because they are *useful* to have (though _I_ don't use them often); the same would apply to adding fork(), exec() and the like (system() is portable, but limiting, not to mention dangerous). >-- > > -Richard L. Goerwitz goer%midway@uchicago.bitnet > goer@midway.uchicago.edu rutgers!oddjob!ellis!goer BTW, the whole world of programming/computing/administrating is ghastly ;-) Nick From icon-group-sender Sat Sep 3 15:28:48 1994 Received: by cheltenham.cs.arizona.edu; Sat, 3 Sep 1994 12:08:05 MST To: icon-group-l@cs.arizona.edu Date: Sat, 3 Sep 1994 15:28:48 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Sep3.152848.12946@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: Reply-To: goer@midway.uchicago.edu Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Michael Sikillian wrote (seems like years ago :-)): >I have been writing some cataloguing and index applications in a PC >database program. I know icon has been out there for a while and >have an intuition that it probably could do this easier than the db. >Is icon a viable language, or just some grand experiment? >Is it a fringe type thing with a cult following, or a real tool? Well, at several people's recommendation I just took a look at the new C calling interface, loadfunc. This is a good solution to a prob- lem that has made C <-> Icon interchange inconvenient at best. To answer your question, I ran into Icon perhaps seven years ago or so, when looking for a language with good string processing facili- ties and a general power and economy of expression. I fell in love with the language. I still use it for nearly all of my daily work, except when speed is absolutely critical, or when some facility is simply not available. I've done some fairly large-scale projects with Icon. And even some real whoppers. I don't see how I could have done the research that led up to my PhD (Near Eastern Languages & Civilizations) without Icon - at least in the time frame that I did. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat Sep 3 22:48:20 1994 Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 10:40:21 MST To: icon-group@cs.arizona.edu Subject: Re: Icon - still alive?? Message-Id: <778632500@mse> Date: Sat, 03 Sep 94 22:48:20 UTC From: whm@mse.com (William H. Mitchell) Errors-To: icon-group-errors@cs.arizona.edu >Nick Williams writes: >What was Icon intended for then? Is it supposed to allow highly portable >programming by putting huge restrictions on what Icon programmers can >do? I bet not (why else would there be a preprocessor?, or &features for >that matter?). ... I think Icon was intended to provide a mechanism to do research in the design and implementation of high-level language facilities. Fortunately for today's Icon users, the research turned out pretty well and as a side effect a powerful language is available free of charge. >Forcing programmers to go hack the RTL code from which icont and iconc >are made or to write C function wrappers to system routines (plus Icon >wrappers as well), then relink the relevant libraries and executables >(or use loadfunc()) just to make them think twice before they use a >system dependent function is CRAZY! ... >Besides, Icon could turn out to be useful for more than just processing >text (why are graphics facilities would have been added otherwise?). I think there's an issue of what's useful to the most people. Most non-graphical programs can be written in plain old Icon. With the graphic extensions, now many graphics programs are in Icon's domain. I just went through an MKS toolkit manual (the MKS toolkit is a collection of ported UNIX commands) and counted programs that could and could not be easily written in Icon. I got 47 that could be written in Icon and 12 that either couldn't be written in Icon or would be inoordinately difficult. That's about 4:1, which is less than I'd hoped for, but consider this: how many lines of code would be required would be required to write all the programs in each category? The non-Icon programs did include some signficant programs like cpio and find, but many were trivial: chomd, date, df, du, and id. To tell you the truth, before typing this note I'd always lamented Icon's lack of system-level facilities, but considering the domain of programming problems, I now have to concede that I think Icon's focus is right on target. But here's a thought for those interested in Icon programs that do serious system-level stuff: Link in a copy of Perl and write a couple of interface routines -- sort of like SNOBOL4's CODE function! /------------------------------\ /----------------\ / William H. Mitchell \ / 7120 E. Kiva Way \ / Mitchell Software Engineering \o----/ Tucson, AZ, 85715 \ \ Consulting/Development/Training / \ 602-577-6431 / \ OO Methods/C++/Icon/UNIX / \ whm@mse.com / \------------------------------/ \----------------/ From icon-group-sender Sun Sep 4 22:02:07 1994 Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 15:28:08 MST To: icon-group-l@cs.arizona.edu Date: Sun, 4 Sep 1994 22:02:07 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Sep4.220207.10360@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: <33vlde$95i@ios.com>, <1994Aug31.140111.22639@midway.uchicago.edu>, <347vun$qkb@ios.com> Reply-To: goer@midway.uchicago.edu Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <347vun$qkb@ios.com> nmw@ios.com (Nick Williams) writes: > >What was Icon intended for then? Is it supposed to allow highly portable >programming by putting huge restrictions on what Icon programmers can >do? I bet not (why else would there be a preprocessor?, or &features for >that matter?). Frankly, Icon needs better access to system dependent >features... Your opinion is a valid one, and shared by others. I just don't happen to agree. We are going in circles here, in a sense, because my answer to what you are saying now is the same answer I gave before: If you need system-dependent features, improve Icon's access to facilities that deal with them. To extend Icon here and there to make it more PERL-like or more C-like will fritter away the language. As I pointed out before, Icon has an improved C calling interface that allows you to dynamically load functions into the run-time system. So all you have to do to call a C function is to put it into a dynamically loadable library, and load it from your Icon program. No recompilation of the Icon source is needed. I like this. There are even some exam- ples in the new documentation for Icon 9.0. >Forcing programmers to go hack the RTL code from which icont and iconc >are made or to write C function wrappers to system routines (plus Icon >wrappers as well), then relink the relevant libraries and executables >(or use loadfunc()) just to make them think twice before they use a >system dependent function is CRAZY! Again, I just don't agree. If loadfunc() isn't elegant enough, then an improved interface should be developed at some point. In theory it is nice to have a language be all things to all people. But once a lang- uage comits to this philosophy, it's hard to know when to stop. And the result can be ugly and messy. Far uglier and messier than loadfunc() - for which there is perfectly good sample code in the Icon docs. >Indeed, and why are they putting in graphics extensions? because they >are *useful* to have (though _I_ don't use them often); the same would >apply to adding fork(), exec() and the like (system() is portable, but >limiting, not to mention dangerous). Here's a prime example. Creation of a new process in Unix is not atomic. You have to copy the current process, then overlay it. This is pretty system dependent. You mentioned setenv() above. I don't believe that the Mac has environment variables per se. Getenv() is marginally useful for passing information about the environment to Icon (e.g. if you want to know what TERM type you have under Unix). I've never needed setenv() within Icon, myself, though. Not so say someone wouldn't. But then I could see how almost every platform-specific facility might be useful at one time or another. That doesn't mean I want to see them as part of the core Icon language definition. To back off a moment, let me just repeat that your opinion is perfectly reasonable, and I'm sure many others share it. There's another side, though, and that's the one I happen to be on. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Sep 4 22:49:35 1994 Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 18:30:53 MST To: icon-group-l@cs.arizona.edu Date: 4 Sep 1994 22:49:35 GMT From: espie@basilic.ens.fr (Marc Espie) Message-Id: <34ditv$nec@nef.ens.fr> Organization: Ecole Normale Superieure, PARIS, France Sender: icon-group-request@cs.arizona.edu References: <1994Aug31.140111.22639@midway.uchicago.edu>, <347vun$qkb@ios.com>, <1994Sep4.220207.10360@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Sep4.220207.10360@midway.uchicago.edu>, Richard L. Goerwitz wrote: >In article <347vun$qkb@ios.com> nmw@ios.com (Nick Williams) writes: >> [some deleted to satisfy my news-poster] > >As I pointed out before, Icon has an improved C calling interface that >allows you to dynamically load functions into the run-time system. So >all you have to do to call a C function is to put it into a dynamically >loadable library, and load it from your Icon program. No recompilation >of the Icon source is needed. I like this. There are even some exam- >ples in the new documentation for Icon 9.0. How many architectures does that new call work under ? Not too many I think... A perfect example of how general and elegant that mechanism is :-( (I'd like it to work on every machine myself). > >>Forcing programmers to go hack the RTL code from which icont and iconc >>are made or to write C function wrappers to system routines (plus Icon >>wrappers as well), then relink the relevant libraries and executables >>(or use loadfunc()) just to make them think twice before they use a >>system dependent function is CRAZY! > >Again, I just don't agree. If loadfunc() isn't elegant enough, then an >improved interface should be developed at some point. In theory it is >nice to have a language be all things to all people. But once a lang- >uage comits to this philosophy, it's hard to know when to stop. And the >result can be ugly and messy. Far uglier and messier than loadfunc() - >for which there is perfectly good sample code in the Icon docs. Just some new simple calls would help icon apply to some domains for which it becomes quite suited. For instance, writing a graphics interface to a text-oriented program would be a cinch, provided you have the specific codes dealing with spawning other programs/interpreting their input/output in a non-blocking way... perfect application of Icon in my opinion: text parsing + graphics. Personally, I think the setenv() system call is not so interesting, but routines to deal with sockets would enable you to write MANY interesting applications that you currently CAN'T write: a WWW browser in Icon, for instance. Should not be that difficult... Icon already knows about GIF files, and is VERY well suited for parsing generalized text files. The big problem being having to use systems to get stuff through connections, where everything could be done in Icon. > >>Indeed, and why are they putting in graphics extensions? because they >>are *useful* to have (though _I_ don't use them often); the same would >>apply to adding fork(), exec() and the like (system() is portable, but >>limiting, not to mention dangerous). > >Here's a prime example. Creation of a new process in Unix is not atomic. >You have to copy the current process, then overlay it. This is pretty >system dependent. You mentioned setenv() above. I don't believe that >the Mac has environment variables per se. Getenv() is marginally useful >for passing information about the environment to Icon (e.g. if you want >to know what TERM type you have under Unix). I've never needed setenv() >within Icon, myself, though. Not so say someone wouldn't. But then I >could see how almost every platform-specific facility might be useful >at one time or another. That doesn't mean I want to see them as part >of the core Icon language definition. Take your prime example and revert it: look at co-expressions under Icon. Not exactly a simple mechanism, quite messy to implement on a new machine, and liable to crash every machine with limited stack-space (just out of curiosity: does ProIcon on the Mac have co-expressions ? If so, how does it work ?) On the other hand, if we wanted REAL subprocesses under Icon, the semantics would have to match very closely co-expression calls to be natural. I don't quite see how you can do that without extensive surgery to the Icon code. I myself believe it would be a very natural extension of the current Icon code, and rather independent of the way it would be implemented. fork() ? CreateNewProcTags() ? Nope. I want an Icon subprocess, saying something like: p := process(thingy) and then I say something like every e:=(expression1|expression2)@p to send icon values to p and get some results back. - complex values should be COPIED over, unless you want to have to deal with shared memory issues. - not everything is clear about non-blocking issues. Something involving the semantics of &fail would probably be necessary... > >To back off a moment, let me just repeat that your opinion is perfectly >reasonable, and I'm sure many others share it. There's another side, >though, and that's the one I happen to be on. Not really a problem for you, especially if that kind of augmented behaviour is user-definable when installing Icon. On the other hand, I noticed a dire problem while playing around with 9.0: it seems that the compiler, even without call by name of proecedures, does NOT prune out unused procedures from its list. Funny but sad when you link with graphics to use the standard WOpen and get all the widgets pulled in :-(. Definitely to be fixed if the IPL is to be part of Standard Icon soon. -- [nosave] `Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai) `$@0>@n(J $@$N$3$H!<9%$-$@$h!#(J' ($@$"$NF|$K5"$j$?$$(J)(B Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Mon Sep 5 01:12:54 1994 Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 18:31:11 MST To: icon-group-l@cs.arizona.edu Date: Mon, 5 Sep 1994 01:12:54 GMT From: Lexigen@world.std.com (Michael Sikillian) Message-Id: Organization: The World Public Access UNIX, Brookline, MA Sender: icon-group-request@cs.arizona.edu References: , <1994Sep3.152848.12946@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu Speaking of your PhD, do you know Frank Lewis? He was working on a doctorate in Persian at UChicago. Richard L. Goerwitz (goer@quads.uchicago.edu) wrote: : Michael Sikillian wrote (seems like years ago :-)): : >I have been writing some cataloguing and index applications in a PC : >database program. I know icon has been out there for a while and : >have an intuition that it probably could do this easier than the db. : >Is icon a viable language, or just some grand experiment? : >Is it a fringe type thing with a cult following, or a real tool? : Well, at several people's recommendation I just took a look at the : new C calling interface, loadfunc. This is a good solution to a prob- : lem that has made C <-> Icon interchange inconvenient at best. : To answer your question, I ran into Icon perhaps seven years ago or : so, when looking for a language with good string processing facili- : ties and a general power and economy of expression. I fell in love : with the language. I still use it for nearly all of my daily work, : except when speed is absolutely critical, or when some facility is : simply not available. I've done some fairly large-scale projects : with Icon. And even some real whoppers. : I don't see how I could have done the research that led up to my : PhD (Near Eastern Languages & Civilizations) without Icon - at least : in the time frame that I did. : -- : -Richard L. Goerwitz goer%midway@uchicago.bitnet : goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Sep 5 12:16:12 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Sep 1994 12:31:37 MST To: icon-group-l@cs.arizona.edu Date: Thu, 1 Sep 94 14:01:08 BST From: m.datko@ic.ac.uk (Mark William George Datko) Message-Id: <1994Sep1.140109.1472@cc.ic.ac.uk> Organization: Department of Mathematics, Imperial College, UK Sender: icon-group-request@cs.arizona.edu Reply-To: m.datko@ic.ac.uk Subject: Use of Icon to process WWW output Errors-To: icon-group-errors@cs.arizona.edu I would be interested to hear if anyone is using icon to process material 'received' from html form output. I have colleagues who are using C and Perl to do this but given my familiarity with the string processing in Icon, I would like to use it to do the job. Has anybody done this ! I'm a novice when it comes to html and WWW so 'newbie' replies welcome ! Mark Datko Computer Officer Department of Mathematics IC From icon-group-sender Mon Sep 5 17:10:07 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Sep 1994 16:06:04 MST Date: Mon, 5 Sep 1994 17:10:07 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9409052210.AA14549@runner.utsa.edu> To: espie@basilic.ens.fr Cc: icon-group@cs.arizona.edu In-Reply-To: <34ditv$nec@nef.ens.fr> (espie@basilic.ens.fr) Subject: Re: Icon - still alive?? Content-Length: 781 Errors-To: icon-group-errors@cs.arizona.edu Marc Espie writes, concerning Icon's new loadfunc() facility for calling C routines: > How many architectures does that new call work under ? Not too many I > think...A perfect example of how general and elegant that mechanism is :-( > (I'd like it to work on every machine myself). My impression is that loadfunc() is delightfully general and elegant. The fact that the first platforms for which it is implemented are certain flavors of UNIX is a side-issue. As always, it will be up to implementors on various platforms to see if they can add loadfunc() to their version of Icon. The reason I am happy about loadfunc() is that it appears a broad class of common systems *will* be able to support it once someone reasonably gifted sets out to do loadfunc() for each system. From icon-group-sender Mon Sep 5 19:54:47 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Sep 1994 17:52:42 MST To: icon-group-l@cs.arizona.edu Date: 5 Sep 1994 19:54:47 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <34gb47$svr@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: <1994Sep1.140109.1472@cc.ic.ac.uk> Subject: Re: Use of Icon to process WWW output Errors-To: icon-group-errors@cs.arizona.edu In article <1994Sep1.140109.1472@cc.ic.ac.uk>, Mark William George Datko wrote: >I would be interested to hear if anyone is using icon to process >material 'received' from html form output. What you want is a library of Icon procedures to help write CGI scripts/programs. I have given this some though and will try to create one when I have time. I already have written some Icon utilities to help create a WWW interface to e-mail; one of the utilities, for example, is much like from(1), but can produce output in the form of HTML anchors, as well as build query URL's for the anchors (this can be used by a CGI script to produce a web document on the fly that lists one's e-mail). >I have colleagues who are using C and Perl to do this but given my >familiarity with the string processing in Icon, I would like to use >it to do the job. >Mark Datko >Computer Officer >Department of Mathematics IC Nick From icon-group-sender Mon Sep 5 19:49:16 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Sep 1994 17:54:03 MST To: icon-group-l@cs.arizona.edu Date: 5 Sep 1994 19:49:16 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <34gaps$ste@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: <1994Aug31.140111.22639@midway.uchicago.edu>, <347vun$qkb@ios.com>, <1994Sep4.220207.10360@midway.uchicago.edu> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <1994Sep4.220207.10360@midway.uchicago.edu>, Richard L. Goerwitz wrote: >In article <347vun$qkb@ios.com> nmw@ios.com (Nick Williams) writes: >>What was Icon intended for then? >Your opinion is a valid one, and shared by others. I just don't happen >to agree. We are going in circles here, in a sense, because my answer >to what you are saying now is the same answer I gave before: If you need >system-dependent features, improve Icon's access to facilities that deal >with them. To extend Icon here and there to make it more PERL-like or >more C-like will fritter away the language. I didn't say that Icon itself should be extended, just that system specific stuff should be put into libraries. I can add them myself (through loadfunc() if you wish), but such system specific function libraries should be standard IMHO. It would just make Icon that much more useful; if people were then to use it in ways you deplore, so what? > No recompilation >of the Icon source is needed. I like this. There are even some exam- >ples in the new documentation for Icon 9.0. It's nice yes (though recompilation is necessary on systems that do not support dynamic loading). Note that the C-Icon calling interface has been removed (you can call C from Icon, but not Icon from C). > In theory it is >nice to have a language be all things to all people. But once a lang- >uage comits to this philosophy, it's hard to know when to stop. And the >result can be ugly and messy. True, and Ada is a perfect example, but as someone else pointed out Icon would be very well suited for developing a WWW browser; but of course, the lack of a standard interface to system specific stuff complicates matters. I can develop my sys specific library, so can you, but a standard would be best. You're limiting Icon's potential! :) >Here's a prime example. Creation of a new process in Unix is not atomic. >You have to copy the current process, then overlay it. This is pretty >system dependent. Not! fork() does not necessarily involve copying, particularly if you exec() soon after the fork(). Every Unix system works like this, and others are similar. Just because these are so system specific doesn't mean you can't use them, just that you should be careful about using them when you intend to write portable code (portable to non-Unix like systems that is). > You mentioned setenv() above. I don't believe that >the Mac has environment variables per se. Getenv() is marginally useful >for passing information about the environment to Icon (e.g. if you want >to know what TERM type you have under Unix). > But then I >could see how almost every platform-specific facility might be useful >at one time or another. That doesn't mean I want to see them as part >of the core Icon language definition. Ah, but you see, sometimes there's no portable way to do a certain task, a small part of a large project for which Icon is well suited; are we to forget about using Icon then, just because one procedure needs to use setenv() or fork(), or exec() or...? >To back off a moment, let me just repeat that your opinion is perfectly >reasonable, and I'm sure many others share it. There's another side, >though, and that's the one I happen to be on. I just don't see what is wrong with standardizing an Icon library of system specific functions. If standard would be welcome I would volunteer time to write/implement it. >-- > > -Richard L. Goerwitz goer%midway@uchicago.bitnet > goer@midway.uchicago.edu rutgers!oddjob!ellis!goer Nick From icon-group-sender Tue Sep 6 08:57:38 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Sep 1994 11:46:15 MST Date: Tue, 06 Sep 1994 08:57:38 -0600 (CST) From: Chris Tenaglia | 456-8765 Subject: Re: Use of Icon to process WWW output To: m.datko@ic.ac.uk Cc: icon-group@cs.arizona.edu Message-Id: <01HGSB1KMOAA8WWKFN@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"m.datko@ic.ac.uk" X-Vms-Cc: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu I've had to write an intercepter for downloads. For some reason files download with a # prepended to the filename. I also want the file to end up in a certain holding tank. Maybe I could have done this better if I knew my mosaic.ini better. The module I wrote so far is xfer.icn and here's what it looks like: ####################################################################### # file : xfer.icn # desc : disguised copy command because DOS doesn't have a COPY.EXE # use : do xfer file destination # # update by what # 12-aug-1994 tenaglia initial write # procedure main(param) source := param[1] target := param[2] command:= "COPY " || source || " " || target || "\\" || source[2:0] write("Performing => ",command) input("Press to continue.") system(command) end procedure input(prompt) writes(prompt) return read() end ######################################################################## Then in mosaic.ini I made the following changes: under [Viewers] TYPE7="binary/download" binary/download="c:\bin59\iconx.exe c:\bin59\xfer %ls \tmp\hold" under [Suffixes] binary/download=.zip,.lzh,.com,.exe,.arc,.Z Note: I'm using icon v5.9 because of memory problems in my environment. Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)456-8765 | tenaglia@mis.mcw.edu > From: IN%"m.datko@ic.ac.uk" 5-SEP-1994 14:42:57.97 > To: IN%"icon-group-l@cs.arizona.edu" > Subj: Use of Icon to process WWW output > I would be interested to hear if anyone is using icon to process > material 'received' from html form output. > I have colleagues who are using C and Perl to do this but given my > familiarity with the string processing in Icon, I would like to use > it to do the job. > Has anybody done this ! I'm a novice when it comes to html and WWW > so 'newbie' replies welcome ! > Mark Datko > Computer Officer > Department of Mathematics IC From icon-group-sender Tue Sep 6 13:23:49 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Sep 1994 11:46:26 MST To: icon-group-l@cs.arizona.edu Date: Tue, 6 Sep 1994 13:23:49 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Sep6.132349.9923@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: <347vun$qkb@ios.com>, <1994Sep4.220207.10360@midway.uchicago.edu>, <34gaps$ste@ios.com> Reply-To: goer@midway.uchicago.edu Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <34gaps$ste@ios.com> nmw@ios.com (Nick Williams) writes: > >I just don't see what is wrong with standardizing an Icon library of >system specific functions. If standard would be welcome I would >volunteer time to write/implement it. I'd sure be interested in anything you do, don't get me wrong. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Sep 6 14:53:41 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Sep 1994 15:32:07 MST Resent-Date: Wed, 07 Sep 94 00:41:59 SAT Resent-From: STUD676@SAUPM00.BITNET Date: Wed, 07 Sep 94 00:41:59 SAT From: Samir sulaiman Subject: subscribe Resent-To: icon-group@cs.arizona.edu To: Bill Mitchell Resent-Message-Id: <01HGSNUONAPW9ARPXT@Arizona.EDU> Message-Id: <940907.004159.SAT.STUD676@SAUPM00.BITNET> Organization: King Fahd University of Petroleum and Minerals, S.A. X-Vms-To: IN%"ICON-GROUP@Arizona.EDU" "Bill Mitchell" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Acknowledge-To: Errors-To: icon-group-errors@cs.arizona.edu subscribe icu-l Samir Sulaiman end From icon-group-sender Wed Sep 7 12:01:41 1994 Received: by cheltenham.cs.arizona.edu; Wed, 7 Sep 1994 10:10:44 MST From: "Art Eschenlauer" Message-Id: <9409071701.AA01120@molbio.cbs.umn.edu> Subject: What's wrong here. To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Wed, 7 Sep 1994 12:01:41 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 696 Errors-To: icon-group-errors@cs.arizona.edu I'm finally trying do use the system call on a unix machine. As a test, I'm trying to list the directory into a file by calling 'ls > ls.file' from Icon. Here are the vital statistics; why am I not getting the system function to behave as expected? Icon Interpreter Version 8.10. May 4, 1993 UNIX interpreted ASCII co-expressions direct execution environment variables error trace back external functions fixed regions keyboard functions large integers math functions multiple regions pipes string invocation system function > cat test.icn procedure main() system("ls > ls.file") end > icont test Translating: test.icn: main No errors Linking: > test > ls outline test* test.icn From icon-group-sender Wed Sep 7 10:34:03 1994 Received: by cheltenham.cs.arizona.edu; Wed, 7 Sep 1994 10:43:55 MST Date: Wed, 7 Sep 1994 10:34:03 -0700 From: Gregg Townsend Message-Id: <199409071734.KAA07922@owl.CS.Arizona.EDU> To: eschen@molbio.cbs.umn.edu Cc: icon-group@owl Subject: Re: What's wrong here. Content-Length: 164 Errors-To: icon-group-errors@cs.arizona.edu From: "Art Eschenlauer" > icont test > test What's your $PATH setting? Are you perhaps executing /bin/test here? From icon-group-sender Wed Sep 7 11:16:38 1994 Received: by cheltenham.cs.arizona.edu; Wed, 7 Sep 1994 12:15:31 MST Date: Wed, 7 Sep 1994 11:16:38 +0700 From: swampler@noao.edu Message-Id: <9409071816.AA05287@orpheus.gemini.edu> Subject: Re: What's wrong here. To: gmt@cs.arizona.edu Cc: icon-group@cs.arizona.edu Content-Length: 322 Errors-To: icon-group-errors@cs.arizona.edu Many shells have 'test' as a builtin, so it doesn't matter what the path is! If ./test doesn't work, then there's a more serious problem. (I've been bitten by this enough times that I never call a program 'test' anymore, but 'tst' or just plain 't'...) -- Steve Wampler swampler@gemini.edu Gemini Project (under AURA) From icon-group-sender Wed Sep 7 12:12:42 1994 Received: by cheltenham.cs.arizona.edu; Wed, 7 Sep 1994 15:56:06 MST To: icon-group-l@cs.arizona.edu Date: 7 Sep 1994 12:12:42 -0700 From: icon-project@cs.arizona.edu Message-Id: <34l3ba$cba@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Frequently Asked Questions About The Icon Programming Language last updated: 08/21/94 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 602-621-8448 (voice) 602-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Fri Sep 9 03:19:28 1994 Received: by cheltenham.cs.arizona.edu; Fri, 9 Sep 1994 05:27:45 MST To: icon-group-l@cs.arizona.edu Date: 9 Sep 1994 03:19:28 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Message-Id: <34ok80$nnb@lowell.bellcore.com> Organization: Bellcore, Morristown NJ Sender: icon-group-request@cs.arizona.edu References: <347vun$qkb@ios.com>, <1994Sep4.220207.10360@midway.uchicago.edu>, <34gaps$ste@ios.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu In article <34gaps$ste@ios.com>, Nick Williams wrote: >I just don't see what is wrong with standardizing an Icon library of >system specific functions. If standard would be welcome I would >volunteer time to write/implement it. I would be thrilled. To write my internet clients in Icon I have resorted to the UGLY expedient of writing a C program that opens a TCP connection, forces standard input and standard output to the connection, then exec's an Icon program. Of course, I can't easily write servers this way if they have peresistent state :-( Norman From icon-group-sender Tue Sep 13 15:29:44 1994 Received: by cheltenham.cs.arizona.edu; Tue, 13 Sep 1994 13:00:49 MST Date: Tue, 13 Sep 1994 15:29:44 -0500 (EST) From: EEID@ACAD.ALBION.EDU Subject: History? To: icon-group@cs.arizona.edu Message-Id: <01HH2H4FTUAQ94DZ7A@ACAD.ALBION.EDU> X-Vms-To: IGROUP Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu In a class today, the professor mentioned a book that was written by the creator of C++, describing the evolution of that language. I was wondering if there is an equivalent book or files available via ftp that detail the growth of Icon, from version 1 on up. Just a curiosity thing... (*----------+--------+--------------------------------*) (* Erik Eid | "Wisp" | EEID@ACAD.ALBION.EDU *) (*----------+--------+------+----------------+--------*) (* Computational Math major | Albion College | Senior *) (*--------------------------+----------------+--------*) From icon-group-sender Tue Sep 13 16:08:19 1994 Received: by cheltenham.cs.arizona.edu; Tue, 13 Sep 1994 18:37:38 MST To: icon-group-l@cs.arizona.edu Date: 13 Sep 1994 16:08:19 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <355bd3$5cl@baskerville.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3554s2$hn2@vixen.cso.uiuc.edu> Subject: Re: Cannot connect to cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu In article <3554s2$hn2@vixen.cso.uiuc.edu>, johnson r scott wrote: >Hi, I cannot connect to cs.arizona.edu. I get the response: >"Unknow host". What can I do about it? Try 192.12.69.5 -Dave From icon-group-sender Mon Sep 19 14:13:49 1994 Received: by cheltenham.cs.arizona.edu; Mon, 19 Sep 1994 08:57:54 MST To: icon-group-l@cs.arizona.edu Date: Mon, 19 Sep 1994 14:13:49 GMT From: ron@mlfarm.com (Ronald Florence) Message-Id: Organization: Maple Lawn Farm, Stonington, CT Sender: icon-group-request@cs.arizona.edu Subject: Version 8 --> Version 9 Errors-To: icon-group-errors@cs.arizona.edu Most of the new improvements listed in The Icon Newsletter announcement of Version 9 sound very good indeed, but I have mixed feelings about the need to rewrite code that uses graphics functions. Has anyone written an icon program (or perhaps a sed or awk script) to automate the rewriting of Version 8 Icon programs so they are compatible with Version 9? Thanks. -- Ronald Florence From icon-group-sender Mon Sep 19 09:05:45 1994 Received: by cheltenham.cs.arizona.edu; Mon, 19 Sep 1994 09:06:06 MST Date: Mon, 19 Sep 1994 09:05:45 MST From: "Ralph Griswold" Message-Id: <199409191605.AA01643@cheltenham.cs.arizona.edu> To: ron@mlfarm.com Subject: Re: Version 8 --> Version 9 Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu We've provided support for converting graphics from Version 8.10 to 9.0, as well as a compatibility package that makes most Version 8.10 programs run under 9.0 without modification. See pp. 48-49 in IPD255 (the Version 9.0 graphics reference manual). Ultimately, however, you'll want to convert. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 602-621-6609 (voice) Tucson, AZ 85721 602-621-4246 (fax) From icon-group-sender Mon Sep 19 17:27:42 1994 Received: by cheltenham.cs.arizona.edu; Mon, 19 Sep 1994 12:12:38 MST To: icon-group-l@cs.arizona.edu Date: 19 Sep 1994 17:27:42 GMT From: espie@pavot.ens.fr (Marc Espie) Message-Id: <35khme$rl1@nef.ens.fr> Organization: Ecole Normale Superieure, PARIS, France Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Version 8 --> Version 9 Errors-To: icon-group-errors@cs.arizona.edu In article , Ronald Florence wrote: >Most of the new improvements listed in The Icon Newsletter >announcement of Version 9 sound very good indeed, but I have mixed >feelings about the need to rewrite code that uses graphics functions. >Has anyone written an icon program (or perhaps a sed or awk script) to >automate the rewriting of Version 8 Icon programs so they are >compatible with Version 9? > >Thanks. There already are a bunch of icon sources in the ipl library that establish compatibility with the old version 8. Except for some name changes, some new protocols (like opening windows through WOpen) are actually wrappers around the old open(... ,"x") function, so porting code mostly is trivial. There is now a full documentation for the vidget library, which, though imperfect, is usable for small-scale projects. By all means, upgrade. As far as rewriting icon source should go, it should obviously be cast in terms of a meta-variant translator :-), not a pesky un-iconish sed/awk script (not portable outside of unix anyway) -- [nosave] `Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai) `$@0>@n(J $@$N$3$H!<9%$-$@$h!#(J' ($@$"$NF|$K5"$j$?$$(J)(B Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Tue Sep 20 14:41:36 1994 Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 08:32:44 MST To: icon-group-l@cs.arizona.edu Date: Tue, 20 Sep 1994 14:41:36 GMT From: eddie@festival.ed.ac.uk (Eddie Corns) Message-Id: Organization: Edinburgh University Sender: icon-group-request@cs.arizona.edu References: <1994Sep4.220207.10360@midway.uchicago.edu>, <34gaps$ste@ios.com>, <34ok80$nnb@lowell.bellcore.com> Subject: Re: Icon - still alive?? Errors-To: icon-group-errors@cs.arizona.edu norman@flaubert.bellcore.com (Norman Ramsey) writes: >In article <34gaps$ste@ios.com>, Nick Williams wrote: >>I just don't see what is wrong with standardizing an Icon library of >>system specific functions. If standard would be welcome I would >>volunteer time to write/implement it. >I would be thrilled. To write my internet clients in Icon I have >resorted to the UGLY expedient of writing a C program that opens a TCP >connection, forces standard input and standard output to the >connection, then exec's an Icon program. Of course, I can't easily >write servers this way if they have peresistent state :-( After observing this thread for a while. Icon is, as we all know, good at data processing. Quite often if you rethink your strategy you can arrange to have a small program generate the data and then feed that data into Icon for processing. This is after all one of the worthwile philosophies on which unix was based. Obviously this wouldn't be suitable for all cases, especially where decisions had to be made on the contents of the data for subsequent actions. Rather than try to reshape the language for system tasks, perhaps we could simply extend the I/O interface so that, given a suitable bit of code, we could open anything from a TCP socket to a directory to whatever. If this all went through the open/read/write interface there would be no loss of portability and no trying to change the language away from its data processing style. There would probably need to be an equivalent to ioctl as well. Just a thought. Eddie From icon-group-sender Tue Sep 20 13:38:49 1994 Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 12:32:53 MST Date: Tue, 20 Sep 1994 13:38:49 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9409201838.AA20878@runner.utsa.edu> To: eddie@festival.ed.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: (eddie@festival.ed.ac.uk) Subject: Re: Icon - still alive?? Content-Length: 1173 Errors-To: icon-group-errors@cs.arizona.edu Eddie Corns writes: > Rather than try to reshape the language for system tasks, perhaps > we could simply extend the I/O interface so that, given a suitable > bit of code, we could open anything from a TCP socket to... whatever. > If this all went through the open/read/write interface there would be > no loss of portability and no trying to change the language... > There would probably need to be an equivalent to ioctl as well. This is a good starting point. One can start with a nice, clean, file-based model, and add many of these capabilities with no change to the language. Once an initial implementation is working, experience suggests that: (a) there will be *pressure* to add features ad nauseum, until it is hideous, complex, and hard to learn. (b) there will be *potential* to significantly improve the interface by adding language support in the form of control structures, keywords, etc. For example, ioctl() is ugly, and there may be nicer notations for manipulating connections waiting to be discovered. Clint Jeffery cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Tue Sep 20 15:41:27 1994 Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 14:33:31 MST From: "Art Eschenlauer" Message-Id: <9409202041.AA18914@molbio.cbs.umn.edu> Subject: Question: conjunction in Icon and C To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Tue, 20 Sep 1994 15:41:27 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 486 Errors-To: icon-group-errors@cs.arizona.edu Hi: I have a C question that Icon'ers are more likely to understand than the average run-of-the-mill C programmer, so here goes. In Icon, if I say: if & then else and fails, will not be evaluated. In C, if I say: if ( && ) ; else ; and has a value of zero (NULL, etc.), is it defined (in the ANSI standard, I guess) whether will be evaluated or is this compiler specific? Thanks, -Art From icon-group-sender Tue Sep 20 15:30:41 1994 Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 15:46:32 MST From: Nevin Liber Message-Id: <199409202230.PAA03229@caslon.CS.Arizona.EDU> Subject: Re: Question: conjunction in Icon and C To: eschen@molbio.cbs.umn.edu (Art Eschenlauer) Date: Tue, 20 Sep 1994 15:30:41 -0700 (MST) Cc: icon-group@cs.arizona.edu In-Reply-To: <9409202041.AA18914@molbio.cbs.umn.edu> from "Art Eschenlauer" at Sep 20, 94 03:41:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1024 Errors-To: icon-group-errors@cs.arizona.edu Art Eschenlauer proudly drove the following message along the Information SuperHypeway(TM) at breakneck speeds: > In Icon, if I say: > if & then else > and fails, will not be evaluated. > > In C, if I say: > if ( && ) ; else ; > and has a value of zero (NULL, etc.), is it defined (in the ANSI > standard, I guess) whether will be evaluated or is this compiler > specific? In C, if has a value of 0, then is not evaluated, and the value of the expression ( && ) is 0. If has a non-zero (true) value, then is evaluated, and the value of the expression ( && ) is 0 if is 0, otherwise, the value is 1 (unlike Icon, where you might expect it to be the same as ). This is specified in both K&R 1 as well as the ANSI C standard. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ^^^ (520) after 3/95 From icon-group-sender Wed Sep 21 09:12:45 1994 Received: by cheltenham.cs.arizona.edu; Wed, 21 Sep 1994 04:36:08 MST Message-Id: <9409210805.AA06761@eithne.aldiscon.ie> From: Simon Chapman Subject: Re: Question: conjunction in Icon and C To: Art Eschenlauer Date: Wed, 21 Sep 1994 09:12:45 +0100 (BST) Cc: icon-group@cs.arizona.edu In-Reply-To: <9409202041.AA18914@molbio.cbs.umn.edu> from "Art Eschenlauer" at Sep 20, 94 03:41:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1212 Errors-To: icon-group-errors@cs.arizona.edu Art Eschenlauer scribbles: > > I have a C question that Icon'ers are more likely to understand than the > average run-of-the-mill C programmer, so here goes. I'm sure that C programmers would actually be better, but anyhow .... > > In Icon, if I say: > if & then else > and fails, will not be evaluated. > > In C, if I say: > if ( && ) ; else ; > and has a value of zero (NULL, etc.), is it defined (in the ANSI > standard, I guess) whether will be evaluated or is this compiler > specific? > Looking at my Que C Quick Reference and ANSI K & R, the two logical operators && and || are subject to what the former calls "Short Circuit Evaluation" which does as you say, namely if evaluates to 0, will NOT be evaluated. Both operators guaranteed left to right evaluation. -- +-------------------------------------------------+ | Aldiscon Ltd., | simon chapman | | Hambleden House, | simonc@aldiscon.ie | | Lwr. Pembroke St., | Ph.: +353.1.6053183 direct | | Dublin 2, Ireland. | (incl. Voice mail ) | +-------------------------------------------------+ From icon-group-sender Fri Sep 23 10:14:34 1994 Received: by cheltenham.cs.arizona.edu; Fri, 23 Sep 1994 11:13:54 MST Via: uk.ac.edinburgh.festival; Fri, 23 Sep 1994 18:13:42 +0100 Acknowledge-To: eddie@festival.edinburgh.ac.uk To: jeffery@runner.jpl.utsa.edu Cc: icon-group@cs.arizona.edu In-Reply-To: "Clinton L. Jeffery"'s message of Tue, 20 Sep 1994 13:38:49 +0600 <9409201838.AA20878@runner.utsa.edu> Subject: Icon - still alive?? From: eddie@festival.ed.ac.uk Date: Fri, 23 Sep 94 18:14:08 BST Message-Id: <9409231814.aa28955@uk.ac.ed.festival> Errors-To: icon-group-errors@cs.arizona.edu Date: Tue, 20 Sep 1994 13:38:49 +0600 From: "Clinton L. Jeffery" content-length: 1173 This is a good starting point. One can start with a nice, clean, file-based model, and add many of these capabilities with no change to the language. Once an initial implementation is working, experience suggests that: (a) there will be *pressure* to add features ad nauseum, until it is hideous, complex, and hard to learn. (b) there will be *potential* to significantly improve the interface by adding language support in the form of control structures, keywords, etc. For example, ioctl() is ugly, and there may be nicer notations for manipulating connections waiting to be discovered. Thanks for your comments, I guess the problem here is that we system programmers don't have a decent language to use and those of us who use Icon in the more normal way would like to be able to use it in different environments too. Especially now it has the graphics interface, making user-friendly system tools would be really nice. Because obviously the other users don't want to be encumbered with the extra features then I suppose what we need is a specialised version. If I had the time and ability I might look into adding some simple realtime and extended communication abilities for myself. Eddie From icon-group-sender Mon Sep 26 03:17:50 1994 Received: by cheltenham.cs.arizona.edu; Mon, 26 Sep 1994 05:35:28 MST To: icon-group-l@cs.arizona.edu Date: 26 Sep 94 10:09:48 BST From: g.landini@bham.ac.uk (Gabriel Landini) Message-Id: <940926100948@ibm3090.bham.ac.uk> Organization: The University of Birmingham, United Kingdom Sender: icon-group-request@cs.arizona.edu Subject: sort() but descending? Errors-To: icon-group-errors@cs.arizona.edu ============================================================================== Hi, I am just a beginner in Icon. Looking in the library files, I found an interesting one tablw.icn which finds the frequency of words in a text. However, the listing is from less-frequent to more frequent. I would like to sort that list from more frequent to less frequent, but I cannot find the way to do it. Any ideas? Does the sort(0 and sortf() only sort in ascending order? thanks Gabriel G.Landini@bham.ac.uk From icon-group-sender Mon Sep 26 14:32:38 1994 Received: by cheltenham.cs.arizona.edu; Mon, 26 Sep 1994 05:35:35 MST Date: Mon, 26 Sep 1994 14:32:38 +0300 (WET) From: Zvi Lamm Subject: Efficiency in Icon MVS? To: icon-group@cs.arizona.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu I am considering using Icon for MVS for system work. Mainly for analyzing (sort of search & replace) large amounts of text. Can someone comment on the I/O efficiency of Icon/MVS? Ehud From icon-group-sender Mon Sep 26 14:02:29 1994 Received: by cheltenham.cs.arizona.edu; Mon, 26 Sep 1994 08:48:09 MST To: icon-group-l@cs.arizona.edu Date: Mon, 26 Sep 1994 14:02:29 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: <1994Sep26.140229.22474@midway.uchicago.edu> Organization: University of Chicago Sender: icon-group-request@cs.arizona.edu References: <940926100948@ibm3090.bham.ac.uk> Reply-To: goer@midway.uchicago.edu Subject: Re: sort() but descending? Errors-To: icon-group-errors@cs.arizona.edu Gabriel Landini writes: > >I would like to sort that list from more frequent to less frequent, but I >cannot find the way to do it. Any ideas? >Does the sort(0 and sortf() only sort in ascending order? >thanks The sort order is predefined, in ascending order. Presumably the reason for this so that we don't have sorted lists floating around with different sort orders. One size fits all. Of course it's easy enough to use elements from sorted lists in any order. In Icon you have ready access to any element within a list. E.g. for as- cending order: l := sort(x) every element := !l do { do something with element ... Or, if you don't need to keep l around - every element := !sort(x) do { do something with element ... For descending order: l := sort(x) every i := *x to 1 by -1 do { do something with x[i] ... Does this seem to help any? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Sep 26 14:33:11 1994 Received: by cheltenham.cs.arizona.edu; Mon, 26 Sep 1994 08:48:36 MST To: icon-group-l@cs.arizona.edu Date: Mon, 26 Sep 1994 14:33:11 GMT From: plat@let.rug.nl (Bert Plat) Message-Id: <1994Sep26.143311.10704@let.rug.nl> Organization: Faculteit der Letteren, Rijksuniversiteit Groningen, NL Sender: icon-group-request@cs.arizona.edu Subject: Problem reading block of text Errors-To: icon-group-errors@cs.arizona.edu Even though I've managed to work around it, I would like to hear *the* ICON solution to the following problem: I have a file of text, containing separate entities, each of which starts with a colon. I.e.: :start of entity lines and lines and more lines of text :start of next entity lines lines and more lines Now, what is the most elegant and ICONesque way to obtain these entities one by one? I've worked around it by concatenating lines, suspend when match(":", line), then resuming with line := inline || "\n", but I wonder if there's a better way. What if, for example, I want to build an array of strings? best, -- . . . Bert Plat (bplat@rugrcx.rug.nl) . . . . . . . . . . . . . . . . . From icon-group-sender Mon Sep 26 21:59:10 1994 Received: by cheltenham.cs.arizona.edu; Mon, 26 Sep 1994 19:26:40 MST To: icon-group-l@cs.arizona.edu Date: Mon, 26 Sep 1994 21:59:10 GMT From: toni@usenix.org (Toni Veglia) Message-Id: Organization: USENIX Association, Berkeley, CA Sender: icon-group-request@cs.arizona.edu Reply-To: toni@usenix.org (Toni Veglia) Subject: USENIX Very High Level Languages Symposium -Hotel Res. Deadline Errors-To: icon-group-errors@cs.arizona.edu USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES (VHLL) OCTOBER 26 - 28, 1994 EL DORADO HOTEL SANTA FE, NEW MEXICO *********************************************** IMPORTANT DATES TO REMEMBER: Hotel Reservation Deadline: September 26, 1994 Pre-Registration Deadline: October 12, 1994 THIS POSTING CONTAINS: Technical Session Descriptions Schedule of Events Hotel and General Conference Information Registration Form *********************************************** The USENIX Symposium on Very High Level Languages will spotlight high level languages and their usefulness in leveraging specific problem areas. The Symposium will introduce participants to new concepts and approaches through original unpublished work. Programmers will learn about the relative strengths and weaknesses and extract the key concepts common to the languages presented. Using very high level languages (VHLLs), programmers can assemble entire applications from large building blocks in just a small fraction of the time required if conventional programming strategies were used. Programmers take advantage of increasingly available hardware cycles, trading cheap machine time for costly programmer time. VHLLs offer one of the most promising approaches toward radically improving programmer productivity. UNIX has long supported very high level languages -- consider AWK and the various shells. Often programmers create new little languages whenever a problem appears of sufficient complexity to merit a higher level programming interface -- consider sendmail.cf. In recent years many UNIX programmers have turned to VHLLs for rapid prototypes and complete applications. They take advantage of these languages' higher level of abstraction to complete projects more rapidly and easily than they could with lower level languages. While VHLLs such as TCL, Perl, Icon, and REXX have gained widespread use and popularity, many others never see the public light. Some of these languages address a limited problem domain (such as graphics, text processing, or mathematical modeling) using powerful primitives created for that specific problem. Other VHLLs are more general-purpose, but still much higher level than most traditional compiled languages. Some are stand-alone languages, while others can be embedded in other programs. Many are interpreted, although some are compiled to native machine code; a few occupy a gap between both worlds. This Symposium will feature: ============================ Three days of refereed technical sessions, including: -Wednesday -- Hour-long overviews of VHLLs in use today: Icon, TCL, Perl, Python, and REXX -Thursday -- An overview of ML Engaging after-dinner Invited Talks on Wednesday Birds-of-a-Feather Sessions (BOFS) Wednesday and Thursday PRELIMINARY TECHNICAL PROGRAM Wednesday-Friday, October 26-28, 1994 ===================================== WEDNESDAY, OCTOBER 26 Keynote Address: Languages I've Loved -- 8:45-9:45 Dr. Jon Bentley, AT&T Bell Laboratories Good languages get the job done; they are useful and clean, but they don't have fans. Great languages will inspire passionate users. This talk surveys some of the languages that I have loved, from AWK to Visual Basic. I will illustrate the languages with the kinds of programs I would like to see in documentation; tiny programs to display language features and small programs that solve substantial problems. Jon L. Bentley is a Member of Technical Staff in the Computing Science Research Center at AT&T Bell Laboratories. His research interests include programming techniques and algorithm design. Dr. Bentley received a B.S. degree in Mathematical Sciences from Stanford University in 1974, and M.S. and Ph.D. degrees in Computer Science from the University of North Carolina in 1976. He is the author of three books: Writing Efficient Programs, Programming Pearls, and More Programming Pearls. Language Overview: Perl -- 10:15 - 11:15 Larry Wall, NetLabs, Inc. Originally perceived as a text-processing language for writing impenetrable one-liners, Perl has recently developed into a language that can be used in polite company. Larry Wall, the author of Perl, will talk about what happens when you try to combine all your favorite languages into one language. He'll present the original design rationale for Perl, and how "Perl philosophy" is evolving with the development of Perl version 5, and why you should care. Language Overview: TCL - A Universal Scripting Language 11:15-12:15 Dr. John Ousterhout, Sun Microsystems, Inc. In this talk I will give a brief overview of Tcl, a universal scripting language, and Tk, its companion GUI toolkit. Then I will discuss how the Tcl language evolved and the design issues behind it. Finally, I will critique the language and describe what I would do differently if I were to start again. Language Overview: Python Programming Language -- 1:30-2:30 Guido van Rossum, CWI Python is an interpreted, object-oriented language with a clear, intuitive syntax, powerful high-level data structures, and a flexible dynamic type system. It provides modules and classes which make the construction of large Python programs feasible. The talk will start with a quick introduction to Python, then discuss the rationale of its design, and round off with a look in the crystal ball. Language Overview: REXX -- 2:30-3:30 Pamela J. Taylor, REXX Language Association, The Workstation Group REXX is a versatile language used for applications that include "throw-away" procedures, "glue" programs, prototyping, systems administration, and mission-critical business applications. This presentation will discuss: The philosophy of the language and the history of its development; features that make it easy to learn, use and suited for a broad range of applications. Language Overview: Icon Programming Languagea -- 4:00-5:00 Dr. Clinton Jeffery, University of Texas - San Antonio Icon is a general-purpose programming language derived from Snobol4. It's primary innovation is an expression evaluation model that integrates procedural programming with generators and backtracking. This is matched in utility by a large repertoire of built-in operations and heterogeneous structures. An optimizing compiler and portability to platforms ranging from supercomputers and IBM mainframes to many PC operating systems broaden Icon's appeal. Invited Talk: From Blazon to Postscript -- 7:00-8:30pm Daniel V. Klein, LoneWolf Systems Invited Talk: Objecting to Objects -- 8:30-10:00pm Stephen C. Johnson, Melismatic Software THURSDAY, OCTOBER 27 Language Overview: Standard ML -- 8:30-9:30 Andy Koenig, AT&T Bell Laboratories Standard ML is a strongly typed general-purpose language with particularly good support for functional programming, data abstraction, and composition of modules. It feels a little like strongly typed Lisp with different syntax. A robust compiler that generates fast machine code is available free of charge. SESSION 1 -- 10:00-11:30 An Anecdote About ML Type Inference Andy Koenig, AT&T Bell Laboratories libscheme: Scheme as a C Library Brent Benson Jr., Harris Computer Systems A New Architecture for the Implementation of Scripting Languages Adam Sah and Jon Blow, University of California, Berkeley SESSION 2 -- 1:00-2:30 Tcl/Tk for a Personal Digital Assistant Karin Petersen, Xerox PARC Using Tcl to Control a Computer-Participative Multimedia Programming Environment Christopher Lindblad, Massachusetts Institute of Technology TkPerl - - A Port of the Tk Toolkit to Per15 Malcolm Beattie, Oxford University SESSION 3 -- 3:00-4:30 Rapid Programming with Graph Rewrite Rules Andy Schuerr, Aachen University of Technology End-User Systems, Reusability, and High-Level Design John Snyder, Kiem-Phong Vo and Glenn Fowler, AT&T Bell Laboratories Compiling Matlab Stephen C. Johnson, Melismatic Software; Cleve Moler, The Mathworks, Inc. Invited Talk: Lessons Learned from Postscript -- 4:30-5:30 Dick Dunn, QMS Inc. USENIX RECEPTION -- 6:00-8:00 FRIDAY, OCTOBER 28 SESSION 4 -- 8:30 - 10:00 Ksh: An Extensible High-Level Language David Korn, AT&T Bell Laboratories Fornax: A General-Purpose Programming Language J. Storrs Hall, Rutgers University Graphics Programming in Icon Version 9 Clinton Jeffery, University of Texas - San Antonio; Ralph Griswold and Gregg Townsend, University of Arizona SESSION 5 -- 10:30-11:30 Application Languages in Software Production David Ladd and Christopher Ramming, AT&T Bell Laboratories Using a Very-High Level Language to Build Familities of High Quality Resuable Components Gary Pollice, CenterLine Software, Inc. SESSION 6 -- 1:00-2:00 Dixie: A Distributed Internet Execution Environment R. Stockton Gaines, University of Southern California, Information Sciences Institute Feature-Based Portability Glenn Fowler, David Korn, John Snyder and Kiem-Phong Vo, AT&T Bell Laboratories Footnote: High-Level Languages, Little Languages, and Software Productivity -- 2:00-3:00 Stephen C. Johnson, Melismatic Software Traditional methods of writing software are pricing themselves out of the market. For a while, traditional software methods will survive through offshore manufacturing, but the future belongs to high level languages both general purpose and special purpose ("little languages")--that can exploit cheap machine cycles to replace expensive programmers, shorten design cycles, and even lead to "user configurable" software. Closing Remarks -- 3:00 Tom Christiansen, Consultant PROGRAM COMMITTEE ================= Program Chair: Tom Christiansen, Consultant Jon Bentley, AT&T Bell Laboratories Stephen C. Johnson, Melismatic Software Brian Kernighan, AT&T Bell Laboratories John Ousterhout, University of California, Berkeley Henry Spencer, University of Toronto Larry Wall, NetLabs, Inc. IMPORTANT SYMPOSIUM DATES & SCHEDULE OF EVENTS ============================================== Pre-Registration Deadline: October 12, 1994 Hotel Reservation Deadline: September 26, 1994 TUESDAY, October 25 6:00pm - 9:00pm - Registration & Welcome Reception WEDNESDAY, October 26 8:30am - 5:00pm - Technical Sessions 7:00pm - 10:00pm - Invited Talks 7:00pm -11:00pm - Birds of a Feather Sessions THURSDAY, October 27 8:30am - 5:30pm - Technical Sessions and Invited Talk 6:00pm - 8:00pm - Symposium Reception 8:00pm - 11:00pm - Birds of a Feather Sessions FRIDAY, October 28 8:30am - 3:00pm - Technical Sessions HOTEL INFORMATION ================= Room reservation deadline is September 26 1994. The Symposium headquarters will be: Eldorado Hotel 309 W. San Francisco Street Santa Fe, New Mexico Telephone: +1 (505) 988-4455 Tollfree: +1 (800) 762-2333 ROOM RATES: $110.00 Single/Double Occupancy (Plus prevailing tax, currently at 10.125%) YOU SHOULD BE AWARE - the hotel has indicated there is a strong possibility that rooms will not be available after the September 26th deadline. It is strongly recommended that you make your room reservations EARLY, even if your attendance and travel plans are not confirmed. Should you desire to cancel your room reservations, you must notify the hotel at least 72 hours in advance. To Make Your Reservation: Call the Hotel directly and ask for the Reservations Desk. Tell reservations that you are a USENIX Attendee to take advantage of our group rate. A one nights deposit is required for all reservations. Should you desire to cancel your reservation, you must notify the hotel at least 72 hours prior to your scheduled arrival. DO YOU KNOW THE WAY TO SANTA FE? ================================ Air Transportation: Albuquerque International Airport is the closest major airport to Santa Fe and is serviced by five major carriers. Santa Fe has its own small municipal airport which offers commuter service from Albuquerque and Denver. Getting from Albuquerque to Santa Fe: Santa Fe is located just off Interstate 25, 60 miles north of Albuquerque. You may make commuter airline arrangements, rent a car, or take the shuttle transportation to reach Santa Fe. Information is shown below: Commuter Airline: Mesa Airlines, +1 (505) 473-4118 Car Rental Agencies: Avis, Budget, Enterprise, Hertz, Payless, Dollar, National, Sears and Alamo Shuttle Transportation: Shuttlejack provides bus transportation service from 6:40am to 10:45pm, every two hours (10 times daily) between the Albuquerque International Airport and the Eldorado Hotel in Santa Fe. Reservations ARE required for this service. Payment must be paid by cash or travelers checks. It is highly recommended that you call Shuttlejack BEFORE you make your flight arrangements to coordinate your flight arrival time with your shuttle service and verify their current time schedule and seating availability. To make your reservation, call: Telephone: +1-505-982-4311 Current Cost: $20 one way USENIX RECEPTION You are invited to join in the fun, mingle with old and new friends and enjoy the plentiful hors d'oeuvres and beverages. The USENIX reception is Thursday, October 27, from 6:00-8:00pm. BIRDS OF A FEATHER SESSIONS On Wednesday evening October 26th BOFs will be held from 7:00pm - 11:00pm and Thursday evening, October 27th from 8:00pm - 11:00pm. If you wish to schedule a BOF, contact a USENIX staff person upon your arrival at the symposium. CONFERENCE PROCEEDINGS: One copy of the proceedings is included with your Technical Sessions registration fee. If you wish to order additional copies, you may contact the USENIX Association Executive Office at Telephone +1 (510) 528-8649, or direct your email to: office@usenix.org. POINTS OF INTEREST Santa Fe's elevation is approximately 7,000 feet above sea level. It is known to have 300+ days of sunshine. Santa Fe is indeed "a city of museums", both state operated and private facilities. Some museums include: Museum of New Mexico including the Palace of the Governors; Fine Arts Museum of Indian Art and Culture; the Laboratory of Anthropology; The Wheelwright Museum of the American Indian; Institute of American Indian Arts and the Children's Museum. More than 200 art galleries display a vast array of works by noted regional artists, photographers and craftspersons. The Santa Fe Ski Basin is located only 18 miles from Santa Fe and Taos is just over an hour away. ABOUT USENIX Since 1975, the USENIX Association has provided a forum for the communication of the results of innovation and research in UNIX and modern open systems. It is well known for its technical conferences, tutorial programs, and the wide variety of publications it has sponsored over the years. USENIX is the original (we celebrate our 20th anniversary in 1995), not-for-profit membership organization for individuals and institutions interested in UNIX and UNIX-like systems, by extension, X, object-oriented technology, and other advanced tools and technologies, and the broad interconnected and interoperable computing enviornment. USENIX and its members are dedicated to: * fostering innovation and research that works, * communicating rapidly the results of both research and innovation, * providing a neutral forum for the exercise of critical thought and the airing of technical issues. FOR FURTHER SYMPOSIUM INFORMATION, PLEASE CONTACT: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone +1 (714) 588-8649 FAX Number +1 (714) 588-9706 Electronic Mail Address: conference@usenix.org Office Hours: 8:30am - 5:00pm Pacific Time REGISTRATION INFORMATION ======================== REGISTER EARLY TO SAVE! PRE-REGISTRATION DEADLINE: October 12, 1994 REGISTRATION FEES ARE $50 HIGHER AFTER THAT DATE! Pre-registration *Member Non-member Full-time Student (Before Oct. 12, 1994) $295.00 $360.00 $75.00 Registration (Aft Oct. 12, 1994)$345.00 $410.00 $75.00 *The member rate applies to current individual members of the USENIX Association, EurOpen , JUS and AUUG. Full-time students please note: A limited number of scholarships are available for full-time students. Contact the Conference Office for details. Enjoy the Benefits of Becoming a USENIX Member - If you are not a current USENIX member and wish to join, pay the non-member fee on the registration form and check the special box requesting membership. $65 of your non-member fee will be designated as dues in full for a one-year individual USENIX Association membership. Please complete and return the enclosed registration form with your payment. You may pay by check (MAKE CHECK PAYABLE TO USENIX CONFERENCE) or use your VISA, MasterCard, Diners Club or American Express charge card. Payment MUST accompany registration form. Purchase orders and vouchers are NOT accepted. NOTE: You may FAX your registration form if paying by credit card. (To avoid duplicate billing when faxing your registration, do not mail an additional copy to the Conference Office. You may telephone the conference office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than October 19, 1994. Direct your letter to the USENIX Conference Office. You may telephone to substitute another in your place. ==========================cut here================================ ****************************************************************** REGISTRATION FORM - USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES ****************************************************************** Please complete the form below and return to the USENIX Conference office (address below). NAME________________________________________________________________ (first) (last) FIRST NAME FOR BADGE____________________________ COMPANY OR INSTITUTION______________________________________________ MAILING ADDRESS_____________________________________________________ CITY___________________________STATE_____COUNTRY________ZIP____________ TELEPHONE NO:_________________________FAX NO.___________________________ NETWORK ADDRESS______________________________________________________ (Please write legibly) If you do NOT want to appear in the attendee list, check here: ___ Is this your first USENIX Conference? ___Yes ___No What is your affiliation? ___ Academic ___ Commercial ___ Gov't. Are you a current member of the USENIX Association? ___ Yes ___No (If you wish to join USENIX see below.*) The address you provide will be used for all future USENIX mailings unless you notify us in writing. ========================================================== FEE SCHEDULE for TECHNICAL SESSIONS TECHNICAL SESSIONS REGISTRATION FEES Wednesday, Thursday, Friday, October 26-28 MEMBER FEE................................................$295.00 _____ The member fee applies to current individual members of the USENIX Association, JUS, EurOpen or AUUG. NON-MEMBER FEE*...........................................$360.00 _____ Late fee applies after October 12, 1994................Add$ 50.00 _____ FULL-TIME STUDENT FEE - Pre-registered/On-Site............$ 75.00 _____ (Students must include photocopy of current student I.D. card with registration form.) TOTAL ENCLOSED...................$_________ *IF YOU WISH TO JOIN OR RENEW USENIX Check Here................... |_| Please take $65.00 of my non-member conference registration fee to pay for a one year indiviudal membership in USENIX. Payments must accompany registration form. Purchase orders and Vouchers not accepted. Payment Enclosed (U.S. Dollars). Make check payable to USENIX CONFERENCE. CHARGE TO MY: ___VISA ___MASTERCARD ___AMERICAN EXPRESS ___DINERS CLUB ACCOUNT NO.______________________________________ EXPIRATION DATE_________ _______________________________________/___________________________ Print Cardholder's Name Cardholder's Signature You may FAX your registration form if paying by credit card to USENIX CONFERENCE OFFICE, FAX +1 714 588 9706. (If you FAX registration, to avoid duplicate billing, do not mail additional copy. You may telephone our office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than October 19, 1994. Direct your letter to the USENIX Conference Office. ******************************************************************** PAYMENT MUST ACCOMPANY REGISTRATION FORM. REGISTRATION VIA EMAIL IS NOT ACCEPTED. ******************************************************************** PLEASE COMPLETE REGISTRATION FORM AND RETURN IT ALONG WITH YOUR FULL PAYMENT TO: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone + 714 588 8649; FAX + 714 588 9706 Internet Address: conference@usenix.org Office Hours: 8:30am-5:00pm Pacific Time From icon-group-sender Mon Oct 3 18:50:27 1994 Received: by cheltenham.cs.arizona.edu; Mon, 3 Oct 1994 17:10:09 MST To: icon-group-l@cs.arizona.edu Date: Mon, 3 Oct 1994 18:50:27 GMT From: toni@usenix.org (Toni Veglia) Message-Id: Organization: USENIX Association, Berkeley, CA Sender: icon-group-request@cs.arizona.edu Reply-To: toni@usenix.org (Toni Veglia) Subject: USENIX Very High Level Languages Symp.- PRE-REG DEADLINE 10/12 Errors-To: icon-group-errors@cs.arizona.edu USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES (VHLL) OCTOBER 26 - 28, 1994 EL DORADO HOTEL SANTA FE, NEW MEXICO *********************************************** IMPORTANT DATES TO REMEMBER: Hotel Reservation Deadline: September 26, 1994 Pre-Registration Deadline: October 12, 1994 THIS POSTING CONTAINS: Technical Session Descriptions Schedule of Events Hotel and General Conference Information Registration Form *********************************************** The USENIX Symposium on Very High Level Languages will spotlight high level languages and their usefulness in leveraging specific problem areas. The Symposium will introduce participants to new concepts and approaches through original unpublished work. Programmers will learn about the relative strengths and weaknesses and extract the key concepts common to the languages presented. Using very high level languages (VHLLs), programmers can assemble entire applications from large building blocks in just a small fraction of the time required if conventional programming strategies were used. Programmers take advantage of increasingly available hardware cycles, trading cheap machine time for costly programmer time. VHLLs offer one of the most promising approaches toward radically improving programmer productivity. UNIX has long supported very high level languages -- consider AWK and the various shells. Often programmers create new little languages whenever a problem appears of sufficient complexity to merit a higher level programming interface -- consider sendmail.cf. In recent years many UNIX programmers have turned to VHLLs for rapid prototypes and complete applications. They take advantage of these languages' higher level of abstraction to complete projects more rapidly and easily than they could with lower level languages. While VHLLs such as TCL, Perl, Icon, and REXX have gained widespread use and popularity, many others never see the public light. Some of these languages address a limited problem domain (such as graphics, text processing, or mathematical modeling) using powerful primitives created for that specific problem. Other VHLLs are more general-purpose, but still much higher level than most traditional compiled languages. Some are stand-alone languages, while others can be embedded in other programs. Many are interpreted, although some are compiled to native machine code; a few occupy a gap between both worlds. This Symposium will feature: ============================ Three days of refereed technical sessions, including: -Wednesday -- Hour-long overviews of VHLLs in use today: Icon, TCL, Perl, Python, and REXX -Thursday -- An overview of ML Engaging after-dinner Invited Talks on Wednesday Birds-of-a-Feather Sessions (BOFS) Wednesday and Thursday PRELIMINARY TECHNICAL PROGRAM Wednesday-Friday, October 26-28, 1994 WEDNESDAY, OCTOBER 26 Keynote Address: Languages I've Loved -- 8:45-9:45 Dr. Jon Bentley, AT&T Bell Laboratories Good languages get the job done; they are useful and clean, but they don't have fans. Great languages will inspire passionate users. This talk surveys some of the languages that I have loved, from AWK to Visual Basic. I will illustrate the languages with the kinds of programs I would like to see in documentation; tiny programs to display language features and small programs that solve substantial problems. Jon L. Bentley is a Member of Technical Staff in the Computing Science Research Center at AT&T Bell Laboratories. His research interests include programming techniques and algorithm design. Dr. Bentley received a B.S. degree in Mathematical Sciences from Stanford University in 1974, and M.S. and Ph.D. degrees in Computer Science from the University of North Carolina in 1976. He is the author of three books: Writing Efficient Programs, Programming Pearls, and More Programming Pearls. Language Overview: Perl -- 10:15 - 11:15 Larry Wall, NetLabs, Inc. Originally perceived as a text-processing language for writing impenetrable one-liners, Perl has recently developed into a language that can be used in polite company. Larry Wall, the author of Perl, will talk about what happens when you try to combine all your favorite languages into one language. He'll present the original design rationale for Perl, and how "Perl philosophy" is evolving with the development of Perl version 5, and why you should care. Language Overview: TCL - A Universal Scripting Language 11:15-12:15 Dr. John Ousterhout, Sun Microsystems, Inc. In this talk I will give a brief overview of Tcl, a universal scripting language, and Tk, its companion GUI toolkit. Then I will discuss how the Tcl language evolved and the design issues behind it. Finally, I will critique the language and describe what I would do differently if I were to start again. Language Overview: Python Programming Language -- 1:30-2:30 Guido van Rossum, CWI Python is an interpreted, object-oriented language with a clear, intuitive syntax, powerful high-level data structures, and a flexible dynamic type system. It provides modules and classes which make the construction of large Python programs feasible. The talk will start with a quick introduction to Python, then discuss the rationale of its design, and round off with a look in the crystal ball. Language Overview: REXX -- 2:30-3:30 Pamela J. Taylor, REXX Language Association, The Workstation Group REXX is a versatile language used for applications that include "throw-away" procedures, "glue" programs, prototyping, systems administration, and mission-critical business applications. This presentation will discuss: The philosophy of the language and the history of its development; features that make it easy to learn, use and suited for a broad range of applications. Language Overview: Icon Programming Languagea -- 4:00-5:00 Dr. Clinton Jeffery, University of Texas - San Antonio Icon is a general-purpose programming language derived from Snobol4. It's primary innovation is an expression evaluation model that integrates procedural programming with generators and backtracking. This is matched in utility by a large repertoire of built-in operations and heterogeneous structures. An optimizing compiler and portability to platforms ranging from supercomputers and IBM mainframes to many PC operating systems broaden Icon's appeal. Invited Talk: From Blazon to Postscript -- 7:00-8:30pm Daniel V. Klein, LoneWolf Systems Invited Talk: Objecting to Objects -- 8:30-10:00pm Stephen C. Johnson, Melismatic Software THURSDAY, OCTOBER 27 Language Overview: Standard ML -- 8:30-9:30 Andy Koenig, AT&T Bell Laboratories Standard ML is a strongly typed general-purpose language with particularly good support for functional programming, data abstraction, and composition of modules. It feels a little like strongly typed Lisp with different syntax. A robust compiler that generates fast machine code is available free of charge. SESSION 1 -- 10:00-11:30 An Anecdote About ML Type Inference Andy Koenig, AT&T Bell Laboratories libscheme: Scheme as a C Library Brent Benson Jr., Harris Computer Systems A New Architecture for the Implementation of Scripting Languages Adam Sah and Jon Blow, University of California, Berkeley SESSION 2 -- 1:00-2:30 Tcl/Tk for a Personal Digital Assistant Karin Petersen, Xerox PARC Using Tcl to Control a Computer-Participative Multimedia Programming Environment Christopher Lindblad, Massachusetts Institute of Technology TkPerl - - A Port of the Tk Toolkit to Per15 Malcolm Beattie, Oxford University SESSION 3 -- 3:00-4:30 Rapid Programming with Graph Rewrite Rules Andy Schuerr, Aachen University of Technology End-User Systems, Reusability, and High-Level Design John Snyder, Kiem-Phong Vo and Glenn Fowler, AT&T Bell Laboratories Compiling Matlab Stephen C. Johnson, Melismatic Software; Cleve Moler, The Mathworks, Inc. Invited Talk: Lessons Learned from Postscript -- 4:30-5:30 Dick Dunn, QMS Inc. USENIX RECEPTION -- 6:00-8:00 FRIDAY, OCTOBER 28 SESSION 4 -- 8:30 - 10:00 Ksh: An Extensible High-Level Language David Korn, AT&T Bell Laboratories Fornax: A General-Purpose Programming Language J. Storrs Hall, Rutgers University Graphics Programming in Icon Version 9 Clinton Jeffery, University of Texas - San Antonio; Ralph Griswold and Gregg Townsend, University of Arizona SESSION 5 -- 10:30-11:30 Application Languages in Software Production David Ladd and Christopher Ramming, AT&T Bell Laboratories Using a Very-High Level Language to Build Familities of High Quality Resuable Components Gary Pollice, CenterLine Software, Inc. SESSION 6 -- 1:00-2:00 Dixie: A Distributed Internet Execution Environment R. Stockton Gaines, University of Southern California, Information Sciences Institute Feature-Based Portability Glenn Fowler, David Korn, John Snyder and Kiem-Phong Vo, AT&T Bell Laboratories Footnote: High-Level Languages, Little Languages, and Software Productivity -- 2:00-3:00 Stephen C. Johnson, Melismatic Software Traditional methods of writing software are pricing themselves out of the market. For a while, traditional software methods will survive through offshore manufacturing, but the future belongs to high level languages both general purpose and special purpose ("little languages")--that can exploit cheap machine cycles to replace expensive programmers, shorten design cycles, and even lead to "user configurable" software. Closing Remarks -- 3:00 Tom Christiansen, Consultant PROGRAM COMMITTEE ================= Program Chair: Tom Christiansen, Consultant Jon Bentley, AT&T Bell Laboratories Stephen C. Johnson, Melismatic Software Brian Kernighan, AT&T Bell Laboratories John Ousterhout, University of California, Berkeley Henry Spencer, University of Toronto Larry Wall, NetLabs, Inc. IMPORTANT SYMPOSIUM DATES & SCHEDULE OF EVENTS ============================================== Pre-Registration Deadline: October 12, 1994 Hotel Reservation Deadline: September 26, 1994 TUESDAY, October 25 6:00pm - 9:00pm - Registration & Welcome Reception WEDNESDAY, October 26 8:30am - 5:00pm - Technical Sessions 7:00pm - 10:00pm - Invited Talks 7:00pm -11:00pm - Birds of a Feather Sessions THURSDAY, October 27 8:30am - 5:30pm - Technical Sessions and Invited Talk 6:00pm - 8:00pm - Symposium Reception 8:00pm - 11:00pm - Birds of a Feather Sessions FRIDAY, October 28 8:30am - 3:00pm - Technical Sessions HOTEL INFORMATION ================= Room reservation deadline is September 26 1994. The Symposium headquarters will be: Eldorado Hotel 309 W. San Francisco Street Santa Fe, New Mexico Telephone: +1 (505) 988-4455 Tollfree: +1 (800) 762-2333 ROOM RATES: $110.00 Single/Double Occupancy (Plus prevailing tax, currently at 10.125%) YOU SHOULD BE AWARE - the hotel has indicated there is a strong possibility that rooms will not be available after the September 26th deadline. It is strongly recommended that you make your room reservations EARLY, even if your attendance and travel plans are not confirmed. Should you desire to cancel your room reservations, you must notify the hotel at least 72 hours in advance. To Make Your Reservation: Call the Hotel directly and ask for the Reservations Desk. Tell reservations that you are a USENIX Attendee to take advantage of our group rate. A one nights deposit is required for all reservations. Should you desire to cancel your reservation, you must notify the hotel at least 72 hours prior to your scheduled arrival. DO YOU KNOW THE WAY TO SANTA FE? ================================ Air Transportation: Albuquerque International Airport is the closest major airport to Santa Fe and is serviced by five major carriers. Santa Fe has its own small municipal airport which offers commuter service from Albuquerque and Denver. Getting from Albuquerque to Santa Fe: Santa Fe is located just off Interstate 25, 60 miles north of Albuquerque. You may make commuter airline arrangements, rent a car, or take the shuttle transportation to reach Santa Fe. Information is shown below: Commuter Airline: Mesa Airlines, +1 (505) 473-4118 Car Rental Agencies: Avis, Budget, Enterprise, Hertz, Payless, Dollar, National, Sears and Alamo Shuttle Transportation: Shuttlejack provides bus transportation service from 6:40am to 10:45pm, every two hours (10 times daily) between the Albuquerque International Airport and the Eldorado Hotel in Santa Fe. Reservations ARE required for this service. Payment must be paid by cash or travelers checks. It is highly recommended that you call Shuttlejack BEFORE you make your flight arrangements to coordinate your flight arrival time with your shuttle service and verify their current time schedule and seating availability. To make your reservation, call: Telephone: +1-505-982-4311 Current Cost: $20 one way USENIX RECEPTION You are invited to join in the fun, mingle with old and new friends and enjoy the plentiful hors d'oeuvres and beverages. The USENIX reception is Thursday, October 27, from 6:00-8:00pm. BIRDS OF A FEATHER SESSIONS On Wednesday evening October 26th BOFs will be held from 7:00pm - 11:00pm and Thursday evening, October 27th from 8:00pm - 11:00pm. If you wish to schedule a BOF, contact a USENIX staff person upon your arrival at the symposium. CONFERENCE PROCEEDINGS: One copy of the proceedings is included with your Technical Sessions registration fee. If you wish to order additional copies, you may contact the USENIX Association Executive Office at Telephone +1 (510) 528-8649, or direct your email to: office@usenix.org. POINTS OF INTEREST Santa Fe's elevation is approximately 7,000 feet above sea level. It is known to have 300+ days of sunshine. Santa Fe is indeed "a city of museums", both state operated and private facilities. Some museums include: Museum of New Mexico including the Palace of the Governors; Fine Arts Museum of Indian Art and Culture; the Laboratory of Anthropology; The Wheelwright Museum of the American Indian; Institute of American Indian Arts and the Children's Museum. More than 200 art galleries display a vast array of works by noted regional artists, photographers and craftspersons. The Santa Fe Ski Basin is located only 18 miles from Santa Fe and Taos is just over an hour away. ABOUT USENIX Since 1975, the USENIX Association has provided a forum for the communication of the results of innovation and research in UNIX and modern open systems. It is well known for its technical conferences, tutorial programs, and the wide variety of publications it has sponsored over the years. USENIX is the original (we celebrate our 20th anniversary in 1995), not-for-profit membership organization for individuals and institutions interested in UNIX and UNIX-like systems, by extension, X, object-oriented technology, and other advanced tools and technologies, and the broad interconnected and interoperable computing enviornment. USENIX and its members are dedicated to: * fostering innovation and research that works, * communicating rapidly the results of both research and innovation, * providing a neutral forum for the exercise of critical thought and the airing of technical issues. FOR FURTHER SYMPOSIUM INFORMATION, PLEASE CONTACT: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone +1 (714) 588-8649 FAX Number +1 (714) 588-9706 Electronic Mail Address: conference@usenix.org Office Hours: 8:30am - 5:00pm Pacific Time REGISTRATION INFORMATION ======================== REGISTER EARLY TO SAVE! PRE-REGISTRATION DEADLINE: October 12, 1994 REGISTRATION FEES ARE $50 HIGHER AFTER THAT DATE! Pre-registration *Member Non-member Full-time Student (Before Oct. 12, 1994) $295.00 $360.00 $75.00 Registration (Aft Oct. 12, 1994)$345.00 $410.00 $75.00 *The member rate applies to current individual members of the USENIX Association, EurOpen , JUS and AUUG. Full-time students please note: A limited number of scholarships are available for full-time students. Contact the Conference Office for details. Enjoy the Benefits of Becoming a USENIX Member - If you are not a current USENIX member and wish to join, pay the non-member fee on the registration form and check the special box requesting membership. $65 of your non-member fee will be designated as dues in full for a one-year individual USENIX Association membership. Please complete and return the enclosed registration form with your payment. You may pay by check (MAKE CHECK PAYABLE TO USENIX CONFERENCE) or use your VISA, MasterCard, Diners Club or American Express charge card. Payment MUST accompany registration form. Purchase orders and vouchers are NOT accepted. NOTE: You may FAX your registration form if paying by credit card. (To avoid duplicate billing when faxing your registration, do not mail an additional copy to the Conference Office. You may telephone the conference office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than October 19, 1994. Direct your letter to the USENIX Conference Office. You may telephone to substitute another in your place. ==========================cut here================================ ****************************************************************** REGISTRATION FORM - USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES ****************************************************************** Please complete the form below and return to the USENIX Conference office (address below). NAME________________________________________________________________ (first) (last) FIRST NAME FOR BADGE____________________________ COMPANY OR INSTITUTION______________________________________________ MAILING ADDRESS_____________________________________________________ CITY___________________________STATE_____COUNTRY________ZIP____________ TELEPHONE NO:_________________________FAX NO.___________________________ NETWORK ADDRESS______________________________________________________ (Please write legibly) If you do NOT want to appear in the attendee list, check here: ___ Is this your first USENIX Conference? ___Yes ___No What is your affiliation? ___ Academic ___ Commercial ___ Gov't. Are you a current member of the USENIX Association? ___ Yes ___No (If you wish to join USENIX see below.*) The address you provide will be used for all future USENIX mailings unless you notify us in writing. ========================================================== FEE SCHEDULE for TECHNICAL SESSIONS TECHNICAL SESSIONS REGISTRATION FEES Wednesday, Thursday, Friday, October 26-28 MEMBER FEE................................................$295.00 _____ The member fee applies to current individual members of the USENIX Association, JUS, EurOpen or AUUG. NON-MEMBER FEE*...........................................$360.00 _____ Late fee applies after October 12, 1994................Add$ 50.00 _____ FULL-TIME STUDENT FEE - Pre-registered/On-Site............$ 75.00 _____ (Students must include photocopy of current student I.D. card with registration form.) TOTAL ENCLOSED...................$_________ *IF YOU WISH TO JOIN OR RENEW USENIX Check Here................... |_| Please take $65.00 of my non-member conference registration fee to pay for a one year indiviudal membership in USENIX. Payments must accompany registration form. Purchase orders and Vouchers not accepted. Payment Enclosed (U.S. Dollars). Make check payable to USENIX CONFERENCE. CHARGE TO MY: ___VISA ___MASTERCARD ___AMERICAN EXPRESS ___DINERS CLUB ACCOUNT NO.______________________________________ EXPIRATION DATE_________ _______________________________________/___________________________ Print Cardholder's Name Cardholder's Signature You may FAX your registration form if paying by credit card to USENIX CONFERENCE OFFICE, FAX +1 714 588 9706. (If you FAX registration, to avoid duplicate billing, do not mail additional copy. You may telephone our office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than Ocotober 19, 1994. Direct your letter to the USENIX Conference Office. ******************************************************************** PAYMENT MUST ACCOMPANY REGISTRATION FORM. REGISTRATION VIA EMAIL IS NOT ACCEPTED. ******************************************************************** PLEASE COMPLETE REGISTRATION FORM AND RETURN IT ALONG WITH YOUR FULL PAYMENT TO: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone + 714 588 8649; FAX + 714 588 9706 Internet Address: conference@usenix.org Office Hours: 8:30am-5:00pm Pacific Time From icon-group-sender Tue Oct 4 01:26:03 1994 Received: by cheltenham.cs.arizona.edu; Tue, 4 Oct 1994 05:36:37 MST To: icon-group-l@cs.arizona.edu Date: 4 Oct 1994 01:26:03 GMT From: amarks@nella30.cc.monash.edu.au (Andy Marks) Message-Id: <36qavb$9n3@harbinger.cc.monash.edu.au> Organization: Monash University Sender: icon-group-request@cs.arizona.edu Subject: Error Message Questionnaire (Re-Post) Errors-To: icon-group-errors@cs.arizona.edu Error Message Questionnaire =========================== Greetings, -- NOTE: This questionnaire has been previously posted to this newsgroup this year. If you have already replied, there is no need to do so again. The re-posting is mainly for those people who missed the first posting and US students who were on summer holidays during the first posting. If you prefer, there is also a WWW version of this question- naire, which is a bit more user-friendly, and automatically posts your answers back to me. The URL for the questionnaire is: "http://insect.sd.monash.edu.au/~amarks/questionnaire/question.html". -- Here is your big chance to have a say about the quality of those nasty little error messages that prevent us from accomplishing our favorite task - programming! I am using the results from this questionnaire in my research (for a Masters by Research degree at Monash University) into error messages and have posted this message to all Internet newsgroups dealing with programming languages. Although this posting might look quite large, relax - there are only 7 questions in total, and the final one is complet- ely optional: most of the questions are just picking options from a list anyway, so it shouldn't take more than 10-15 minutes to complete. If you would like your response to remain confidential, please indicate this - otherwise you will be given a "thanks" somewhere in my thesis (best I can do, sorry!). Please email replies back to the original sender. If you are NOT replying to this questionnaire through the news reader, address your reply to "amarks@nellads.cc.monash.edu.au". Also, please mark all answers on the original copy of the questionnaire - as opposed to writing your answers in a freeform manner, which will make collating the results a lot more difficult and time-consuming. When all responses have been collected, a summary of the results will be posted back to each newsgroup. Then we'll all be able to sleep safely with the knowledge that we all make mistakes, and no-one is perfect! :-) ----------------------------------------------------------- Section A: PROGRAMMING LANGUAGE BACKGROUND - these questions will help me learn a little about the language you're referring to in your answers. The term "this language" refers to the one served by the newsgroup this questionnaire appeared on. For example, if you got this questionnaire from "comp.lang.apl", then "this language" refers to apl. 1a.Which programming language(s) are you referring to in your answers? ada dylan ml rexx apl eiffel modula2 sas asm forth modula3 sather awk fortran oberon scheme basic functional objective-c sigplan visual-basic hermes pascal smalltalk c icon perl tcl c++ idl pop teco cobol intercal postscript verilog cfutures lisp prograph vhdl clos logo prolog visual clu misc python (*) other: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ insert other language here, if applicable (please mark ONE or MORE of these languages using a "*") b. If applicable, please indicate below the particular environment(s) of this language you use (for example, Borland C++ versus Microsoft C++). (*) environment: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ insert environment name(s) here ----------------------------------------------------------- Section B: PROGRAMMER BACKGROUND - these questions will give me some idea of your background and level of experience. Programmer experience and background is reputedly one of the most influential factors when dealing with error messages. The term "this language" refers to the one selected in question one. 3a.How many years have you been actively programming in this language? less than one year 1-2 years 3-5 years 5-10 years more than ten years (please mark ONE of these year ranges with a "*") NOTE: By "actively programming", I mean consistent use of a particular language on a regular basis. For example, usage for at least an hour each day or a couple of hours each week, say, in the regime of a course/degree/job of some sort. b. Using the levels of experience below, how experienced would you rate yourself in this language? novice programmer intermediate programmer expert programmer (*) other: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ insert other level of experience, if applicable (please mark ONE of these levels with a "*") NOTE: A "novice" programmer is still learning the language, needs to refer to manuals frequently and is often inefficient in using the language. An "intermediate" programmer is comfortable with the language and is familiar with most of/all of the commands of the language. An "expert" programmer uses the language in the most efficient way possible and spends time searching for better ways to use the language. 4. Which other languages have you used? Please also indicate your level of experience in each language you've used by marking each one with a number indicating the number of years you have been actively using the language. For example, "3 c" would indicate three years experience in the C language. ada dylan ml rexx apl eiffel modula2 sas asm forth modula3 sather awk fortran oberon scheme basic functional objective-c sigplan visual-basic hermes pascal smalltalk c icon perl tcl c++ idl pop teco cobol intercal postscript verilog cfutures lisp prograph vhdl clos logo prolog visual clu misc python (*) other: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ insert other language here, if applicable (please mark ONE or MORE of these languages with a number) ----------------------------------------------------------- Section C: ERROR MESSAGES - these questions are the most important part of the questionnaire; they will tell me how you rate the quality of the error messages in this language. By "error messages", I mean the messages generated by the compiler/interpreter when your code is being compiled or interpreted (probably due to a syntax violation), or at run-time. 5. What is your general impression of the quality of error messages in this language? poor below average average good excellent (please mark ONE of these levels of quality with a "*") 6. Using the kinds of problems below, how do you see the error messages in this language being deficient? obscure/vague in content misleading in information unfriendly in tone unhelpful in removing error jargonistic in wording accusatory in tone (*) other: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ insert other problem, if applicable (please mark NONE/SOME/ALL of these problems with a "*") ----------------------------------------------------------- Section D: OPTIONAL - only answer this question if you wish to and can remember the wording of some of the error messages in this language. 7. What are some of the most common error messages you encounter in this language? (also indicate whether they are satisfactory/unsatisfactory, and how you would improve them) (>) --- (please put your answer below here) (<) --- (please put your answer above here) NOTE: The term "satisfactory/unsatisfactory" in the above question refers to your opinion as to whether the error message clearly indicates the source of the error and how to remove the error. ----------------------------------------------------------- Thank you for the time and effort spent in making your contribution. -- Andrew Marks (amarks@nellads.cc.monash.edu.au) IKKI! Masters by Research (Software Development) IKKI! Monash University, Caulfield IKKI! From icon-group-sender Tue Oct 4 08:43:58 1994 Received: by cheltenham.cs.arizona.edu; Tue, 4 Oct 1994 11:22:49 MST To: icon-group-l@cs.arizona.edu Date: 4 Oct 1994 08:43:58 -0700 From: icon-project@cs.arizona.edu Message-Id: <36rt7u$cme@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Frequently Asked Questions About The Icon Programming Language last updated: 08/21/94 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 602-621-8448 (voice) 602-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Wed Oct 12 11:27:10 1994 Received: by cheltenham.cs.arizona.edu; Wed, 12 Oct 1994 16:05:07 MST To: icon-group-l@cs.arizona.edu Date: 12 Oct 94 13:19:19 From: emery@goldfinger.mitre.org (David Emery) Message-Id: Organization: The Mitre Corp., Bedford, MA. Sender: icon-group-request@cs.arizona.edu References: <36qavb$9n3@harbinger.cc.monash.edu.au> Subject: Re: Error Message Questionnaire (Re-Post) Errors-To: icon-group-errors@cs.arizona.edu >5. What is your general impression of the quality of error > messages in this language? I'm confused by this questionaire? Are we talking about error messages generated by a specific language compiler? Programming languages, per se, don't have error messages... dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- From icon-group-sender Tue Oct 18 23:29:16 1994 Received: by cheltenham.cs.arizona.edu; Tue, 18 Oct 1994 19:53:06 MST To: icon-group-l@cs.arizona.edu Date: Tue, 18 Oct 1994 23:29:16 GMT From: toni@usenix.org (Toni Veglia) Message-Id: Organization: USENIX Association, Berkeley, CA Sender: icon-group-request@cs.arizona.edu Reply-To: toni@usenix.org (Toni Veglia) Subject: USENIX Very High Level Languages Symposium - NEXT WEEK! Errors-To: icon-group-errors@cs.arizona.edu USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES (VHLL) OCTOBER 26 - 28, 1994 EL DORADO HOTEL SANTA FE, NEW MEXICO *********************************************** THIS POSTING CONTAINS: Technical Session Descriptions Schedule of Events Hotel and General Conference Information Registration Form *********************************************** The USENIX Symposium on Very High Level Languages will spotlight high level languages and their usefulness in leveraging specific problem areas. The Symposium will introduce participants to new concepts and approaches through original unpublished work. Programmers will learn about the relative strengths and weaknesses and extract the key concepts common to the languages presented. Using very high level languages (VHLLs), programmers can assemble entire applications from large building blocks in just a small fraction of the time required if conventional programming strategies were used. Programmers take advantage of increasingly available hardware cycles, trading cheap machine time for costly programmer time. VHLLs offer one of the most promising approaches toward radically improving programmer productivity. UNIX has long supported very high level languages -- consider AWK and the various shells. Often programmers create new little languages whenever a problem appears of sufficient complexity to merit a higher level programming interface -- consider sendmail.cf. In recent years many UNIX programmers have turned to VHLLs for rapid prototypes and complete applications. They take advantage of these languages' higher level of abstraction to complete projects more rapidly and easily than they could with lower level languages. While VHLLs such as TCL, Perl, Icon, and REXX have gained widespread use and popularity, many others never see the public light. Some of these languages address a limited problem domain (such as graphics, text processing, or mathematical modeling) using powerful primitives created for that specific problem. Other VHLLs are more general-purpose, but still much higher level than most traditional compiled languages. Some are stand-alone languages, while others can be embedded in other programs. Many are interpreted, although some are compiled to native machine code; a few occupy a gap between both worlds. PRELIMINARY TECHNICAL PROGRAM Wednesday-Friday, October 26-28, 1994 WEDNESDAY, OCTOBER 26 Keynote Address: Languages I've Loved -- 8:45-9:45 Dr. Jon Bentley, AT&T Bell Laboratories Good languages get the job done; they are useful and clean, but they don't have fans. Great languages will inspire passionate users. This talk surveys some of the languages that I have loved, from AWK to Visual Basic. I will illustrate the languages with the kinds of programs I would like to see in documentation; tiny programs to display language features and small programs that solve substantial problems. Jon L. Bentley is a Member of Technical Staff in the Computing Science Research Center at AT&T Bell Laboratories. His research interests include programming techniques and algorithm design. Dr. Bentley received a B.S. degree in Mathematical Sciences from Stanford University in 1974, and M.S. and Ph.D. degrees in Computer Science from the University of North Carolina in 1976. He is the author of three books: Writing Efficient Programs, Programming Pearls, and More Programming Pearls. Language Overview: Perl -- 10:15 - 11:15 Larry Wall, NetLabs, Inc. Originally perceived as a text-processing language for writing impenetrable one-liners, Perl has recently developed into a language that can be used in polite company. Larry Wall, the author of Perl, will talk about what happens when you try to combine all your favorite languages into one language. He'll present the original design rationale for Perl, and how "Perl philosophy" is evolving with the development of Perl version 5, and why you should care. Language Overview: TCL - A Universal Scripting Language 11:15-12:15 Dr. John Ousterhout, Sun Microsystems, Inc. In this talk I will give a brief overview of Tcl, a universal scripting language, and Tk, its companion GUI toolkit. Then I will discuss how the Tcl language evolved and the design issues behind it. Finally, I will critique the language and describe what I would do differently if I were to start again. Language Overview: Python Programming Language -- 1:30-2:30 Guido van Rossum, CWI Python is an interpreted, object-oriented language with a clear, intuitive syntax, powerful high-level data structures, and a flexible dynamic type system. It provides modules and classes which make the construction of large Python programs feasible. The talk will start with a quick introduction to Python, then discuss the rationale of its design, and round off with a look in the crystal ball. Language Overview: REXX -- 2:30-3:30 Pamela J. Taylor, REXX Language Association, The Workstation Group REXX is a versatile language used for applications that include "throw-away" procedures, "glue" programs, prototyping, systems administration, and mission-critical business applications. This presentation will discuss: The philosophy of the language and the history of its development; features that make it easy to learn, use and suited for a broad range of applications. Language Overview: Icon Programming Languages -- 4:00-5:00 Dr. Clinton Jeffery, University of Texas - San Antonio Icon is a general-purpose programming language derived from Snobol4. It's primary innovation is an expression evaluation model that integrates procedural programming with generators and backtracking. This is matched in utility by a large repertoire of built-in operations and heterogeneous structures. An optimizing compiler and portability to platforms ranging from supercomputers and IBM mainframes to many PC operating systems broaden Icon's appeal. Applications Experience with an Implicitly Parallel Compositional Language -- 7:00-7:30 Rangaswamy Jagannathan, Christopher Dodd, Computer Science Laboratory, SRI International Invited Talk: From Blazon to Postscript -- 7:30-8:45pm Daniel V. Klein, LoneWolf Systems Invited Talk: Objecting to Objects -- 8:45-10:00pm Stephen C. Johnson, Melismatic Software THURSDAY, OCTOBER 27 Language Overview: Standard ML -- 8:30-9:30 Andy Koenig, AT&T Bell Laboratories Standard ML is a strongly typed general-purpose language with particularly good support for functional programming, data abstraction, and composition of modules. It feels a little like strongly typed Lisp with different syntax. A robust compiler that generates fast machine code is available free of charge. SESSION 1 -- 10:00-11:30 An Anecdote About ML Type Inference Andy Koenig, AT&T Bell Laboratories libscheme: Scheme as a C Library Brent Benson Jr., Harris Computer Systems A New Architecture for the Implementation of Scripting Languages Adam Sah and Jon Blow, University of California, Berkeley SESSION 2 -- 1:00-2:30 Tcl/Tk for a Personal Digital Assistant Karin Petersen, Xerox PARC Using Tcl to Control a Computer-Participative Multimedia Programming Environment Christopher Lindblad, Massachusetts Institute of Technology TkPerl - - A Port of the Tk Toolkit to Per15 Malcolm Beattie, Oxford University SESSION 3 -- 3:00-4:30 Rapid Programming with Graph Rewrite Rules Andy Schuerr, Aachen University of Technology End-User Systems, Reusability, and High-Level Design John Snyder, Kiem-Phong Vo and Glenn Fowler, AT&T Bell Laboratories Compiling Matlab Stephen C. Johnson, Melismatic Software; Cleve Moler, The Mathworks, Inc. Invited Talk: Lessons Learned from Postscript -- 4:30-5:30 Dick Dunn, QMS Inc. USENIX RECEPTION -- 6:00-8:00 FRIDAY, OCTOBER 28 SESSION 4 -- 8:30 - 10:00 Ksh: An Extensible High-Level Language David Korn, AT&T Bell Laboratories Fornax: A General-Purpose Programming Language J. Storrs Hall, Rutgers University Graphics Programming in Icon Version 9 Clinton Jeffery, University of Texas - San Antonio; Ralph Griswold and Gregg Townsend, University of Arizona SESSION 5 -- 10:30-11:30 Application Languages in Software Production David Ladd and Christopher Ramming, AT&T Bell Laboratories Using a Very-High Level Language to Build Familities of High Quality Resuable Components Gary Pollice, CenterLine Software, Inc. SESSION 6 -- 1:00-2:00 Dixie: A Distributed Internet Execution Environment R. Stockton Gaines, University of Southern California, Information Sciences Institute Feature-Based Portability Glenn Fowler, David Korn, John Snyder and Kiem-Phong Vo, AT&T Bell Laboratories Footnote: High-Level Languages, Little Languages, and Software Productivity -- 2:00-3:00 Stephen C. Johnson, Melismatic Software Traditional methods of writing software are pricing themselves out of the market. For a while, traditional software methods will survive through offshore manufacturing, but the future belongs to high level languages both general purpose and special purpose ("little languages")--that can exploit cheap machine cycles to replace expensive programmers, shorten design cycles, and even lead to "user configurable" software. Closing Remarks -- 3:00 Tom Christiansen, Consultant PROGRAM COMMITTEE ================= Program Chair: Tom Christiansen, Consultant Jon Bentley, AT&T Bell Laboratories Stephen C. Johnson, Melismatic Software Brian Kernighan, AT&T Bell Laboratories John Ousterhout, University of California, Berkeley Henry Spencer, University of Toronto Larry Wall, NetLabs, Inc. IMPORTANT SYMPOSIUM DATES & SCHEDULE OF EVENTS ============================================== Pre-Registration Deadline: October 12, 1994 Hotel Reservation Deadline: September 26, 1994 TUESDAY, October 25 6:00pm - 9:00pm - Registration & Welcome Reception WEDNESDAY, October 26 8:30am - 5:00pm - Technical Sessions 7:00pm - 10:00pm - Invited Talks 7:00pm -11:00pm - Birds of a Feather Sessions THURSDAY, October 27 8:30am - 5:30pm - Technical Sessions and Invited Talk 6:00pm - 8:00pm - Symposium Reception 8:00pm - 11:00pm - Birds of a Feather Sessions FRIDAY, October 28 8:30am - 3:00pm - Technical Sessions HOTEL INFORMATION ================= Room reservation deadline is September 26 1994. The Symposium headquarters will be: Eldorado Hotel 309 W. San Francisco Street Santa Fe, New Mexico 87501 Telephone: +1 (505) 988-4455 Tollfree: +1 (800) 762-2333 ROOM RATES: $110.00 Single/Double Occupancy (Plus prevailing tax, currently at 10.125%) YOU SHOULD BE AWARE - the hotel has indicated there is a strong possibility that rooms will not be available after the September 26th deadline. It is strongly recommended that you make your room reservations EARLY, even if your attendance and travel plans are not confirmed. Should you desire to cancel your room reservations, you must notify the hotel at least 72 hours in advance. To Make Your Reservation: Call the Hotel directly and ask for the Reservations Desk. Tell reservations that you are a USENIX Attendee to take advantage of our group rate. A one nights deposit is required for all reservations. Should you desire to cancel your reservation, you must notify the hotel at least 72 hours prior to your scheduled arrival. DO YOU KNOW THE WAY TO SANTA FE? ================================ Air Transportation: Albuquerque International Airport is the closest major airport to Santa Fe and is serviced by five major carriers. Santa Fe has its own small municipal airport which offers commuter service from Albuquerque and Denver. Getting from Albuquerque to Santa Fe: Santa Fe is located just off Interstate 25, 60 miles north of Albuquerque. You may make commuter airline arrangements, rent a car, or take the shuttle transportation to reach Santa Fe. Information is shown below: Commuter Airline: Mesa Airlines, +1 (505) 473-4118 Car Rental Agencies: Avis, Budget, Enterprise, Hertz, Payless, Dollar, National, Sears and Alamo Shuttle Transportation: Shuttlejack provides bus transportation service from 6:40am to 10:45pm, every two hours (10 times daily) between the Albuquerque International Airport and the Eldorado Hotel in Santa Fe. Reservations ARE required for this service. Payment must be paid by cash or travelers checks. It is highly recommended that you call Shuttlejack BEFORE you make your flight arrangements to coordinate your flight arrival time with your shuttle service and verify their current time schedule and seating availability. To make your reservation, call: Telephone: +1-505-982-4311 Current Cost: $20 one way USENIX RECEPTION You are invited to join in the fun, mingle with old and new friends and enjoy the plentiful hors d'oeuvres and beverages. The USENIX reception is Thursday, October 27, from 6:00-8:00pm. BIRDS OF A FEATHER SESSIONS On Wednesday evening October 26th BOFs will be held from 7:00pm - 11:00pm and Thursday evening, October 27th from 8:00pm - 11:00pm. If you wish to schedule a BOF, contact a USENIX staff person upon your arrival at the symposium. CONFERENCE PROCEEDINGS: One copy of the proceedings is included with your Technical Sessions registration fee. If you wish to order additional copies, you may contact the USENIX Association Executive Office at Telephone +1 (510) 528-8649, or direct your email to: office@usenix.org. POINTS OF INTEREST Santa Fe's elevation is approximately 7,000 feet above sea level. It is known to have 300+ days of sunshine. Santa Fe is indeed "a city of museums", both state operated and private facilities. Some museums include: Museum of New Mexico including the Palace of the Governors; Fine Arts Museum of Indian Art and Culture; the Laboratory of Anthropology; The Wheelwright Museum of the American Indian; Institute of American Indian Arts and the Children's Museum. More than 200 art galleries display a vast array of works by noted regional artists, photographers and craftspersons. The Santa Fe Ski Basin is located only 18 miles from Santa Fe and Taos is just over an hour away. ABOUT USENIX Since 1975, the USENIX Association has provided a forum for the communication of the results of innovation and research in UNIX and modern open systems. It is well known for its technical conferences, tutorial programs, and the wide variety of publications it has sponsored over the years. USENIX is the original (we celebrate our 20th anniversary in 1995), not-for-profit membership organization for individuals and institutions interested in UNIX and UNIX-like systems, by extension, X, object-oriented technology, and other advanced tools and technologies, and the broad interconnected and interoperable computing enviornment. USENIX and its members are dedicated to: * fostering innovation and research that works, * communicating rapidly the results of both research and innovation, * providing a neutral forum for the exercise of critical thought and the airing of technical issues. FOR FURTHER SYMPOSIUM INFORMATION, PLEASE CONTACT: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone +1 (714) 588-8649 FAX Number +1 (714) 588-9706 Electronic Mail Address: conference@usenix.org Office Hours: 8:30am - 5:00pm Pacific Time REGISTRATION INFORMATION ======================== REGISTER EARLY TO SAVE! PRE-REGISTRATION DEADLINE: October 12, 1994 REGISTRATION FEES ARE $50 HIGHER AFTER THAT DATE! Pre-registration *Member Non-member Full-time Student (Before Oct. 12, 1994) $295.00 $360.00 $75.00 Registration (Aft Oct. 12, 1994)$345.00 $410.00 $75.00 *The member rate applies to current individual members of the USENIX Association, EurOpen , JUS and AUUG. Full-time students please note: A limited number of scholarships are available for full-time students. Contact the Conference Office for details. Enjoy the Benefits of Becoming a USENIX Member - If you are not a current USENIX member and wish to join, pay the non-member fee on the registration form and check the special box requesting membership. $65 of your non-member fee will be designated as dues in full for a one-year individual USENIX Association membership. Please complete and return the enclosed registration form with your payment. You may pay by check (MAKE CHECK PAYABLE TO USENIX CONFERENCE) or use your VISA, MasterCard, Diners Club or American Express charge card. Payment MUST accompany registration form. Purchase orders and vouchers are NOT accepted. NOTE: You may FAX your registration form if paying by credit card. (To avoid duplicate billing when faxing your registration, do not mail an additional copy to the Conference Office. You may telephone the conference office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than October 19, 1994. Direct your letter to the USENIX Conference Office. You may telephone to substitute another in your place. ==========================cut here================================ ****************************************************************** REGISTRATION FORM - USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES ****************************************************************** Please complete the form below and return to the USENIX Conference office (address below). NAME________________________________________________________________ (first) (last) FIRST NAME FOR BADGE____________________________ COMPANY OR INSTITUTION______________________________________________ MAILING ADDRESS_____________________________________________________ CITY___________________________STATE_____COUNTRY________ZIP____________ TELEPHONE NO:_________________________FAX NO.___________________________ NETWORK ADDRESS______________________________________________________ (Please write legibly) If you do NOT want to appear in the attendee list, check here: ___ Is this your first USENIX Conference? ___Yes ___No What is your affiliation? ___ Academic ___ Commercial ___ Gov't. Are you a current member of the USENIX Association? ___ Yes ___No (If you wish to join USENIX see below.*) The address you provide will be used for all future USENIX mailings unless you notify us in writing. ========================================================== FEE SCHEDULE for TECHNICAL SESSIONS TECHNICAL SESSIONS REGISTRATION FEES Wednesday, Thursday, Friday, October 26-28 MEMBER FEE................................................$295.00 _____ The member fee applies to current individual members of the USENIX Association, JUS, EurOpen or AUUG. NON-MEMBER FEE*...........................................$360.00 _____ Late fee applies after October 12, 1994................Add$ 50.00 _____ FULL-TIME STUDENT FEE - Pre-registered/On-Site............$ 75.00 _____ (Students must include photocopy of current student I.D. card with registration form.) TOTAL ENCLOSED...................$_________ *IF YOU WISH TO JOIN OR RENEW USENIX Check Here................... |_| Please take $65.00 of my non-member conference registration fee to pay for a one year indiviudal membership in USENIX. Payments must accompany registration form. Purchase orders and Vouchers not accepted. Payment Enclosed (U.S. Dollars). Make check payable to USENIX CONFERENCE. CHARGE TO MY: ___VISA ___MASTERCARD ___AMERICAN EXPRESS ___DINERS CLUB ACCOUNT NO.______________________________________ EXPIRATION DATE_________ _______________________________________/___________________________ Print Cardholder's Name Cardholder's Signature You may FAX your registration form if paying by credit card to USENIX CONFERENCE OFFICE, FAX +1 714 588 9706. (If you FAX registration, to avoid duplicate billing, do not mail additional copy. You may telephone our office to confirm receipt of your fax.) REFUND CANCELLATION POLICY: If you must CANCEL, all refund requests must be in writing and postmarked no later than Ocotober 19, 1994. Direct your letter to the USENIX Conference Office. ******************************************************************** PAYMENT MUST ACCOMPANY REGISTRATION FORM. REGISTRATION VIA EMAIL IS NOT ACCEPTED. ******************************************************************** PLEASE COMPLETE REGISTRATION FORM AND RETURN IT ALONG WITH YOUR FULL PAYMENT TO: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA 92630 Telephone + 714 588 8649; FAX + 714 588 9706 Internet Address: conference@usenix.org Office Hours: 8:30am-5:00pm Pacific Time From icon-group-sender Wed Oct 19 05:47:00 1994 Received: by cheltenham.cs.arizona.edu; Wed, 19 Oct 1994 06:16:29 MST To: icon-group-l@cs.arizona.edu Date: 19 Oct 1994 05:47:00 GMT From: tchrist@usenix.org (Tom Christiansen) Message-Id: <382bsk$lu5@csnews.cs.Colorado.EDU> Organization: USENIX Association, Berkeley, CA Sender: icon-group-request@cs.arizona.edu References: Subject: Abstracts from Upcoming VHLL Symposium Errors-To: icon-group-errors@cs.arizona.edu Here are some abstracts for next week's conference. ABSTRACTS from the upcoming USENIX Very High level Languages Symposium October 26-28, 1994 Santa Fe, New Mexico ============================================================= TkPerl-- A port of the Tk toolkit to Perl5 Malcolm Beattie Oxford University Computing Services mbeattie@sable.ox.ac.uk ABSTRACT: TkPerl is a port (work in progress) of the Tk[1] toolkit to Perl5[2]. It takes advantage of Perl5's object oriented features and magic variables to implement the Tk toolkit in Perl5. Nothing passes through the Tcl parser so knowledge of Tcl syntax is not required to use TkPerl. TkPerl is freeware (distributed under the GNU General Public License) and is currently in alpha testing. Section 1 of the paper introduces TkPerl and is followed by a brief section on its target uses.. Since TkPerl relies heavily on the object oriented features of Perl5 (which is itself only just into beta test), section 3 explains how Perl5 implements classes, ob- jects and methods. Section 4 discusses the differ- ences between Tk/Tcl and TkPerl both at scripting level and at C level. Section 5 looks at some of the porting issues and problems and how Tcl conven- tions affect the design of Tk itself. Section 6 ex- plains the current intentions for the future of TkPerl and section 7 gives availability information. ================================== libscheme: Scheme as a C Library Brent W. Benson Jr. Harris Computer Systems Brent.Benson@mail.csd.harris.com Abstract Because of its small size and simplicity, Scheme is often seen as an ideal extension or scripting language. While there are many Scheme implementations available, their interfaces are often complex and can get in the way of using the implementation as part of a larger software product. The libscheme library makes the Scheme language available as a C library. Its interface is through a single C header file and it is easily extended with new primitive procedures, new primitive types, and new syntax. It is portable to any system that has an ANSI C compiler and to which Hans Boehm's popular conservative garbage collector [1] has been ported. It has been used to build a variety of special purpose data manipulation tools, and as an extension language for an ethernet monitor. ================================== END-USER SYSTEMS, REUSABILITY, AND HIGH-LEVEL DESIGN Glenn S. Fowler (gsf@research.att.com) John J. Snyder (jjs@research.att.com) Kiem-Phong Vo (kpv@research.att.com) AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974 USA During the past ten years, the number of computer users has grown by orders of magnitude. This has been brought about by dramatic increase in computing power combined with equally dramatic decrease in hardware costs. Beyond "stand-alone" user applications like word processing and spreadsheets, new classes of business applications arise where competitive advantage is created by empowering "end-users" with instant access to relevant information. In many cases, code already exists to access and process the desired information; the challenge is finding a way to couple such processing capabilities to individual user requests in a timely, specific, and friendly fashion. The keys to such end- user systems lie in high-level design and software reusability. This paper describes a language tool EASEL (End-User Application System Encoding Language) for building end-user systems and experiences in its development and deployment. ================================== FEATURE-BASED PORTABILITY Glenn S. Fowler (gsf@research.att.com) David G. Korn (dgk@research.att.com) John J. Snyder (jjs@research.att.com) Kiem-Phong Vo (kpv@research.att.com) AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974 USA Current computing platforms encompass a dizzying variety of hardware and software. A software application may live or die based on how portable it is. Much has been written and talked about how to enhance portability. But few tools are available to support writing portable code and, more importantly, to en- code porting knowledge. This paper describes IFFE, a tool and an accompanying programming style that supports software por- tability. IFFE has enabled the porting and construction of many large software applications on heterogeneous platforms with virtually no user intervention. ================================ Dixie Language and Interpreter Issues R. Stockton Gaines U. S. C. Information Sciences Institute 4674 Admiralty Way Marina del Rey CA 90292 Abstract Dixie (Distributed Internet Execution Environment) provides a base for sending programs called Dixie applications to Internet sites for execution. It provides the features generally found in operating systems, such as a file system, multiprocessing, interprocess communications, etc., and in addition capabilities to permit Dixie applications to interact with resources at the local site. Security is of first importance; it must not be possible for a Dixie application to have an undesired effect on the local system. This paper explains the Dixie concept and discusses language and execution issues. The languages understood by Dixie, at least initially, will fall in the class of Very High Level Languages, not the least because these languages will support the security requirements of Dixie, as well as the command language requirements. Dixie complements these languages, and provides uniform platform independent of the local hardware and operating systems to support Dixie application programs. ================================ Fornax: A General-Purpose Programming Language J. Storrs Hall Laboratory for Computer Science Research Hill Center, Busch Campus Rutgers University New Burnswick, NJ 08903 [Fornax, ``the Furnace,'' is an obscure Southern Hemisphere constellation between Cetus and Eridanus.] Abstract Fornax is a very high-level programming based on pattern-matching concepts from Snobol (and Icon) and array or "data-parallel" concepts from APL (and J). =============================== An Application Experience with an Implicitly Parallel Composition Language R. Jagannathan and Chris Dodd SRI International Computer Science Laboratory 333 Ravenswood Avenue Menlo Park, California 94025 {jaggan,dodd}@csl.sri.com Abstract: We describe our experiences with a very high-level parallel composition language (called GLU) that enables rapid construction of parallel applications using sequential building blocks (extracted from existing sequential applications) and their execution on diverse parallel computer systems. GLU is sufficiently rich to succinctly express different forms of parallelism --- from function parallelism to data parallelism and from pipeline parallelism to tree parallelism. We show by example how a typical sequential application can be converted to a parallel one in GLU and executed on different parallel systems. We also show how GLU has been used to convert two widely used sequentially written, inherently parallel workstation applications --- the make utility and a raytracing system --- to parallel equivalents that can then be run much faster on a network of workstations. =============================== Graphics Programming in Icon Version 9 Clinton L. Jeffery Division of MCSS, The University of Texas San Antonio, TX 78249, U.S.A. E-mail: jeffery@ringer.cs.utsa.edu Ralph E. Griswold and Gregg M. Townsend Department of Computer Science, The University of Arizona, Tucson, AZ 85721, U.S.A. E-mail: {ralph|gmt}@cs.arizona.edu Abstract Version 9 of the Icon programming language introduces support for graphics and user interface programming as an extension of the existing file-based input/output model, rather than introducing graphics as a disjoint facility. Simplicity, generality, and portability are the primary emphases. The result is a language in which common graphic effects are easy to write using ordinary procedural code. Complex techniques such as event-driven programming are optional and not forced on the programmer when they are not needed. ============================================== An anecdote about ML type inference Andrew Koenig (ark@research.att.com) AT&T Bell Laboratories Murray Hill, New Jersey 07974 Introduction ML strongly supports functional programming; its programmers tend to avoid operations with side effects. Thus, for example, instead of mutable arrays, ML programmers usually use lists. These lists behave much like those in Lisp, with the added requirement that all elements have the same type.1 ML lists are not themselves mutable, although the individual elements can be of a (uniform) mutable type. In Lisp terms, ML lists can optionally support RPLACA but not REPLACD. Although it is possible to define a type in ML that would support REPLACD as well, ML programmers usually don't do this unless they need it. ========================================== ksh - An Extensible High Level Language David G. Korn (dgk@research.att.com) AT&T Bell Laboratories Murray Hill, N. J. 07974 ksh is a high level interactive script language that is a superset of the UNIX system shell. ksh has better programming features and better performance. Versions of ksh are distributed with the UNIX system by many vendors; this has created a large and growing user community in many different companies and universities. Applications of up to 25,000 lines have been written in ksh and are in production use. ksh-93 is the first major revision of ksh in five years. Many of the changes for ksh-93 were made in order to conform to the IEEE POSIX and ISO shell standards. In addition, ksh-93 has many new programming features that vastly extend the power of shell programming. It was revised to meet the ========================================== Application Languages in Software Production David A. Ladd J. Christopher Ramming AT&T Bell Laboratories 1 Introduction PRL5 is an application-oriented language used to maintain the integrity of databases in the AT&T 5ESSTM telecommunications switch. PRL5 is unusual in that it was explicitly designed to eliminate a number of different coding and inspection steps rather than simply to improve individual productivity. Because PRL5 replaced an earlier high-level language named PRL, which in turn replaced a combination of English and C on the same project, it is possible to trace the effect of several fundamentally different languages on this single project. The linguistic evolution has been away from languages describing computation toward a "declarative" high-level language that has been deliberately restricted to accommodate the requirements of certain analyses. Algorithms for checking database constraints are no longer specified by human developers; instead, code is generated from static representations of the constraints themselves. These constraint descriptions can be used in more than one way, whereas a program to check constraints is useful only for performing that particular computation. In effect, PRL5 allows the re-use of project information at a high level, before it has been specialized into particular implementations. The effects of this re-use on quality, interval, and cost are tangible. A key lesson is that application-oriented languages should not be designed to describe computation, they should be designed to express useful facts from which one or more computations can be derived. ========================================== Using Tcl to Control a Computer-Participative Multimedia Programming Environment Christopher J. Lindblad Telemedia Networks and Systems Group Laboratory for Computer Science Massachusetts Institute of Technology Abstract This paper describes how the VuSystem, a programming environment for the development of computer-participative multimedia applications, is controlled through Tcl scripts. In the VuSystem, networks of in-band media-processing modules are created and controlled by interpreted out-of-band Tcl scripts through object commands and callbacks. Tcl's extensibility, simple type system, efficient interface to C, and introspective capabilities are used by the VuSystem to produce a highly dynamic and capable media processing system. ============================================ Using a Very High Level Language to Build Families of High Quality Reusable Components Gary F. Pollice CenterLine Software, Inc. and U. Massachusetts, Lowell 1 Introduction While most programs are designed to perform a specific task, they have a natural evolution over time; causing a single program to become a set of programs that perform related tasks. In 1976 David Parnas introduced the concept of a family of programs [11 ]. He suggests that any program should be considered a member of a family of programs, all of which perform related tasks. If one plans for change when a program is designed less effort may be required to produce future revisions. Today there is an emphasis on building software components for reuse. Components may be designs, programs, functions, classes, or code segments. Major reuse projects are in progress at several institutions, for example, the Software Productivity Consortium and the Software Engineering Institute [1,6 ]. Processes have been developed to introduce and support reuse programs. The disciplines of domain engineering and software synthesis emphasize creating families of components and developing tools to assist in constructing them. Component generation is a prominent part of most efforts. ============================================ A New Architecture for the Implementation of Scripting Languages Computer Science Division Electrical Engineering and Computer Sciences University of California Berkeley, CA 94720 {asah,blojo}@cs.Berkeley.EDU September 12, 1994 Abstract Nearly all scripting languages today are implemented as interpreters written in C. We propose an alternate architecture where the language is translated into the dynamic language Scheme [R4RS]. The plethora of high quality, public domain Scheme implementations give the developer a wide selection of interpreters, byte compilers, and machine code compilers to use as targets for her VHLL. Our VHLL, Rush, provides high-level features such as automatic type conversion and production rules [SHH86][Ston93]. Performance benchmarks show that our system runs with acceptable speed; in fact, Rush programs run much more quickly than their equivalents in languages such as Tcl and Perl4. Whereas those languages are coded in C, Rush takes advantage of Scheme's existing high-level features, saving de- velopment time. Since the features provided by Scheme are among those most VHLLs share, we expect this approach to be widely applicable. *supported in part by a grant from the National Science Foundation #NSF-IRI9107455 From icon-group-sender Wed Oct 19 23:01:45 1994 Received: by cheltenham.cs.arizona.edu; Thu, 20 Oct 1994 05:25:13 MST To: icon-group-l@cs.arizona.edu Date: 19 Oct 1994 23:01:45 -0500 From: bkeefe@seas.gwu.edu (Brian J. Keefe) Message-Id: Organization: UTexas Mail-to-News Gateway Sender: icon-group-request@cs.arizona.edu Subject: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu Does anyone know if there is any work merging IconX with Tk, comparable to what is happeing with Perl and Tk? Thanks, -- Brian Keefe From icon-group-sender Thu Oct 20 07:44:32 1994 Received: by cheltenham.cs.arizona.edu; Thu, 20 Oct 1994 08:31:52 MST Date: Thu, 20 Oct 94 15:43:27 BST From: Steve Holden Message-Id: <9410201443.AA05049@r7.cs.man.ac.uk> To: icon-group@cs.arizona.edu Subject: Makefiles for interpret and/or compile Errors-To: icon-group-errors@cs.arizona.edu [This group is like London buses. You wait weeks for an enquiry, then two come along together ;-] Does anybody have any good solutions to building complex projects? I have built a fairly big system which uses Makefiles to build, and to keep testing times down I use the interpreter. When I distribute I end up compiling ina higher-level Makefile having first built the system with the interpreter to make sure all dependencies have been accounted for. Has anyone got any useful advcie on neater ways to do this? Ideally I would like to use a single Makefile, but how do I cope with the problem that an program depends on the u1/u2 files when using the interpreter, but the icn files when using the compiler? regards Steve -------------------------------------------------------------------- Steve Holden Scotia Electronic Publishing Tel: +44 436 678962 29 John Street Fax: +44 436 677814 Helensburgh Internet: steveh@cs.man.ac.uk Scotland Compuserve: 100343,2205 G84 8XL -------------------------------------------------------------------- Tools, Technology and Training for Successful Electronic Publishing. -------------------------------------------------------------------- From icon-group-sender Thu Oct 20 11:04:07 1994 Received: by cheltenham.cs.arizona.edu; Thu, 20 Oct 1994 14:09:16 MST To: icon-group-l@cs.arizona.edu Date: 20 Oct 1994 11:04:07 -0400 From: nmw@ios.com (Nick Williams) Message-Id: <3860t7$i9d@ios.com> Organization: Internet Online Services Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu In article , Brian J. Keefe wrote: >Does anyone know if there is any work merging IconX with Tk, comparable to >what is happeing with Perl and Tk? Icon has some pretty good graphics facilities, including a tool to help with gui creation. So why merge Icon with Tk, abandoning all the work that's been put into Icon's graphics facilities? >Thanks, >-- Brian Keefe Nick From icon-group-sender Thu Oct 20 17:16:59 1994 Received: by cheltenham.cs.arizona.edu; Thu, 20 Oct 1994 17:53:24 MST Date: Thu, 20 Oct 1994 17:16:59 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9410202216.AA01007@runner.utsa.edu> To: bkeefe@seas.gwu.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (bkeefe@seas.gwu.edu) Subject: Re: Icon and Tk Content-Length: 682 Errors-To: icon-group-errors@cs.arizona.edu Brian Keefe wrote: Does anyone know if there is any work merging IconX with Tk, comparable to what is happeing with Perl and Tk? I don't know of any such work, and I think I'd be one of the earlier persons to hear about it. Tk has some nice ideas that may be worth borrowing, but its not the best model for user interface programming I've seen; for example, DEC's Trestle system has a very nice design. There are lots of different opinions about what language support for user interface programming in Icon should look like. I think its very likely that improvements and alternative sets of tools will appear; what they look like will depend on who implements them. From icon-group-sender Thu Oct 20 14:49:41 1994 Received: by cheltenham.cs.arizona.edu; Fri, 21 Oct 1994 08:51:06 MST To: icon-group-l@cs.arizona.edu Date: Thu, 20 Oct 1994 14:49:41 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu Brian J. Keefe (bkeefe@seas.gwu.edu) wrote: : Does anyone know if there is any work merging IconX with Tk, comparable to : what is happeing with Perl and Tk? There is also access to Tk from Python (tkinter). Maybe what the world needs is a document that explains how to interface your high level language to Tk and what requirements your language (whatever language) has to satisfy in order for this to be easy or even possible. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Fri Oct 21 14:45:23 1994 Received: by cheltenham.cs.arizona.edu; Sat, 22 Oct 1994 05:43:43 MST To: icon-group-l@cs.arizona.edu Date: Fri, 21 Oct 1994 14:45:23 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: , <3860t7$i9d@ios.com> Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu Nick Williams (nmw@ios.com) wrote: : In article , : Brian J. Keefe wrote: : >Does anyone know if there is any work merging IconX with Tk, comparable to : >what is happeing with Perl and Tk? : Icon has some pretty good graphics facilities, including a tool to help : with gui creation. So why merge Icon with Tk, abandoning all the work : that's been put into Icon's graphics facilities? I'm not too well informed about Icon's graphics capabilities, so correct me if I'm wrong, but from a quick reading it seems like X Icon supports drawing, but not creating windows containing pushbuttons, checkboxes, listboxes, etc and interacting with those controls. If this is true, an Icon interface to Tk could provide complementary capabilities, not replace existing ones. Does X Icon have support for buttons and listboxes and menus etc? -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Sat Oct 22 12:45:54 1994 Received: by cheltenham.cs.arizona.edu; Sat, 22 Oct 1994 08:27:41 MST To: icon-group-l@cs.arizona.edu Date: Sat, 22 Oct 1994 12:45:54 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Oct22.124554.21508@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: , <3860t7$i9d@ios.com>, Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu In article , dkuhlman@netcom.com (G. David Kuhlman) says: +--------------- | X Icon supports drawing, but not creating windows containing pushbuttons, | checkboxes, listboxes, etc and interacting with those controls. If +------------->8 Look in the Icon Program Library. There are quite a few widgets supported. (ipl/gprocs/*.icn) ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH ~\U Waiting For Godot^H^H^H^H^HRothenberg From icon-group-sender Sat Oct 22 13:59:40 1994 Received: by cheltenham.cs.arizona.edu; Sat, 22 Oct 1994 13:22:13 MST Date: Sat, 22 Oct 1994 13:59:40 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9410221859.AA00125@runner.utsa.edu> To: dkuhlman@netcom.com Cc: icon-group@cs.arizona.edu In-Reply-To: <1994Oct22.124554.21508@kf8nh.wariat.org> (bsa@kf8nh.wariat.org) Subject: Re: Icon and Tk Content-Length: 1689 Errors-To: icon-group-errors@cs.arizona.edu dkuhlman@netcom.com (G. David Kuhlman) says: | X Icon supports drawing, but not creating windows containing pushbuttons, | checkboxes, listboxes, etc and interacting with those controls. If To which bsa@kf8nh.wariat.org (Brandon S. Allbery) sagely replies: Look in the Icon Program Library. There are quite a few widgets supported. (ipl/gprocs/*.icn) To sum up: Icon's built-in support is mainly graphics output oriented. It gives convenient access to mouse input, but does not provide a hardwired set of user interface facilities. The IPL does indeed offer a suite of user interface tools, and an interface builder, which both started as student efforts but which are usable (and are being further improved) thanks to Gregg Townsend. We are using these tools extensively in my Software Engineering class this semester, and students are almost happy. Built-in language support for user interfaces in Icon could be much better than the present suite of tools. Doing a good language design is extremely hard; there are things about the graphics interface that still aren't quite right. What I am trying to say is, sure, we can improve the function library, or write alternative function libraries to e.g. Tk, but the real Challenge for the long haul is to figure out what language support for user interfaces should look like in terms of built-in types and control structures. I think almost every user interface library author on earth believes this includes objects, but what else? What can we do to make it fit seamlessly into conventional programming and existing programs, and what can we do to make it truly easy to extend with new user interface devices? From icon-group-sender Wed Oct 26 20:38:12 1994 Received: by cheltenham.cs.arizona.edu; Wed, 26 Oct 1994 18:02:27 MST To: icon-group-l@cs.arizona.edu Date: Wed, 26 Oct 1994 20:38:12 GMT From: horton@vitro.com (John Horton) Message-Id: <1994Oct26.203812.23214@vitro.com> Organization: Vitro Corporation Sender: icon-group-request@cs.arizona.edu References: <3860t7$i9d@ios.com>, , <1994Oct22.124554.21508@kf8nh.wariat.org> Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu In article <1994Oct22.124554.21508@kf8nh.wariat.org>, bsa@kf8nh.wariat.org (Brandon S. Allbery) says: > >In article , dkuhlman@netcom.com (G. David Kuhlman) says: >+--------------- >| X Icon supports drawing, but not creating windows containing pushbuttons, >| checkboxes, listboxes, etc and interacting with those controls. If >+------------->8 > >Look in the Icon Program Library. There are quite a few widgets supported. >(ipl/gprocs/*.icn) > For informatin purposes, and to satisfy my humble inqusitivness, just where is the icon library? From icon-group-sender Wed Oct 26 15:37:22 1994 Received: by cheltenham.cs.arizona.edu; Thu, 27 Oct 1994 12:29:25 MST To: icon-group-l@cs.arizona.edu Date: 26 Oct 1994 15:37:22 -0700 From: scott@cs.arizona.edu (Scott E Gilbert) Message-Id: <38mln2$ftc@caslon.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: , <1994Oct22.124554.21508@kf8nh.wariat.org>, <1994Oct26.203812.23214@vitro.com> Subject: Re: Icon and Tk Errors-To: icon-group-errors@cs.arizona.edu In article <1994Oct26.203812.23214@vitro.com>, John Horton wrote: >> >>Look in the Icon Program Library. There are quite a few widgets supported. >>(ipl/gprocs/*.icn) > >For informatin purposes, and to satisfy my humble inqusitivness, just where is the icon library? Anonymous ftp to ftp.cs.arizona.edu in /icon/library, but there is all kinds of other good stuff floating in the directories near and around there. -- Scott Gilbert ( scott@cs.arizona.edu ) From icon-group-sender Fri Oct 28 21:32:11 1994 Received: by cheltenham.cs.arizona.edu; Sat, 29 Oct 1994 20:20:47 MST To: icon-group-l@cs.arizona.edu Date: 28 Oct 1994 21:32:11 GMT From: kim@cs.arizona.edu (Kyung Soo Kim) Message-Id: <38rqkr$nat@optima.cs.arizona.edu> Organization: U of Arizona, CS Dept, Tucson Sender: icon-group-request@cs.arizona.edu Subject: Icon 9.0 for MS-Windows Errors-To: icon-group-errors@cs.arizona.edu Is anyone porting Icon 9.0 for MS-Windows, NT or 3.1 or 4.0? Kenny From icon-group-sender Sat Oct 29 20:11:19 1994 Received: by cheltenham.cs.arizona.edu; Sat, 29 Oct 1994 20:23:52 MST To: icon-group-l@cs.arizona.edu Date: 29 Oct 1994 20:11:19 GMT From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <38ua97$48k@ringer.cs.utsa.edu> Organization: University of Texas at San Antonio Sender: icon-group-request@cs.arizona.edu References: <38rqkr$nat@optima.cs.arizona.edu> Subject: Re: Icon 9.0 for MS-Windows Errors-To: icon-group-errors@cs.arizona.edu Kyung Soo Kim (kim@cs.arizona.edu) wrote: : Is anyone porting Icon 9.0 for MS-Windows, NT or 3.1 or 4.0? From the Icon FAQ, you can find out that Icon 9.0 is being ported to Windows; the Win32 port is well along, to the alpha-test stage. I welcome offers from folks who want to beta test when I am ready to do so. If anyone wants to help more substantially on it, please feel free to contact me. By the way, I already have a long-ish list of volunteers, and if you already sent me a message about it, thanks for your patience and I'll contact you when we're ready to beta. I could probably also use volunteers pretty soon who want to compile it on various compilers. -- Clint Jeffery cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Tue Nov 1 09:18:08 1994 Received: by cheltenham.cs.arizona.edu; Tue, 1 Nov 1994 08:41:27 MST To: icon-group-l@cs.arizona.edu Date: 1 Nov 1994 09:18:08 -0500 From: hunnia@aol.com (HUNNIA) Message-Id: <395in0$2ec@newsbf01.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Subject: Colors to Widgets. Errors-To: icon-group-errors@cs.arizona.edu Could anybody show an example, that after I created for example a radio button with the VIB, XIB how can I add color to it. Unfilled vidgets do not look nice. Sandor From icon-group-sender Wed Nov 2 23:48:36 1994 Received: by cheltenham.cs.arizona.edu; Wed, 2 Nov 1994 18:06:46 MST To: icon-group-l@cs.arizona.edu Date: 2 Nov 1994 23:48:36 GMT From: Soon E MC Message-Id: <3998gk$so5@sifon.cc.mcgill.ca> Organization: McGill University Computing Centre Sender: icon-group-request@cs.arizona.edu Subject: MS-WINDOWS 3.1? Errors-To: icon-group-errors@cs.arizona.edu Is the icon interpeter available for MS-Windows 3.1? thanks. m.z./ From icon-group-sender Fri Nov 4 10:28:02 1994 Received: by cheltenham.cs.arizona.edu; Fri, 4 Nov 1994 12:44:22 MST To: icon-group-l@cs.arizona.edu Date: 4 Nov 1994 10:28:02 -0500 From: hunnia@aol.com (HUNNIA) Message-Id: <39dju2$ggk@newsbf01.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Subject: Cheat sheet? Errors-To: icon-group-errors@cs.arizona.edu Where can I find a short description of all the built in functions, keywords and operators in Icon, on the internet? The documentation package does dnot provide it. Is there a mailing list? Sandor From icon-group-sender Fri Nov 4 11:19:05 1994 Received: by cheltenham.cs.arizona.edu; Fri, 4 Nov 1994 12:45:55 MST Message-Id: <9411041819.AA11551@orpheus.gemini.edu> From: swampler@noao.edu Date: Fri, 4 Nov 1994 11:19:05 GMT+447 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: icon-group@cs.arizona.edu Subject: A debugging hint... Content-Length: 1478 Errors-To: icon-group-errors@cs.arizona.edu This is a trick I use when debugging Icon code. Maybe someone else will find it useful... When trying to track down a bug in an Icon program, &trace does a nice job of showing the procedure calls and returns, including the line numbers. Unfortunately, it doesn't help in sections of code where there are long stretches without any procedure calls. A common method to 'trace' in those code stretches is to embed calls to 'write()', but then you have to do something to each call to disable them for runs without tracing, and put something into the argument list to each write to identify the line (&line is nice for that, incidently, etc.) Let &trace work for you. Create a procedure: procedure Trace(s) return end and embed the calls to it where you would have put the write()s before: Trace(i) ... Trace("at start of loop") etc. Now just run the program with &trace turned on. Presto, you see a nice 'trace' showing the line numbers of the calls to Trace and the value of the argument. Turn off &trace, and the debug output isn't shown. If you want to see multiple values at each trace point, change the procedure to: procedure Trace(s[]) return end and now you can call it as: Trace("size of table is", *symbol_table) I hope someone finds this useful. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] -- The Gods that were smiling when you were born are laughing now. -- found in a fortune cookie From icon-group-sender Fri Nov 4 08:44:38 1994 Received: by cheltenham.cs.arizona.edu; Fri, 4 Nov 1994 12:47:59 MST To: icon-group-l@cs.arizona.edu Date: 4 Nov 1994 08:44:38 -0700 From: icon-project@cs.arizona.edu Message-Id: <39dkt6$sbe@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Frequently Asked Questions About The Icon Programming Language last updated: 08/21/94 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 602-621-8448 (voice) 602-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Fri Nov 4 16:46:34 1994 Received: by cheltenham.cs.arizona.edu; Fri, 4 Nov 1994 20:12:23 MST Date: Fri, 4 Nov 1994 16:46:34 MST From: "Cliff Hathaway" Message-Id: <199411042346.AA07790@cheltenham.cs.arizona.edu> To: hunnia@aol.com Subject: Re: Cheat sheet? Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu There's an online help program in the Basic Icon Program Library (bipl), available via anonymous ftp from ftp.cs.arizona.edu, in the /icon/libarary directory. The program is called ihelp. I don't know of any reference card for Icon. Cliff Hathaway From icon-group-sender Mon Nov 7 10:40:36 1994 Received: by cheltenham.cs.arizona.edu; Mon, 7 Nov 1994 12:25:29 MST Date: Mon, 7 Nov 94 10:40:36 PST From: slengy@calcomp.com (Sandor Lengyel x5786) Message-Id: <9411071840.AA24533@ecad04.plotter.calcomp.com> To: icon-group@cs.arizona.edu Subject: XIB for OS/2 problem Errors-To: icon-group-errors@cs.arizona.edu I installed XIB for the OS/2 Icon. It comes up properly. I can put vidgets in the window, but when I do save or prototype, the resulting *.icn file is empty, and the *.exe file does not do anything. What did I do wrong? Sandor. From icon-group-sender Mon Nov 7 01:04:16 1994 Received: by cheltenham.cs.arizona.edu; Tue, 8 Nov 1994 08:10:16 MST To: icon-group-l@cs.arizona.edu Date: 7 Nov 1994 01:04:16 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Message-Id: <39jueg$bu3@lowell.bellcore.com> Organization: Bellcore, Morristown NJ Sender: icon-group-request@cs.arizona.edu References: <39dju2$ggk@newsbf01.news.aol.com> Subject: Re: Cheat sheet? Errors-To: icon-group-errors@cs.arizona.edu I make heavy use of the ihelp program distributed with the icon program library. From icon-group-sender Tue Nov 8 15:16:01 1994 Received: by cheltenham.cs.arizona.edu; Tue, 8 Nov 1994 12:27:34 MST To: icon-group-l@cs.arizona.edu Date: Tue, 8 Nov 1994 15:16:01 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: <39dju2$ggk@newsbf01.news.aol.com> Subject: Re: Cheat sheet? Errors-To: icon-group-errors@cs.arizona.edu HUNNIA (hunnia@aol.com) wrote: : Where can I find a short description of all the built in functions, : keywords and operators in Icon, on the internet? : The documentation package does dnot provide it. The book "The Icon programming language", by Griswold contains an appendix that describes all the built-in functions and operators. Make sure that you get the 2nd edition. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com Compuserve: 72470,116 ---------------------- From icon-group-sender Tue Nov 8 23:53:22 1994 Received: by cheltenham.cs.arizona.edu; Wed, 9 Nov 1994 08:04:20 MST To: icon-group-l@cs.arizona.edu Date: Tue, 8 Nov 1994 23:53:22 GMT From: toni@usenix.org (Toni Veglia) Message-Id: Organization: USENIX Association, Berkeley, CA Sender: icon-group-request@cs.arizona.edu Reply-To: toni@usenix.org (Toni Veglia) Subject: USENIX Very High Level Languages Symposium Proceedings Available Errors-To: icon-group-errors@cs.arizona.edu If you couldn't attend the USENIX Very High Level Languages Symposium held October, you can now purchase the proceedings for $23 for members, and $30 for non-members. This price includes domestic and Canadian shipping; please add $10 for overseas postage (air printed matter). You can place your order by fax, email, or phone by using a VISA or Mastercard, or you can mail a check to the address below. USENIX Association phone: +1 510 528 8649 2560 Ninth Street, Suite 215 fax: +1 510 548 5738 Berkeley, CA 94710 USA email: office@usenix.org ================================================================= TABLE OF CONTENTS VERY HIGH LEVEL LANGUAGES SYMPOSIUM October 26-28, 1994 Santa Fe, New Mexico An Anecdote about ML Type Inference Andrew Koenig, AT&T Bell Laboratories libscheme: Scheme as a C Library Brent W. Benson Jr., Harris Computer Systems A New Architecture for the Implementation of Scripting Languages Adam Sah and Jon Blow, University of California, Berkeley Tcl/Tk for a Personal Digital Assistant Karin Petersen, Xerox PARC Using Tcl to Control a Computer-Participative Multimedia Programming Environment Christopher J. Lindblad, Massachusetts Institute of Technology TkPerl -- A port of the Tk toolkit to Perl5 Dr. Malcolm Beattie, Oxford University Computing Services Rapid Programming with Graph Rewrite Rules Dr. Andy Scherr, University of Technology, Aachen, Germany End-User Systems, Reusability and High-Level Design Glenn S. Fowler, John J. Snyder, and Kiem-Phong Vo, AT&T Bell Laboratories Compiling Matlab Stephen C. Johnson, Melismatic Software and Cleve Moler, The MathWorks, Inc. ksh: An Extensible High Level Language David G. Korn, AT&T Bell Laboratories Fornax: A General-Purpose Programming Language J. Storrs Hall, Laboratory for Computer Science Research, Rutgers University Graphics Programming in Icon Version 9 Clinton L. Jeffery, University of Texas, San Antonio Two Application Languages in Software Production David A. Ladd and J. Christopher Ramming, AT&T Bell Laboratories Using a Very High Level Language to Build Families of High Quality Reusable Components Gary F. Pollice, CenterLine Software Inc. and University of Massachusetts, Lowell Dixie Languages and Interpreter Issues R. Stockton Gaines, University of Southern California, Information Sciences Institute Feature-Based Portability Glenn S. Fowler, David G. Korn, John J. Snyder and Kiem-Phong Vo, AT&T Bell Laboratories Application Experience with an Implicitly Parallel Composition Language R. Jagannathan and Chris Dodd, Computer Science Laboratory, SRI International ================================================================= To get more information about USENIX publications, events, or membership, access the USENIX Resource Center on the World Wide Web. The URL is: http://www.usenix.org Or, send mail to our automatic mailserver at: info@usenix.org Send in your message the line: send catalog and the catalog of available information will be returned to you. ================================================================= From icon-group-sender Wed Nov 9 15:16:30 1994 Received: by cheltenham.cs.arizona.edu; Thu, 10 Nov 1994 08:04:40 MST To: icon-group-l@cs.arizona.edu Date: Wed, 9 Nov 1994 15:16:30 GMT From: Ryan Walcott Message-Id: Organization: AT&T Global Information Solutions Sender: icon-group-request@cs.arizona.edu Reply-To: Ryan.Walcott@columbiasc.ncr.com (WALCOTT) Subject: Optimizing Icon on a UNIX Platform Errors-To: icon-group-errors@cs.arizona.edu We use ICON applications at AT&T Global Information Solutions to create statistical reports on data generated by benchmark runs. Currently these reports take several hours to run. Is there a way to optimize the applications for our platform so that the reports will execute faster? We are considering porting the applications to C and recompiling, but would like to avoid this if possible because they are very long and complicated. Any tips or suggestions would be greatly appreciated. Ryan Walcott AT&T Global Information Solutions Ryan.Walcott@ColumbiaSC.NCR.COM (803) 939-6350 From icon-group-sender Thu Nov 10 14:23:34 1994 Received: by cheltenham.cs.arizona.edu; Thu, 10 Nov 1994 13:01:17 MST To: icon-group-l@cs.arizona.edu Date: 10 Nov 1994 14:23:34 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <39tad6$6nr@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Optimizing Icon on a UNIX Platform Errors-To: icon-group-errors@cs.arizona.edu Hi, Ryan, Ryan Walcott (Ryan.Walcott@ColumbiaSC.NCR.COM) wrote: : We use ICON applications at AT&T Global Information Solutions to create : statistical reports on data generated by benchmark runs. Currently these : reports take several hours to run. I smell some recursion here :-) : Is there a way to optimize the applications for our platform so that the : reports will execute faster? We are considering porting the applications to C : and recompiling, but would like to avoid this if possible because they are : very long and complicated. I don't know whether you are using the interpreter of the compiler for these icon programs, but if you are using the interpreter you might try to compile the programs using the Icon compiler. If you don't do really esoteric things this might speed up your executables considerably. Another (tedious, but probably effective) option would be to port critical sections to C, and hook the C code up to the icon programs. This might also gain some speed. Hope this helps. Jan From icon-group-sender Thu Nov 10 10:40:37 1994 Received: by cheltenham.cs.arizona.edu; Thu, 10 Nov 1994 13:03:45 MST Date: Thu, 10 Nov 1994 10:40:37 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9411101640.AA07036@runner.utsa.edu> To: Ryan.Walcott@columbiasc.ncr.com Cc: icon-group@cs.arizona.edu In-Reply-To: (message from Ryan Walcott on Wed, 9 Nov 1994 15:16:30 GMT) Subject: Re: Optimizing Icon on a UNIX Platform Content-Length: 2013 Errors-To: icon-group-errors@cs.arizona.edu > We use ICON applications at AT&T Global Information Solutions to create > statistical reports on data generated by benchmark runs. Currently these > reports take several hours to run. > Is there a way to optimize the applications for our platform so that the > reports will execute faster? We are considering porting the applications > to C and recompiling, but would like to avoid this if possible because > they are very long and complicated. There is no quick and easy solution to this, beyond studying the programs' behavior, and using the Icon compiler for performance-critical applications if it is feasible to do so. Hiring an Icon guru to look at your code might be another possibility... The "real" solution to this is for some of us to invest further in the language. What we have so far is free, thanks to the investment by the National Science Foundation and countless donated hours by the Griswolds and various volunteers. Here are two further investments, one that we are pursuing, and one that we haven't the resources to pursue at present: (1) Invest in profiling and debugging tools. Taking the research on execution monitoring and visualization that's already been done and putting it in the hands of users is a lot of work, but we are in the process of doing this. The core supporting code is present in the Icon 9.0 sources, but I think it will take awhile to do useful end-user documentation and produce a polished Icon Program Library section on profiling, debugging, and visualization. Some interesting profiling and debugging tools have been produced by Icon users, which is another way to invest. (2) Invest further in the Icon compiler. With adequate resources, it could be maintained and further optimized. Whether this happens appears like it will depend on whether the industry folks and users choose to make it so. You could do it yourself and contribute it to the community, or you could commit resources to Icon Project for that express purpose. From icon-group-sender Thu Nov 10 18:48:11 1994 Received: by cheltenham.cs.arizona.edu; Thu, 10 Nov 1994 18:01:14 MST To: icon-group-l@cs.arizona.edu Date: Thu, 10 Nov 1994 18:48:11 GMT From: gmurphy@june.cs.washington.edu (Gail Murphy) Message-Id: Organization: University of Washington, Department of Computer Science and Engineering Sender: icon-group-request@cs.arizona.edu Reply-To: gmurphy@cs.washington.edu Subject: Three Questions: Allocated, Memory, and C Functions/Porting to PC Errors-To: icon-group-errors@cs.arizona.edu Some questions from a novice Icon user.... 1. Does anyone have any example programs using the &allocated keyword? From the documentation, I thought it would return 4 values, but I am only getting one on the DECstation and the Alpha using Icon 9. 2. I have an Icon program that must process input character by character for tokenizing. This creates a lot of garbage, slowing things down considerably. Is there any way to manage some memory directly in conjunction with the garbage collector? Or are there any hints for efficent use of Icon on a character by character basis? 3. One way around #2 above may be to use a C function. Can C functions be linked in with the PC version? Does anyone have any experience doing this and supporting the feature under both Unix and DOS? Thanks, Gail. ------------------------------------------------------------ Gail Murphy Graduate Student Department of Computer Science and Engineering, FR-35 University of Washington, Seattle WA 98195 (206) 616-1847 gmurphy@cs.washington.edu ------------------------------------------------------------ From icon-group-sender Thu Nov 10 21:30:12 1994 Received: by cheltenham.cs.arizona.edu; Fri, 11 Nov 1994 15:22:46 MST To: icon-group-l@cs.arizona.edu Date: 10 Nov 1994 21:30:12 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <39us0k$i35@caslon.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Three Questions: Allocated, Memory, and C Functions/Porting to PC Errors-To: icon-group-errors@cs.arizona.edu In article , Gail Murphy wrote: > >1. Does anyone have any example programs using the &allocated keyword? > From the documentation, I thought it would return 4 values, but > I am only getting one on the DECstation and the Alpha using > Icon 9. Try this: procedure main() every write( &allocated ) end It works for me. >2. I have an Icon program that must process input character by character for > tokenizing. This creates a lot of garbage, slowing things down considerably. Are you reading in characters one at a time? If so, try reading in a line at a time. I've done tokenizing (of Icon itself) that way. I didn't check how bad garbage collection was, but the routine runs tolerably fast. >3. [...] Can C functions be linked in with the PC version? I don't know the immediate answer to this quetion. I have looked at the documentation for combining C functions with Icon programs, and it looks like a lot of work (and probably over the head of the average Icon novice). I would highly recommend looking hard for a solution within Icon before bailing to C. -Dave From icon-group-sender Fri Nov 11 09:25:09 1994 Received: by cheltenham.cs.arizona.edu; Fri, 11 Nov 1994 15:23:58 MST To: icon-group-l@cs.arizona.edu Date: 11 Nov 1994 09:25:09 -0500 From: hunnia@aol.com (HUNNIA) Message-Id: <39vus5$169@newsbf01.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Subject: Re: Optimizing on the UNIX Platform Errors-To: icon-group-errors@cs.arizona.edu The Icon compiler is called ICONC, and it works hand in hand with your C compiler. From icon-group-sender Fri Nov 11 09:30:30 1994 Received: by cheltenham.cs.arizona.edu; Fri, 11 Nov 1994 15:24:34 MST To: icon-group-l@cs.arizona.edu Date: 11 Nov 1994 09:30:30 -0500 From: hunnia@aol.com (HUNNIA) Message-Id: <39vv66$19i@newsbf01.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Subject: Icon OS/2 problems Errors-To: icon-group-errors@cs.arizona.edu The following segment outputs data to a file, if compiled under OS/2 ICONT, but generate only an empty file if compiled under OS/2 XICONT. It will print correctly onto a window, if "w' is changed into "x". Why cannot I get a file output with XICONT in OS/2 aFile := open("app.icn","w") write(aFile,"This is a test") Thanks Sandor From icon-group-sender Fri Nov 11 16:49:42 1994 Received: by cheltenham.cs.arizona.edu; Fri, 11 Nov 1994 15:25:06 MST To: icon-group-l@cs.arizona.edu Date: 11 Nov 1994 16:49:42 GMT From: dmerrill@hobbes.boulder.ibm.com (Darren Merrill) Message-Id: <3a07b6INN8t9@afshub.boulder.ibm.com> Organization: IBM Boulder Sender: icon-group-request@cs.arizona.edu References: <39vv66$19i@newsbf01.news.aol.com> Reply-To: dmerrill@hobbes.boulder.ibm.com (Darren Merrill) Subject: Re: Icon OS/2 problems Errors-To: icon-group-errors@cs.arizona.edu In article <39vv66$19i@newsbf01.news.aol.com>, hunnia@aol.com (HUNNIA) writes: |> The following segment outputs data to a file, if compiled |> under OS/2 ICONT, but generate only an empty file if |> compiled under OS/2 XICONT. It will print correctly onto |> a window, if "w' is changed into "x". |> Why cannot I get a file output with XICONT in OS/2 |> |> aFile := open("app.icn","w") |> write(aFile,"This is a test") |> |> Thanks |> Sandor Bug in PM icon runtime. Darren Merrill From icon-group-sender Mon Nov 14 10:06:22 1994 Received: by cheltenham.cs.arizona.edu; Wed, 16 Nov 1994 05:34:55 MST To: icon-group-l@cs.arizona.edu Date: 14 Nov 1994 10:06:22 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3a7cqu$p8f@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: Sockets? Errors-To: icon-group-errors@cs.arizona.edu Hi, Does anyone know anything on the use of sockets in (unix) Icon? I'd like to use them, and I would also like to avoid using Perl :-) Thanks for any information. Jan From icon-group-sender Wed Nov 16 08:29:27 1994 Received: by cheltenham.cs.arizona.edu; Wed, 16 Nov 1994 08:44:22 MST Date: Wed, 16 Nov 1994 08:29:27 -0700 From: Gregg Townsend Message-Id: <199411161529.IAA29108@owl.CS.Arizona.EDU> To: icon-group@owl Subject: Icon on the Web Content-Length: 473 Errors-To: icon-group-errors@cs.arizona.edu For those of you with access to Mosaic or similar browsers, there is now an Icon page on the World Wide Web. Its URL is: http://www.cs.arizona.edu/icon/www/ The Icon FAQ and Help Summaries are available as well as a link to our FTP area. We thank Bob Alexander for putting this material into hypertext form. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Wed Nov 16 15:15:56 1994 Received: by cheltenham.cs.arizona.edu; Wed, 16 Nov 1994 11:59:46 MST To: icon-group-l@cs.arizona.edu Date: 16 Nov 1994 15:15:56 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3ad7nc$6v0@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: socket question dumb? Errors-To: icon-group-errors@cs.arizona.edu Hi, Since I haven't gotten any reply to my question about how to program sockets in Icon, I started to wonder whether my question was a "dumb question". Is that so? I did not find it in the FAQ or in the documentation, anyhow. Could someone please help me out? cheers, Jan From icon-group-sender Wed Nov 16 21:00:52 1994 Received: by cheltenham.cs.arizona.edu; Wed, 16 Nov 1994 16:08:36 MST Date: Wed, 16 Nov 94 21:00:52 GMT From: Steve Holden Message-Id: <9411162100.AA23344@r7.cs.man.ac.uk> To: icon-group@cs.arizona.edu Subject: Re: socket question dumb? Errors-To: icon-group-errors@cs.arizona.edu Since I haven't gotten any reply to my question about how to program sockets in Icon, I started to wonder whether my question was a "dumb question". Is that so? I did not find it in the FAQ or in the documentation, anyhow. Could someone please help me out? Doesn't seem like a dumb question to me, but the answer is, I suspect, "program access routines in C and build them into Icon". regards Steve -------------------------------------------------------------------- Steve Holden Scotia Electronic Publishing Tel: +44 436 678962 29 John Street Fax: +44 436 677814 Helensburgh Internet: steveh@cs.man.ac.uk Scotland Compuserve: 100343,2205 G84 8XL -------------------------------------------------------------------- Tools, Technology and Training for Successful Electronic Publishing. -------------------------------------------------------------------- From icon-group-sender Thu Nov 17 06:31:08 1994 Received: by cheltenham.cs.arizona.edu; Thu, 17 Nov 1994 05:32:28 MST Date: Thu, 17 Nov 1994 06:31:08 -0600 (CST) From: Chris Tenaglia | 456-8765 Subject: Re:Sockets? To: icon-group@cs.arizona.edu Message-Id: <01HJKRAMVRGO8WVZ2E@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu I don't know what they are exactly, but it sounds like opening a pipe and either reading from it or writing to it. I have asked about 2 way pipes, but the answer I got was that it was too hard. I thought about writing to a pipe to do clever things with email by telnetting to the sendmail port but without the two way pipe there was no way to make it reliable. Maybe this what you mean by sockets? Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future foretold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)456-8765 | tenaglia@mis.mcw.edu > Since I haven't gotten any reply to my question about how to > program sockets in Icon, I started to wonder whether my > question was a "dumb question". Is that so? I did not find > it in the FAQ or in the documentation, anyhow. Could someone > please help me out? > Doesn't seem like a dumb question to me, but the answer is, I suspect, > "program access routines in C and build them into Icon". > regards > Steve > -------------------------------------------------------------------- > Steve Holden Scotia Electronic Publishing > Tel: +44 436 678962 29 John Street > Fax: +44 436 677814 Helensburgh > Internet: steveh@cs.man.ac.uk Scotland > Compuserve: 100343,2205 G84 8XL > -------------------------------------------------------------------- > Tools, Technology and Training for Successful Electronic Publishing. > -------------------------------------------------------------------- From icon-group-sender Thu Nov 17 08:07:24 1994 Received: by cheltenham.cs.arizona.edu; Thu, 17 Nov 1994 08:07:29 MST Date: Thu, 17 Nov 1994 08:07:24 -0700 From: Gregg Townsend Message-Id: <199411171507.IAA00279@owl.CS.Arizona.EDU> To: icon-group@owl Subject: Re: socket question Content-Length: 446 Errors-To: icon-group-errors@cs.arizona.edu Icon contains no explicit socket support. In the Icon library, however, there is a simple C interface to TCP sockets (sufficient, say, for a news reader) in the packs/loadfunc directory. It's loaded into Icon via loadfunc(), which is implemented on Sun, SGI, and Dec Alpha machines. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Fri Nov 18 06:00:24 1994 Received: by cheltenham.cs.arizona.edu; Thu, 17 Nov 1994 22:12:59 MST To: icon-group-l@cs.arizona.edu Date: 18 Nov 1994 06:00:24 GMT From: blue@achilles.net (Brian Tiffin) Message-Id: <3ahfto$2na@hermes.achilles.net> Organization: B.W. Tiffin Enterprises Inc. Sender: icon-group-request@cs.arizona.edu References: <3ad7nc$6v0@highway.LeidenUniv.nl> Subject: Re: socket question dumb? Errors-To: icon-group-errors@cs.arizona.edu In article <3ad7nc$6v0@highway.LeidenUniv.nl>, ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) says: > >Hi, > >Since I haven't gotten any reply to my question about how to >program sockets in Icon, I started to wonder whether my >question was a "dumb question". Is that so? I did not find >it in the FAQ or in the documentation, anyhow. Could someone >please help me out? > >cheers, > >Jan I don't think it's a dumb question, but I think you may want to do socket programming in C and attempt to link it for calling from Icon. (Something I have never attempted but seems reasonable if you can keep the interface small and tight.) Blue ~~~~ From icon-group-sender Sun Nov 20 21:40:31 1994 Received: by cheltenham.cs.arizona.edu; Sun, 20 Nov 1994 15:13:34 MST To: icon-group-l@cs.arizona.edu Date: 20 Nov 1994 21:40:31 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3aofof$f5m@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu Hi, I've just finished reading (first pass) the book "The Implementation of the Icon Programming Language" by Griswold & Griswold and I can recommend any Icon programmer to read this book too. Not only is it beautifully set, highly readable and very informative, it also gives a whole new view on how powerful and sophisticated the language actually is. Having said this, I remember Tim Peters (who used to honor the Icon newsgroup with helpful advice, and who did some outrageous programming in Icon) saying in a private email to me that it is a pity that the performance of Icon prevents the Icon compiler/interpreter to be written in Icon. This performance issue is one that I gladly take for granted seeing how much time I save in developing Icon programs (as opposed to, say, C programs) but I also agree with Tim that it would be nice to be able to bootstrap Icon. Being somewhat wiser after having read the book, I also fully understand why the Icon compiler depends so heavily on run-time checks. But I started analysing some of my Icon programs that I would like to speed up, and noticed that many times *I* know (as opposed to the compiler) that variable V is only used as {integer, string, real etc} or as {list_of_integer, list_of_strings, table_of_strings_and_ints, etc }. So my question is: what do you think of the option to add *optional* type declarations to Icon? By optional type declarations I mean something along these lines: global count : table(string,integer,0) procedure main() local f : file f := open("wordlist") concordance(f) end procedure concordance(f : file) local s : string while s := read(f) do count[s] +:= 1 end Please realise that the syntax does not matter here - the idea is that if I know that s is only going to be used as string, I can declare it to be a string-only variable. I don't *have* to, but I can. BTW, the typing scheme could of course allow for things like: local count : table(list(string),list(real),[]) in other words, type embeddings could be allowed as well. This optional typing would of course be truly optional. That is, any Icon program without type declarations would run without modification. At the moment, I see great advantages in such an extension of Icon. Allowing type declarations is not the same as enforcing them, and nobody would be forced to use them. Programs could be developped using dynamic-type variables as they are now, and later be optimised by adding types. I am aware of the fact that this would mean an extensive modification of both the Icon compiler and interpreter. Also, I understand that problems arise with mixing typed and untyped variables. In order to allow for mixtures, a special type declaration (e.g. 'dynamic') could be used to allow for mixing typed and dynamic variables. Extending the Icon compiler would be a lot of work, I guess, but the technology is already there - most compilers use type checking and as you know probably better than me, the theory of typing systems is quite advanced. For the runtime environment, I am not sure excactly what the consequences would be. The specific questions I have for the Icon community are: o How much optimisation opportunities will arise from having variables with a fixed type. o How much speed & size performance gain could be expected from this. o Could a typed variable also lead to more efficient generators and backtracking (over typed variables of course). o Could a version of the Icon runtime environment be developed that gives information on how often the type of all variables changes during program execution (in order to obtain reliable statistics on how often variables are, in effect, of fixed type) o What do you generally think about this idea. Any comments welcome. Please do not interpret this posting as criticism on Icon, for it is not intended as such. Greetings, Jan From icon-group-sender Sun Nov 20 16:57:46 1994 Received: by cheltenham.cs.arizona.edu; Sun, 20 Nov 1994 18:15:15 MST To: icon-group-l@cs.arizona.edu Date: 20 Nov 1994 16:57:46 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <3aonpq$4kp@caslon.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3aofof$f5m@highway.leidenuniv.nl> Subject: Re: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu In article <3aofof$f5m@highway.leidenuniv.nl>, Jan-Peter de Ruiter wrote: [much deletia] >o How much optimisation opportunities will arise from having > variables with a fixed type. For types that have primitive operations that can be implemented in a few machine operations (few enough to be in-lined reasonably), this can be a significant savings. Not only do you get the benefit of not having to go through the general case (which probably involves a function call), but you also get the benefit of less stuff dynamically allocated, so the garbage collecter has less work to do. For stuff like lists and tables, where most operations are going to be function calls anyway (and probably require garbage collection anyway), there probably won't be any benefit at all. >o How much speed & size performance gain could be expected from > this. I wouldn't look for a lot of size gain from this sort of optimization. Much of the size of a compiled Icon program is due to the support libraries, which you'll need anyway. Speed is really where the win is in this kind of optimization. How much speed you can get is a matter for research. >o Could a version of the Icon runtime environment be developed > that gives information on how often the type of all variables > changes during program execution (in order to obtain reliable > statistics on how often variables are, in effect, of fixed type) Sure. In fact, you could probably do this with MT Icon (multi-tasking Icon) reasonably easy. (see ftp:cs.arizona.edu/icon/monitors for info on MT Icon) -Dave From icon-group-sender Mon Nov 21 01:07:51 1994 Received: by cheltenham.cs.arizona.edu; Mon, 21 Nov 1994 00:08:04 MST Date: Mon, 21 Nov 1994 01:07:51 +0600 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9411210707.AA09975@runner.utsa.edu> To: ruiter@ruls41.fsw.LeidenUniv.nl Cc: icon-group@cs.arizona.edu In-Reply-To: <3aofof$f5m@highway.LeidenUniv.nl> (ruiter@ruls41.fsw.LeidenUniv.nl) Subject: Re: optional typing in Icon (longish) Content-Length: 973 Errors-To: icon-group-errors@cs.arizona.edu > Jan Peter de Ruiter suggests we add optional type declarations to Icon... The Icon implementation book contains much useful material based on the Icon version 6.0 translator/interpreter system (icont), but it does not report on the last 7-8 years' of work on Icon. The Icon compiler (iconc) does type inferencing and determines a precise type for over 90% of the uses of variables. It produces code that skips run-time checks when they are not needed. Your suggestion would speed up the Icon interpreter somewhat, but would not help the Icon compiler much. I think optional type declarations are a good idea anyhow, because in larger (multiperson) projects, they would serve as documentation and as an assertion that the Icon compiler could verify during type inferencing. Unfortunately, there are presently no resources to pursue this kind of effort, so your options are: write your own, or form a group that will support these kinds of additions to the language. From icon-group-sender Mon Nov 21 01:19:30 1994 Received: by cheltenham.cs.arizona.edu; Mon, 21 Nov 1994 05:45:11 MST To: icon-group@cs.arizona.edu Subject: Re: optional typing in Icon (longish) Message-Id: <785380770@mse> Date: Mon, 21 Nov 94 01:19:30 UTC From: whm@mse.com (William H. Mitchell) Errors-To: icon-group-errors@cs.arizona.edu In the past I've done some sketching on the notion of optional types in Icon. My own interest has been motivated not by performance, but rather by using Icon for programming in the large. Having used C++ for a number of years I've come to appreciate the language's ability to stop a lot of stupid errors at compile time. On the other hand, in the typical C++ program evolving intra-program interfaces usually cause a lot of suffering because of extensive recompilation being required for even the smallest change in common interfaces. I'd like to have my cake and eat it too: I'd like to be able to fully specify stable interfaces and have compliance checked at compile time and I'd also like to have unspecfied or partially specified interfaces for code under development. A lot of issues come to mind immediately and I have to think that the idea of partial typing must have had some research exploration already. Does anybody know of languages that directly support the concept? /------------------------------\ /----------------\ / William H. Mitchell \ / 7120 E. Kiva Way \ / Mitchell Software Engineering \o----/ Tucson, AZ, 85715 \ \ Consulting/Development/Training / \ 602-577-6431 / \ OO Methods/C++/Icon/UNIX / \ whm@mse.com / \------------------------------/ \----------------/ From icon-group-sender Mon Nov 21 11:31:37 1994 Received: by cheltenham.cs.arizona.edu; Mon, 21 Nov 1994 13:15:18 MST To: icon-group-l@cs.arizona.edu Date: 21 Nov 1994 11:31:37 -0700 From: kline@cs.arizona.edu (Nick Kline) Message-Id: <3aqp29$do0@cheltenham.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3aofof$f5m@highway.leidenuniv.nl>, <3aonpq$4kp@caslon.cs.arizona.edu> Subject: Re: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu In article <3aonpq$4kp@caslon.cs.arizona.edu>, Dave Schaumann wrote: >In article <3aofof$f5m@highway.leidenuniv.nl>, >Jan-Peter de Ruiter wrote: >[much deletia] >>o How much optimisation opportunities will arise from having >> variables with a fixed type. > >For types that have primitive operations that can be implemented >in a few machine operations (few enough to be in-lined reasonably), >this can be a significant savings. Not only do you get the benefit >of not having to go through the general case (which probably involves >a function call), but you also get the benefit of less stuff dynamically >allocated, so the garbage collecter has less work to do. and also think how much this would complicate the runtime. The run time is complex, but basically it has encapsulated types, and all the run time function take these as parameters. It can take a pointer and see what type it is and decide whether to convert it to a string, or convert a string to an int and add another number to it or whatever. If we could somehow figure out that certain things were only going to be used as ints (and it is sure possible), then we would need to have a much more complex runtime, which instead of simply passing ptrs to "objects" as parameters to icon internal routines, we'd need to special case all that code in the case where we already knew things were ints. I think a better soln is to improve the icon compiler (which I know clint has one of his students working on). -nick From icon-group-sender Tue Nov 22 12:49:51 1994 Received: by cheltenham.cs.arizona.edu; Tue, 22 Nov 1994 08:17:18 MST To: icon-group-l@cs.arizona.edu Date: 22 Nov 1994 12:49:51 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3aspdf$ob3@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu References: <3aofof$f5m@highway.leidenuniv.nl>, <3aonpq$4kp@caslon.cs.arizona.edu>, <3aqp29$do0@cheltenham.cs.arizona.edu> Subject: Re: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu Nick Kline (kline@CS.Arizona.EDU) wrote: : If we could somehow figure out that certain things were only going to : be used as ints (and it is sure possible), then we would need to have a much : more complex runtime, which instead of simply passing ptrs to "objects" as : parameters to icon internal routines, we'd need to special case all : that code in the case where we already knew things were ints. Sure, some code would have to be added, but a *lot* of code does not need to be executed anymore. It's just two sides of a coin. Jan From icon-group-sender Tue Nov 22 15:33:59 1994 Received: by cheltenham.cs.arizona.edu; Tue, 22 Nov 1994 09:18:37 MST To: icon-group-l@cs.arizona.edu Date: 22 Nov 1994 15:33:59 GMT From: pmcnally@uoguelph.ca (Paul Mcnally) Message-Id: <3at317$qus@nermal.cs.uoguelph.ca> Organization: University of Guelph Sender: icon-group-request@cs.arizona.edu References: <3aonpq$4kp@caslon.cs.arizona.edu>, <3aqp29$do0@cheltenham.cs.arizona.edu>, <3aspdf$ob3@highway.LeidenUniv.nl> Subject: Re: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu [stuff deleted] I find this thread very interesting. I am currently reading _The Icon Programming Lanuguage_ by Griswold & Griswold. More specifically, I have read the section on records. I was able to do all sorts of untold things to various fields that would horrify my professors! (not a bad idea ;) ) I think that records would be one of those instances where the types do not usually (should not ? ) change. In fact, the fact that there is no static typing in records makes icon a dubious choice in database applications. Any comments? I am currently writing an undergraduate term paper on icon and any comments on this or any issue would be well received. Thx Paul -- \\\\\// | | (.)^(.) ==========================oOO==(_)==OOo============================ Paul McNally Computer Support Computing & Communications Services University of Guelph Ontario, Canada =================================================================== From icon-group-sender Tue Nov 22 23:01:55 1994 Received: by cheltenham.cs.arizona.edu; Tue, 22 Nov 1994 17:16:42 MST To: icon-group-l@cs.arizona.edu Date: Tue, 22 Nov 1994 23:01:55 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Nov22.230155.10114@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: <3aqp29$do0@cheltenham.cs.arizona.edu>, <3aspdf$ob3@highway.LeidenUniv.nl>, <3at317$qus@nermal.cs.uoguelph.ca> Subject: Re: optional typing in Icon (longish) Errors-To: icon-group-errors@cs.arizona.edu Also sprach pmcnally@uoguelph.ca (Paul Mcnally) (<3at317$qus@nermal.cs.uoguelph.ca>): +--------------- | I think that records would be one of those instances where the types | do not usually (should not ? ) change. In fact, the fact that | there is no static typing in records makes icon a dubious choice in | database applications. Any comments? +------------->8 (1) I have some cases where I need to store variably-typed data in a single column of a relational database table. I used a string and another table table containing regexps defining the types... UGH! (2) DON'T tell the above to the OO folks. I'm pretty sure OO keeps the type with each object, like Icon does. ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH ~\U Controlling application developers is like herding cats. --Oracle DBA Manual From icon-group-sender Thu Nov 24 02:35:53 1994 Received: by cheltenham.cs.arizona.edu; Wed, 23 Nov 1994 20:12:59 MST To: icon-group-l@cs.arizona.edu Date: Thu, 24 Nov 1994 02:35:53 GMT From: dsh@netcom.com (David S. Harrison) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu Subject: proc() in Icon 9.0 on SGI Errors-To: icon-group-errors@cs.arizona.edu I was recently trying to use ibpag2 using Icon 9.0 on an SGI machine. It seems ibpag2 uses proc() to call the actions associated with rules. However, under 9.0 on an SGI, proc() fails to find procedures. Below is an example: procedure user_func(a) return a-7 end procedure main() if p := proc("user_func") then { write("found it") t := p(7) write("result value: ", t) } else { write("didn't find it") } end This program always produces "didn't find it". I note that if the function is built in, proc finds it (i.e., repl, or match, etc.). Perhaps the semantics of proc() have changed since ibpag2 was written. Has proc() changed since 8.10 or is this a bug in 9.0? David Harrison (dsh@netcom.com) From icon-group-sender Fri Nov 25 14:30:51 1994 Received: by cheltenham.cs.arizona.edu; Fri, 25 Nov 1994 07:41:24 MST Original-Via: Pp-Warning: Illegal Via field on preceding line From: ROBERT VAN DER ZWAN To: icon-group@cs.arizona.edu Date: Fri, 25 Nov 1994 14:30:51 GMT Subject: textual analysis/tilt project glasgow uni. Priority: normal X-Mailer: PMail v3.0 (R1) Message-Id: <49B16401C94@dish.gla.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu My name is Robert van der Zwan. I am working for the TILT-c (Teaching with Independent Learning technologies) Project at Glasgow University. Within this framework I am working at the development of a CAL application for undergraduate history students, which will focus on textual analysis. We will use texts on political philosophy from the 17th and 18th century. Currently I am evaluating software for textual analysis. (You will find the checklist I use, attached to this file). This software will probably be combined with authoring software to develop the CAL application. From a front-end (developed with the authoring software, possibly Toolbook) students will have access to the texts, background information and the analysis tool (possibly TACT version 2.1). At the moment we are seriously considering the use of Tact in combination with Toolbook, but there are other options as well. One of them is using a programming language. Therefore I am interested to know: - whether ICON can meet the requirements for the text analysis tool stated in the attached checklist. - whether ICON can be combined with authoring software (like Toolbook f.e.) - is ICON available for the PC platform (since our institute is PC based.) - whether you could give a rough indication of how much time would be involved to develop an analysis tool (as described in the attached file) using ICON, for a non experienced programmer. - whether you have any information on similar projects. I would be very grateful if you could answer my query. If you need more information about the project do not hesitate to contact me. Yours sincerely, Drs. Robert M. van der Zwan Tilt-c project, Department of Modern History Glasgow University 1 University Gardens Glasgow G12 9DB fax: (0)41-330-5518 tel: (0)41-339-8855 (ext.2136) e-mail: rzwan@dish.gla.ac.uk =========================================== Drs. Robert van der Zwan RA TILT-C project (textual information) Department of Modern History University of Glasgow 1 University Gardens Glasgow G12 8QQ =========================================== From icon-group-sender Fri Nov 25 14:30:48 1994 Received: by cheltenham.cs.arizona.edu; Fri, 25 Nov 1994 07:42:26 MST Original-Via: Pp-Warning: Illegal Via field on preceding line From: ROBERT VAN DER ZWAN To: icon-group@cs.arizona.edu Date: Fri, 25 Nov 1994 14:30:48 GMT Subject: textual analysis/tilt project glasgow uni. Priority: normal X-Mailer: PMail v3.0 (R1) Message-Id: <49B163D1DE4@dish.gla.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Tilt C History Checklist textual analysis 9/11/94 1. Textual database preparation/running * a. allowing import of extended-character set ASCII text (including main European languages) Importing should be easy to handle. * b. recognition of simple mark up (for stucture of a text (chapters, pages etc.) and for elements of content. Mark up of structure of a text is essential for possibility of performing searches in parts of the text. - Mark up preferably SGML because of possibilities of interchange. - Also of importance: possibilities of (semi)-automatic markup. - It should be possible to hide the mark-up. 2. Vocabulary overview (providing rough pointers to the nature and content of a text). * a. Type-token ratio * b. Complete word list with frequency count, displayable both in alphabetic order and in order of frequency, for all or a predetermined part of the text. Also selected wordlist (as opposed to complete) c. token-character ratio (which should give rough average of lenghts of words) 3. Content retrieval facilities. NB. As much as possible of a-e should be done in conjunction and should be subject to 'filtering' (treating only limited parts of the text) * a. word searches including use of wild cards and Boolean operators. * b. combined search for user-defined clusters of semantically unrelated but near synonymous words (noble, aristocr*) * c. search for word pairs (f.e. social contract) and proximate associates (mandatories of the people), rights of man/woman) * d. search for roots and lemma's (f.e.: oligarchy, monarchy, noble for ennoblement, nobility. - this could be done by the use of wildcards, but preferable by way of parsing.? * e. collocation (including a user defined span) producing a z- score, which indicates the measure of probability that words are used together on purpose. f. macine generated search strategy via thesaurus (preferably user-trainable thesaurus, to accomodate variable historical usage), were potential related words are offered from thesaurus for confirmation or rejection by searcher. 4. Additional quantitative/stylistic facilities (extending basics of 2 above and currently achievable only through combination of various software) * a. enhancement of word frequency list (2/b.) by means of statistical options to calculate how much unique words, twice occurring words, and so on up to high frequency words contribute both to the total vocabulary and to the total word length (?) (useful to assess the audience for which an author may conciously or unconsciously have wanted to address and to refine the potentially misleading type-token ratio. * b. graphical display of frequencies of unique words and so on. c. direct quantification of word - and sentence length (see 2c above) (paragraph length is not meaningful for most historical texts and therefore not necessary). d. quantification of use of question marks, passive voice etc. e. simple parsing to assist with 3 d-f. (allowing to exclude f.e. all function words or search for nouns only etc.) 5 Display functions: * a. keyword(s) displayed in full text (highlit), and in concordance form (index, user-definable KWIC), giving location- reference by line or marked-up section (chapter, page etc.) or both. * b. 'topographical' distribution display, showing clustering of keyword(s) over the entire text or user-specified sections of that text. c. free movement between displays without the need for new retrieval. 6 User facilities: * a. simple interface for 'naive' users: - all functions available by menu and or icon - preferably Windows compatible - step by step guidance through procedures - no use of difficult terms, or good help function available. * b. easy output of results (to printer, wordproccessor, database package or spreadsheet), preferably by using cut and paste option in Windows. * c. reasonable speed of performance for complex retrievals (f.e. collocations) and large bodies of text (2-5 Mb) From icon-group-sender Mon Nov 28 12:57:56 1994 Received: by cheltenham.cs.arizona.edu; Mon, 28 Nov 1994 06:12:46 MST To: icon-group-l@cs.arizona.edu Date: Mon, 28 Nov 1994 12:57:56 GMT From: e2-vonbo@csd.uwe.ac.uk (E Vonbodecker) Message-Id: <1994Nov28.125756.12142@pat.uwe.ac.uk> Organization: The University of West of England, Bristol Sender: icon-group-request@cs.arizona.edu References: Reply-To: e2-vonbo@csd.uwe.ac.uk Subject: Re: proc() in Icon 9.0 on SGI Errors-To: icon-group-errors@cs.arizona.edu From icon-group-sender Tue Nov 29 03:59:39 1994 Received: by cheltenham.cs.arizona.edu; Mon, 28 Nov 1994 21:12:43 MST To: icon-group-l@cs.arizona.edu Date: 29 Nov 1994 03:59:39 GMT From: brady@cybernetics.net (Don Brady) Message-Id: <3be8vb$g10@jabba.cybernetics.net> Organization: Cybernetx, Inc. Sender: icon-group-request@cs.arizona.edu Subject: ICON speed? Errors-To: icon-group-errors@cs.arizona.edu How would the speed of ICON compare to that of Catspaw Spitbol/386, which I am using now? I do some lengthy runs and would not want to switch if it were say 5 or 6 times slower. Thanks for any info, Don From icon-group-sender Mon Nov 28 10:27:00 1994 Received: by cheltenham.cs.arizona.edu; Tue, 29 Nov 1994 14:15:31 MST To: icon-group-l@cs.arizona.edu Date: Mon, 28 Nov 94 10:27:00 -0800 From: contest@datanet.com (Contest) Message-Id: <25.30.3077@datanet.com> Organization: DNIS * Palm Springs, CA * Via Modem Call: (619) 864-1468 Sender: icon-group-request@cs.arizona.edu Subject: :SKILL CONTEST - WIN $750,000 CONDO! Errors-To: icon-group-errors@cs.arizona.edu ******** WIN ********* LUXURY 4BR PENTHOUSE MARINA DEL REY, CA. USA VALUED AT $725,000 Steps to beach-near LAX Located within exclusive Los Angeles, CA. Marina Peninsula. area Home to movie, TV, and sports celebrities. 3350 sq. ft. + 1200' private sun deck, 3 fireplaces, 4 and 1/2 baths library/den, bar and game room. Winner is determined by simple contest of skill. Limited to 4000 entries. $250 entrance fee. For application & details send Internet EMail to CONTEST@DATANET.COM DNIS - Palm Springs, California * Via Modem Call: (619) 864-1468 A Winner Of The 1993 John C. Dvorak Telecommunications Award!! From icon-group-sender Thu Dec 1 08:06:25 1994 Received: by cheltenham.cs.arizona.edu; Thu, 1 Dec 1994 07:07:28 MST From: "Art Eschenlauer" Message-Id: <9412011406.AA17839@molbio.cbs.umn.edu> Subject: :SKILL CONTEST - WIN $750,000 CONDO! - GAMBLING??? To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Thu, 1 Dec 1994 08:06:25 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1518 Errors-To: icon-group-errors@cs.arizona.edu With a $250 entrance fee, does this not constitute gambling?????? 4000 entries at $250 per is $1 million, so that's a PROFIT of $275000 for the contest runners (presuming they get 4000 entries). How legal is this, anyway? Forwarded message: > From icon-group-sender@cs.arizona.edu Tue Nov 29 15:18:26 1994 > To: icon-group-l@cs.arizona.edu > Date: Mon, 28 Nov 94 10:27:00 -0800 > From: contest@datanet.com (Contest) > Message-Id: <25.30.3077@datanet.com> > Organization: DNIS * Palm Springs, CA * Via Modem Call: (619) 864-1468 > Sender: icon-group-request@cs.arizona.edu > Subject: :SKILL CONTEST - WIN $750,000 CONDO! > Errors-To: icon-group-errors@cs.arizona.edu > > > ******** WIN ********* > LUXURY 4BR PENTHOUSE > MARINA DEL REY, CA. USA > VALUED AT $725,000 > > Steps to beach-near LAX Located within exclusive Los Angeles, CA. > Marina Peninsula. area Home to movie, TV, and sports celebrities. > 3350 sq. ft. + 1200' private sun deck, 3 fireplaces, > 4 and 1/2 baths library/den, bar and game room. > Winner is determined by simple contest of skill. > Limited to 4000 entries. $250 entrance fee. > > For application & details send Internet EMail to CONTEST@DATANET.COM > > > DNIS - Palm Springs, California * Via Modem Call: (619) 864-1468 > A Winner Of The 1993 John C. Dvorak Telecommunications Award!! > > From icon-group-request Thu Dec 1 16:13:52 1994 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 1 Dec 1994 13:13:00 MST Received: from agate.Berkeley.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA09230; Thu, 1 Dec 1994 13:12:55 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id LAA05322; Thu, 1 Dec 1994 11:46:15 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: 1 Dec 1994 16:13:52 GMT From: haakee@dcc308.its.rpi.edu (Erik Haakenson) Message-Id: <3bkso1$ke2@usenet.rpi.edu> Organization: Rensselaer Polytorture Institute, Troy, NY. Sender: icon-group-request@cs.arizona.edu Reply-To: haakee@rpi.edu Subject: SNOBOL information I am writing a term paper on SNOBOL and would be very pleased if anyone out there could supply me with some historical information on the SNOBOL programming language. You can mail me at haakee@rpi.edu Thanks in advance, Erik From icon-group-request Thu Dec 1 19:49:25 1994 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 1 Dec 1994 13:13:29 MST Received: from agate.Berkeley.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA09308; Thu, 1 Dec 1994 13:13:26 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id MAA06278; Thu, 1 Dec 1994 12:07:39 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: 1 Dec 1994 19:49:25 GMT From: corre@alpha1.csd.uwm.edu (Alan D Corre) Message-Id: <3bl9c5$7j5@uwm.edu> Organization: University of Wisconsin - Milwaukee, Computing Services Division Sender: icon-group-request@cs.arizona.edu References: <3bkso1$ke2@usenet.rpi.edu> Subject: Re: SNOBOL information In article <3bkso1$ke2@usenet.rpi.edu> haakee@rpi.edu writes: > I am writing a term paper on SNOBOL and would be very pleased if anyone >out there could supply me with some historical information on the SNOBOL >programming language. You can mail me at haakee@rpi.edu > > Thanks in advance, > Erik I should like to suggest, in all seriousness, that you first put yourself through the monotorture of going to your college library and browsing among the books that deal with the history of programming languages. I'm prepared to bet that you will find lots of eye-opening, interesting and amusing information concerning what you are looking for. Armed with the basic information you have dug up (which will probably stay with you because you dug it) you can then ask some specific questions which may get authoritative replies, because there are people reading this group who know it all by heart. (I'm not one of them. I'm just an admirer of that green book which first piqued my interest in all of this.) You are asking what in Hebrew terminology is called a "sheelat tam" (the question of a simpleton). Why not spend a little time and ask a "sheelat hakham" (the question of a smart person)? -- Alan D. Corre Emeritus Professor of Hebrew Studies University of Wisconsin-Milwaukee From icon-group-sender Fri Dec 2 01:56:49 1994 Received: by cheltenham.cs.arizona.edu; Thu, 1 Dec 1994 23:17:21 MST To: icon-group-l@cs.arizona.edu Date: 2 Dec 1994 01:56:49 GMT From: pmcnally@uoguelph.ca (Paul Mcnally) Message-Id: <3blut1$ng2@nermal.cs.uoguelph.ca> Organization: University of Guelph Sender: icon-group-request@cs.arizona.edu References: <3bkso1$ke2@usenet.rpi.edu>, <3bl9c5$7j5@uwm.edu> Subject: Re: SNOBOL information Errors-To: icon-group-errors@cs.arizona.edu Alan D Corre (corre@alpha1.csd.uwm.edu) wrote: : In article <3bkso1$ke2@usenet.rpi.edu> haakee@rpi.edu writes: : > I am writing a term paper on SNOBOL and would be very pleased if anyone : >out there could supply me with some historical information on the SNOBOL : >programming language. You can mail me at haakee@rpi.edu : > : > Thanks in advance, : > Erik : I should like to suggest, in all seriousness, that you first put yourself : through the monotorture of going to your college library and browsing among : the books that deal with the history of programming languages. I'm prepared : to bet that you will find lots of eye-opening, interesting and amusing : information concerning what you are looking for. Armed with the basic : information you have dug up (which will probably stay with you because you : dug it) you can then ask some specific questions which may get authoritative : replies, because there are people reading this group who know it all by : heart. (I'm not one of them. I'm just an admirer of that green book which : first piqued my interest in all of this.) : You are asking what in Hebrew terminology is called a "sheelat tam" (the : question of a simpleton). Why not spend a little time and ask a "sheelat : hakham" (the question of a smart person)? : -- : Alan D. Corre : Emeritus Professor of Hebrew Studies : University of Wisconsin-Milwaukee I was able to find _plenty_ of information on Icon. While looking for this information I came across information on SNOBOL - it's out there, you just have to put in the time to find it. Check the ACM SIGPLAN notices, Software Practice and Experience, IEEE Transactions on Software Engineering, or an index on computer periodicals. Yes, they should be at a library near you. Best of Luck Paul -- \\\\\// | | (.)^(.) ==========================oOO==(_)==OOo============================ Paul McNally Computer Support Computing & Communications Services University of Guelph Ontario, Canada =================================================================== From nevin@caslon Mon Dec 5 05:58:11 1994 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 5 Dec 1994 05:58:16 MST Received: from caslon.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA28193; Mon, 5 Dec 1994 05:58:15 MST Received: (nevin@localhost) by caslon.CS.Arizona.EDU (8.6.7/8.6.4) id FAA00432 for icon-group@cs.arizona.edu; Mon, 5 Dec 1994 05:58:13 -0700 From: Nevin Liber Message-Id: <199412051258.FAA00432@caslon.CS.Arizona.EDU> Subject: Icon debugging tip To: icon-group@cs.arizona.edu (Icon Group) Date: Mon, 5 Dec 1994 05:58:11 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2193 Since I'm currently working on a fairly large project, I thought I'd share one of the debugging tips that I'm using. I need to be able to control on a procedure by procedure basis which procedures should output debugging information, and which ones shouldn't. Additionally, I want to be able to easily turn off all the embedded debugging code when I am done. First, I have a global variable gTfDebug, which is a table of files. Next, given a procedure Peachfuzz(x1, x2) where I wish to write a line of debugging output every time it is invoked, I would add the following line of code to Peachfuzz: write(\gTfDebug[Peachfuzz], repl(" ", &level), "Peachfuzz(", image(x1), ", ", image(x2), ")") [Note: the reason that I have the repl(" ", &level) is to visually show how many levels deep the procedure call is. This has the added benefit of lining up debugging output for the same instance of a call; ie, I might want to print out the suspended or returned values. I use image() to make sure that the debugging code never has a run time error, even if the parameters aren't exactly what was expected.] Now, I would put the following as my first statement in main(): 1) I want all procedures to write their debugging output to &errout: gTfDebug := table(&errout) 2) I want no debugging output: gTfDebug := table() 3) I want only Rocky() and Bullwinkle() to produce debugging output: gTfDebug := table() every gTfDebug[Rocky | Bullwinkle] := &errout 4) I want everything except Boris() and Natasha() to produce debugging output: gTfDebug := table(&errout) every gTfDebug[Boris | Natasha] := &null Etc., etc. Hopefully, someone else will find this helpful! -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ^^^ (520) after 3/95 ___ _ ____ _ ___ / \__/ \__/ \__/ \__/ \ "Hey Rocky! | _|@ @ __ | Watch me pull some intelligence \________/ | | \________/ out of the internet!" __/ _/ "But that trick never works." /) (o _/ "This time for sure." \____/ From cary@hpclpax.cup.hp.com Mon Dec 5 10:46:49 1994 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 5 Dec 1994 11:44:11 MST Received: from hp.com by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA20030; Mon, 5 Dec 1994 11:44:10 MST Received: from hpclpax.cup.hp.com by hp.com with SMTP (1.37.109.14/15.5+ECS 3.3) id AA062303044; Mon, 5 Dec 1994 10:44:04 -0800 Received: from localhost by hpclpax.cup.hp.com with SMTP (1.37.109.4/15.5+IOS 3.20+cup+OMrelay) id AA06669; Mon, 5 Dec 94 10:46:50 -0800 Message-Id: <9412051846.AA06669@hpclpax.cup.hp.com> To: icon-group@cs.arizona.edu Subject: Re: SNOBOL information Date: Mon, 05 Dec 1994 10:46:49 -0800 From: Cary Coutant Perhaps someone has already pointed this out privately, but don't overlook Ralph's excellent paper in the proceedings of the first History of Programming Languages Conference (HOPL-I, ca. 1979?). -cary From nevin@caslon Mon Dec 5 16:01:34 1994 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 5 Dec 1994 16:01:39 MST Received: from caslon.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA08948; Mon, 5 Dec 1994 16:01:38 MST Received: (nevin@localhost) by caslon.CS.Arizona.EDU (8.6.7/8.6.4) id QAA18516 for icon-group@cs.arizona.edu; Mon, 5 Dec 1994 16:01:36 -0700 From: Nevin Liber Message-Id: <199412052301.QAA18516@caslon.CS.Arizona.EDU> Subject: Re: Icon debugging tip To: icon-group@cs.arizona.edu (Icon Group) Date: Mon, 5 Dec 1994 16:01:34 -0700 (MST) In-Reply-To: <199412051258.FAA00432@caslon.CS.Arizona.EDU> from "Nevin Liber" at Dec 5, 94 05:58:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 581 Nevin Liber (nevin@cs.arizona.edu) writes: > write(\gTfDebug[Peachfuzz], repl(" ", &level), > "Peachfuzz(", image(x1), ", ", image(x2), ")") I forgot to mention that the reason I index the table gTfDebug with Peachfuzz instead of "Peachfuzz" (the procedure instead of a string of the name of the procedure) is because I always run icont with the -u option, and I will get a warning if the procedure does not exist (because I misspelled it, for instance). -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ^^^ (520) after 3/95 From icon-group-sender Mon Dec 5 18:11:15 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Dec 1994 16:11:22 MST Date: Mon, 5 Dec 94 18:11:15 -0500 From: Menasse ZAUDOU Message-Id: <9412052311.AA23732@binkley.cs.mcgill.ca> To: icon-group@cs.arizona.edu Subject: please unsubscribe Errors-To: icon-group-errors@cs.arizona.edu please unsubscribe me from this list: tegest@cs.mcgill.ca thanks From icon-group-sender Mon Dec 5 19:35:01 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Dec 1994 20:14:32 MST To: icon-group-l@cs.arizona.edu Date: 5 Dec 1994 19:35:01 -0500 From: Bobr@voyager.cris.com (BobR) Message-Id: <3c0bjl$ndf@voyager.cris.com> Organization: Concentric Research Corporation Sender: icon-group-request@cs.arizona.edu Subject: Help - Install Prob. Errors-To: icon-group-errors@cs.arizona.edu I'm trying to install Icon v8.10 on my Linux system but hit a problem. I'm on _Step 4: Configure Icon for your platform_ and after entering _make Configure name=I386_linux_ I received the following error; ed- ../../../bin/icon_vt < ../Config/dequote.ed ed: No such file or directory make[3]: ***[vt] error 2 make[3]: leaving dir '/root/icon/config/unix/i386_linux' make[2]: ***[setup] Error 1 make[2]: leaving dir '/root/icon/config/unix/i386_linux' make[1]: ***[all] Error 1 make[1]: leaving dir '/root/icon/config/unix/i386_linux' make: ***[Configure] Error 1 I suspect that an error occurred with the ed command, but I don't possess the knowledge to correct the error. Any help that anyone cares to give me will be much appreciated. Thanks in advance Bob Randall From icon-group-sender Tue Dec 6 03:28:44 1994 Received: by cheltenham.cs.arizona.edu; Mon, 5 Dec 1994 22:13:51 MST To: icon-group-l@cs.arizona.edu Date: Tue, 6 Dec 1994 03:28:44 GMT From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-Id: <1994Dec6.032844.26406@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Sender: icon-group-request@cs.arizona.edu References: <3c0bjl$ndf@voyager.cris.com> Subject: Re: Help - Install Prob. Errors-To: icon-group-errors@cs.arizona.edu Also sprach Bobr@voyager.cris.com (BobR) (<3c0bjl$ndf@voyager.cris.com>): +--------------- | ed- ../../../bin/icon_vt < ../Config/dequote.ed | ed: No such file or directory +------------->8 Install the "ed" package (it's optional in Slackware, at least). If it dumps core (make prints something like Error 139) get the latest version of ed from prep.ai.mit.edu; the Slackware version of ed has had a bug for some time. ++Brandon -- Brandon S. Allbery KF8NH [44.70.248.67] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH ~\U Controlling application developers is like herding cats. --Oracle DBA Manual From icon-group-sender Mon Dec 5 13:26:16 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Dec 1994 02:04:11 MST To: icon-group@cs.arizona.edu Subject: Re: SNOBOL information Message-Id: <786633976@mse> Date: Mon, 05 Dec 94 13:26:16 UTC From: whm@mse.com (William H. Mitchell) Errors-To: icon-group-errors@cs.arizona.edu A perhaps off the track historical tidbit re SNOBOL4: Dave Hanson retargeted Ratfor to work with SNOBOL4 rather than FORTRAN. He called it Ratsno. I've never met anyone else who used it for serious work, but it was my primary language for the last two years of my undergraduate course-work. I believe there was a Software Practice and Experience paper by Hanson on Ratsno c. 1978 or so. The paper focused more on the transformation of Ratfor -- he did it in an afternoon. From icon-group-sender Tue Dec 6 19:16:27 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Dec 1994 15:14:12 MST To: icon-group-l@cs.arizona.edu Date: Tue, 6 Dec 1994 19:16:27 GMT From: gilbert@marin.cc.ca.us (Tim Gilbert) Message-Id: Organization: College of Marin, Kentfield, CA 94904 Sender: icon-group-request@cs.arizona.edu Subject: Status of Icon on the Mac? Errors-To: icon-group-errors@cs.arizona.edu Hi. Does anyone know what the status of icon on the Mac is? At this point I am using the (newly free) version of ProIcon, but I wonder if version 9.x will ever be ported. I don't care so much about the graphics stuff as about the preproccessor... I wanted to use ibpag2, but couldn't due to all the $defines. I gave a try at writing the preprocessor myself in Icon 8, but couldn't quite get it. On a related note, will the source code to ProIcon be publicly released ant time in the forseeable future? I'd be willing to make a stab at hacking up version 9... Oh yeah, also I don't have MPW, so that's no help. Any information appreciated... -- Tim -- Tim Gilbert <> gilbert@marin.cc.ca.us <> College of Marin, S.F. Bay Area From icon-group-sender Tue Dec 6 15:43:13 1994 Received: by cheltenham.cs.arizona.edu; Tue, 6 Dec 1994 15:43:16 MST Date: Tue, 6 Dec 1994 15:43:13 MST From: "Ralph Griswold" Message-Id: <199412062243.AA15102@cheltenham.cs.arizona.edu> To: gilbert@marin.cc.ca.us Subject: Re: Status of Icon on the Mac? Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu Version 9.x is being ported by a student of Clint Jeffery. No scheduled release date. You may have trouble getting enough memory for ibpag2, however. I worked for a while with someone using it under MPW Icon and he ran out of memory at something like 20MB. ProIcon source will not be released. It contains proprietary components belonging to commercial companies. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 602-621-6609 (voice) Tucson, AZ 85721 602-621-4246 (fax)