From icon-group-sender Sun Apr 18 05:45:33 1993 Received: by cheltenham.cs.arizona.edu; Mon, 19 Apr 1993 05:11:21 MST Date: Sun, 18 Apr 1993 05:45:33 MST From: "Clint Jeffery" Message-Id: <199304181245.AA21479@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu In-Reply-To: (Pat's message of 16 Apr 93 19:30:24 GMT <1qn1gg$hng@access.digex.net> Subject: Is there a run time Debugger in developement? Status: R Errors-To: icon-group-errors@cs.arizona.edu is anyone plowing along at writing a run-time debugger? ... It would be nice to be able to single step the code and examine values or see them changing as teh code runs. My Ph.D. research has produced an environment that makes it easy to do this sort of stuff; its not just a debugger but rather a monitoring system that is easy to extend and customize (by writing Icon procedures of course). It would be a great deal of work to put together a package for public consumption. It can only be done if there is sufficient demand; Icon Project has limited resources. I'd be interested in hearing how many people are really interested in a debugger. Clint Jeffery -- cjeffery@cs.arizona.edu From icon-group-sender Fri Apr 16 20:46:38 1993 Received: by cheltenham.cs.arizona.edu; Mon, 19 Apr 1993 05:11:36 MST Date: 16 Apr 93 20:46:38 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Nathan Wharton) Subject: Unix Pipes and Amiga Icon Message-Id: <9304162046.AA20451@uahcs2.cs.uah.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have a question about reading from pipes within icon on unix, and a question about how to set up the IPATH variable on an Amiga 3000 running 2.1. First, the pipe question. I made a named pipe using the unix 'mknod' command with the p option. Is there a way in icon that you can call some procedure to see if there is a data ready on the pipe? What would be nice is a procedure that would return the line read in from the pipe, or else fail if no info is in the pipe. The read function just waits until a line is there. Second, on the Amiga, I can not get icont to link in ucode from other directories. Here is an example of the problem: 9> echo $IPATH ICON:ucode 9> cd $IPATH 9> ls options* options.u1 options.u2 9> cd icon:progs 9> icont zipsort.icn Translating: zipsort.icn: main (1174/15000) No errors Linking: icont: cannot resolve reference to file 'options.u1' Thanks in advance. -- Nathan Wharton nwharton@cs.uah.edu Work: (205)922-6000 From icon-group-sender Mon Apr 19 10:01:36 1993 Received: by cheltenham.cs.arizona.edu; Mon, 19 Apr 1993 05:12:16 MST Message-Id: <9304190901.AA04075@ruls41.LeidenUniv.nl> To: icon-group@cs.arizona.edu Cc: ruiter@ruls41.LeidenUniv.nl Subject: runtime debugger Date: Mon, 19 Apr 93 10:01:36 +0100 From: ruiter@ruls41.LeidenUniv.nl X-Mts: smtp Status: R Errors-To: icon-group-errors@cs.arizona.edu One of the great strengths of Icon, and one of the reasons I still don't understand why Icon isn't a *very* popular language, is that it is implemented and supported so well. (what about PR? Are there any Arizona Marketing Students that could help?) A run-time debugger, with a functionality like dbx (text-mode) would indeed, as Pat writes, be *very* helpful. IMHO it is just the thing that needs to be added to the Icon system to make it an irresistable deal for courses in computer languages. ---------------------------------------------------- Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Tue Apr 20 21:22:55 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 21 Apr 1993 18:47:36 MST Received: by owl.cs.arizona.edu; Wed, 21 Apr 1993 18:47:35 MST Date: 20 Apr 93 21:22:55 GMT From: enterpoop.mit.edu!spool.mu.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@ucbvax.Berkeley.EDU (Alan D Corre) Organization: Computing Services Division, University of Wisconsin - Milwaukee Subject: Re: runtime debugger Message-Id: <1r1pjfINN3ql@uwm.edu> References: <9304190901.AA04075@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9304190901.AA04075@ruls41.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl writes: >I still don't understand why Icon isn't a *very* popular >language, >---------------------------------------------------- >Jan de Ruiter >Leiden University >Dept. of Information Science for the Social Sciences >The Netherlands >ruiter@ruls41.leidenuniv.nl It seems to me that the reason why Icon isn't a *very* popular language is that most of the implementations are non-commercial, so it has not been advertised as much as others. If this is true, it is ironic that the fact that it is free makes it less, rather than more, popular. -- Alan D. Corre Department of Hebrew Studies University of Wisconsin-Milwaukee (414) 229-4245 PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.edu From icon-group-sender Fri Apr 2 07:56:52 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 21 Apr 1993 18:47:50 MST Received: by owl.cs.arizona.edu; Wed, 21 Apr 1993 18:47:48 MST Date: 2 Apr 93 07:56:52 GMT From: ftpbox!mothost!binford!mcdchg!tellab5!ruth.wheaton.edu!gmribeir@uunet.uu.net (Glauber) Organization: The Bossa Nova University Subject: Is this passable code? Message-Id: <1993Apr2.075652.11967@wheaton.wheaton.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu My apologies if this is repeated, but this is the 3rd time that i'm trying to post this. News sometimes behaves weird here. I started using Icon recently, and am impressed with the power of the language. But, since i'm learning on my own and don't have experience with Icon, i don't know if i'm doing things right. Recently i wrote a short program to find anagrams (yeah...) using the unix dictionary. I'd appreciate any comments/suggestions/flames, etc about my programming style and the Icon way. Thank you very much Glauber. ---------------------------------------------------------------------- # Find all the anagrams of a given word # In the Unix dictionary # Tue Mar 30 07:15:53 CST 1993 procedure main(argv) word := argv[1] if not ( in := open("/usr/dict/words") ) then stop("Can't open system dictionary! :-( ") #initialize l := map( read(in), &ucase, &lcase ) #main loop every ( w := lexperm( word ) ) do { while ( l << w ) do if not ( l := map( read(in), &ucase, &lcase ) ) then return # at this point, either (l == w) or (l >> w) if (l == w) then write(l) } end #I think this is it! # Lexicographical permutation, # Reingold, Combinatorial Algorithms, page 162 # (this is a generator) procedure lexperm( w ) # initialize w := sortword ( map(w, &ucase, &lcase) ) repeat { suspend (w) # now permute every i := (*w - 1) to 1 by (-1) do { if w[i] << w[i+1] then break } every j := *w to 1 by (-1) do { if w[i] << w[j] then break } w[i] :=: w[j] r := *w s := i + 1 while r >= s do { w[r] :=: w[s] r -:= 1 s +:= 1 } # end of permutation if (j = 1) & (i = 1) then fail } end # insertion sort for now... procedure sortword( w ) size := *w # external loop, traverses the word every j := 2 to size do { hold := w[j] # internal loop, "sinks" each letter in place i := j - 1 while i >= 1 do { if hold >>= w[i] then break w[i+1] := w[i] i -:= 1 } w[i+1] := hold } return w end ---------------------------------------------------------------------- -- Glauber Ribeiro glauber@david.wheaton.edu glauber%david.wheaton.edu@tellab5.tellabs.com constantly risking absurdity From icon-group-sender Wed Apr 21 14:02:33 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 22 Apr 1993 09:13:18 MST Received: by owl.cs.arizona.edu; Thu, 22 Apr 1993 09:13:18 MST Date: 21 Apr 93 14:02:33 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: runtime debugger Message-Id: <1r3k5p$9dp@access.digex.net> References: <9304190901.AA04075@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9304190901.AA04075@ruls41.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl writes: > >A run-time debugger, with a functionality like dbx (text-mode) Text Mode? I was thinking GUI based interface, myself. dbx is nice, but run under suntools, it's awesome. pat From icon-group-sender Wed Apr 21 22:11:28 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 22 Apr 1993 09:13:25 MST Received: by owl.cs.arizona.edu; Thu, 22 Apr 1993 09:13:25 MST Date: Wed, 21 Apr 1993 22:11:28 MST From: "Clint Jeffery" Message-Id: <199304220511.AA28454@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu In-Reply-To: (Alan D Corre's message of 20 Apr 93 21:22:55 GMT <1r1pjfINN3ql@uwm.edu> Subject: runtime debugger Status: R Errors-To: icon-group-errors@cs.arizona.edu Alan D. Corre writes on the question of why Icon isn't more popular: It seems to me that the reason why Icon isn't a *very* popular language is that most of the implementations are non-commercial, so it has not been advertised as much as others. If this is true, it is ironic that the fact that it is free makes it less, rather than more, popular. Sure, popular languages attract commercial implementations, but that doesn't prove anything. How did they get popular in the first place? BASIC and Pascal became very popular because they are used in introductory programming courses. BASIC was built-in (and "free") on many early microcomputers. C was developed in an industry lab but became popular because UNIX and C were made available at little or no cost to universities. People who used it in school often later asked for it in industry projects. So I think Icon is not more popular because it does not cater to introductory computer science education, because its implementations are not very fast, because it does not provide much access to system-specific features, and also because there are plenty of other languages out there that are already popular. From icon-group-sender Thu Apr 22 10:42:12 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 22 Apr 1993 09:13:30 MST Received: by owl.cs.arizona.edu; Thu, 22 Apr 1993 09:13:30 MST Message-Id: <9304220942.AA05692@ruls41.LeidenUniv.nl> To: icon-group@cs.arizona.edu Cc: ruiter@ruls41.LeidenUniv.nl Subject: popularity of Icon Date: Thu, 22 Apr 93 10:42:12 +0100 From: ruiter@ruls41.LeidenUniv.nl X-Mts: smtp Status: R Errors-To: icon-group-errors@cs.arizona.edu Alan D. Corre writes > > It seems to me that the reason why Icon isn't a *very* popular language is > that most of the implementations are non-commercial, so it has not been > advertised as much as others. If this is true, it is ironic that the fact > that it is free makes it less, rather than more, popular. > Yes, that may be very true. Perhaps one of the ways to make it more popular is to make it expensive, but nevertheless possible to obtain for free (like shareware).Then many people will get a kick out of obtaining Icon without the payment involved. But, seriously, I wonder what the Icon developers themselves think of this paradox: a well implemented, platform independent *free* language, a lot of happy users, and still not popular. I find it even hard to convince my colleagues of the usefulness of Icon. I have the distinct feeling that they imagine some nice-try experimental home-brewn not-quite-finished freak-language. It takes persuasive argueing to convince them that Icon is a serious language. In a way, Icon hangs between freeware and shareware, since one needs the book in order to learn/use Icon. *Really* free languages usually offer documentation included in electronic format. This makes people frown when I tell them to buy the book. Of course having to buy a book in order to use an otherwise completely free language is entirely reasonable, but not all programmers are. Hope you people have some comments; I did not intend to offend anyone, by the way. I just hope that Icon becomes more popular. Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Thu Apr 22 06:23:02 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 22 Apr 1993 09:13:35 MST Received: by owl.cs.arizona.edu; Thu, 22 Apr 1993 09:13:35 MST Date: 22 Apr 1993 06:23:02 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: runtime debugger To: icon-group@cs.arizona.edu Message-Id: <01GXAUZOLQ368WW2JD@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu > In article <9304190901.AA04075@ruls41.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl writes: > >I still don't understand why Icon isn't a *very* popular > >language, >---------------------------------------------------- > >Jan de Ruiter > >Leiden University > >Dept. of Information Science for the Social Sciences > >The Netherlands > >ruiter@ruls41.leidenuniv.nl > It seems to me that the reason why Icon isn't a *very* popular language is > that most of the implementations are non-commercial, so it has not been > advertised as much as others. If this is true, it is ironic that the fact > that it is free makes it less, rather than more, popular. > -- > Alan D. Corre > Department of Hebrew Studies > University of Wisconsin-Milwaukee (414) 229-4245 > PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.edu I think it may due to several additional factors too. First, it seems to me that the main computers languages taught (sanctioned) by education are C, COBOL, and BASIC. Others like LISP, ADA, and others are picked up in order to accomplish something else. ICON also has kind of a funny name. Sometimes the name of something is sufficient to market it. WordPerfect might have been a good name for a string language ;-), but I guess that's hindsight. Another is resistance to change. When I put it on our VAX the first question management asked is "so who knows this language?", "who's going to support this when you're sick or vacationing?". I mentioned that it's easy to learn, and the book and docs are on the shelf. But a crew of COBOLers on VAX and FOXPROs on PCs are self sufficient in their toolsets and not really interested in learning yet another language. Maybe I am too, since I haven't haven't played much with the COBOL, FORTRAN, FOCUS, INGRES, or SPSS which I have access too either. I can't much beyond printf("\nHello\n"); in C (but I download and build other peoples' C ware). Now that ICON is getting into X and OOP I think it has a chance to catch on more. Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia From icon-group-sender Fri Apr 23 11:36:35 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 23 Apr 1993 08:38:54 MST Received: by owl.cs.arizona.edu; Fri, 23 Apr 1993 08:38:51 MST Date: Fri, 23 Apr 93 11:36:35 +0200 From: karczma@univ-caen.fr (Jerzy Karczmarczuk) Message-Id: <9304230936.AA23022@univ-caen.fr> To: icon-group@cs.arizona.edu Subject: The popularity of Icon Never Ending Stooooory... Status: R Errors-To: icon-group-errors@cs.arizona.edu Dear Icon Masters, To resume, Icon has acquired less popularity that it deserves because: A. It is free, or even worse (as you should buy the book), it is cheap. So, the people do not appreciate. B. It is not being taught early enough. Not used in introductory programming courses. C. There are plenty of other languages that are already popular, and people are resistant to changes. Perhaps you wouldn't mind taking into account some other factors. 1. There are dozens of other languages *which are NOT popular* as well. Perhaps we shouldn't be so catholic? We are the elite and not the popular prophets, or are we? How many new religious sects, sorry, I wanted to say *programming languages* are born every day? YES, I know that we are the best, but... 2. In the computing science community the tendencies fluctuate, from time to time we want something really powerful and universal, as Algol68 (yes, no need to check my address, I am an European), or (pardonnez le gros mot) PL/I, but more often people like the simplicity. Look at the successes of LISP despite its syntactic austerity and quite primitive semantics. Why almost all physicists still use FORTRAN? You might be tempted by the obvious answer: the are forced to reuse the terabytes of existing library code, so the disease perpetuates itself. But this answer is incomplete, I assure you, I was a physicist myself before moving (evolving? degenerating?) into comp. sci.: they are reluctant to learn something too complex! While using FORTRAN you are not tempted by some new, elegant ways of coding your algorithms. You are so disgusted by the programming that you don't risk paying too much attention to it, and you feel well that you are still a physicist inside your heart. So, perhaps Icon is too nice and powerful? It is a drug to be avoided? 3. Something serious this time. I think that we need more APPLICATIONS. The Newsletter article about stems in Finnish language was very good. I transmitted immediately the information about it to our linguists, and I suggested that I could give a seminar about the possible uses of Icon in the domain of automatic language processing. But, somebody asked me about some other practical examples, and when I dumped on paper some elegant modules from the Icon library, the reaction was: "I wanted something PRACTICAL!" Funny, but there are people who do not consider a parser generator to be something practical. It seems that the number of existing tool building facilities is so large that there is a tendency to judge the quality of the language by the number of closed, finished and polished products. Not kross.icn, but theUltimateScrabblePlayer.icn. Jurek Karczmarczuk Lab. d'Informatique Universite de Caen Caen, Normandy, France. karczma@univ-caen.fr From icon-group-sender Fri Apr 23 12:55:14 1993 Received: by cheltenham.cs.arizona.edu; Fri, 23 Apr 1993 18:17:27 MST Date: Fri, 23 Apr 1993 12:55:14 MST From: "Cliff Hathaway" Message-Id: <199304231955.AA22488@javelina.cs.arizona.edu> To: icon-group Subject: Re: a list where Icon should be of interest and use Status: R Errors-To: icon-group-errors@cs.arizona.edu [ Forrest Richey sent this me. Posting to icon-group is a good way to spread the word, in case other Icon users are interested. cliff ] Cliff, though this is probably known to many/all Iconners, in case it's not in the forefront of consciousness, here's a reminder. Maybe especially for those wanting to point to PRACTICAL applications of Icon. Best, Forrest Richey > Date: Wed, 21 Apr 1993 12:28:57 -0500 > From: BITNET list server at TAMVM1 (1.7f) > Subject: Your subscription to list LINGUIST > To: Forrest Richey > Cc: ARISTAR@TAMUTS.TAMU.EDU, EDITORS@TAMSUN.TAMU.EDU, HDRY@EMUNIX.EMICH.EDU, > LINGUIST@TAMSUN.TAMU.EDU > X-Lsv-Listid: LINGUIST > > Dear networker, > > As of Wednesday, April the 21st of 1993, you have been added to the LISTSERV > distribution list LINGUIST (The LINGUIST Discussion List) by Anthony Aristar > . The introductory message for LINGUIST follows: > > Welcome to LINGUIST, an e-mail distribution list for the > academic discussion of language. LINGUIST is > international in orientation and has as one of its > primary aims the enhancement of communication > between professional linguists in different countries. > The success of such a list depends crucially on > subscriber participation. We encourage you to > join in the discussion yourself and to ask your > department to direct all linguistically relevant public > announcements (e.g., jobs, conferences, seminars) to > this list. > Your moderators and their addresses are: > > Anthony Aristar: Texas A&M University: > e311aa@tamuts.tamu.edu > Helen Dry: Eastern Michigan University: > hdry@emunix.emich.edu > > Our assistant editor is Brian Wallace: bwallace@emunix.emich.edu. > > Please use the personal addresses of the moderators > only for messages directed specifically at them, and > not for postings to the list. To join in the discussion, > direct your messages to: > linguist@tamvm1.tamu.edu (for Internet users) > linguist@tamvm1 (for Bitnet users) > > In addition, there is one other address you should know about > immediately. This address belongs to the Listserv software > which handles routine administrative matters for > LINGUIST. If you wish to request files, tell the list > not to send you mail for a while, or even sign off > LINGUIST, this is the address to use: > listserv@tamvm1.tamu.edu (for Internet users) > listserv@tamvm1 (for Bitnet users) > > You will be sent in due course a "How-To" text, which will > familiarize you with the mechanics of interaction with > lists and the Listserv. > > The list is moderated and submissions are subject to > editorial discretion. But moderating is as light-handed > as we can make it, since we wish to encourage free and > open interchange. You are at liberty to pass on and > disseminate any LINGUIST message provided it is clearly > attributed to LINGUIST. But you may only publish LINGUIST > postings with the permission of both the list moderators > and the original author of the message. > > We hope you enjoy and benefit from your participation in > LINGUIST. If you have any problems or questions, please > feel free to contact either of us, or the assistant > editor. > > Sincerely, > > THE MODERATORS > (Anthony & Helen) From icon-group-sender Fri Apr 23 19:55:14 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:21:07 MST Date: 23 Apr 93 19:55:14 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Cliff Hathaway) Subject: Re: a list where Icon should be of interest and use Message-Id: <199304231955.AA22488@javelina.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu [ Forrest Richey sent this me. Posting to icon-group is a good way to spread the word, in case other Icon users are interested. cliff ] Cliff, though this is probably known to many/all Iconners, in case it's not in the forefront of consciousness, here's a reminder. Maybe especially for those wanting to point to PRACTICAL applications of Icon. Best, Forrest Richey > Date: Wed, 21 Apr 1993 12:28:57 -0500 > From: BITNET list server at TAMVM1 (1.7f) > Subject: Your subscription to list LINGUIST > To: Forrest Richey > Cc: ARISTAR@TAMUTS.TAMU.EDU, EDITORS@TAMSUN.TAMU.EDU, HDRY@EMUNIX.EMICH.EDU, > LINGUIST@TAMSUN.TAMU.EDU > X-Lsv-Listid: LINGUIST > > Dear networker, > > As of Wednesday, April the 21st of 1993, you have been added to the LISTSERV > distribution list LINGUIST (The LINGUIST Discussion List) by Anthony Aristar > . The introductory message for LINGUIST follows: > > Welcome to LINGUIST, an e-mail distribution list for the > academic discussion of language. LINGUIST is > international in orientation and has as one of its > primary aims the enhancement of communication > between professional linguists in different countries. > The success of such a list depends crucially on > subscriber participation. We encourage you to > join in the discussion yourself and to ask your > department to direct all linguistically relevant public > announcements (e.g., jobs, conferences, seminars) to > this list. > Your moderators and their addresses are: > > Anthony Aristar: Texas A&M University: > e311aa@tamuts.tamu.edu > Helen Dry: Eastern Michigan University: > hdry@emunix.emich.edu > > Our assistant editor is Brian Wallace: bwallace@emunix.emich.edu. > > Please use the personal addresses of the moderators > only for messages directed specifically at them, and > not for postings to the list. To join in the discussion, > direct your messages to: > linguist@tamvm1.tamu.edu (for Internet users) > linguist@tamvm1 (for Bitnet users) > > In addition, there is one other address you should know about > immediately. This address belongs to the Listserv software > which handles routine administrative matters for > LINGUIST. If you wish to request files, tell the list > not to send you mail for a while, or even sign off > LINGUIST, this is the address to use: > listserv@tamvm1.tamu.edu (for Internet users) > listserv@tamvm1 (for Bitnet users) > > You will be sent in due course a "How-To" text, which will > familiarize you with the mechanics of interaction with > lists and the Listserv. > > The list is moderated and submissions are subject to > editorial discretion. But moderating is as light-handed > as we can make it, since we wish to encourage free and > open interchange. You are at liberty to pass on and > disseminate any LINGUIST message provided it is clearly > attributed to LINGUIST. But you may only publish LINGUIST > postings with the permission of both the list moderators > and the original author of the message. > > We hope you enjoy and benefit from your participation in > LINGUIST. If you have any problems or questions, please > feel free to contact either of us, or the assistant > editor. > > Sincerely, > > THE MODERATORS > (Anthony & Helen) From icon-group-sender Fri Apr 23 21:04:06 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:21:16 MST Date: 23 Apr 93 21:04:06 GMT From: think.com!spdcc!iecc!compilers-sender@uunet.uu.net (David Gudeman) Organization: U of Arizona CS Dept, Tucson Subject: Representations of Dynamic Type Information Message-Id: <93-04-095@comp.compilers> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm preparing a document that is intended to be an encyclopedic summary of all of the different ways of encoding the type of a value in dynamically typed languages. In order to make this list as comprehensive as possible, I thought I'd post to some relevant groups on the net to see if anyone has a technique I'm not aware of. Instead of asking for techniques and having to go through all of the responses looking for new ones, I thought I'd list the ones I know about and hope that some implementers will be willing to go through my list looking for their own favorite technique, and let me know if it is missing. Also, many of these techniques are either folk-lore, or (probably re-)invented by me, so I would appreciate knowing if anyone can give me references that have some claim to originiality. I don't need to know about cdr-coding or other methods to represent data, I'm only interested in methods to encode dynamic type information. If you can help I prefer to get replies by mail. If you post a follow-up to this article, please notice that there are a lot of groups in the subject line, and some replies may not be relevant for some groups (I recommend comp.lang.misc for general discussions of representational schemes). Any and all help is greatly appreciated. The LIST: tagged-words (type information is in the machine word) tag fields (word is broken up into tag and data fields) tag field in high end (most-significant bits) of word use tag of all zeros for one type to avoid tagging cost negative ints get a tag of all ones, non-negative ints get a tag of all zeros use sign bit for one type use sign-bit = 0 for one type and optimize another type by giving it the tag of all ones in the high end and tagging by negation. tag field in low end of word use two-bit tags to represent word pointers to avoid shifting use the tag 00 for word pointers to save the cost of tagging use all zeros to optimize integer arithmetic optimize integer arithmetic by adding/subtracting tag after subtraction/addition tag field in both ends of word various combinations of tricks from the other two options partitioning by magnitude (type is encoded in the magnitude of the word used to represent it) simple range tests to identify types segments with statically determined types segments with dynamically determined types use BIBOP to identify types identify type in the segment itself first word of segment last word of segment object-pointers (untagged pointers refering to self-identifying blocks on the heap) combinations of this scheme with the tagged-word scheme descriptors (two-word data elements divided into a type word and a value word) encoding a qualifier in a descriptor encoding a cons cell in a descriptor -- David Gudeman gudeman@cs.arizona.edu -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. From icon-group-sender Fri Apr 23 15:00:30 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:21:48 MST Date: 23 Apr 93 15:00:30 GMT From: howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!uchinews!ellis!goer@gatech.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger Message-Id: <1993Apr23.150030.11124@midway.uchicago.edu> References: <199304220511.AA28454@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu "Clint Jeffery" writes: > >So I think Icon is not more popular because it does not cater to >introductory computer science education, because its implementations are >not very fast, because it does not provide much access to system-specific >features, and also because there are plenty of other languages out there >that are already popular. Implementation speed is certainly no worse than it is for Prolog, uncom- piled LISP, PERL, AWK, etc., and these languages are nothing to scoff at. System-specific features are not particularly prominent in three of these four languages. And Icon is more widely implemented than two, equally widely implemented as one, and second only to LISP in this respect. But of course if we restrict LISP to Common Lisp, then perhaps it's even on a par there as well. This is not said in disagreement with you Clint. In fact, I agree with your main reason why Icon is used by a small, devoted community: Icon does not cater to the introductory CS course regimen. Icon has, as its natural constituency, people interested in AI, NLP, text, translation, and general nonnumeric computing. Intro CS courses are not taught, in general, by this sort of person. Humanities people, when they decide to take the few non-CS programming courses that are available, generally must suffer with Pascal or something high-level special-purpose language that only works on this or that machine. When the millennium arrives, universities will recognize that all students doing any serious research should know something about programming. They will also recognize that humanities students need a separate track. Fin- ally, they will recognize that, in order to teach humanities programming, one needs a true humanist - not a "willing" CS instructor. I have been frustrated all of my computing life by the lack of good instruction avail- able for humanists. We generally have to be self-educated. The Icon Project members are, interestingly, more capable in nonnumeric matters than most CS researchers I've met. Which leads me to wonder: Why pretend any longer that Icon is standard CS fare? Its major user-accessible advances have largely been in interface design and in solving problems that require heuristic methods, rather than algorithmic ones. Icon really isn't (from a user's standpoint) a good, standard CS language, except for those interested in language design and theory. Icon is a *great* language, and I hope it won't go away. Makes life easier for a large range of problems. It's just that this range of problems lies more in my area, I think, than it does in the CS fold. Clint: Why not take advantage of Icon's uniqueness, and start showing up a Humanities computing conferences, interface design conventions, etc. :-) 1/2 ? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat Apr 24 14:27:49 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:14 MST Date: 24 Apr 93 14:27:49 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Lets Make Icon Popular. Lets hold a contest. Message-Id: <1993Apr24.142749.24979@midway.uchicago.edu> References: <1raf77$bti@access.digex.net> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1raf77$bti@access.digex.net> prb@access.digex.com (Pat) writes: > >Every year at Usenix, they hold the IOCCC that is the International >Obfuscated C coding Contest. The rules are simple. No more then >1 page of source code. Must do soemthing non-trivial. Winner >is the most amazing bit of code. > >what do you all think? Sounds like a neat idea. Of course, the reason the obfuscated C contest is such a hit is because it plays on a "feature" of C, namely sparse syn- tax and no seat belts. You can subscript past the end of an array, create pointers to pointers to nothing in particular. You can declare variables and assign a value to them whose storage has a shorter lifetime than the variable. You can do incredibly stupid and/or cryptic things in C. What's funny is when somebody makes something that *looks* incredibly stupid or cryptic actually work. In Icon, cryptic-ness would have to dwell more, I'd think, on unexpected or complex side-effects from coexpressions or generators. There is a fine line, at times, between "expressiveness" and "power" and "obfuscation." -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Apr 23 14:44:21 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:19 MST Date: 23 Apr 93 14:44:21 GMT From: howland.reston.ans.net!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!usenet.cis.ufl.edu!usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: popularity of Icon Message-Id: <12606@sun13.scri.fsu.edu> References: <9304220942.AA05692@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9304220942.AA05692@ruls41.LeidenUniv.nl> ruiter@ruls41.LeidenUniv.nl writes: >Alan D. Corre writes >> >> It seems to me that the reason why Icon isn't a *very* popular language is >> that most of the implementations are non-commercial, so it has not been >> advertised as much as others. If this is true, it is ironic that the fact >> that it is free makes it less, rather than more, popular. ... >Hope you people have some comments; I did not intend to offend anyone, >by the way. I just hope that Icon becomes more popular. Not me, man! If it becomes more popular, the following will happen: (a) A Standards Committee will be set up to write a set of standards which will satisfy no one, but will be accepted anyway. (2) The U.S. Government will demand that all manufacturers who want to respond to federal RFP's for computer equipment offer the new standard. (3) IBM will come out with its own version of Icon, which will be much bigger and use a lot more disk space (in every way). (4) This newsgroup will become saturated with meaningless messages from people who ask ridiculous questions and other people who flame them for doing so. (5) And last, but not at all least, the Icon people at U of Ariz. will say to hell with it and go off and do something else. And the cycle will start over :-) John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "You gotta know when to hold 'em/know when to fold 'em/ "know when to walk away/and know when to run..." From icon-group-sender Mon Apr 19 09:01:36 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:24 MST Date: 19 Apr 93 09:01:36 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: runtime debugger Message-Id: <9304190901.AA04075@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu One of the great strengths of Icon, and one of the reasons I still don't understand why Icon isn't a *very* popular language, is that it is implemented and supported so well. (what about PR? Are there any Arizona Marketing Students that could help?) A run-time debugger, with a functionality like dbx (text-mode) would indeed, as Pat writes, be *very* helpful. IMHO it is just the thing that needs to be added to the Icon system to make it an irresistable deal for courses in computer languages. ---------------------------------------------------- Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Sun Apr 18 12:45:33 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:32 MST Date: 18 Apr 93 12:45:33 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Clint Jeffery) Subject: Is there a run time Debugger in developement? Message-Id: <199304181245.AA21479@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu is anyone plowing along at writing a run-time debugger? ... It would be nice to be able to single step the code and examine values or see them changing as teh code runs. My Ph.D. research has produced an environment that makes it easy to do this sort of stuff; its not just a debugger but rather a monitoring system that is easy to extend and customize (by writing Icon procedures of course). It would be a great deal of work to put together a package for public consumption. It can only be done if there is sufficient demand; Icon Project has limited resources. I'd be interested in hearing how many people are really interested in a debugger. Clint Jeffery -- cjeffery@cs.arizona.edu From icon-group-sender Fri Apr 23 14:16:08 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:41 MST Date: 23 Apr 93 14:16:08 GMT From: howland.reston.ans.net!agate!linus!progress!neil@gatech.edu (Neil Galarneau) Organization: Progress Software Corp. Subject: Re: popularity of Icon Message-Id: <1993Apr23.141608.25747@progress.com> References: <9304220942.AA05692@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu ruiter@ruls41.LeidenUniv.nl writes: [stuff deleted...] >In a way, Icon hangs between freeware and shareware, since one needs the >book in order to learn/use Icon. *Really* free languages usually offer >documentation included in electronic format. This makes people frown >when I tell them to buy the book. Of course having to buy a book in order >to use an otherwise completely free language is entirely reasonable, but >not all programmers are. Actually, I think the presence of BOTH a user book and an implementation book can help convince people that the language is for real and not some quick hack. >Jan de Ruiter >ruiter@ruls41.leidenuniv.nl Neil neil@progress.com From icon-group-sender Tue Apr 20 11:40:17 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:51 MST Date: 20 Apr 93 11:40:17 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!eng.ufl.edu!usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@ucbvax.Berkeley.EDU (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: Is there a run time Debugger in developement? Message-Id: <12578@sun13.scri.fsu.edu> References: <199304181245.AA21479@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <199304181245.AA21479@chuckwalla.cs.arizona.edu> cjeffery@cs.arizona.edu (Clint Jeffery) writes: ... >It would be a great deal of work to put together a package for >public consumption. It can only be done if there is sufficient >demand; Icon Project has limited resources. I'd be interested >in hearing how many people are really interested in a debugger. > >Clint Jeffery -- cjeffery@cs.arizona.edu Me, for one. I tend to use both Icon and Perl for doing things, and having a good debugger definitely gives Perl an edge, even though it is in many ways a more difficult language to use. John Nall -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "You gotta know when to hold 'em/know when to fold 'em/ "know when to walk away/and know when to run..." From icon-group-sender Sun Apr 25 00:41:30 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:55 MST Date: 25 Apr 93 00:41:30 GMT From: agate!howland.reston.ans.net!usc!cs.utexas.edu!news.uta.edu!utafll.uta.edu!bruce@ucbvax.Berkeley.EDU (Bruce Samuelson) Organization: UTexas at Arlington, Linguistics Subject: Lack of robustness limits Icon's popularity Message-Id: References: <9304230936.AA23022@univ-caen.fr> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Another possible reason Icon is not more popular is lack of robustness in some circumstances. A friend who programs in C needed to write some software to index and compress several megabytes of text data for use in a commercial product. Each multimegabyte text is indexed and compressed once and placed on floppy disks. I suggested Icon as the ideal language. Although he had never used it before, he followed my suggestion. He was impressed by how effective it was at implementing his parsing and compression algorithms, but he was plagued by its unreliability. Compression runs would take several hours on his 486/33 with 8MB of memory running DOS 5.0. That wasn't a particular problem, since he ran it overnight. The real problem was that when he checked the results the next morning, he could never be sure whether the run would complete or crash. His and my best guess was that he was bumping up against some memory constraint. He did try adjusting the various parameters you can set when compiling Icon. I think string space was one he modified to be able to process larger texts. However, he was never able to find settings which would guarantee consistently reliable runs. He insisted the program was so fragile that even the presence or absence of a comment in the soure code could determine whether it would crash. I don't remember the Icon version number, other than that when I ftp-ed it a year or so ago it was the most current one for 32-bit Intel--8.something I think. It was interpreted, not compled. I told him that my experience with Icon on a Sun workstation running Unix had been more positive, and that I only encountered one serious bug for which there was a workaround. (With DOS, using an older version of Icon that was restricted to 640K, my experiences were even worse than my friend's, but that was to be exptected.) My positive Sun experience failed to console him. In the end, he did manage to get all the texts compressed, writing C modules in place of Icon ones when necessary. The company had considered turning their compression software into a commercial product. It started out being written for internal use only. My friend is a good programmer and documents his systems well. Unfortunately, his Icon programs are too fragile to sell commercially. Another problem, of course, is the niche nature of the language. Source code written in C would seem to offer more commercial potential. In a postmortem analysis, my friend said that if he could do it all over again, he would have simply used C. He does not have internet or usenet access. I tried to get him to find a benefactor at the local university who could give him an account, but he didn't pursue this vigorously. I told him that if he had posted his symptoms in detail to this newsgroup, and perhaps reported them to the Icon project, he might have gotten some practical help. It is not fair for me to complain about Icon's robustness to this group without giving sufficient documentation so that one of you could track down the problem and fix it. It could be as trivial as a compiler flag or setting. And perhaps the 32-bit DOS version of Icon is one of the poorer ones. I have no idea. But I think this does illustrate that for at least one version of Icon, intermittant, unreproduceable runtime failures in building indexes for and compressed representations of fairly large texts limits its popularity. There were so many ways my friend caused intermittant crashes by legitimately modifying his source code that he will probably never again use Icon again for serious work. On a more positive note, I would, under the right circumstances. -- ********************************************************** * Bruce Samuelson Department of Linguistics * * bruce@ling.uta.edu University of Texas at Arlington * ********************************************************** From icon-group-sender Sat Apr 24 04:20:55 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:23:00 MST Date: 24 Apr 93 04:20:55 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications, Greenbelt MD USA Subject: Lets Make Icon Popular. Lets hold a contest. Message-Id: <1raf77$bti@access.digex.net> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Every year at Usenix, they hold the IOCCC that is the International Obfuscated C coding Contest. The rules are simple. No more then 1 page of source code. Must do soemthing non-trivial. Winner is the most amazing bit of code. I propose the INternational Incomprehensible Icon imposition, or the IIII for short. Rules should be simple: 1 page of code. Must do something interesting. Maybe we could even get some prize money together. like a round trip ticket to arizona, or autographed pictures of authors. what do you all think? pat From icon-group-sender Sun Apr 25 02:02:59 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:23:03 MST Date: 25 Apr 93 02:02:59 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: DOS (was Re: Lack of robustness) Message-Id: <1993Apr25.020259.18787@midway.uchicago.edu> References: <9304230936.AA23022@univ-caen.fr>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu bruce@utafll.uta.edu (Bruce Samuelson) writes: >Another possible reason Icon is not more popular is lack of >robustness in some circumstances. > >...running DOS 5.0.... Hint: Icon really prefers not to run in the small address space of an 8086 processor. DOS was, in turn, never meant to run pro- grams that bite off large amounts of working memory, and do their own reallocation, extension, and memory management. Under UNIX, Icon is quite robust. I have run into only a handful of problems with it in the six or so years that I've been using it under SunOS and Xenix. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Apr 25 03:53:18 1993 Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:23:08 MST Date: 25 Apr 93 03:53:18 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: Lets Make Icon Popular. Lets hold a contest. Message-Id: <1rd1ve$e9m@access.digex.net> References: <1raf77$bti@access.digex.net>, <1993Apr24.142749.24979@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I was thinking that given the fact ICON is a typeless language and that type conversion is done seamlessly, one could have some real fun with that. the other thing is one could write an ICON program that modifies itself, pumps it into a pipe or file directly to the icon translator for running. pat From icon-group-sender Sun Apr 25 22:08:38 1993 Received: by cheltenham.cs.arizona.edu; Mon, 26 Apr 1993 04:31:36 MST Message-Id: <9304260508.AA21290@internal.apple.com> Date: Sun, 25 Apr 1993 22:08:38 -0800 To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin ":-]" Liber) X-Sender: nevin@130.43.2.2 Subject: Re: Is this passable code? Cc: glauber@david.wheaton.edu (Glauber Ribeiro) Status: R Errors-To: icon-group-errors@cs.arizona.edu >I started using Icon recently, and am impressed with the >power of the language. But, since i'm learning on my own and >don't have experience with Icon, i don't know if i'm doing >things right. Recently i wrote a short program to find >anagrams (yeah...) using the unix dictionary. I'd appreciate >any comments/suggestions/flames, etc about my programming >style and the Icon way. I did think of a different (simpler, I believe) way of implementing the anagram algorithm, using sets. I don't know if it's better or worse, but it does illustrate my particular style for programming in Icon. Here it is, along with an explanation of some of my stylistic choices: # look up anagrams of all the command line arguments in /usr/dict/words procedure main(LArguments) local SAnagrams local fWords local sWord SAnagrams := set() every insert(SAnagrams, Permute(map(!LArguments))) fWords := open("/usr/dict/words") | stop("Cannot open /usr/dict/words for reading; aborting.") while sWord := read(fWords) do { if member(SAnagrams, map(sWord)) then write(sWord) } close(fWords) end procedure Permute(sString) local iPos if 0 = *sString then return sString suspend sString[iPos := 1 to *sString] || Permute(sString[1:iPos] || sString[iPos+1:0]) end Variable conventions: In my code, the first letter of each variable identifies what kind of value it contains, following the convention on the first page of the Reference Manual in the Icon book. In this program, L stands for list, S for set, f for file, s for string, and i for integer. I also try and give full names to variables to make the code more readable and understandable. I also capitalise the first letter of each word (an Apple convention for code, which I like much, much better than using underscores), as well as starting all of my functions with a capital letter. I tend to declare all of my local variables, so that icont -u can catch an inadvertent spelling errors. Permute(): This is a recursive generator which produces all possible permutations of its argument. I tend to let the caller (in this case, main()) build the container structure (a set) instead of the callee because in many cases the results of a generator can be used directly without having to build a large data structure in memory. Important points about main(): every insert(SAnagrams, Permute(map(!LArguments))): "every" generates all possible values for the insert(...) expression. Let's analyse this from inside to out: every !LArguments: this produces all the members of list LArguments, in order. In this case, this produces strings of all the command line arguments. If there are no arguments, it fails; failure is inherited by the rest of the expression, and the set SAnagrams remains empty. every map(!LArguments): When I use map() with it's default arguments for s2 (source mapping string) and s3 (destination mapping string), I think of it as "removing" the caseness of its argument; I don't really care if it converts it to all uppercase or all lowercase. every Permute(map(!LArguments)): This produces all the possible "caseless" permutations of all the command line arguments. Although this is logically equivalent to every map(Permute(!LArguments)), I chose to put it inside of Permute(...) because it is more efficient to call it once per command line argument than to call it for each permutation. every insert(SAnagrams, Permute(map(!LArguments))): This produces a set of all the possible "caseless" permutations of all the command line arguments. If there are duplicate permutations (if a given letter appears more than once in a word, there will be duplicate permutations), they are automatically discarded since we are using a set data type. fWords := open("/usr/dict/words") | stop("Cannot open /usr/dict/words for reading; aborting."): I prefer to use alternation (|) instead of an if statement. I think of the open() as the normal expected case, and the stop() clause as the "exception". if member(SAnagrams, map(sWord)) then write(sWord): Again, I do a map(sWord) to remove the caseness of SWord so I can do a caseless comparison. If it's in the set of possible anagrams, I write out the word, preserving the case it has in /usr/dict/words. Variations on this algorithm: There are 24259 words in /usr/dict/words on my Unix machine. If I was expecting to process many words with 8 or more unique letters (8! = 40320 permutations), I would have approached this a little differently. I would have read /usr/dict/words into a set (or a table, if I thought that preserving case was important), and do something like [note: if you want to preserve case, it's actually a little harder than this. The algorithm below ignores words in /usr/dict/words that only differ by case, and it probably shouldn't]: procedure main(LArguments) local TWords local fWords local sWord TWords := table() fWords := open("/usr/dict/words") | stop("Cannot open /usr/dict/words for reading; aborting.") while sWord := read(fWords) do TWords[map(sWord)] := sWord close(fWords) every write(\TWords[Permute(map(!LArguments))]) end I would probably even come up with a heuristic that analyses LArguments and determines which of the two above variations to call to do the work. I hope this is what you were looking for. I can't believe I wrote this much on a 20 line algorithm. :-) Comments are appreciated. ___ NEVIN ":-)" LIBER, Blue Meanie, Macintosh System Software email: nevin@apple.com paper: Apple Computer, Inc. voice: (408) 974-MIX1 2 Infinite Loop, MS: 302-4Q AppleLink: BADENOV Cupertino, CA 95014 From icon-group-sender Fri Apr 23 17:09:15 1993 Received: by cheltenham.cs.arizona.edu; Mon, 26 Apr 1993 04:31:59 MST Date: 23 Apr 93 17:09:15 GMT From: agate!howland.reston.ans.net!ira.uka.de!math.fu-berlin.de!easix!flyer!larry!ms.open.de!hugo!gb@ucbvax.Berkeley.EDU (Georg Bauer) Organization: Hugos Box of (Mail)-Horror Subject: runtime debugger Message-Id: <735584955snx@hugo.ms.open.de> References: <1r3k5p$9dp@access.digex.net> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi! In article <1r3k5p$9dp@access.digex.net> prb@access.digex.com writes: > >A run-time debugger, with a functionality like dbx (text-mode) > Text Mode? I was thinking GUI based interface, myself. > dbx is nice, but run under suntools, it's awesome. There are lots of users of the DOS-Version of Icon (at least I know 2 ;-) ) - so I think a text-mode debugger for the start would be nice. A graphics interface could be given as an option - like the program visualization. Would it be possible to build a debugger on top of the multithreaded Icon? bye, Georg --- Georg Bauer /// Martin-Niemoeller-Strasse 21 /// D-W4400 Muenster /// Germany short mail to : gb@st2.maus.de (please only mail < 48 KB) long mail to : gb@hugo.ms.open.de "It's alive commander - but not as we know it" From icon-group-sender Mon Apr 26 08:02:33 1993 Received: by cheltenham.cs.arizona.edu; Mon, 26 Apr 1993 10:29:01 MST Date: Mon, 26 Apr 1993 08:02:33 -0400 Message-Id: <9304261202.AA37887@medinah.atc.ucarb.com> To: icon-group@cs.arizona.edu From: far@medinah.atc.ucarb.com Subject: "Find that Niche!" contest? Status: R Errors-To: icon-group-errors@cs.arizona.edu In the spirit of 'why isn't Icon, a truly useful language, more widely recognized as such', the following... 1) needing a PRACTICAL application (i.e.- a program people would be willing to pay buck$ for even if only shareware magnitude bucks) as proof of 'worthiness' makes sense. 2) The Icon project needs $upport (a loop is complete here already.) so we need an idea (!) for an application that Icon is uniquely suited to provide, that is not now being satisfied, that is not so big that the startup resources required would make it impractical (save the blockbuster until startup $$ are there from the first commercial Icon product)..... etc., etc. Perhaps this also would make a good contest. one thing that occurs to me from OCR user experience (now maybe three years out of date) is that programs then available seemed to have no smarts at the word level. If a word was clearly three letters and the first two were "th" it didn't go ahead and try harder to find out if the third was "e" or just guess "the". As a linguist or programmer, I make a good industrial Organic Chemist so I leave it to the experts to decide if there's anything in this posting worth doing or modifying. Forrest Richey From icon-group-sender Sun Apr 25 23:14:24 1993 Received: by cheltenham.cs.arizona.edu; Mon, 26 Apr 1993 12:21:13 MST Date: 25 Apr 93 23:14:24 GMT From: howland.reston.ans.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!news.uta.edu!utafll.uta.edu!bruce@gatech.edu (Bruce Samuelson) Organization: UTexas at Arlington, Linguistics Subject: Lack of robustness in 32-bit DOS version Message-Id: References: <9304230936.AA23022@univ-caen.fr>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > Hint: Icon really prefers not to run in the small address space > of an 8086 processor. DOS was, in turn, never meant to run pro- > grams that bite off large amounts of working memory, and do their > own reallocation, extension, and memory management. The data indexing and compression runs I referred to used the 32-bit version of Icon for 386/486 processors that bundles a DOS extender. They were running on a 486 processor. If they had been run "in the small address space of an 8086 processor", they would have crashed in short order. The most probable explanation of the problems I reported is that this particular 32-bit version of Icon is not robust. Like Richard Goerwitz, the Unix version I use is robust for the applications for which I have used it. -- ********************************************************** * Bruce Samuelson Department of Linguistics * * bruce@ling.uta.edu University of Texas at Arlington * ********************************************************** From icon-group-sender Tue Apr 27 09:45:32 1993 Received: by cheltenham.cs.arizona.edu; Tue, 27 Apr 1993 05:14:52 MST Message-Id: <9304270845.AA09147@ruls41.LeidenUniv.nl> To: icon-group@cs.arizona.edu Cc: ruiter@ruls41.LeidenUniv.nl Subject: Re: "Find that Niche!" contest? Date: Tue, 27 Apr 93 09:45:32 +0100 From: ruiter@ruls41.LeidenUniv.nl X-Mts: smtp Status: R Errors-To: icon-group-errors@cs.arizona.edu I don't know whether finding a 'hot' or 'cool' application written *in* Icon would be so convincing. Of course, any good application written in Icon *supports* the language by means of illustration and a sort of "see what you can do in this language"-proof. However, I think the main power of Icon lies in the possibility of reducing development time. I have implemented several psycholinguistic models using Icon in 2-3 hours, including a handy command-line interface. What struck me as one of the advantages of Icon in that context is that I could call procedures by their string values, so after defining a new procedure in the model, the user interface did not have to be adapted; the new procedure could be called from the command line right away! This sort of 'trics' usually surpises programmers in a positive way. I had a colleague (C programmer) turn whitish when he saw me scramble (randomize) a file with: procedure main(ar) infile := open(ar[1]) | &input lines := list() every(put(lines,!infile)) every(?lines :=: !lines) every(write(!lines)) close(infile) end Now this rather innocent kind of program is so easy to write in Icon that you'd have to run it a thousand times a day to justify writing it in C. The unique thing of Icon (IMHO, of course) is that it reduces development time so drastically that it actually pays to use it, even when the performance is interpreter-like. Maybe what would help to convince programmers if they are potential Icon enjoyers is a document that does not only highlight Icon's features, but also compares these features with other programming languages like awk() en C(++). If such a document is written well, it could be quite convincing. Jan ---------------------------------------------------- Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Tue Apr 27 08:44:18 1993 Received: by cheltenham.cs.arizona.edu; Tue, 27 Apr 1993 10:49:44 MST Date: 27 Apr 1993 08:44:18 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Icon in the Real World To: icon-group@cs.arizona.edu Message-Id: <01GXI05D4Y7M8WW7BE@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu Even though Icon isn't officially supported by our organization, I have put together a number applications with it that I consider to be production quality. Most of the time, icon is mixed with one or more other software products to produce the desired effect. Application : Requestline Department : Library Purpose : Interlibrary loan. This is a very simple application that displays a data entry form with a request for book, newspaper, periodical, thesis etc,... Depending on the type of request a second for pops up taking in specific fields identifying information. A special transmittal file is written and emailed to the librarians for processing. The 144 line icon program replaces an 8,000 line C program, and it took me all of 4 hours to put together. The data-entry forms are de-coupled from the application, so they can be edited and updated without needing to recompile. Application : TSM_Check Department : MIS/ITS Purpose : Works in concert with DECs terminal server manager software to find terminal server ports stuck in a 'disconnecting' state and clear them. Application : 600Baud Department : MIS/ITS Purpose : Works in concert with DECs terminal server manager software to find terminal server ports stuck at 600 baud because of flakey slave printers or rain storms and resets them. Application : VERSIONS Department : MIS/ITS Purpose : Works in concert with DECs terminal server manager software to display the software versions and boot dates of all the terminal servers. (in our multi-enterprise network occasionally another corporations software loads the wrong version. And in general they need to be rebooted once every 6 months for reliability reasons. Application : SRCH Department : MIS/ITS Purpose : Works in concert with a FOCUS download of name, address, and ssn as a search engine to verify that people requesting accounts are indeed current employees. Application : MENU Department : ITS Purpose : Easy menu system for users initially given unix accounts. It offers a simple front end to Email, News, Telnet, Ftp, Gopher, Library Card Catalog, and some other campus services. Application : XMENU Department : ITS Purpose : Same as MENU, but is point and click X-based. Application : FIND/PHONEBOOK Department : MIS Purpose : This runs in the background occasionally. It goes through the user database that contains names, departments and phone numbers in order to provide an on-line telephone/email directory. The search engine the users use was built from bundled VMS utilities. Application : INACTIVE_USER Department : MIS Purpose : Looks for user accounts not used since a certain date and deletes the account, files, directories, and mailing list entries for those users. Application : CPU & MEM Department : ITS Purpose : Graphically monitors memory and CPU usage on unix systems with the user interface much like VMS MONITOR. Application : NETWORK Department : Faculty Affairs Purpose : Pathworks LAN Network services menu. A number of services exist, except that the USE and NET commands have such a hairy syntax, I front ended them with this menu. This is PC based and is actually still running Icon 5.9 (because of memory constraints). These are a sampling of what I've been able to do with ICON. There is tons of things we can do with email and messaging, and while I've mentioned one here, I've written others and they've all been well received. We hired a net guru with Icon and Perl experience a little over a year ago so I've been saying he can back me up on all this stuff. Gotta get the foot in the door somehow. (besides it'll make nice consultant/contract programmer business if I decide to leave someday). 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Mon Apr 26 06:40:42 1993 Received: by cheltenham.cs.arizona.edu; Tue, 27 Apr 1993 10:51:12 MST Date: 26 Apr 93 06:40:42 GMT From: agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!news-feed-1.peachnet.edu!umn.edu!csus.edu!netcom.com!cas@ucbvax.Berkeley.EDU (Charles A. Shartsis) Organization: Netcom Online Communications Services (408-241-9760 login: guest) Subject: Re: runtime debugger Message-Id: References: <1r3k5p$9dp@access.digex.net>, <735584955snx@hugo.ms.open.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I am rather surprised that no one has mentioned the fact that there is a debugger for Icon called DEBUGIFY! It is one of the packages included in the current Icon Program Library. It is not fancy, but it is infinitely better than the trace function. It has source-line tracing and breakpoints. Variable values can be printed and simple variables (not lists or records yet) can be assigned new values. Best of all anyone can modify or enhance the debug code since it is written in Icon. There are two components to the debugger: a module that inserts debug hooks into ucode and the code which actually executes when the debugger is invoked from within a program. The fact that I wrote DEBUGIFY might have something to do with my plugging it here. From icon-group-sender Thu Apr 22 19:06:16 1993 Received: by cheltenham.cs.arizona.edu; Tue, 27 Apr 1993 10:51:39 MST Date: 22 Apr 93 19:06:16 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Is there a run time Debugger in developement? Message-Id: <1993Apr22.190616.5863@midway.uchicago.edu> References: <199304181245.AA21479@chuckwalla.cs.arizona.edu>, <735348344snx@hugo.ms.open.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <735348344snx@hugo.ms.open.de> gb@hugo.ms.open.de writes: > > ...interested > > in hearing how many people are really interested in a debugger. > >Me! Icon is really a very interesting and nice language - but I often find >myself screwed up with some problem, and no idea how to solve it. I think a >- at least to some degree - visual debugging tool would help to find your >way through the jungle of icon. I'd pay real $ for a good Icon debugger. George: If you get to problem spots, no matter how mundane you think they are, consider posting. This group isn't a high-volume one, and I think that a lot of us like bending our minds over queries involving real-world prob- lems. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Apr 26 16:18:51 1993 Received: by cheltenham.cs.arizona.edu; Tue, 27 Apr 1993 19:49:08 MST Date: 26 Apr 93 16:18:51 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: runtime debugger Message-Id: <1rh21b$nbb@access.digex.net> References: <1r3k5p$9dp@access.digex.net>, <735584955snx@hugo.ms.open.de>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article cas@netcom.com (Charles A. Shartsis) writes: | |I am rather surprised that no one has mentioned the |fact that there is a debugger for Icon called DEBUGIFY! |can be assigned new values. Best of all anyone can ^^^^^^^^ |modify or enhance the debug code since it is written in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Icon. I don't think so Tim :-) From icon-group-sender Tue Apr 27 01:52:23 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 04:50:04 MST Date: 27 Apr 93 01:52:23 GMT From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@ames.arc.nasa.gov (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Help! Message-Id: <1993Apr27.015223.18496@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu erholm@CS.ColoState.EDU (scott erholm) writes: > >In Pascal, I could pass values to and from procedures in this manner: > >Procedure P (VAR x, y, z : Integer; l, m : Real); > (* procedure body *) >end; > >And the call to P would look like this: > >P (a, b, c, 10, 20); > >meaning that procedure P would get 10 and 20 for l and m, and would >pass the values of x, y, and z back to the calling program. So-called "var" parameters in Pascal are a way of introducing side- effects. These are not permitted in Icon per se. One usually does not want or need them, although I have often wondered whether adding them would be difficult - if they were done precisely as in Pascal (i.e. not as in C, which might break Icon's type-safe scheme). Show us what you want to do in Icon, and I'll bet someone here will gladly suggest how to do it. The question is whether you should pass a structure, or whether you are approaching the whole problem in an "Iconish" fashion. Be pretty specific, and I'm sure you'll get some cogent suggestions. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Apr 26 12:02:33 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 04:50:17 MST Date: 26 Apr 93 12:02:33 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: "Find that Niche!" contest? Message-Id: <9304261202.AA37887@medinah.atc.ucarb.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In the spirit of 'why isn't Icon, a truly useful language, more widely recognized as such', the following... 1) needing a PRACTICAL application (i.e.- a program people would be willing to pay buck$ for even if only shareware magnitude bucks) as proof of 'worthiness' makes sense. 2) The Icon project needs $upport (a loop is complete here already.) so we need an idea (!) for an application that Icon is uniquely suited to provide, that is not now being satisfied, that is not so big that the startup resources required would make it impractical (save the blockbuster until startup $$ are there from the first commercial Icon product)..... etc., etc. Perhaps this also would make a good contest. one thing that occurs to me from OCR user experience (now maybe three years out of date) is that programs then available seemed to have no smarts at the word level. If a word was clearly three letters and the first two were "th" it didn't go ahead and try harder to find out if the third was "e" or just guess "the". As a linguist or programmer, I make a good industrial Organic Chemist so I leave it to the experts to decide if there's anything in this posting worth doing or modifying. Forrest Richey From icon-group-sender Fri Apr 23 16:57:22 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 04:50:55 MST Date: 23 Apr 93 16:57:22 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: runtime debugger Message-Id: <1r975i$lmq@access.digex.net> References: <199304220511.AA28454@chuckwalla.cs.arizona.edu>, <1993Apr23.150030.11124@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993Apr23.150030.11124@midway.uchicago.edu> goer@midway.uchicago.edu writes: >"Clint Jeffery" writes: |> |does not cater to the introductory CS course regimen. Icon has, as its |natural constituency, people interested in AI, NLP, text, translation, |and general nonnumeric computing. Intro CS courses are not taught, in | |The Icon Project members are, interestingly, more capable in nonnumeric |matters than most CS researchers I've met. Which leads me to wonder: Why |pretend any longer that Icon is standard CS fare? Its major user-accessible |advances have largely been in interface design and in solving problems that |require heuristic methods, rather than algorithmic ones. Icon really isn't |(from a user's standpoint) a good, standard CS language, except for those |interested in language design and theory. | |Icon is a *great* language, and I hope it won't go away. Makes life easier |for a large range of problems. It's just that this range of problems lies |more in my area, I think, than it does in the CS fold. Clint: Why not take |advantage of Icon's uniqueness, and start showing up a Humanities computing |conferences, interface design conventions, etc. :-) 1/2 ? | My question, is? WHat really cool things have been done in ICON? and how much code did it take to implement them? pat From icon-group-sender Wed Apr 28 07:56:23 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 07:46:17 MST Date: 28 Apr 1993 07:56:23 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: Help! To: icon-group@cs.arizona.edu Message-Id: <01GXJCRBTCHU8WW7RY@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu On Passing several variables In and several Out: Structures and globals are the methods I use. Structures are better if you have this as a widespread problem. Globals are useful in smaller cases. I use globals a lot when converting a BASIC program into ICON. ---------------------------------------------------------------------- Method 1 : Use a structure stuff := obtain(a,b,c) ... # Using a List # Using a table procedure obtain(a,b,c) or procedure obtain(a,b,c) return [x,y,z] result := table("") end result["x"] := 5*1.4 result["y"] := 22/7 result["z"] := ?25 return result end ------------------------------------------------------------------------------ Method 2. Use globals global x,y,z procedure main() ... obtain(a,b,c) end procedure obtain(a,b,c) x := 5*1.3 y := 22/7 z := ?25 end --------------------------------------------------------------------- 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Wed Apr 28 13:10:24 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 07:46:39 MST Date: Wed, 28 Apr 93 13:10:24 GMT From: Jerry D. Nowlin Message-Id: <9304281310.AA23936@iwtqg> To: @att.UUCP:cs.arizona.edu!icon-group Subject: Re: Help! Status: R Errors-To: icon-group-errors@cs.arizona.edu > erholm@CS.ColoState.EDU (scott erholm) writes: > > In Pascal, I could pass values to and from procedures in this manner: > > Procedure P (VAR x, y, z : Integer; l, m : Real); > (* procedure body *) > end; > > And the call to P would look like this: > > P (a, b, c, 10, 20); > > meaning that procedure P would get 10 and 20 for l and m, and would > pass the values of x, y, and z back to the calling program. In Icon you can pass a list into a procedure and then stuff things into it or yank things out of it and when the procedure exits the list remains modified. If you pass an empty list to a procedure you can put the x, y and z values in it and access them from the calling routine. An empty table may be more convenient if you want to access the values returned in a specific order. Finally, while an Icon procedure can only return one item, that item can be a list or table or any other Icon type. Rather than including an empty list or table in the parameter list why not just return one you constructed on the fly inside the procedure. Icon magically keeps the values in the list or table around for you until you don't need them anymore. Oh sure... you could explain it in terms of pointers and that other technical stuff but I like magic. procedure main() addem(l := [],t := table()) every write(!l | t[1 to 3] | !retem()) end procedure addem(l,t) every put(l,"new"|"list"|"items") t[1] := "and" t[2] := "table" t[3] := "values" end procedure retem() every put(l := [],"and"|"more"|"list"|"items") return l end Jerry Nowlin nowlin@iwtqg.att.com (work) isidev!nowlin@uunet.uu.net (home) From icon-group-sender Wed Apr 28 08:13:44 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 07:47:09 MST Date: 28 Apr 1993 08:13:44 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: runtime debugger To: icon-group@cs.arizona.edu Message-Id: <01GXJDCU5ZIW8WW7RY@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu > In article <1993Apr23.150030.11124@midway.uchicago.edu> goer@midway.uchicago.edu writes: > >"Clint Jeffery" writes: > |> > |does not cater to the introductory CS course regimen. Icon has, as its > |natural constituency, people interested in AI, NLP, text, translation, > |and general nonnumeric computing. Intro CS courses are not taught, in > | > |The Icon Project members are, interestingly, more capable in nonnumeric > |matters than most CS researchers I've met. Which leads me to wonder: Why > |pretend any longer that Icon is standard CS fare? Its major user-accessible > |advances have largely been in interface design and in solving problems that > |require heuristic methods, rather than algorithmic ones. Icon really isn't > |(from a user's standpoint) a good, standard CS language, except for those > |interested in language design and theory. > | > |Icon is a *great* language, and I hope it won't go away. Makes life easier > |for a large range of problems. It's just that this range of problems lies > |more in my area, I think, than it does in the CS fold. Clint: Why not take > |advantage of Icon's uniqueness, and start showing up a Humanities computing > |conferences, interface design conventions, etc. :-) 1/2 ? > | > My question, is? WHat really cool things have been done in ICON? > and how much code did it take to implement them? > pat This depends on ones definition of 'COOL'. The best, production quality, and yes software I've written and sold is usually rather boring and mundane. But that's what computing is all about; getting the machine to do boring and mundane things so we humans can have more fun. I wrote a tick-tack-toe game that cheats (as a side effect of automatic type casting), and I think it's real cool. But I don't expect anyone to pay money for something like that. I wrote a peotry/verse generator that generates great material for talk.bizaare, but I don't expect any big offers on that. Where the money and opportunites are now is in things like mailing labels, marketing demos, email/groupware, and client/server. Boring as can be, but packaged right, and promoted right, it'll fly. Icon in and of itself won't ever be used by Microsoft, CA, DEC, IBM, et al because they've established a culture and dynasty that is set in stone. The customer doesn't care if we use Icon, C++, or DOS BATCH to solve a problem. They simply want their problem solved, and as cheaply as possible. Oh well. 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Wed Apr 28 12:27:37 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 12:33:19 MST From: mitch@roll.csd.sgi.com (Tom Mitchell) Message-Id: <9304281927.AA17778@roll.csd.sgi.com> Subject: Re: runtime debugger and the Icon fan club. To: icon-group@cs.arizona.edu Date: Wed, 28 Apr 1993 12:27:37 -0800 (PDT) X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 2370 Status: R Errors-To: icon-group-errors@cs.arizona.edu There has been a 'discussion' that Icon could have a wider circle of users. |> |does not cater to the introductory CS course regimen. Icon has, as its |natural constituency, people interested in AI, NLP, text, translation, |and general nonnumeric computing. Intro CS courses are..... I see a couple of things. I suspect that this is a generic problem with the mind set of education today. Consider the transition from slide rule to calculator. There was a lot of resistance to calculators because people felt that understanding slide rules of itself is important. I heard this in in a chem class no less. There are still art schools that demand that students grind their own paint and pigment. Bletch... I think. I wonder, since Icon is implemented in 'C' it might be considered dependent on 'C' and thus less interesting. Also given that there is also a strong bias toward stronger type defines in ANSI 'C', the lack of type checking in Icon could be seen as a loss against the curriculum goals. A real power of Icon is the ease of expressing things like generators. Should these be taught before or after recursion in a CS course, message passing, object oriented programming? Should the implementation of generators in c, Fortran, assembler be a CS goal. I believe that a general purpose language does need to be 'invented' that defines an expressive context to permit strong type checking, object hiding, generators, lists, multi-dimension arrays, bounds checking etc. Just in case should some one sets out to do this. An irritant to me is little inconsistent 'features' like {} and ; omissions where the parser can permit such things to be omitted in one place and not in others. I find that they are a problem to me learning a language or using a language infrequently. We all like to start with simple examples that illustrate something. These are also the examples that permit shortcuts. When I expand from the trivial example to something interesting I find I now need the missing {}; and wish they were there in the example the start. Sort of a summary: Does Icon support these goals in the first two years of a CS education? Mostly not I suspect. What are the curriculum goals of a CS education? What are the education goals of a non CS education. Does Icon support the CS needs of a non-CS education? Mostly not I suspect. From icon-group-sender Wed Apr 28 12:56:19 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 13:06:06 MST Message-Id: <9304281953.AA17496@enlil.premenos.sf.ca.us> From: Ken Walker Subject: var paramters To: icon-group@cs.arizona.edu Date: Wed, 28 Apr 93 12:56:19 PDT Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > from Richard L. Goerwitz: > > So-called "var" parameters in Pascal are a way of introducing side- > effects. These are not permitted in Icon per se. One usually does > not want or need them, although I have often wondered whether adding > them would be difficult - if they were done precisely as in Pascal > (i.e. not as in C, which might break Icon's type-safe scheme). >From an implementation perspective, I'd prefer the in/out style of parameter passing, where the updated value of an out parameter is only copied back to the caller's variable upon return and suspend (should they be updated on failure?). There is also an advanatage from the language philosophy point of view: in the case of an out parameter, you can consider the call rather than the called procedure as being what updates a local variable passed as an argument; this means that local variables are still only updated by the procedure they belong to, protecting their "local" status. Those not interested in "technical" matters might want to skip the rest of the discussion. I haven't investigated this in detail, but I think the following is what is needed to add in/out parameters to Icon. In the translator, the grammar for paramters must be updated and flags must be added to the symbol table to distinguish in, out, and in-out parameters. In the runtime system, in/out information must be added to procedure blocks. Invocation must keep a copy of variable refereces for out parameters and, on return, must assign the updated parameter values to those variables before popping the parameters from the stack. Suspend must also copy the updated out parameter values to the variables. The linker must be updated to produce the procedure blocks with the in-out information. As one might expect, the compiler is a little harder because of optimizations. However, in-out parameters are easier than var parameters; type inference can be modified to handle var paramters, but it would make type inference more expensive. The modifications to the compiler's grammar and symbol table are similar to those of the translator for the interpreter. The abstract invocation of type inference must be updated to mirror the semantics of actual invocation; if you understand type inference, this is probably not harder than updating invocation in the run-time system. Non-optimized invocation can be handled similar to the way invocation is handled in the interpreter, though some of the inplementation conventions are different. One way to handle optimized procedure invocation is to not optimize if there are out parameters (but that's not much fun :-). The current case analysis for optimizing invocation is rather gross and optimizing out parameter passed will make it worse, but clearly it can be done. Can anyone think of something I've missed? Note: the preceding discussion should not be taken to mean that I'm considering trying to implement in/out parameters in the immediate future. Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Wed Apr 28 23:23:02 1993 Received: by cheltenham.cs.arizona.edu; Thu, 29 Apr 1993 05:50:30 MST Date: Wed, 28 Apr 93 23:23:02 PDT From: John Paolillo To: icon-group@cs.arizona.edu Subject: "What cool things..." Message-Id: Status: R Errors-To: icon-group-errors@cs.arizona.edu pat someone writes: > My question, is? WHat really cool things have been done in ICON? and how much code did it take to implement them? pat < As my first real project in Icon, I wrote a program that could parse some Icon(-like) expressions, and execute them. The code was all of one page in length. I used this to learn about Icon expressions that I wanted to know more about, and to have fun with long-integer arithmetic (like 345 raised to the 24th). I'd like to know if a rank beginner like me could expect to do as much in any other language. Icon is such a powerful language, and I bet we could really see that if we held an informal "one-liner" contest (Heizer software does this for their compiled HyperTalk product). The rules are simple: you are allowed one line of code between your procedure declaration and the "end" statement. Within that, you can do anything you like. Anybody know any good one-liners? John C. Paolillo University of Texas at Arlington From icon-group-sender Thu Apr 29 13:24:55 1993 Received: by cheltenham.cs.arizona.edu; Thu, 29 Apr 1993 08:57:26 MST Date: Thu, 29 Apr 93 13:24:55 GMT From: Jerry D. Nowlin Message-Id: <9304291324.AA12397@iwtqg> To: @att.UUCP:cs.arizona.edu!icon-group Subject: Re: one liners Status: R Errors-To: icon-group-errors@cs.arizona.edu Trivial but handy # filter to convert to lower case procedure main() while write(map(read())) end # filter to convert to upper case procedure main() while write(map(read(),&lcase,&ucase)) end From icon-group-sender Thu Apr 29 08:59:43 1993 Received: by cheltenham.cs.arizona.edu; Thu, 29 Apr 1993 09:00:02 MST Date: Thu, 29 Apr 1993 08:59:43 MST From: "Ralph Griswold" Message-Id: <199304291559.AA29845@cheltenham.cs.arizona.edu> To: icon-group Subject: one-liners Status: R Errors-To: icon-group-errors@cs.arizona.edu Here's my favorite one-liner, written by Anthony Hewitt and improved by Bob Alexander. It filers out identical adjacent lines from the input file. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ procedure main() every write(s ~===:= !&input) end From icon-group-sender Tue Apr 27 02:15:01 1993 Received: by cheltenham.cs.arizona.edu; Thu, 29 Apr 1993 12:08:29 MST Date: 27 Apr 93 02:15:01 GMT From: darwin.sura.net!wupost!usc!sdd.hp.com!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@gatech.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Is this passable code? Message-Id: <1993Apr27.021501.19198@midway.uchicago.edu> References: <9304260508.AA21290@internal.apple.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu nevin@apple.com (Nevin ":-]" Liber) writes: > >procedure main(LArguments) >etc. every insert(SAnagrams, Permute(map(!LArguments))) This shows precisely how Icon's control mechanisms ought to be used. !LArguments generates everything in the arg list. Permute is also a generator. The keyword "every" indicates that all possible results should be fetched, just as if this were Prolog :-). >suspend sString[iPos := 1 to *sString] || > Permute(sString[1:iPos] || sString[iPos+1:0]) This is nice, too. Uses "suspend" to trigger backtracking - which is then fed into the recursion to produce a full set of permutations. Nevin: Where did you learn your Icon? Pretty idiomatic stuff. You say it's 20 lines, but in fact most of that is whitespace or extra local declarations (e.g. local x local y = local x,y). You did the important stuff in about 8 lines.... -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Apr 27 22:23:18 1993 Received: by cheltenham.cs.arizona.edu; Sun, 2 May 1993 06:17:30 MST Date: 27 Apr 93 22:23:18 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ersys!ab@ucbvax.Berkeley.EDU (Allan Brockman) Organization: Edmonton Remote Systems #1, Edmonton, AB, Canada Subject: icon popularity Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu i have tried to introduce icon to 4 peaple. one read the book and agrees whith me that it is well writen and that the language is excelent... so long ase you are only working whith text. one said i can't bebouthered to learn a new language. two said great language so simple so clean so powerfull ... to bad there are no graphic ruotiens... 4/5 of the peapkle i know who know of icon have expresed a desire for some graphic ability in the language. ya ya i know ... you could always have icon generate postscript files but then why not just learn and use postscript? ( or ray-trace or ect. ) perhaps a companion language to icon ( call it scribe ) that has minimal string manipulation words but describes sound and graphic well. iff i could tell my friends who say 'it has no graphic' that scribe HAS graphic and its ase clear and powerfull as icon is whith text AND that you can -easaly- call one from the other...then i think the popularity of icon would increase (espechaly amonst new users). -- Allan Brockman ab@ersys.edmonton.ab.ca From icon-group-sender Tue Apr 27 08:45:32 1993 Received: by cheltenham.cs.arizona.edu; Sun, 2 May 1993 06:17:44 MST Date: 27 Apr 93 08:45:32 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: Re: "Find that Niche!" contest? Message-Id: <9304270845.AA09147@ruls41.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I don't know whether finding a 'hot' or 'cool' application written *in* Icon would be so convincing. Of course, any good application written in Icon *supports* the language by means of illustration and a sort of "see what you can do in this language"-proof. However, I think the main power of Icon lies in the possibility of reducing development time. I have implemented several psycholinguistic models using Icon in 2-3 hours, including a handy command-line interface. What struck me as one of the advantages of Icon in that context is that I could call procedures by their string values, so after defining a new procedure in the model, the user interface did not have to be adapted; the new procedure could be called from the command line right away! This sort of 'trics' usually surpises programmers in a positive way. I had a colleague (C programmer) turn whitish when he saw me scramble (randomize) a file with: procedure main(ar) infile := open(ar[1]) | &input lines := list() every(put(lines,!infile)) every(?lines :=: !lines) every(write(!lines)) close(infile) end Now this rather innocent kind of program is so easy to write in Icon that you'd have to run it a thousand times a day to justify writing it in C. The unique thing of Icon (IMHO, of course) is that it reduces development time so drastically that it actually pays to use it, even when the performance is interpreter-like. Maybe what would help to convince programmers if they are potential Icon enjoyers is a document that does not only highlight Icon's features, but also compares these features with other programming languages like awk() en C(++). If such a document is written well, it could be quite convincing. Jan ---------------------------------------------------- Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Wed Apr 28 04:41:04 1993 Received: by cheltenham.cs.arizona.edu; Sun, 2 May 1993 06:18:51 MST Date: 28 Apr 93 04:41:04 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!geraldo.cc.utexas.edu!geraldo.cc.utexas.edu!plyon@ucbvax.Berkeley.EDU (Paul Lyon) Organization: The University of Texas at Austin Subject: Re: OS/2 & Icon (was Lack of robustness in 32-bit DOS version) Message-Id: References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Well, since I may be the only OS/2 user of Icon there is (or so I sometimes imagine, at least :-), I suppose I should speak to this. First of all, DOS support in OS/2 2.0 is quite good, though fine-tuning the DOS settings for a particular programme can be a bit of chore (there are almost 50 items on the settings menu for a DOS session!). Secondly, OS/2 does have most of the features of a "real OS" (TM), including one that most versions of UNIX do not have, namely multi-threading. (The major difference is that OS/2 is not multi-user, save by means of networking; the software for this must be purchased separately). As for utilities, provided one has ftp access, one can get virtually the entire GNU suite, including Emacs, two ports of gcc, flex, bison, diff, gawk, perl, rcs & cvs, bash, the text and file utilities, M4, tar, and so on, not to mention the GMD compiler toolkit (aka Cocktail), gnuplot, emTeX, and serveral literate programming tools (FunnelWeb, Cweb, and SpiderWeb). In addition, the X Window interface for Icon is also available in a OS/2 Presentation Manager version. As a development environment, then, OS/2 2.0 is not inferior to most Unix set-ups. Besides, if one has the disk space, one can always use a dual boot set-up with OS/2 2.0 and linux; judging by some of the traffic in the OS/2 newsgroups, it would seem a fair number of folks have done exactly that. Ciao, Paul Lyon From icon-group-sender Wed Apr 28 19:15:54 1993 Received: by cheltenham.cs.arizona.edu; Sun, 2 May 1993 16:53:14 MST Date: 28 Apr 93 19:15:54 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!not-for-mail@ucbvax.Berkeley.EDU (Lewis Perin) Organization: UTexas Mail-to-News Gateway Subject: Re: OS/2 & Icon (was Lack of robustness in 32-bit DOS version) Message-Id: <51238.perin@cumc.cornell.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu plyon@emx.cc.utexas.edu (Paul Lyon) writes: > Well, since I may be the only OS/2 user of Icon there is (or so I > sometimes imagine, at least :-) There are two of us, Paul. I seem to be as happy with my "poor man's SPARCstation as you are. > As for utilities, provided one has ftp access, one can get [...] serveral > literate programming tools (FunnelWeb, Cweb, and SpiderWeb). Perhaps you're unaware of yet another literate programming tool called noweb, which is available over the net much the same way as the others you mention. It's *very* well suited to Icon - it's what I use for my Icon code - and interestingly enough, it's partly written *in* Icon. Having used a few of the repertory of LP tools, I can say that noweb is by far the simplest of those I've tried. This isn't a newsgroup for literate programming, so I won't rant on, but since I'm on the subject allow me to raise an LP-related issue in Icon that's nagged at me for a while. It would be much easier to debug a literate Icon program if the language had a locution akin to the C #line preprocessor directive, i.e. a way of identifying from where in which source file a given chunk of code came. (Since Icon is so well suited for text processing, and since code is text, this might also assist in debugging programs automatically transformed by Icon programs, all literacy aside.) Does anyone else care about this? ______________________________________________________ __ perin@cumc.cornell.edu (212)746-2946 | |_ \ / : Lew Perin |__ |__ \/\/ : Home: (201)435-2679 From icon-group-sender Wed Apr 28 21:24:52 1993 Received: by cheltenham.cs.arizona.edu; Sun, 2 May 1993 16:53:36 MST Date: 28 Apr 93 21:24:52 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: icon tokenizer in icon Message-Id: <1993Apr28.212452.19699@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I wonder if anyone else will find this as useful as I have. -Richard ############################################################################ # # Name: itokens.icn # # Title: itokens (Icon source-file tokenizer) # # Author: Richard L. Goerwitz # # Version: 1.2 # ############################################################################ # # This file contains itokens() - a utility for breaking Icon source # files up into individual tokens. Itokens(f) takes, as its first # and only argument, an open file, and suspends successive TOK # records (defined below). TOK records contain two fields. The # first field, sym, contains a string that represents the name of the # next token (e.g. "CSET", "STRING", etc.). The second field, str, # gives that token's literal value. E.g. the TOK for a literal # semicolon is TOK("SEMICOL", ";"). For a mandatory newline, itokens # would suspend TOK("SEMICOL", "\n"). # # This is the sort of routine one needs to have around when # implementing things like pretty printers, preprocessors, code # obfuscators, etc. It would also be useful for implementing # cut-down implementations of Icon written in Icon - the sort of # thing one might use in an interactive tutorial. # # NOTE WELL: If new reserved words or operators are added to a given # implementation, the tables below will have to be altered. Note # also that &keywords are implemented on the syntactic level - not on # the lexical one. As a result, a keyword like &features will be # suspended as TOK("CONJUNC", "&") and TOK("IDENT", "features"). In # fact, this tokenizer mirrors closely the tokenizer used in the # underlying Icon implementation. # ############################################################################ # # Links: slashupto # # Requires: coexpressions # ############################################################################ #link ximage, slashupto link slashupto #make sure you have version 1.2 or above global next_c, line_number record TOK(sym, str) # # main: an Icon source code uglifier # # Stub main for testing; uncomment & compile. The resulting # executable will act as an Icon file compressor, taking the # standard input and outputting Icon code stripped of all # unnecessary whitespace. Guaranteed to make the code a visual # mess :-). # #procedure main() # # local separator, T # separator := "" # every T := itokens(&input) do { # if any(&digits ++ &letters ++ '_.', \T.str, 1, 2) & \T.sym ~== "DOT" # then writes(separator) # if T.sym == "SEMICOL" then writes(";") else writes(T.str) # if any(&digits ++ &letters ++ '_.', \T.str, -1, 0) & \T.sym ~== "DOT" # then separator := " " else separator := "" # } # #end # # itokens: file -> TOK records (a generator) # (stream) -> Rs # # Where stream is an open file, and Rs are TOK records. Note that # itokens strips out useless newlines. If you want to preserve # the line structure of the original file, see the description of # iparse_tokens() below. # procedure itokens(stream) local T every T := \iparse_tokens(&input) do # # Newlines that don't need to be present are signalled by a # null sym field. We'll strip them out here. # if \T.sym then suspend T end # # iparse_tokens: file -> TOK records (a generator) # (stream) -> tokens # # Where file is an open input stream, and tokens are TOK records # holding both the token type and actual token text. # # TOK records contain two parts, a preterminal symbol (the first # "sym" field), and the actual text of the token ("str"). The # parser only pays attention to the sym field, although the # strings themselves get pushed onto the value stack. # # Note the following kludge: Unlike real Icon tokenizers, this # procedure returns syntactially meaningless newlines as TOK # records with a null sym field. Normally they would be ignored. # I wanted to return them so they could be printed on the output # stream, thus preserving the line structure of the original # file, and making later diagnostic messages more usable. # procedure iparse_tokens(stream, getchar) local elem, whitespace, token, primitives, reserveds static be_tbl, reserved_tbl, operators initial { # Primitive Tokens # primitives := [ ["identifier", "IDENT", "be"], ["integer-literal", "INTLIT", "be"], ["real-literal", "REALLIT", "be"], ["string-literal", "STRINGLIT", "be"], ["cset-literal", "CSETLIT", "be"], ["end-of-file", "EOFX", "" ]] # Reserved Words # reserveds := [ ["break", "BREAK", "be"], ["by", "BY", "" ], ["case", "CASE", "b" ], ["create", "CREATE", "b" ], ["default", "DEFAULT", "b" ], ["do", "DO", "" ], ["else", "ELSE", "" ], ["end", "END", "b" ], ["every", "EVERY", "b" ], ["fail", "FAIL", "be"], ["global", "GLOBAL", "" ], ["if", "IF", "b" ], ["initial", "INITIAL", "b" ], ["invocable", "INVOCABLE", "" ], ["link", "LINK", "" ], ["local", "LOCAL", "b" ], ["next", "NEXT", "be"], ["not", "NOT", "b" ], ["of", "OF", "" ], ["procedure", "PROCEDURE", "" ], ["record", "RECORD", "" ], ["repeat", "REPEAT", "b" ], ["return", "RETURN", "be"], ["static", "STATIC", "b" ], ["suspend", "SUSPEND", "be"], ["then", "THEN", "" ], ["to", "TO", "" ], ["until", "UNTIL", "b" ], ["while", "WHILE", "b" ]] # Operators # operators := [ [":=", "ASSIGN", "" ], ["@", "AT", "b" ], ["@:=", "AUGACT", "" ], ["&:=", "AUGAND", "" ], ["=:=", "AUGEQ", "" ], ["===:=", "AUGEQV", "" ], [">=:=", "AUGGE", "" ], [">:=", "AUGGT", "" ], ["<=:=", "AUGLE", "" ], ["<:=", "AUGLT", "" ], ["~=:=", "AUGNE", "" ], ["~===:=", "AUGNEQV", "" ], ["==:=", "AUGSEQ", "" ], [">>=:=", "AUGSGE", "" ], [">>:=", "AUGSGT", "" ], ["<<=:=", "AUGSLE", "" ], ["<<:=", "AUGSLT", "" ], ["~==:=", "AUGSNE", "" ], ["\\", "BACKSLASH", "b" ], ["!", "BANG", "b" ], ["|", "BAR", "b" ], ["^", "CARET", "b" ], ["^:=", "CARETASGN", "b" ], [":", "COLON", "" ], [",", "COMMA", "" ], ["||", "CONCAT", "b" ], ["||:=", "CONCATASGN","" ], ["&", "CONJUNC", "b" ], [".", "DOT", "b" ], ["--", "DIFF", "b" ], ["--:=", "DIFFASGN", "" ], ["===", "EQUIV", "b" ], ["**", "INTER", "b" ], ["**:=", "INTERASGN", "" ], ["{", "LBRACE", "b" ], ["[", "LBRACK", "b" ], ["|||", "LCONCAT", "b" ], ["|||:=", "LCONCATASGN","" ], ["==", "LEXEQ", "b" ], [">>=", "LEXGE", "" ], [">>", "LEXGT", "" ], ["<<=", "LEXLE", "" ], ["<<", "LEXLT", "" ], ["~==", "LEXNE", "b" ], ["(", "LPAREN", "b" ], ["-:", "MCOLON", "" ], ["-", "MINUS", "b" ], ["-:=", "MINUSASGN", "" ], ["%", "MOD", "" ], ["%:=", "MODASGN", "" ], ["~===", "NOTEQUIV", "b" ], ["=", "NUMEQ", "b" ], [">=", "NUMGE", "" ], [">", "NUMGT", "" ], ["<=", "NUMLE", "" ], ["<", "NUMLT", "" ], ["~=", "NUMNE", "b" ], ["+:", "PCOLON", "" ], ["+", "PLUS", "b" ], ["+:=", "PLUSASGN", "" ], ["?", "QMARK", "b" ], ["<-", "REVASSIGN", "" ], ["<->", "REVSWAP", "" ], ["}", "RBRACE", "e" ], ["]", "RBRACK", "e" ], [")", "RPAREN", "e" ], [";", "SEMICOL", "" ], ["?:=", "SCANASGN", "" ], ["/", "SLASH", "b" ], ["/:=", "SLASHASGN", "" ], ["*", "STAR", "b" ], ["*:=", "STARASGN", "" ], [":=:", "SWAP", "" ], ["~", "TILDE", "b" ], ["++", "UNION", "b" ], ["++:=", "UNIONASGN", "" ], ["$(", "LBRACE", "b" ], ["$)", "RBRACE", "e" ], ["$<", "LBRACK", "b" ], ["$>", "RBRACK", "e" ]] # static be_tbl, reserved_tbl reserved_tbl := table() every elem := !reserveds do insert(reserved_tbl, elem[1], elem[2]) be_tbl := table() every elem := !primitives | !reserveds | !operators do { insert(be_tbl, elem[2], elem[3]) } } /getchar := create { line_number := 0 ! ( 1(!stream, line_number +:=1) || "\n" ) } whitespace := ' \t' /next_c := @getchar repeat { case next_c of { "." : { # Could be a real literal *or* a dot operator. Check # following character to see if it's a digit. If so, # it's a real literal. We can only get away with # doing the dot here because it is not a substring of # any longer identifier. If this gets changed, we'll # have to move this code into do_operator(). # last_token := do_dot(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } "\n" : { # If do_newline fails, it means we're at the end of # the input stream, and we should break out of the # repeat loop. # every last_token := do_newline(getchar, last_token, be_tbl) do suspend last_token if next_c === &null then break next } "\#" : { # Just a comment. Strip it by reading every character # up to the next newline. The global var next_c # should *always* == "\n" when this is done. # do_number_sign(getchar) # write(&errout, "next_c == ", image(next_c)) next } "\"" : { # Suspend as STRINGLIT everything from here up to the # next non-backslashed quotation mark, inclusive # (accounting for the _ line-continuation convention). # last_token := do_quotation_mark(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } "'" : { # Suspend as CSETLIT everything from here up to the # next non-backslashed apostrophe, inclusive. # last_token := do_apostrophe(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } &null : stop("iparse_tokens: unexpected EOF message") default : { # If we get to here, we have either whitespace, an # integer or real literal, an identifier or reserved # word (both get handled by do_identifier), or an # operator. The question of which we have can be # determined by checking the first character. # if any(whitespace, next_c) then { # Like all of the TOK forming procedures, # do_whitespace resets next_c. do_whitespace(getchar, whitespace) # don't suspend any tokens next } if any(&digits, next_c) then { last_token := do_digits(getchar) suspend last_token next } if any(&letters ++ '_', next_c) then { last_token := do_identifier(getchar, reserved_tbl) suspend last_token next } # write(&errout, "it's an operator") last_token := do_operator(getchar, operators) suspend last_token next } } } # If stream argument is nonnull, then we are in the top-level # iparse_tokens(). If not, then we are in a recursive call, and # we should not emit all this end-of-file crap. # if \stream then { suspend TOK("EOFX") return TOK("$") } else fail end # # do_dot: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that produces the next # character from the input stream and t is a token record whose # sym field contains either "REALLIT" or "DOT". Essentially, # do_dot checks the next char on the input stream to see if it's # an integer. Since the preceding char was a dot, an integer # tips us off that we have a real literal. Otherwise, it's just # a dot operator. Note that do_dot resets next_c for the next # cycle through the main case loop in the calling procedure. # procedure do_dot(getchar) local token # global next_c # write(&errout, "it's a dot") # If dot's followed by a digit, then we have a real literal. # if any(&digits, next_c := @getchar) then { # write(&errout, "dot -> it's a real literal") token := "." || next_c while any(&digits, next_c := @getchar) do token ||:= next_c if token ||:= (next_c == ("e"|"E")) then { while (next_c := @getchar) == "0" while any(&digits, next_c) do { token ||:= next_c next_c = @getchar } } return TOK("REALLIT", token) } # Dot not followed by an integer; so we just have a dot operator, # and not a real literal. # # write(&errout, "dot -> just a plain dot") return TOK("DOT", ".") end # # do_newline: coexpression x TOK record x table -> TOK records # (getchar, last_token, be_tbl) -> Ts (a generator) # # Where getchar is the coexpression that returns the next # character from the input stream, last_token is the last TOK # record suspended by the calling procedure, be_tbl is a table of # tokens and their "beginner/ender" status, and Ts are TOK # records. Note that do_newline resets next_c. Do_newline is a # mess. What it does is check the last token suspended by the # calling procedure to see if it was a beginner or ender. It # then gets the next token by calling iparse_tokens again. If # the next token is a beginner and the last token is an ender, # then we have to suspend a SEMICOL token. In either event, both # the last and next token are suspended. # procedure do_newline(getchar, last_token, be_tbl) local next_token # global next_c # write(&errout, "it's a newline") # Go past any additional newlines. # while next_c == "\n" do { # NL can be the last char in the getchar stream; if it *is*, # then signal that it's time to break out of the repeat loop # in the calling procedure. # next_c := @getchar | { next_c := &null fail } suspend TOK(&null, next_c == "\n") } # If there was a last token (i.e. if a newline wasn't the first # character of significance in the input stream), then check to # see if it was an ender. If so, then check to see if the next # token is a beginner. If so, then suspend a TOK("SEMICOL") # record before suspending the next token. # if find("e", be_tbl[(\last_token).sym]) then { # write(&errout, "calling iparse_tokens via do_newline") # &trace := -1 # First arg to iparse_tokens can be null here. until \(next_token := iparse_tokens(&null, getchar)).sym if \next_token then { # write(&errout, "call of iparse_tokens via do_newline yields ", # ximage(next_token)) if find("b", be_tbl[next_token.sym]) then suspend TOK("SEMICOL", "\n") # # See below. If this were like the real Icon parser, # the following line would be commented out. # else suspend TOK(&null, "\n") return next_token } else { # # If this were a *real* Icon tokenizer, it would not emit # any record here, but would simply fail. Instead, we'll # emit a dummy record with a null sym field. # return TOK(&null, "\n") # &trace := 0 # fail } } # See above. Again, if this were like Icon's own tokenizer, we # would just fail here, and not return any TOK record. # # &trace := 0 return TOK(&null, "\n") # fail end # # do_number_sign: coexpression -> &null # getchar -> # # Where getchar is the coexpression that pops characters off the # main input stream. Sets the global variable next_c. This # procedure simply reads characters until it gets a newline, then # returns with next_c == "\n". Since the starting character was # a number sign, this has the effect of stripping comments. # procedure do_number_sign(getchar) # global next_c # write(&errout, "it's a number sign") while next_c ~== "\n" do { next_c := @getchar } # Return to calling procedure to cycle around again with the new # next_c already set. Next_c should always be "\n" at this point. return end # # do_quotation_mark: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that yields another character # from the input stream, and t is a TOK record with "STRINGLIT" # as its sym field. Puts everything upto and including the next # non-backslashed quotation mark into the str field. Handles the # underscore continuation convention. # procedure do_quotation_mark(getchar) local token # global next_c # write(&errout, "it's a string literal") token := "\"" while next_c := @getchar do { if next_c == "\n" & token[-1] == "_" then { token := token[1:-1] next } else { if slashupto("\"", token ||:= next_c, 2) then { next_c := @getchar # resume outermost (repeat) loop in calling procedure, # with the new (here explicitly set) next_c return TOK("STRINGLIT", token) } } } end # # do_apostrophe: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that yields another character # from the input stream, and t is a TOK record with "CSETLIT" # as its sym field. Puts everything upto and including the next # non-backslashed apostrope into the str field. # procedure do_apostrophe(getchar) local token # global next_c # write(&errout, "it's a cset literal") token := "'" while next_c := @getchar do { if slashupto("'", token ||:= next_c, 2) then { next_c := @getchar # Return & resume outermost containing loop in calling # procedure w/ new next_c. return TOK("CSETLIT", token) } } end # # do_digits: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that produces the next char # on the input stream, and where t is a TOK record containing # either "REALLIT" or "INTLIT" in its sym field, and the text of # the numeric literal in its str field. # procedure do_digits(getchar) local token, tok_record # global next_c # Assume integer literal until proven otherwise.... tok_record := TOK("INTLIT") # write(&errout, "it's an integer or real literal") token := ("0" ~== next_c) | "" while any(&digits, next_c := @getchar) do token ||:= next_c if token ||:= (next_c == ("R"|"r")) then { while any(&digits, next_c := @getchar) do token ||:= next_c } else { if token ||:= (next_c == ".") then { while any(&digits, next_c := @getchar) do token ||:= next_c tok_record := TOK("REALLIT") } if token ||:= (next_c == ("e"|"E")) then { while any(&digits, next_c := @getchar) do token ||:= next_c tok_record := TOK("REALLIT") } } tok_record.str := ("" ~== token) | 0 return tok_record end # # do_whitespace: coexpression x cset -> &null # getchar x whitespace -> &null # # Where getchar is the coexpression producing the next char on # the input stream. Do_whitespace just repeats until it finds a # non-whitespace character, whitespace being defined as # membership of a given character in the whitespace argument (a # cset). # procedure do_whitespace(getchar, whitespace) # write(&errout, "it's junk") while any(whitespace, next_c) do next_c := @getchar return end # # do_identifier: coexpression x table -> TOK record # (getchar, reserved_tbl) -> t # # Where getchar is the coexpression that pops off characters from # the input stream, reserved_tbl is a table of reserved words # (keys = the string values, values = the names qua symbols in # the grammar), and t is a TOK record containing all subsequent # letters, digits, or underscores after next_c (which must be a # letter or underscore). Note that next_c is global and gets # reset by do_identifier. # procedure do_identifier(getchar, reserved_tbl) local token # global next_c # write(&errout, "it's an indentifier") token := next_c while any(&letters ++ &digits ++ '_', next_c := @getchar) do token ||:= next_c return TOK(\reserved_tbl[token], token) | TOK("IDENT", token) end # # do_operator: coexpression x list -> TOK record # getchar x operators -> t # # Where getchar is the coexpression that produces the next # character on the input stream, and t is a TOK record # describing the operator just scanned. Calls recognop, which # creates a DFSA to recognize valid Icon operators. Arg2 # (operators) is the list of lists containing valid Icon operator # string values and names (see above). # procedure do_operator(getchar, operators) local token, elem token := next_c # Go until recognop fails. while elem := recognop(operators, token, 1) do token ||:= (next_c := @getchar) # write(&errout, ximage(elem)) if *\elem = 1 then return TOK(elem[1][2], elem[1][1]) else fail end record dfstn_state(b, e, tbl) record start_state(b, e, tbl, master_list) # # recognop: list x string x integer -> list # (l, s, i) -> l2 # # Where l is the list of lists created by the calling procedure # (each element contains a token string value, name, and # beginner/ender string), where s is a string possibly # corresponding to a token in the list, where i is the position # in the elements of l where the operator string values are # recorded, and where l2 is a list of elements from l that # contain operators for which string s is an exact match. # Fails if there are no operators that s is a prefix of, but # returns an empty list if there just aren't any that happen to # match exactly. # # What this does is let the calling procedure just keep adding # characters to s until recognop fails, then check the last list # it returned to see if it is of length 1. If it is, then it # contains list with the vital stats for the operator last # recognized. If it is of length 0, then string s did not # contain any recognizable operator. # procedure recognop(l, s, i) local current_state, master_list, c, result, j static dfstn_table initial dfstn_table := table() /i := 1 # See if we've created an automaton for l already. /dfstn_table[l] := start_state(1, *l, &null, &null) & { dfstn_table[l].master_list := sortf(l, i) } current_state := dfstn_table[l] # Save master_list, as current_state will change later on. master_list := current_state.master_list s ? { while c := move(1) do { # Null means that this part of the automaton isn't # complete. # if /current_state.tbl then create_arcs(master_list, i, current_state, &pos) # If the table has been clobbered, then there are no arcs # leading out of the current state. Fail. # if current_state.tbl === 0 then fail # write(&errout, "c = ", image(c)) # write(&errout, "table for current state = ", # ximage(current_state.tbl)) # If we get to here, the current state has arcs leading # out of it. See if c is one of them. If so, make the # node to which arc c is connected the current state. # Otherwise fail. # current_state := \current_state.tbl[c] | fail } } # Return possible completions. # result := list() every j := current_state.b to current_state.e do { if *master_list[j][i] = *s then put(result, master_list[j]) } # return empty list if nothing the right length is found return result end # # create_arcs: fill out a table of arcs leading out of the current # state, and place that table in the tbl field for # current_state # procedure create_arcs(master_list, field, current_state, POS) local elem, i, first_char, old_first_char current_state.tbl := table() old_first_char := "" every elem := master_list[i := current_state.b to current_state.e][field] do { # Get the first character for the current position (note that # we're one character behind the calling routine; hence # POS-1). # first_char := elem[POS-1] | next # If we have a new first character, create a new arc out of # the current state. # if first_char ~== old_first_char then { # Store the start position for the current character. current_state.tbl[first_char] := dfstn_state(i) # Store the end position for the old character. (\current_state.tbl[old_first_char]).e := i-1 old_first_char := first_char } } (\current_state.tbl[old_first_char]).e := i # Clobber table with 0 if no arcs were added. current_state.tbl := (*current_state.tbl = 0) return current_state end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Apr 29 02:41:53 1993 Received: by cheltenham.cs.arizona.edu; Mon, 3 May 1993 05:24:59 MST Date: 29 Apr 93 02:41:53 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: OS/2 & Icon (was Lack of robustness in 32-bit DOS version) Message-Id: <1993Apr29.024153.1315@midway.uchicago.edu> References: <51238.perin@cumc.cornell.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <51238.perin@cumc.cornell.edu> perin@cumc.cornell.edu writes: > >This isn't a newsgroup for literate programming, so I won't rant on, but >since I'm on the subject allow me to raise an LP-related issue in Icon >that's nagged at me for a while. It would be much easier to debug a >literate Icon program if the language had a locution akin to the C #line >preprocessor directive... The most recent version has $line directives, apparently, and a pre- processor. So, as if by magic, your wish has been granted :-). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Apr 28 13:56:23 1993 Received: by cheltenham.cs.arizona.edu; Mon, 3 May 1993 05:25:22 MST Date: 28 Apr 93 13:56:23 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Chris Tenaglia - 257-8765) Organization: Medical College of Wisconsin (Milwaukee, WI) Subject: Re: Help! Message-Id: <01GXJCRBTCHU8WW7RY@mis.mcw.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu On Passing several variables In and several Out: Structures and globals are the methods I use. Structures are better if you have this as a widespread problem. Globals are useful in smaller cases. I use globals a lot when converting a BASIC program into ICON. ---------------------------------------------------------------------- Method 1 : Use a structure stuff := obtain(a,b,c) ... # Using a List # Using a table procedure obtain(a,b,c) or procedure obtain(a,b,c) return [x,y,z] result := table("") end result["x"] := 5*1.4 result["y"] := 22/7 result["z"] := ?25 return result end ------------------------------------------------------------------------------ Method 2. Use globals global x,y,z procedure main() ... obtain(a,b,c) end procedure obtain(a,b,c) x := 5*1.3 y := 22/7 z := ?25 end --------------------------------------------------------------------- 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Wed Apr 28 13:10:24 1993 Received: by cheltenham.cs.arizona.edu; Mon, 3 May 1993 05:25:45 MST Date: 28 Apr 93 13:10:24 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Jerry D. Nowlin) Subject: Re: Help! Message-Id: <9304281310.AA23936@iwtqg> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > erholm@CS.ColoState.EDU (scott erholm) writes: > > In Pascal, I could pass values to and from procedures in this manner: > > Procedure P (VAR x, y, z : Integer; l, m : Real); > (* procedure body *) > end; > > And the call to P would look like this: > > P (a, b, c, 10, 20); > > meaning that procedure P would get 10 and 20 for l and m, and would > pass the values of x, y, and z back to the calling program. In Icon you can pass a list into a procedure and then stuff things into it or yank things out of it and when the procedure exits the list remains modified. If you pass an empty list to a procedure you can put the x, y and z values in it and access them from the calling routine. An empty table may be more convenient if you want to access the values returned in a specific order. Finally, while an Icon procedure can only return one item, that item can be a list or table or any other Icon type. Rather than including an empty list or table in the parameter list why not just return one you constructed on the fly inside the procedure. Icon magically keeps the values in the list or table around for you until you don't need them anymore. Oh sure... you could explain it in terms of pointers and that other technical stuff but I like magic. procedure main() addem(l := [],t := table()) every write(!l | t[1 to 3] | !retem()) end procedure addem(l,t) every put(l,"new"|"list"|"items") t[1] := "and" t[2] := "table" t[3] := "values" end procedure retem() every put(l := [],"and"|"more"|"list"|"items") return l end Jerry Nowlin nowlin@iwtqg.att.com (work) isidev!nowlin@uunet.uu.net (home) From icon-group-sender Thu Apr 29 14:17:49 1993 Received: by cheltenham.cs.arizona.edu; Mon, 3 May 1993 12:47:51 MST Date: 29 Apr 93 14:17:49 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993Apr29.141749.24949@midway.uchicago.edu> References: <9304281927.AA17778@roll.csd.sgi.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu mitch@roll.csd.sgi.com (Tom Mitchell) makes some interesting comments on a posting of mine: >|does not cater to the introductory CS course regimen. Icon has, as its >|natural constituency, people interested in AI, NLP, text, translation, >|and general nonnumeric computing. > >I wonder, since Icon is implemented in 'C' it might be considered >dependent on 'C' and thus less interesting. Also given that there >is also a strong bias toward stronger type defines in ANSI 'C', >the lack of type checking in Icon could be seen as a loss >against the curriculum goals. Actually, if you think deeply about it, you'll notice that Icon has more extensive type checking than most other languages. It is a very strongly typed language. This does not mean, however, that it is statically typed. If strong/dynamic typing is seen as a deficit (and I believe you that it is), then this is very odd, since in fact a great many higher-level languages use similar schemes. The way Icon works is this: Objects of any type can be assigned to a variable. The language always knows what type data object that variable reflects at any given time. The variable, however, may be assigned a new object of any type, though. In this case, Icon still knows what type the variable is, and it knows (moreover) whether to garbage-collect the old object. Described in this way, Icon hardly differs from LISP, which is used by many CS instructors as a first programming language instead of Pascal (and rightly so, since it allows one to move rapidly into the conceptual foundations of programming). >Just in case should some one sets out to do this. An >irritant to me is little inconsistent 'features' like {} and ; >omissions where the parser can permit such things to be >omitted in one place and not in others. I am not sure what you're talking about when it comes to {}, except in the sense that {} can always be used to group a code block, just as in C. Automatic semicolon insertion is also an interesting issue. Most inveterate Icon programmers find it silly to have to insert a semicolon after every line. We mainly use the semicolon to separate two expres- sions abutted on the same line. Generally it is lacking from idiomatic Icon code, and with good reason: It is generally superfluous even in languages that force one to use it! >Sort of a summary: > >Does Icon support these goals in the first two years of a CS >education? Mostly not I suspect. What are introductory CS goals? I'd say they are: 1) getting a basic grasp of control flow, 2) learning about basic data structures, and 3) getting some hands-on, practical experience cutting code. Good stu- dents should be exposed to several styles of programming, and language paradigms. They need not actually study them (and in fact probably should not at this level), but students should have explained to them about 1) classic languages like LISP, 2) non-imperative, backtracking languages like Prolog, 3) standard data structures, control-flow, and scoping mechanisms found in Algol-family languages, and 4) object-ori- ented programming languages and/or techniques. My problem is that I had to learn all of this stuff on my own, being a humanities student. It is misery and agony trying to exist in a world where introductory programming to most people means learning about fac- toring and sorting algorithms in a cut-down language like Pascal. For a humanities student, these sorts of things are largely irrelevant, or at least not relevant at the introductory level. >What are the curriculum goals of a CS education? What are >the education goals of a non CS education. For a humanities programmer the goals are exactly the same as for a CS programmer. The only difference is that the actual content of 3 above. At least this has been my *personal* experience. >Does Icon support the CS needs of a non-CS education? I can't honestly say I know until I've had the chance to teach a few introductory humanities programming courses, which I doubt I'll get to do, seeing as my degree is in Near Eastern Languages & Civilizations :-). Interesting comments you make, though. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon May 3 22:59:19 1993 Received: by cheltenham.cs.arizona.edu; Tue, 4 May 1993 05:06:01 MST Date: Mon, 3 May 93 22:59:19 -0400 From: isidev!nowlin@uunet.uu.net Message-Id: <9305040259.AA21069@relay1.UU.NET> To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET Subject: Re: Icon as intro CS Status: R Errors-To: icon-group-errors@cs.arizona.edu > lots of stuff you can get from... > > Subject: Re: runtime debugger and the Icon fan club. > Message-Id: <1993Apr29.141749.24949@midway.uchicago.edu> > References: <9304281927.AA17778@roll.csd.sgi.com> > > >What are the curriculum goals of a CS education? What are > >the education goals of a non CS education. > > For a humanities programmer the goals are exactly the same as for a CS > programmer. The only difference is that the actual content of 3 above. > At least this has been my *personal* experience. > > >Does Icon support the CS needs of a non-CS education? > > I can't honestly say I know until I've had the chance to teach a few > introductory humanities programming courses, which I doubt I'll get to > do, seeing as my degree is in Near Eastern Languages & Civilizations :-). > > Interesting comments you make, though. I have been doing CSish stuff for a number of years now but my introduction to programming had to do with Fish stuff. I was a student in a fisheries class with gobs of red horse (a species of sucker) tissue samples to analyze for traces of pesticide and fertilizer contamination. We had trays and trays of cards punched with the data from gas chromatograph runs, and the state of the art analysis method was students with scientific calculators. Being basically a lazy person (in the best possible way :-) I took a course in FORTRAN to allow me to whip through the data. I actually liked this computer stuff, and could actually find a job with it, so it stuck. The point is, different people learn programming for different reasons. I would contend that the majority of people who could benefit from knowing how to program are NOT CS types. They are scientists in humanities or biology or agriculture or sociology - disciplines with lots of data that doesn't necessarily fit the pigeon holes provided by commercial databases and spreadsheets or even some of the scientific analysis packages available commercially. Icon makes a great language for these programmers because it does numbers and text and combinations of the two. It's simple to program on a basic (pun intended) level and once you get hooked you can do some amazing things. Once a programmer learns what a computer can do for them they can look at the other tools available and if needed add other languages to their repertoire. For non-CS programmers I can't see anything with advantages over Icon. The non-CS programmer is not as likely to be hung up on declaring all their variables or knowing how big their arrays or strings will be ahead of time or what type their data will be every time around. Icon is a "what if" kind of language. The speed of the interpreter encourages programmers to try things that languages like C or C++ make a royal pain. You get so many interesting Icon programs because the quickness of the interpreter fairly shouts "just because it works now, doesn't mean you have to quit playing with it." Only a very narrow mind looks at a bouquet of spring flowers and tries to decide which is more lovely, the tulip or the daffodil. Icon is one of the beautiful languages. It can stand alone or complement other languages in a medley of programming tools. Sorry if I run on...I love Icon and just wish everyone could see the beauty and elegance in it. --- --- | S | Iconic Software, Inc. - Jerry Nowlin - uunet!isidev!nowlin --- --- From icon-group-sender Fri Apr 30 02:31:13 1993 Received: by cheltenham.cs.arizona.edu; Tue, 4 May 1993 05:07:11 MST Date: 30 Apr 93 02:31:13 GMT From: gudeman@arizona.edu (David Gudeman) Organization: U of Arizona CS Dept, Tucson Subject: Summary: Representations of Dynamic Type Information Message-Id: <38557@optima.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Well, thanks for all of the responses. I got several new ideas, and got reminded of several things I had forgotten to include. It would be a little impractical for me to "summarize" the entire report here, since it is 26 pages long. However, there is a fairly complete draft available (at 26 pages it ought to be fairly complete :-), and if anyone is interested in reading it, it is available in compressed postscript by anonymous ftp from cs.arizona.edu in the file "/usr/ftp/janus/jc/tags.ps.Z". If anyone has trouble getting this or needs an uncompressed file, or wants the latex source, let me know. I haven't had time to discuss all of the ideas I got from the net, so I've included draft notes in the text to give a hint about these (and I've tried to credit the people who wrote me). A few of the draft notes are essentially the remainders of my outline. Since I have to go on to other work, the report is probably going to remain in this unfinished state for a while. For those who are curious, but not curious enough to read a 26-page report, here is a rough outline of the methods (this does not include all of the tricks and special cases) tagged-words (type information is in the machine word) tag fields (word is broken up into tag and data fields) tag field in high end (most-significant bits) of word use tag of all zeros for one type to avoid tagging cost negative ints get a tag of all ones, non-negative ints get a tag of all zeros use sign bit for one type use sign-bit = 0 for one type and optimize another type by giving it the tag of all ones in the high end and tagging by negation. tag field in low end of word use n-bit tags to represent pointers data aligned on n-byte boundaries this allows tagging without shifting use a tag of all zeros to avoid tagging and untagging use tags that contain only one non-zero bit to make testing faster use all zeros to optimize integer arithmetic optimize integer arithmetic by adding/subtracting tag after subtraction/addition tag field in both ends of word various combinations of tricks from the other two options partitioning by pattern (type is encoded in the representation of the value, no boxing/unboxing is done, usually words are partitioned into ranges of numbers they rep.) simple range tests to identify types segments with statically determined types (a segment is a range of numbers that can be identified by an initial field in the bit-patterns used to represent them). segments with dynamically determined types use BIBOP (table indexed by segments) to identify types identify type in the segment itself first word of segment last word of segment on a segmented architecture like the 80x86, one location has many addresses so the (machine) segment part of the address can be set to the (representation) segment of the data type being represented, and the offset can be set in such a way that any object can be in any machine segment. on machines that ignore the high bits of pointer, these bits can be used for free boxing/unboxing make everything a legal IEEE float, using the NaN bit patterns to encode all other types of data. object-pointers (untagged pointers refering to self-identifying blocks on the heap) combinations of this scheme with the tagged-word scheme descriptors (two-word data elements divided into a type word and a value word) encoding a qualifier (address+length representation of a sequence) in a descriptor encoding a cons cell in a descriptor direct representation of floats segregated type codes (type information is kept elsewhere) type information for globals kept in a global area type information for locals kept in stack frame type information kept in header of aggregate objects Thanks to Paul Tarau, Richard Fateman, Mikael Pettersson, Nick Thompson, Andrew Wright, Benjamin Goldberg, Aubrey Jaffer, Eric Benson, Marc Brandis, Kelvin Nilsen, Stavros Macrakis, Alexandr Kopilovich, Pekka Pirinen, William Griswold, David Keppel, Marc-Michael Brandis, Mark Tillotson, Richard Brooksby, cowan@magpie.linknet.com, Hintermeier Claus, Hendrik Boom, and Tim Lindholm for your help. -- David Gudeman gudeman@cs.arizona.edu From icon-group-sender Thu Apr 29 18:47:55 1993 Received: by cheltenham.cs.arizona.edu; Tue, 4 May 1993 14:34:03 MST Date: 29 Apr 93 18:47:55 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: var paramters Message-Id: <1993Apr29.184755.6046@midway.uchicago.edu> References: <9304281953.AA17496@enlil.premenos.sf.ca.us>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >From the programmer's point of view, the fact that it's a var parameter >should be obvious from reading the call site, so that I can see which >parameters are going to get cronged. ^^^^^^^^^^^^^^^^^^^^ I guess this is why I like to avoid these sorts of side-effects. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue May 4 09:32:33 1993 Received: by cheltenham.cs.arizona.edu; Tue, 4 May 1993 14:33:43 MST Date: Tue, 4 May 93 09:32:33 EDT From: motto@srdslc1.fb4.noaa.gov (Mark Otto) Message-Id: <9305041332.AA13516@srdslc1.fb4.noaa.gov.fb4.noaa.gov> To: icon-group@cs.arizona.edu Subject: Re: Is there a run time Debugger in developement? Status: R Errors-To: icon-group-errors@cs.arizona.edu Clint, Add my name to the list of people that are interested in a debugger. Sometimes I give up on icon and write in c just to get a program debugged. Wouldn't the new multi-threaded version of icon that can monitor other icon programs be a good base for a debugger? Good luck Mark Otto Census Bureau Rm 3000-4 (SRD) WASH DC 20233-4200 e-mail: motto@srdslc1.fb4.noaa.gov tel: +301-261-3627 home +301-763-3957 office fax: +301-763-2633 From icon-group-sender Thu Apr 29 19:18:22 1993 Received: by cheltenham.cs.arizona.edu; Tue, 4 May 1993 20:13:36 MST Date: 29 Apr 93 19:18:22 GMT From: att!att-out!walter!flaubert!norman@ucbvax.Berkeley.EDU (Norman Ramsey) Organization: Bellcore Subject: Re: OS/2 & Icon (was Lack of robustness in 32-bit DOS version) Message-Id: <1993Apr29.191822.6542@walter.bellcore.com> References: <51238.perin@cumc.cornell.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <51238.perin@cumc.cornell.edu> perin@cumc.cornell.edu writes: >This isn't a newsgroup for literate programming, so I won't rant on, but >since I'm on the subject allow me to raise an LP-related issue in Icon >that's nagged at me for a while. It would be much easier to debug a >literate Icon program if the language had a locution akin to the C #line >preprocessor directive, i.e. a way of identifying from where in which source >file a given chunk of code came. Icon (at least the Unix implementation thereof) does support this notation. I use the following code in noweb: notangle -L'#line %-1L "%F"%N' foo.nw > foo.icn Norman From icon-group-sender Wed May 5 03:34:42 1993 Received: by cheltenham.cs.arizona.edu; Wed, 5 May 1993 05:24:23 MST Via: uk.ac.manchester.computer-science; Wed, 5 May 1993 11:11:47 +0100 From: Steve Holden Date: Wed, 5 May 93 10:05:31 BST Message-Id: <4052.9305050905@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: Icon fan club ... Status: R Errors-To: icon-group-errors@cs.arizona.edu Richard l. Goerwitz (goer@midway.uchicago.edu) writes: > I am not sure what you're talking about when it comes to {}, except in > the sense that {} can always be used to group a code block, just as in > C. Automatic semicolon insertion is also an interesting issue. Most > inveterate Icon programmers find it silly to have to insert a semicolon > after every line. We mainly use the semicolon to separate two expres- > sions abutted on the same line. Generally it is lacking from idiomatic > Icon code, and with good reason: It is generally superfluous even in > languages that force one to use it! Personally my only problem with the {} braces is that I can't make declarations inside the code blocks they enbrace. This tends to clutter up the larger procedures with declarations for locals which are only used with limited scope. Not knowing the guts of the systems I'm not sure how easy it would be to alter Icon's syntax and semantics. Would this be a reasonable request for enhancement? regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Wed May 5 03:34:50 1993 Received: by cheltenham.cs.arizona.edu; Wed, 5 May 1993 05:25:40 MST Via: uk.ac.manchester.computer-science; Wed, 5 May 1993 11:12:08 +0100 From: Steve Holden Date: Wed, 5 May 93 11:04:23 BST Message-Id: <4206.9305051004@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: More Icon Applications Status: R Errors-To: icon-group-errors@cs.arizona.edu Sorry about this late posting. You didn't see it a week ago due to a combination of foul-ups and e-mail problems. Since I consider myself quite a serious (if not sophisticated) Icon user I'd like the group to know that at least one person uses very little else... Following Chris Tenaglia's (tenaglia@mis.mcw.edu) posting, I am also working on a number of applications in Icon. Most of them haven't yet seen the light of day, but I intend that they should. Application: mail2fm Purpose: Takes e-mail folders and produces FrameMaker hypertext documents from them, with hypertext indexing by date, subject and sender. Application: rmaker Purpose: Parses FrameMaker documents and allows the merging of data (typically, but not necessarily, from a database) with the document's contents. There are also a few day-to-day utilities which haven't yet seen the light of day becuase they were written when I was new to Icoin, so the style may be somewhat unedifying. Application: mailtrim Purpose: Trims out unnecessary cr*p from mail files - if you've ever wanted to leave your e-mail with only "To:", "From:", "Subject:" and "Date:" this will do it for you. Application: fields Purpose: Allows selection of fields by number or name (assumes when names are used that the first line contains field names which are echoed to the output file). Application: mc Purpose: Works like "wc" but reports headers & body lines for mail folders (oh yes, # messages too). Application: getmail Purpose: Selects mail items from folders by number, allowing extraction of any number of items from a folder. Application: print Purpose: Converts text files to PostScript for printing, wrapping long lines round and right-justifying continuations, and keeping blocks of text separated by whitespace together. Library: mlib Purpose: Offers routines for reading and writing mail folders. Headers are parsed and the body is presented as a list of text lines while the headers are a table of lists index by keyword. Library: dates Purpose: Offers rather "brute-force" routined for parsing dates, returning a structure with all componenets present in the date non-null. Like Chris, I regard some of these as production-quality software (dammit, I haven't touched the sources of some of them for at least a week, now :-), I have no axe to grind about making Icon commercial, but I really agree with whoever suggested Icon was a _great_ prototyping language. The more I use it, the less I feel like rewriting the prototypes. regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Wed Apr 28 22:07:34 1993 Received: by cheltenham.cs.arizona.edu; Wed, 5 May 1993 05:23:54 MST Date: 28 Apr 93 22:07:34 GMT From: pipex!warwick!qmw-dcs!qmw!demon!cix.compulink.co.uk!pmoore@uunet.uu.net (Paul Moore) Subject: Re: "Find that Niche!" contest? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Jan de Ruiter writes: > The unique thing of Icon (IMHO, of course) is that it > reduces development time so drastically that it actually > pays to use it, even when the performance is > interpreter-like. Interestingly enough, this relates to my experiences. The important thing about Icon is that it is about string processing. Huge amounts of the time people spend using computers involves string processing, so any language which makes this easy, tends to win in the "quick program" department. (For bigger projects, other considerations come into play, such as ease of reuse, configuration management, etc) Now, I have access to both perl and Icon. Both are good for quick string hacking programs. Perl is 100% interpreted, and so the cycle is "type the program in, run it, work out what went wrong, fix & rerun ...". With Icon, where there is a compile stage, the cycle, while similar, FEELS more like "write a program, test it, fix errors, and once working, run it for real". That is, perl programs tend to converge on the behaviour you want (and may never get there - you may stop when you have something "good enough"), whereas Icon programs are designed to do what you want, and debugged until they work. This is more opinion/psychology than hard fact, but perhaps it explains why I use perl more than Icon - I think I can get away with a quick hack, until it is too late and I realise I should have designed more carefully from the start. On the other hand, it does mean that I tend to use Icon when I want something that *works*. Not faults of the language(s), [of course, you can write well designed perl code - all I am saying is that *I* don't, often...] but definitely different "flavours" to them... Just my penny worth, Gustav (pmoore@cix.compulink.co.uk) From icon-group-sender Wed May 5 09:29:12 1993 Received: by cheltenham.cs.arizona.edu; Wed, 5 May 1993 12:36:08 MST Date: Wed, 5 May 1993 09:29:12 MST From: att!ihlpf!pax Message-Id: <199305051629.AA28201@univers.cs.arizona.edu> To: icon-group@cs.arizona.edu Subject: debugger Status: R Errors-To: icon-group-errors@cs.arizona.edu Clint, Since moving to Icon from SNOBOL, SNOBOL3 and SNOBOL4 I have often missed the extensive tracing facities available in at least SNOBOL3 and SNOBOL4. Just having the equivalent stuff in Icon would be super. jth From icon-group-sender Fri Apr 30 19:02:03 1993 Received: by cheltenham.cs.arizona.edu; Thu, 6 May 1993 16:50:48 MST Date: 30 Apr 93 19:02:03 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!emory!sol.ctr.columbia.edu!src.honeywell.com!skyler.mavd.honeywell.com!djbailey@ucbvax.Berkeley.EDU Organization: Honeywell Systems & Research Center Subject: Re: Is this passable code? Message-Id: <1993Apr30.130203.1@skyler.mavd.honeywell.com> References: <9304260508.AA21290@internal.apple.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9304260508.AA21290@internal.apple.com>, nevin@apple.com (Nevin ":-]" Liber) writes: > > procedure Permute(sString) > > local iPos > > if 0 = *sString then return sString > > suspend sString[iPos := 1 to *sString] || > Permute(sString[1:iPos] || sString[iPos+1:0]) > > end > Ok, I understand it's a generator. I understand it's recursive. I understand it works because I have run it and traced it. I don't understand why it works or how you thought of the design. Please explain. -- Don J. Bailey From icon-group-sender Fri May 7 09:44:23 1993 Received: by cheltenham.cs.arizona.edu; Fri, 7 May 1993 11:40:17 MST Date: 07 May 1993 09:44:23 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Handy Icon Utility To: icon-group@cs.arizona.edu Message-Id: <01GXW15C1RDS8WW2LB@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu Anyone interested in some small useful iconware? Here's one we use here a lot. It's called slave, for slave printer. It allows users to print files to slave printers directly attached to PCs, MACs, and Terminals running VT/Ansi screen modes. It works as both a utility and filter. Usage : slave file slave From: Ken Walker Subject: Re: Is this passable code? To: icon-group@cs.arizona.edu Date: Fri, 7 May 93 8:15:04 PDT In-Reply-To: <1993Apr30.130203.1@skyler.mavd.honeywell.com>; from "sol.ctr.columbiaicon-group@cs.arizona.edu" at Apr 30, 93 7:02 pm Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Don J. Bailey writes: > > In article <9304260508.AA21290@internal.apple.com>, nevin@apple.com (Nevin ":-]" Liber) writes: > > > > procedure Permute(sString) > ... > > Ok, I understand it's a generator. I understand it's recursive. > I understand it works because I have run it and traced it. I don't > understand why it works or how you thought of the design. Here is a permutation procedure that produces a set of permutations. It is not as neat as Nevin's recursive generator, but is perhaps a little easier to follow. Once you understand it, it may be easier to understand Nevin's code; just think of a generator as returning elements of a set, one at a time. # permutations - return the set of all permuation of the characters in s procedure permutations(s) local p, pi, i if *s <= 1 then return set([s]) # Choose each character in turn and concatenate it on the front of each # of the permutations of the remaining characters. p := set() every i := 1 to *s do { pi := permutations(s[1:i] || s[i+1:0]) every insert(p, s[i] || !pi) } return p end Ken Walker kwalker@premenos.sf.cs.us From icon-group-sender Fri Apr 23 17:09:15 1993 Received: by cheltenham.cs.arizona.edu; Fri, 7 May 1993 11:41:19 MST Date: 23 Apr 93 17:09:15 GMT From: agate!howland.reston.ans.net!ira.uka.de!math.fu-berlin.de!easix!flyer!larry!ms.open.de!hugo!gb@ucbvax.Berkeley.EDU (Georg Bauer) Organization: Hugos Box of (Mail)-Horror Subject: runtime debugger Message-Id: <735584955snx@hugo.ms.open.de> References: <1r3k5p$9dp@access.digex.net> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi! In article <1r3k5p$9dp@access.digex.net> prb@access.digex.com writes: > >A run-time debugger, with a functionality like dbx (text-mode) > Text Mode? I was thinking GUI based interface, myself. > dbx is nice, but run under suntools, it's awesome. There are lots of users of the DOS-Version of Icon (at least I know 2 ;-) ) - so I think a text-mode debugger for the start would be nice. A graphics interface could be given as an option - like the program visualization. Would it be possible to build a debugger on top of the multithreaded Icon? bye, Georg --- Georg Bauer /// Martin-Niemoeller-Strasse 21 /// D-W4400 Muenster /// Germany short mail to : gb@st2.maus.de (please only mail < 48 KB) long mail to : gb@hugo.ms.open.de "It's alive commander - but not as we know it" From icon-group-sender Fri May 7 20:55:51 1993 Received: by cheltenham.cs.arizona.edu; Sat, 8 May 1993 05:49:45 MST Date: 7 May 93 20:55:51 GMT From: uchinews!ellis!goer@migs.ucar.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993May7.205551.1831@midway.uchicago.edu> References: <9304281927.AA17778@roll.csd.sgi.com>, <1993Apr29.141749.24949@midway.uchicago.edu>, <1993May7.182643.26824@netlabs.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu lwall@netlabs.com (Larry Wall) writes: > >: [Icon programmers] mainly use the semicolon to separate two expres- >: sions abutted on the same line. Generally it is lacking from idiomatic >: Icon code, and with good reason: It is generally superfluous even in >: languages that force one to use it! > >Not to contradict a valid assertion, but as a point of interest it's >not superfluous in Perl, since it switches the lexer from expecting an >operator to expecting a term, just as any other operator would. So, for example, if we see INTEGER 1, then OP '*', then INTEGER 1, if we then see a ';' the lexer knows that the next thing is not going to be an operator? Maybe I'm not understanding, but wouldn't a newline accom- plish the same thing? 1 * 1; 2 * 2... vs. 1 * 1 2 * 2... Let's suppose I have a prefix operator '*' - the same string as the binary, right associative multiplication operator. Will there be any problem inserting semicolons? Not normally. The third example below might pose a problem if we are simply *omitting* newlines and semicolons. But the Icon tokenizer does not omit semicolons. It inserts one if the end of every line that happens to coincide with the end of an expression: 1) a * b * c 2) a * * b 3) a * b * a * b The natural way our eyes group 3 is the way Icon's tokenizer groups it, too. The only problem with this method of handling semicolons is that you have to be careful not to break up expressions in such a way that the first part could be an expression. For example if you want to say "a * b * c", then the following isn't a valid way of expressing this in using an Icon like system of semicolon insertion: 4) a * b * b (4) is, of course, terrible programming style, if a * b * c is intended. Occasionally, an Icon beginner (i.e. someone who doesn't yet have a feel for what Icon expressions should look like) will make mistakes like (4). These, however, are quickly remedied. I can't recall grouping something wrong in this way for over five years (and I've used Icon for less than six years, I think). Bottom line: Icon doesn't omit semicolons. Rather it inserts them ac- cording to a simple algorithm that lets the user pretty much forget about inserting them him or herself. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri May 7 21:01:18 1993 Received: by cheltenham.cs.arizona.edu; Sat, 8 May 1993 05:50:05 MST Date: 7 May 93 21:01:18 GMT From: agate!howland.reston.ans.net!usc!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993May7.210118.2214@midway.uchicago.edu> References: <1993Apr29.141749.24949@midway.uchicago.edu>, <1993May7.182643.26824@netlabs.com>, <1993May7.205551.1831@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu goer@midway.uchicago.edu writes: > >Let's suppose I have a prefix operator '*' - the same string as the binary, >right associative multiplication operator.... ^^^^ I was trying to be so careful to make my posting understandable to people who haven't ever designed a lexical analyzer, and then I go about mixing left with right... :-). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon May 3 19:18:52 1993 Received: by cheltenham.cs.arizona.edu; Sat, 8 May 1993 11:35:14 MST Date: 3 May 93 19:18:52 GMT From: walter!flaubert!norman@uunet.uu.net (Norman Ramsey) Organization: Bellcore Subject: Intro to Icon Message-Id: <1993May3.191852.19708@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm going to give my organization a one-hour talk on Icon, with an emphasis on using Icon to build prototypes quickly. Does anyone have any suggestions (or religious beliefs) about what should be included in such a talk? Does anyone have a favorite code fragment? My audience is composed of researchers who are proficient Unix hackers, so I don't have to pull any punches :-) Norman -- Norman Ramsey norman@bellcore.com From icon-group-sender Tue May 4 02:22:48 1993 Received: by cheltenham.cs.arizona.edu; Sun, 9 May 1993 05:54:16 MST Date: 4 May 93 02:22:48 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Intro to Icon Message-Id: <1993May4.022248.20092@midway.uchicago.edu> References: <1993May3.191852.19708@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu norman@flaubert.bellcore.com (Norman Ramsey) writes: > >I'm going to give my organization a one-hour talk on Icon, with an >emphasis on using Icon to build prototypes quickly. Does anyone have >any suggestions (or religious beliefs) about what should be included >in such a talk? Yeah. Two things: 1) Explain to them right away that Icon yields elegant solutions for poking at the conceptual foundations of programming, and for doing general nonnumeric computing. It's not what you use for mundane system administration problems on a specific plat- form. 2) Start them right away on goal-directed evaluation and on string scanning. Show them its elegance. If you start on basic data structures and syntax, they'll think it's a cut-down Pascal, & miss the whole point. Please tell us how it goes, and if you have any text that comes with your presentation, please let us know! -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue May 4 03:01:03 1993 Received: by cheltenham.cs.arizona.edu; Sun, 9 May 1993 05:55:12 MST Date: 4 May 93 03:01:03 GMT From: portal!cup.portal.com!Eric-Amick@uunet.uu.net (Richard E Amick) Organization: The Portal System (TM) Subject: Re: Is this passable code? Message-Id: <80791@cup.portal.com> References: <9304260508.AA21290@internal.apple.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >>I started using Icon recently, and am impressed with the >>power of the language. But, since i'm learning on my own and >>don't have experience with Icon, i don't know if i'm doing >>things right. Recently i wrote a short program to find >>anagrams (yeah...) using the unix dictionary. I'd appreciate >>any comments/suggestions/flames, etc about my programming >>style and the Icon way. > >I did think of a different (simpler, I believe) way of implementing the >anagram algorithm, using sets. I don't know if it's better or worse, but >it does illustrate my particular style for programming in Icon. Here it >is, along with an explanation of some of my stylistic choices: > > ># look up anagrams of all the command line arguments in /usr/dict/words > > >procedure main(LArguments) > >local SAnagrams >local fWords >local sWord > >SAnagrams := set() > >every insert(SAnagrams, Permute(map(!LArguments))) > >fWords := open("/usr/dict/words") | > stop("Cannot open /usr/dict/words for reading; aborting.") > >while sWord := read(fWords) do { > if member(SAnagrams, map(sWord)) then write(sWord) >} > >close(fWords) > > >end > > >procedure Permute(sString) > >local iPos > >if 0 = *sString then return sString > >suspend sString[iPos := 1 to *sString] || > Permute(sString[1:iPos] || sString[iPos+1:0]) > >end > > > [Lots of commentary about code deleted.] >Variations on this algorithm: There are 24259 words in /usr/dict/words on >my Unix machine. If I was expecting to process many words with 8 or more >unique letters (8! = 40320 permutations), I would have approached this a >little differently. I would have read /usr/dict/words into a set (or a >table, if I thought that preserving case was important), and do something >like [note: if you want to preserve case, it's actually a little harder >than this. The algorithm below ignores words in /usr/dict/words that only >differ by case, and it probably shouldn't]: > > > >procedure main(LArguments) > >local TWords >local fWords >local sWord > >TWords := table() > >fWords := open("/usr/dict/words") | > stop("Cannot open /usr/dict/words for reading; aborting.") > >while sWord := read(fWords) do TWords[map(sWord)] := sWord > >close(fWords) > > >every write(\TWords[Permute(map(!LArguments))]) > >end > > > >I would probably even come up with a heuristic that analyses LArguments and >determines which of the two above variations to call to do the work. > > >I hope this is what you were looking for. I can't believe I wrote this >much on a 20 line algorithm. :-) Comments are appreciated. Allow me to propose a combination of the two which just might be faster. Since virtually all of the permutations generated will not match anything, perhaps you should consider the basic principle of anagrams: all the letters are present in both, just in a different order. If we put the letters of a word in a standard order, say, sorted alphabetically, then the comparison will go much faster; surely sorting is less work than generating 40,000 permutations. (Considering that 10-letter words produce about 4,000,000 permutations, this is a very reasonable idea.) Build your table as before, but make the sorted letters the key and the set of words with the same key the data associated with it. I'm still in the novice stage with Icon myself, so I'll let someone else do the coding. :-) (The algorithm comes from the book "Programming Pearls" by Jon Bentley, much as I wish I had thought of it myself.) >___ >NEVIN ":-)" LIBER, Blue Meanie, Macintosh System Software > email: nevin@apple.com paper: Apple Computer, Inc. > voice: (408) 974-MIX1 2 Infinite Loop, MS: 302-4Q > AppleLink: BADENOV Cupertino, CA 95014 From icon-group-sender Tue May 4 15:08:10 1993 Received: by cheltenham.cs.arizona.edu; Sun, 9 May 1993 17:17:33 MST Date: 4 May 93 15:08:10 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!zaphod.axion.bt.co.uk!nemesis.muppet.bt.co.uk!bealfeirste!jmd@ucbvax (John Downey) Organization: BT Subject: Is there a FAQ list for this group? Message-Id: <1s60sq$1a6k206@nemesis.muppet.bt.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Pardon my ignorance, but I couldn't see a FAQ list either here or in news.answers. Is there one anywhere else? Regards, John Downey Mail: jmd_@cix.compulink.co.uk Paper mail: 55a Sutherland Sq., London SE17, England Telephone: (UK) 071 708 1299 (international) +44 71 708 1299 From icon-group-sender Tue May 4 22:33:18 1993 Received: by cheltenham.cs.arizona.edu; Mon, 10 May 1993 05:34:08 MST Date: 4 May 93 22:33:18 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!cs.umd.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Is there a FAQ list for this group? Message-Id: <1993May4.223318.5648@midway.uchicago.edu> References: <1s60sq$1a6k206@nemesis.muppet.bt.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu jmd_@cix.compulink.co.uk writes: >Pardon my ignorance, but I couldn't see a FAQ list either here or in >news.answers. Is there one anywhere else? The traffic here is quite moderate, and so we've never felt the need to post a FAQ. We get "what is Icon" queries come in from time to time, and some one or another of us invariably takes the time to answer. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon May 10 07:41:56 1993 Received: by cheltenham.cs.arizona.edu; Mon, 10 May 1993 07:39:56 MST Date: 10 May 1993 07:41:56 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Icon Tips To: icon-group@cs.arizona.edu Message-Id: <01GY03I039EA8WW3GW@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu From: IN%"MAILER-DAEMON@watserv1.uwaterloo.ca" "Mail Delivery Subsystem" 9-MAY-1993 00:06:16.42 To: IN%"walter!xenitec!spectre.uunet.ca!mis.mcw.edu!tenaglia@watserv1.uwaterloo.ca" Subj: Returned mail: Service unavailable > I'm going to give my organization a one-hour talk on Icon, with an > emphasis on using Icon to build prototypes quickly. Does anyone have > any suggestions (or religious beliefs) about what should be included > in such a talk? Does anyone have a favorite code fragment? My > audience is composed of researchers who are proficient Unix hackers, > so I don't have to pull any punches :-) > Norman Ramsey > norman@bellcore.com I like Richard Goerwitz points about the novelty of the language and how it pushes programming paradigms. I also think speed of development and prototyping are another super point. I gave a 1 hour talk on it at a DECUS symposium in Las Vegas in December. I'm not accustomed to speaking so I think I was rather boring, but the crowd was interested, and that helped. The only questions I got afterword were 'how do I get this for my system?'. I think my overheads were pretty good. I brought 20 paper copies of them, and they nearly all disappeared at the Languages and Tools campground. Good luck on your endeavor. Here are my favorite fragments : I call | the either-or operator. One use might be like: (out := open("OUT.DAT","a") | #either open for append (out := open("OUT.DAT","w") | #or for write/create stop("Can't write to OUT") #or flag the error I call &random "amper-random" and other variables that begin with &, amper variables. This helps when speaking about the language without visual aids. The icon project hasn't said to much about this idea, but I use it, maybe because the FOCUS language also used around here has amper variables too, so it's a little more familiar. # # parse a string into a list with respect to a delimiter # procedure parse(line,delims) # 1p static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end # # prompt for an input string # procedure input(prompt) # 2p writes(prompt) return read() end # # converts a linear list into columnated format (like unix ls) # procedure cook(lst,cols,width) # 3p local limit,size,array,meal,food,i,j,row,column /cols := 5 ; /width := 80 items := *lst ; size := width / cols rows := items / cols + 1 ; limit := rows * cols array := table(" ") ; meal := [] until *lst > limit do put(lst," ") # push for reverse order every column := 1 to cols do every row := 1 to rows do array[row||","||column] := pop(lst) # pull for reverse order every row := 1 to rows do { food := "" every column := 1 to cols do food ||:= left(array[row||","||column],size) put(meal,trim(food)) } return meal end # # ebcdic/ascii mapping string # ebcdic := "\000\001\002\003\234\011\206\177\227\215\216\013\014\015\016\017"|| "\020\021\022\023\235\205\010\207\030\031\222\217\034\035\036\037"|| "\200\201\202\203\204\012\027\033\210\211\212\213\214\005\006\007"|| "\220\221\026\223\224\225\226\004\230\231\232\233\024\025\236\032"|| "\040\240\241\242\243\244\245\246\247\250\133\056\074\050\053\041"|| "\046\251\252\253\254\255\256\257\260\261\135\044\052\051\073\136"|| "\055\057\262\263\264\265\266\267\270\271\174\054\045\137\076\077"|| "\272\273\274\275\276\277\300\301\302\140\072\043\100\047\075\042"|| "\303\141\142\143\144\145\146\147\150\151\304\305\306\307\310\311"|| "\312\152\153\154\155\156\157\160\161\162\313\314\315\316\317\320"|| "\321\176\163\164\165\166\167\170\171\172\322\323\324\325\326\327"|| "\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347"|| "\173\101\102\103\104\105\106\107\110\111\350\351\352\353\354\355"|| "\175\112\113\114\115\116\117\120\121\122\356\357\360\361\362\363"|| "\134\237\123\124\125\126\127\130\131\132\364\365\366\367\370\371"|| "\060\061\062\063\064\065\066\067\070\071\372\373\374\375\376\377" # # formats a input string into an output string using a control string # patch("120389","##/##/19##") returns 12/03/1989 # patch("12/03/1989","##$") returns 12 # procedure edit(var,mask) # 9p uses string scanning text := "" var ? { every chr := !mask do { case chr of { "#" : text ||:= move(1) "$" : move(1) default : text ||:= chr } } } return text end # # THIS ROUTINE SETS THE CURSOR TO A GIVEN X (COL) Y(ROW) SCREEN LOCATION # procedure at(x,y) # 11p return "\e[" || y || ";" || x || "f" end # # # FILE : PROGRAM.ICN # DESC : GENERIC PROGRAM STARTER # # UPDATE BY WHAT # # procedure main(param) source := param[1] | input("_Source:") target := param[2] | input("_Target:") (in := open(source)) | stop("Can't open ",source) (out := open(target,"w")) | stop("Can't open ",target) while line := read(in) do { } close(in) ; close(out) end 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Sat May 8 15:30:05 1993 Received: by cheltenham.cs.arizona.edu; Mon, 10 May 1993 12:19:58 MST Date: 8 May 93 15:30:05 GMT From: agate!howland.reston.ans.net!ira.uka.de!sbusol.rz.uni-sb.de!coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman@ucbvax.Berkeley.EDU (Stephen P Spackman) Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken Subject: Re: runtime debugger and the Icon fan club. Message-Id: References: <9304281927.AA17778@roll.csd.sgi.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May7.205551.1831@midway.uchicago.edu> goer@ellis.uchicago.edu (Richard L. Goerwitz) writes: | 4) a * b | * b | | (4) is, of course, terrible programming style, if a * b * c is intended. I think the only reason you say this is that you are used to Icon. In Algol68 this was the preferred method, and indeed the Gnu C formatting standard follows this venerable tradition. The idea is that this: ( a * broof * cl ) is much clearer than this: ( a * broof * cli ) because the related operators line up neatly and are suitably prominent (at the cost of an extra line when something is parenthesised, of course). (This isn't the optimal strategy for C, because it chooses to make ; a statement *terminator* rather than a *separator* as God intended - in that if it is a separator it has the clear semantics of a binary operator that discards its left argument, while if it's a terminator it isn't really clear what, if anything, it _means_ - but then that goes along with the strange decision in C to reintroduce a distinction between statements and void-expressions. That is, you'd really like this to work too: { something ; something else ; another something } but it doesn't because C goes and demands an extra semicolon at the end. C's a mess.) ---------------------------------------------------------------------- stephen p spackman +49 681 302 5288(o) 5282(sec) stephen@acm.org dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany ---------------------------------------------------------------------- [p.s. I'm an infrequent visitor to comp.lang.icon. If you want to take issue, best to email as well.] From icon-group-sender Sun May 9 06:17:47 1993 Received: by cheltenham.cs.arizona.edu; Mon, 10 May 1993 12:20:36 MST Date: 9 May 93 06:17:47 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993May9.061747.2214@midway.uchicago.edu> References: <1993May7.182643.26824@netlabs.com>, <1993May7.205551.1831@midway.uchicago.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu stephen@acm.org writes: > >| 4) a * b >| * b >| >| (4) is, of course, terrible programming style, if a * b * c is intended. > >I think the only reason you say this is that you are used to Icon. Maybe. Think of it in intuitive terms, though. You want the ends of your expressions to coincide with the ends of lines in many cases. In those cases where you want to spread an expression across more than one line, you want to end nonfinal lines with a token that could not end an expression. Anyone having any familiarity with the language will immediately understand what is going on. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon May 10 23:34:34 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 06:08:56 MST Date: Mon, 10 May 93 23:34:34 PDT Message-Id: <9305110634.AA11851@internal.apple.com> To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin ":-]" Liber) X-Sender: nevin@130.43.2.2 Subject: Re: runtime debugger and the Icon fan club. Cc: stephen@acm.org (Stephen P Spackman) Status: R Errors-To: icon-group-errors@cs.arizona.edu Stephen Spackman (stephen@acm.org) writes: >I think the only reason you say this is that you are used to Icon. In >Algol68 this was the preferred method, and indeed the Gnu C formatting >standard follows this venerable tradition. The idea is that this: > > ( a > * broof > * cl > ) > >is much clearer than this: > > ( a * > broof * > cli ) I disagree. At first glance, I and most other C programmers would interpret the expression "* broof" as a dereference of the pointer broof. I would have to go back and find the type of broof (and that might require going through many headers full of typedefs) before I'd be sure of what was intended here. >(This isn't the optimal strategy for C, because it chooses to >make ; a statement *terminator* rather than a *separator* as God >intended I beleive that HCI (human computer interface) folks have done studies that show that it is easier for programmers to have semicolons as terminators than as seperators. I've always found that it always takes a little effort in Pascal (where semicolons are seperators) to determine whether or not a semicolon is even allowed in certain situations (you have to always think about what it MEANS), where in C it is almost a no-brainer (you are allowed to put them after any statement without changing the semantics of the code you are writing). In Icon it is a no-brainer since in practice I've never actually had occasion to use one. >That is, you'd really like this to work too: > > { something > ; something else > ; another something > } > >but it doesn't because C goes and demands an extra semicolon at the >end. C's a mess.) I've written a lot of C (and even some Pascal/Modula 2) code in my time, and I've never wanted to write code like this (although ANSI C does have some annoying things like allowing an extra comma at the end of a structure initialisation list, but disallowing it at the end of an enumeration list, but I digress). The only time I've ever needed to remotely do something like this was for an MPW (Macintosh Programmer's Workshop -- a development environment for Macintosh) script I was writing which needed to call a different tool (StreamEdit, for those who might care) on itself from within the script (StreamEdit considers semicolon as a comment character), but this was only to make up for deficiencies in the scripting language (no "here" documents, for those people familiar with Unix shells). It certainly isn't the norm, and would need a very good reason before it could pass even a simple code review. ___ NEVIN ":-)" LIBER, Blue Meanie, Macintosh System Software email: nevin@apple.com paper: Apple Computer, Inc. voice: (408) 974-MIX1 2 Infinite Loop, MS: 302-4Q AppleLink: BADENOV Cupertino, CA 95014 From icon-group-sender Mon May 10 16:03:02 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 10:22:43 MST Date: 10 May 93 16:03:02 GMT From: dog.ee.lbl.gov!network.ucsd.edu!news.cerf.net!netlabs!lwall@ucbvax.Berkeley.EDU (Larry Wall) Organization: NetLabs, Inc. Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993May10.160302.6574@netlabs.com> References: <1993Apr29.141749.24949@midway.uchicago.edu>, <1993May7.182643.26824@netlabs.com>, <1993May7.205551.1831@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May7.205551.1831@midway.uchicago.edu> goer@midway.uchicago.edu writes: : lwall@netlabs.com (Larry Wall) writes: : > : >: [Icon programmers] mainly use the semicolon to separate two expres- : >: sions abutted on the same line. Generally it is lacking from idiomatic : >: Icon code, and with good reason: It is generally superfluous even in : >: languages that force one to use it! : > : >Not to contradict a valid assertion, but as a point of interest it's : >not superfluous in Perl, since it switches the lexer from expecting an : >operator to expecting a term, just as any other operator would. : : So, for example, if we see INTEGER 1, then OP '*', then INTEGER 1, if : we then see a ';' the lexer knows that the next thing is not going to be an : operator? Maybe I'm not understanding, but wouldn't a newline accom- : plish the same thing? : : 1 * 1; : 2 * 2... : : vs. : : 1 * 1 : 2 * 2... Certainly, if you're willing to place that kind of syntactic load on a newline. I don't happen to be, probably for irrational reasons--I once got a bad taste in my mouth from the way awk does it. I much prefer that a newline character be treated (by default) as nothing more than a funny-looking space character, in the tradition of so-called "free-form" languages. Only in the explicitly line-oriented constructs of Perl (here-docs and formats) are newlines syntactically different from spaces. Hmm, looking back at that last paragraph I wrote, I only see one period at the end of a line, and that one, being at the end of a paragraph, is superfluous... :-) Larry From icon-group-sender Tue May 11 12:50:01 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 18:34:52 MST Via: uk.ac.manchester.computer-science; Tue, 11 May 1993 17:10:46 +0100 From: Steve Holden Date: Tue, 11 May 93 16:33:40 BST Message-Id: <8351.9305111533@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: Icon Fan Club... Status: R Errors-To: icon-group-errors@cs.arizona.edu NEVIN ":-)" LIBER (nevin@apple.com) writes, in response to an earlier mail... > >That is, you'd really like this to work too: > > > > { something > > ; something else > > ; another something > > } > > > >but it doesn't because C goes and demands an extra semicolon at the > >end. C's a mess.) > > I've written a lot of C (and even some Pascal/Modula 2) code in my time, > and I've never wanted to write code like this and neither have I. I always assumed people wrote their code this way to make it easier to insert and delete statements as units. While there may have been some justification for that in the days of unit- record equipment (I presume other members of this group beside myself have had the joys of programming on IBM 026 and 029 card punches, now there was a machine, but I digress...) this is the 1990's. If mouse-based editing isn't flexible enough to cope with your needs, why not simply (?) use a structured editor with a knowledge of your particular programming language? Without wishing to enter or start a C v Algol 68 debate, I agree that Algol 68 was an elegant language while C might not be. However, most implementations made you do something stupid liek stropping keywords (eg 'BEGIN'), just for the elegance of being able to declare variables spelt the same. I'm a pragmatist, and I'm happy to put up with reserved words in a language if it means I can turn (churn?) out reasonable code, comprehensibly, in quick time. And that's why I like Icon! regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Wed May 5 09:05:31 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 18:35:17 MST Date: 5 May 93 09:05:31 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Steve Holden) Subject: Re: Icon fan club ... Message-Id: <4052.9305050905@desktop.desktop.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Richard l. Goerwitz (goer@midway.uchicago.edu) writes: > I am not sure what you're talking about when it comes to {}, except in > the sense that {} can always be used to group a code block, just as in > C. Automatic semicolon insertion is also an interesting issue. Most > inveterate Icon programmers find it silly to have to insert a semicolon > after every line. We mainly use the semicolon to separate two expres- > sions abutted on the same line. Generally it is lacking from idiomatic > Icon code, and with good reason: It is generally superfluous even in > languages that force one to use it! Personally my only problem with the {} braces is that I can't make declarations inside the code blocks they enbrace. This tends to clutter up the larger procedures with declarations for locals which are only used with limited scope. Not knowing the guts of the systems I'm not sure how easy it would be to alter Icon's syntax and semantics. Would this be a reasonable request for enhancement? regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Mon May 10 18:16:58 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 18:40:11 MST Date: 10 May 93 18:16:58 GMT From: dog.ee.lbl.gov!network.ucsd.edu!usc!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: runtime debugger and the Icon fan club. Message-Id: <1993May10.181658.3966@midway.uchicago.edu> References: <1993May7.182643.26824@netlabs.com>, <1993May7.205551.1831@midway.uchicago.edu>, <1993May10.160302.6574@netlabs.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu lwall@netlabs.com (Larry Wall) writes: > >Hmm, looking back at that last paragraph I wrote, I only see one period >at the end of a line, and that one, being at the end of a paragraph, is >superfluous... :-) But your sentences don't generally coincide with the end of a line. If they did, then you might dispense with the period as a mandatory sentence- marker. The implementation of the Icon tokenizer is a curious, but conceptually very simple piece of work. Tokens are classified as beginners or enders or neither. If a line ends with an ender, and the next line begins with a beginner, a newline is emitted. I've written countless lines of Icon code by now, and a good deal of C as well. Both systems have their good points and their bad points, I guess. The bottom line is that the auto- matic insertion regime is much more pleasing and much simpler to imple- ment than is usually supposed. Try it on for size for a while. I'll bet you'll see some redeeming fea- tures. If most semicolons coincide with line breaks, and if continued expressions are best written so that each line ends in something that obviously requires a continuation, then there is (in point of fact) not much need for semicolons. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu May 6 10:22:43 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 21:03:24 MST Date: 6 May 93 10:22:43 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!sdd.hp.com!sgiblab!munnari.oz.au!cs.mu.OZ.AU!mundoe!foda@ucbvax.Berkeley.EDU (Omar Foda) Organization: Computer Science, University of Melbourne, Australia Subject: icon in genetic programming Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hello, I am vaguely familiar with icon: I still do not have the book, but I would still like to pose the following question: I am interested in genetic programming a la Koza. Koza's pioneering code was written in lisp, basically because a lisp program is its own parse tree: in other words, the parse tree is available to the programmer to 'genetically manipulate'. I would like to do the same thing, at the level of Mathematica functions which can also be written consistently in terms of binary trees: I wish to produce the best possible solution to a Mathematical problem in terms of a function that can be evaluated by Mathematica. The starting point would be a population of randomly generated, but syntactically correct composite Mathematica functions. These will have to be cross-bred, mutated, etc. in such a way that the resulting functions are also correct functions. This will require extensive pattern scanning, substitution, exchanging, etc. something that can be done in Mathematica, but extremely slowly. I can probably do that also in awk. My question is: is that something that can be easily done in icon? More interestingly for me: are there others who are busy with similar problems? Thank you in advance, Omar Foda. From icon-group-sender Tue May 11 20:58:15 1993 Received: by cheltenham.cs.arizona.edu; Tue, 11 May 1993 21:03:58 MST Date: Tue, 11 May 1993 20:58:15 MST From: "Clint Jeffery" Message-Id: <199305120358.AA17912@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu In-Reply-To: (Steve Holden's message of 5 May 93 09:05:31 GMT <4052.9305050905@desktop.desktop.co.uk> Subject: Icon improvements ... Status: R Errors-To: icon-group-errors@cs.arizona.edu Steve Holden writes that he wants to be able to declare local variables inside any pair of {} braces: > Not knowing the guts of the systems I'm not sure how easy it would be to > alter Icon's syntax and semantics. Would this be a reasonable request > for enhancement? Sure, but who is going to implement it? There is no funding for stuff like this, so volunteers are welcome. Personally, I like the idea. I keep copious notes of things people request like this, and I bet others do too, so it is not a waste to ask for things! Clint Jeffery cjeffery@cs.arizona.edu From icon-group-sender Wed May 12 02:19:08 1993 Received: by cheltenham.cs.arizona.edu; Wed, 12 May 1993 05:43:24 MST Via: uk.ac.manchester.computer-science; Wed, 12 May 1993 10:10:04 +0100 From: Steve Holden Date: Wed, 12 May 93 09:49:06 BST Message-Id: <9082.9305120849@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: runtime debugger and the Icon fan club. Status: R Errors-To: icon-group-errors@cs.arizona.edu "lwall (Larry Wall) " writes ... > Certainly, if you're willing to place that kind of syntactic load on a > newline. I don't happen to be, probably for irrational reasons--I once > got a bad taste in my mouth from the way awk does it. Come now, this is supposed to be a discussion about _programming_ languages :-) Awk may be Turing-complete, but I don't regard it as anything other than a hacking tool. And, as a matter of fact, I now use Icon in preference, because the only message I ever seemed to get from awk was the well-known awk: syntax error near line n awk: bailing out near line n where n was usually less than three! regards Steve From icon-group-sender Fri May 14 09:46:40 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 08:58:37 MST Date: Fri, 14 May 93 09:46:40 -0400 Message-Id: <9305141346.AA10725@sanborn.bbn.com> To: icon-group@cs.arizona.edu Subject: string stripping From: Sean Boisen Sender: sboisen@bbn.com Reply-To: sboisen@bbn.com Status: R Errors-To: icon-group-errors@cs.arizona.edu This is so basic it's probably covered in the second week of Icon 101, but since i never took the class ... If i have a string and i want to strip out certain characters (internal ones, so trim won't do it), i can do it like this # assume you want to remove hyphens and periods full := "abc-def.ghi" bare := "" badchars := '-.' every c := !full do # test whether the intersection of c and badchars is empty if *(c ** badchars) = 0 then bare ||:= c But this seems awfully clunky, and i was disappointed that i couldn't come up with a tighter way to do it: am i missing some more idiomatic way to express this? Note there's two parts that i perceive as clunky: the testing of whether c is in badchars (i suppose you could make badchars a string and use find instead), and the control structure with explicit generation and assignment to a new string. Any Icon stylists want to offer some pointers on improvements? Sean From icon-group-sender Fri May 14 11:47:26 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 10:04:50 MST Date: Fri, 14 May 93 11:47:26 CDT From: John David Stone Message-Id: <9305141647.AA24170@HILBERT.MATH.GRIN.EDU> To: sboisen@bbn.com Cc: icon-group@cs.arizona.edu In-Reply-To: Sean Boisen's message of Fri, 14 May 93 09:46:40 -0400 <9305141346.AA10725@sanborn.bbn.com> Subject: string stripping Status: R Errors-To: icon-group-errors@cs.arizona.edu Sean Boysen asks: > ... i have a string and i want to strip out certain characters > (internal ones, so trim won't do it) ... am i missing some more > idiomatic way to express this? Note there's two parts that i perceive as > clunky: the testing of whether c is in badchars (i suppose you could > make badchars a string and use find instead), and the control structure > with explicit generation and assignment to a new string. Explicit assignment is not a stylistic defect, since Icon is _not_ going to do in-place updating of the original string even if you use the same variable name. New storage is going to be allocated for the result of the stripping no matter what. However, it would be nice to break off long sequences of goodchars instead of inspecting them singly; the predefined upto procedure is the winning way to do this. String scanning can be used to avoid the other problem: bare := "" badchars := '-.' full ? { while bare ||:= tab(upto(badchars)) do move (1) bare ||:= tab(0) } Or in English: Scan through the value of full, up to the next position occupied by a badchar. Break off the part you've just scanned over and append it to the value of bare. Advance one position to get past the badchar. Repeat until there are no more badchars in the subject. Then scan to the end and append what you've just scanned over to the value of bare. ------ John David Stone - Lecturer in Computer Science and Philosophy ----- -------------- Manager of the Mathematics Local-Area Network -------------- -------------- Grinnell College - Grinnell, Iowa 50112 - USA -------------- -------- stone@math.grin.edu - (515) 269-3181 - stone@grin1.bitnet -------- From icon-group-sender Fri May 14 12:10:26 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 10:39:05 MST Date: Fri, 14 May 93 12:10:26 CDT From: "Richard L. Goerwitz" Message-Id: <9305141710.AA04578@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: string stripping Status: R Errors-To: icon-group-errors@cs.arizona.edu This is a long posting, but I hope it will be helpful. We have a lot of quite newbies online here, and they should be let in on the fun. For Sean it might be a bit simplistic, seeing as he's been using Icon for a while. Bear with me Sean, and I'll offer you several distinct answers to your question! Sean states: If i have a string and i want to strip out certain characters (internal ones, so trim won't do it), ... This is a good problem, and I'll bet that everyone who programs with strings a lot has had to perform this chore. It's a perfect set-up for a discussion of string scanning. Here's your code: # assume you want to remove hyphens and periods full := "abc-def.ghi" bare := "" badchars := '-.' every c := !full do # test whether the intersection of c and badchars is empty if *(c ** badchars) = 0 then bare ||:= c This is perfectly good code, and nicely formatted. The only problem with it I can see is that it doesn't take advantage of string scanning, and its elegance/optimizations. Let's use our full, bare, and badchars variables above, and try again using scanning: full ? { while bare ||:= tab(upto(badchars)) do tab(many(badchars)) bare ||:= tab(0) } This actually subsumes a lot of stuff. Assume that our current position is initially 1, and that position 0 means the end of the string (note the distinct use of the zero offset in Icon, allowing us not to worry about string lengths): 1) append everything in full, from our current position up to the next occurrence of a badchar, to bare; if there are no badchars left in full, do step 4 2) go past however many badchars we have found, and reset our cur- rent position to just before the next "good" char 3) then do 1 again 4) append everything from the current position to the end of the string to bare Scanning, once you get the feel for it, is pretty clear, and usually very elegant. And although people don't use Icon, Prolog, LISP, etc. for their blinding speed, the scanning process is optimized, so you get relatively good performance. Note that if you prefer a less thoroughly Iconish solu- tion to your problem, you could write the following as a kind of compro- mise: every c := !full do # test whether the intersection of c and badchars is empty if any(badchars, c) then bare ||:= c But here again, the temptation to use Icon's backtracking features for more general expression of the problem is almost irresistable: every bare ||:= !full -- badchars I don't find this as clear as the scanning method, so I'd probably want to prepend a comment: # bare defined as full stripped of badchars every bare ||:= !full -- badchars If you want, you can use encapsulation via recursive function calls to get rid of the assignment altogether: procedure stripbads(full, badchars) if *full = 0 then return "" return (full[1] -- badchars) || strip(full[2:0], badchars) end This is starting to look LISPish, though, and I personally find it verbose and somewhat opaque. Note that I haven't tested any of this code, so if you find any bugs, please don't be too shocked. My internal Icon interpreter still isn't fully iso- morphic with the real one. I'd love to teach an Icon course some day, but that's not the typical way in which philologists normally find employment :-). -Richard Goerwitz goer@midway.uchicago.edu From icon-group-sender Fri May 14 11:12:38 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 12:27:10 MST Via: uk.ac.manchester.computer-science; Fri, 14 May 1993 18:13:22 +0100 From: Steve Holden Date: Fri, 14 May 93 18:03:46 BST Message-Id: <12646.9305141703@desktop.desktop.co.uk> To: sboisen@bbn.com Subject: Re: string stripping Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Sean: The conventional way of stripping out unwanted characters woould, I think, use string scanning. The basis is to use "upto()" to skip any you don't want to avoid, and many() to skip the rest. The code would look something like this: procedure main() full := "abc-def.ghi" bare := "" badchars := '-.' full ? { while bare ||:= tab(many(~badchars)) do tab(many(badchars)) } write(bare) end You may notice that despite my suggestion of using "upto()" I actually used tab(many(~badchars)). This allows you to include any trailing good characters as a part of the loop processing rather than having to program in possible special cases. This group being what it is you may well get several other good (possibly even better :-) ideas on how to go about this. regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Fri May 14 14:17:41 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 12:27:28 MST Date: 14 May 1993 14:17:41 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: parsing? To: icon-group@cs.arizona.edu Message-Id: <01GY60RE36O28WW2YZ@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: IN%"sboisen@bbn.com" 14-MAY-1993 11:03:31.80 > To: IN%"icon-group@cs.arizona.edu" > Subj: string stripping > This is so basic it's probably covered in the second week of Icon 101, > but since i never took the class ... > If i have a string and i want to strip out certain characters > (internal ones, so trim won't do it), i can do it like this > # assume you want to remove hyphens and periods > full := "abc-def.ghi" > bare := "" > badchars := '-.' > every c := !full do > # test whether the intersection of c and badchars is empty > if *(c ** badchars) = 0 then bare ||:= c HOW ABOUT # procedure parse converts a string into # a list of strings eliminating delimiters. full := "abc-def.ghi" # you can then concatenate them, sort them, bare := "" # or do whatever you like. I put the delim- badchars := '-.' # iters into a cset which has the effect of # collapsing them away. new := parse(full,'-.') # # write(image(new)) # ["abc","def","ghi"] # # procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end > But this seems awfully clunky, and i was disappointed that i couldn't > come up with a tighter way to do it: am i missing some more idiomatic > way to express this? Note there's two parts that i perceive as clunky: > the testing of whether c is in badchars (i suppose you could make > badchars a string and use find instead), and the control structure > with explicit generation and assignment to a new string. > Any Icon stylists want to offer some pointers on improvements? > Sean 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Tue May 11 15:33:40 1993 Received: by cheltenham.cs.arizona.edu; Fri, 14 May 1993 15:41:48 MST Date: 11 May 93 15:33:40 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Steve Holden) Subject: Re: Icon Fan Club... Message-Id: <8351.9305111533@desktop.desktop.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu NEVIN ":-)" LIBER (nevin@apple.com) writes, in response to an earlier mail... > >That is, you'd really like this to work too: > > > > { something > > ; something else > > ; another something > > } > > > >but it doesn't because C goes and demands an extra semicolon at the > >end. C's a mess.) > > I've written a lot of C (and even some Pascal/Modula 2) code in my time, > and I've never wanted to write code like this and neither have I. I always assumed people wrote their code this way to make it easier to insert and delete statements as units. While there may have been some justification for that in the days of unit- record equipment (I presume other members of this group beside myself have had the joys of programming on IBM 026 and 029 card punches, now there was a machine, but I digress...) this is the 1990's. If mouse-based editing isn't flexible enough to cope with your needs, why not simply (?) use a structured editor with a knowledge of your particular programming language? Without wishing to enter or start a C v Algol 68 debate, I agree that Algol 68 was an elegant language while C might not be. However, most implementations made you do something stupid liek stropping keywords (eg 'BEGIN'), just for the elegance of being able to declare variables spelt the same. I'm a pragmatist, and I'm happy to put up with reserved words in a language if it means I can turn (churn?) out reasonable code, comprehensibly, in quick time. And that's why I like Icon! regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Fri May 14 18:11:03 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sat, 15 May 1993 09:22:45 MST Received: by owl.cs.arizona.edu; Sat, 15 May 1993 09:22:43 MST Date: Fri, 14 May 93 18:11:03 CDT From: John David Stone Message-Id: <9305142311.AA24639@HILBERT.MATH.GRIN.EDU> To: icon-group@cs.arizona.edu In-Reply-To: Steve Holden's message of Fri, 14 May 93 18:03:46 BST <12646.9305141703@desktop.desktop.co.uk> Subject: string stripping Status: R Errors-To: icon-group-errors@cs.arizona.edu For stripping hyphens and dots out of a string, Steve Holden suggests: bare := "" badchars := '-.' full ? { while bare ||:= tab(many(~badchars)) do tab(many(badchars)) } which is tempting, but incorrectly sets bare to "" whenever the value of full begins with a dot or hyphen. ------ John David Stone - Lecturer in Computer Science and Philosophy ----- -------------- Manager of the Mathematics Local-Area Network -------------- -------------- Grinnell College - Grinnell, Iowa 50112 - USA -------------- -------- stone@math.grin.edu - (515) 269-3181 - stone@grin1.bitnet -------- From icon-group-sender Sat May 15 20:32:40 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:00 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:42:58 MST Message-Id: <9305160132.AA01794@relay2.UU.NET> Subject: Re: string stripping To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET (Icon News Group) Date: Sat, 15 May 1993 20:32:40 -0500 (CDT) From: Jerry Nowlin X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1577 Status: R Errors-To: icon-group-errors@cs.arizona.edu > John David Stone Writes... > > For stripping hyphens and dots out of a string, Steve Holden > suggests: > full ? { > while bare ||:= tab(many(~badchars)) do > tab(many(badchars)) > } > > which is tempting, but incorrectly sets bare to "" whenever the value of > full begins with a dot or hyphen. I'm often amazed at how compact you can implement what appear to be complicated algorithms in Icon. String scanning sometimes seems like there has to be a more elegant way but look how cool it is already! There are two ways I could make this work. Both require more code. The first is more straightforward: full ? until pos(0) do { bare ||:= tab(many(~badchars)) tab(many(badchars)) } Notice that the order in which the two matching expressions occur makes no difference. The second solution requires an initial attempt to skip over badchars and is closer to the original: full ? { tab(many(badchars)) while bare ||:= tab(many(~badchars)) do tab(many(badchars)) } I like the first solution. Fewer lines, less mess, incomplete sentence. Both use the principle that failure does not have to be a bad thing. I know I know...I submitted a code fragment. Anyone who can't reconstitute this on their own just email me for a complete program. Jerry Nowlin - uunet!isidev!nowlin - isidev!nowlin@uunet.uu.net From icon-group-sender Sun May 16 17:30:41 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:30 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:29 MST Date: 16 May 93 17:30:41 GMT From: sdd.hp.com!portal!cup.portal.com!Eric-Amick@hplabs.hpl.hp.com (Richard E Amick) Organization: The Portal System (TM) Subject: Re: string stripping Message-Id: <81483@cup.portal.com> References: <12646.9305141703@desktop.desktop.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >procedure main() > >full := "abc-def.ghi" >bare := "" >badchars := '-.' > >full ? { > while bare ||:= tab(many(~badchars)) do > tab(many(badchars)) >} >write(bare) > >end > >You may notice that despite my suggestion of using "upto()" >I actually used tab(many(~badchars)). This allows you to include >any trailing good characters as a part of the loop processing >rather than having to program in possible special cases. > >This group being what it is you may well get several other good >(possibly even better :-) ideas on how to go about this. Your solution won't work if the string starts off with bad characters. On the other hand, making the scanning loop read as follows works: while tab(upto(~badchars)) do bare ||:= tab(many(~badchars)) The only likely objection might be that creating what is almost always a large cset of good characters is inefficient, but I don't think that's a horrible thing in this case (and Icon is not renowned for blazing speed anyway :-). Maybe you should have taken your own advice about upto(), eh? ;-) > >regards > Steve From icon-group-sender Thu May 13 15:34:56 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:48 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:47 MST Date: 13 May 93 15:34:56 GMT From: pipex!uknet!mucs!m1!bevan@uunet.uu.net (Stephen J Bevan) Organization: Department of Computer Science, University of Manchester Subject: Re: runtime debugger and the Icon fan club. Message-Id: References: <9305110634.AA11851@internal.apple.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9305110634.AA11851@internal.apple.com> nevin@apple.com (Nevin ":-]" Liber) writes: I disagree. At first glance, I and most other C programmers would interpret the expression "* broof" as a dereference of the pointer broof. Indeed, but this only goes to show that it was a design error to make the dereferencing operator a prefix operator. I beleive that HCI (human computer interface) folks have done studies that show that it is easier for programmers to have semicolons as terminators than as seperators. References? The only study I saw used (refs long lost) used 1st year students from a single university (Berkeley?) as the sample. Not very representative IMHO. Are there any recent studies that compare languages that require terminators (C) with languages that require separators (Pascal) with languages that can adopt either approach (Oberon-2) with languages that require no terminators or separators at all (Eiffel)? From icon-group-sender Fri May 14 02:01:30 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:52 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:51 MST Date: 14 May 93 02:01:30 GMT From: amethyst!organpipe.uug.arizona.edu!news@noao.edu (Dave Schaumann) Organization: University of Arizona Subject: Re: Icon vs Prolog, docs, availability ? Message-Id: <1993May14.020130.17872@organpipe.uug.arizona.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article , borbor@divsun (Boris Borcic) writes: >I have read in this group that Icon uses a backtracking >mechanism very similar to Prolog. Would a user of both >languages care to sketch Icon with Prolog as background ? >What are the most significant differences ? Probably the most significant difference is that Icon is a (mostly) imperative language. Thus, most Icon programs tend to be (mostly) imperative. On the other hand, I was just working on implementing an algorithm for which backtracking worked out very nicely. The algorithm (in part) maintians a list of sets. Part of the algorithm is a loop which selects an element from one of these sets. The pseudo-code is expressed as Select a in (size of list) and i in L[a]. The loop terminates when L[a] is empty for all a. This can be expressed very nicely in Icon as while a := 1 to *L & i := !L[a] do { # do the loop stuff } Here, Icon's backtracking feature is used to elide the fact that (in general) you have to loop to find appropriate values of a and i. It's been a long time since I did any Prolog programming, so I can't speak directly to the relative strengths of each language, but I wouldn't be to surprised if one could write a fairly complete Prolog interpreter in Icon with relatively few lines of code (particularly since you have the backtracking feature "for free"). -- Dave Schaumann dave@cs.arizona.edu From icon-group-sender Thu May 13 21:39:30 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:43 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:42 MST Date: 13 May 93 21:39:30 GMT From: netcomsv!netcom.com!cas@decwrl.dec.com (Charles A. Shartsis) Organization: Netcom Online Communications Services (408-241-9760 login: guest) Subject: Re: Is there a run time Debugger in developement? Message-Id: References: <9305041332.AA13516@srdslc1.fb4.noaa.gov.fb4.noaa.gov> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9305041332.AA13516@srdslc1.fb4.noaa.gov.fb4.noaa.gov> motto@srdslc1.fb4.noaa.gov (Mark Otto) writes: > >Clint, >Add my name to the list of people that >are interested in a debugger. >Sometimes I give up on icon and write >in c just to get a program debugged. >Wouldn't the new multi-threaded version >of icon that can monitor other icon programs >be a good base for a debugger? > There is a debugger package in the latest release of the Icon Program Library called DEBUGIFY. The library can be ordered from the University of Arizona computer science department or gotten via anonymous ftp from cs.arizona.edu. From icon-group-sender Thu May 13 10:28:52 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:10 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:09 MST Date: 13 May 93 10:28:52 GMT From: pipex!zaphod.crihan.fr!univ-lyon1.fr!scsing.switch.ch!news.unige.ch!NewsWatcher!user@uunet.uu.net (Boris Borcic) Organization: University of Geneva Subject: Icon vs Prolog, docs, availability ? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have read in this group that Icon uses a backtracking mechanism very similar to Prolog. Would a user of both languages care to sketch Icon with Prolog as background ? What are the most significant differences ? What is the typical problem easily solved in the same way in both languages? What typical problems are there, if any, that are easy to solve in Icon but not in Prolog, and vice-versa ? For instance, it is at times desirable to constrain the search for further solutions in a way that depends on the solutions already found. IMHO, the declarative leaning of Prolog's backtracking makes this difficult and unnatural to program. Does Icon let me do this naturally ? Some FAQs : Is there an Icon Bible ? Internet on-line docs ? Public domain implementations ? For what systems ? Thanks in advance - Boris Borcic, borbor@divsun.unige.ch From icon-group-sender Thu May 13 14:46:25 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:38 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:37 MST Date: 13 May 93 14:46:25 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon vs Prolog, docs, availability ? Message-Id: <1993May13.144625.16769@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu borbor@divsun.unige.ch (Boris Borcic) writes: > >For instance, it is at times desirable to constrain the >search for further solutions in a way that depends on the >solutions already found. IMHO, the declarative leaning of Prolog's >backtracking makes this difficult and unnatural to program. >Does Icon let me do this naturally ? This is the main advantage of Icon, and its disadvantage (rela- tive to Prolog). Icon is not an attempt at instantiating first- order predicate logic. It is not pure in this respect. Yet it includes all of the mechanisms one would need to do this: It has control and optional data backtracking, and can handle prob- lems without any notion of assignment. You can write programs that function solely by something analogous to term unification, and the like. The fact that Icon is not pure makes it easier to cheat, if you are so inclined. I.e. there are operators that limit the amount of backtracking. For example, if I take a string like "hellolo," and ask for the position of every "l" in it, I might say: "hellolo" ? every write(find("l")) The question mark says "we're going to work on the preceding string." This expression will write 3, 4, and 6. But let's say we only want two results. We can cheat: "hellolo" ? every write(find("l")) \ 2 Now if you want to check earlier results, Icon has a more Algol- ish exterior than Prolog. You can assign variables explicitly, much as you would in Pascal: "hellolo" ? { every i := find("l") do { if i = 6 then next else write(i) } } This will have the same effect as saying "hellolo" ? every write(find("l")) \ 2 I.e. it will write only 3 and 4, but not 6. Personally, my favorite part of Icon is string scanning. It is, in a way, syntactic sugar. But there are aspects of it that make it uniquely elegant. The ? marker sets up a string as the object of a scanning expression, and you can then do lots of neat things to that string. The scanning expression is a kind of control structure, so you can break out of it or return, and its environ- ments are handled correctly. There's not much point in explaining it, though, until you've looked at a textbook and tried it out. If you had a whiff of Snobol, I guess it's probably broadly simi- lar. >Some FAQs : Is there an Icon Bible ? Internet on-line docs ? >Public domain implementations ? For what systems ? The main archive site is cs.arizona.edu, and you'll find lots of interesting PD implementations there for most popular systems, and porting instructions for the unpopular ones :-). The main text- book is Griswold & Griswold _The Icon Programming Language_ (Pren- tice Hall, c. 1989). Enjoy. If you have X or OS/2, try enabling the visual interface. If you're using UNIX and are interested in a bit of experimentation, try the (still a bit experimental) compiler as well. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat May 15 20:03:20 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 07:43:22 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 07:43:22 MST Date: 15 May 93 20:03:20 GMT From: sdd.hp.com!portal!cup.portal.com!Eric-Amick@hplabs.hpl.hp.com (Richard E Amick) Organization: The Portal System (TM) Subject: Re: runtime debugger and the Icon fan club. Message-Id: <81438@cup.portal.com> References: <9082.9305120849@desktop.desktop.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >Come now, this is supposed to be a discussion about _programming_ >languages :-) Awk may be Turing-complete, but I don't regard it as >anything other than a hacking tool. And, as a matter of fact, I >now use Icon in preference, because the only message I ever seemed >to get from awk was the well-known > >awk: syntax error near line n >awk: bailing out near line n > >where n was usually less than three! > >regards > Steve You should try nawk, the newer version of awk, instead; besides more functions and the ability to define your own functions, it has much better error messages. I'll bet that gawk (the GNU counterpart) is the same way. From icon-group-sender Mon May 17 08:41:30 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 09:19:07 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 09:19:06 MST Message-Id: <9305171538.AA58087@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Icon vs Prolog, docs, availability ? To: icon-group@cs.arizona.edu Date: Mon, 17 May 93 8:41:30 PDT In-Reply-To: ; from "Boris Borcic" at May 13, 93 10:28 am Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Boris Borcic writes: > > I have read in this group that Icon uses a backtracking > mechanism very similar to Prolog. Would a user of both > languages care to sketch Icon with Prolog as background ? > What are the most significant differences ? - Icon does not have unification or even tree pattern matching. Tree and list processing can certainly be done, but some things are far less elegant than in Prolog. - Icon is strongly oriented toward string manipulation; string scanning is the most fully developed built-in facility that uses backtracking. - In Prolog, data backtracking is an inescapable part of the language. In Icon, there are two kinds of assignments, those that are undone upon backtracking and those that are not. The latter are typically used much more than the former; Icon programs are not declarative. - Icon has control structures that look similar to those of more conventional programming langauges, but have somewhat different semantics in that they use and control success and failure rather than being driven by boolean values. Many of these control structure lexically limit backtracking; there is nothing as messy as Prolog's "cut". > What typical problems are there, if any, > that are easy to solve in Icon but not in Prolog, and vice-versa ? > > For instance, it is at times desirable to constrain the > search for further solutions in a way that depends on the > solutions already found. IMHO, the declarative leaning of Prolog's > backtracking makes this difficult and unnatural to program. > Does Icon let me do this naturally ? I never got to the point where I felt I could "think in Prolog", so I'm not sure I can make a fair comparison at this level. Prolog gives you a very simple, very high-level programming model. If your problem fits easily into that model, Prolog is beautiful to program in. How may problems fit the model may depend on how you are able to think about them (sorry if this is rather vague). Icon, on the other hand, has more features and as an imperative languages gives you more control and more flexibility. It might be interesting to look at specific problems. Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Mon May 17 17:46:22 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 17 May 1993 09:19:17 MST Received: by owl.cs.arizona.edu; Mon, 17 May 1993 09:19:15 MST Date: Mon, 17 May 93 17:46:22 +0200 From: karczma@univ-caen.fr (Jerzy Karczmarczuk) Message-Id: <9305171546.AA02842@univ-caen.fr> To: icon-group@cs.arizona.edu Subject: Re: Icon vs Prolog? Status: R Errors-To: icon-group-errors@cs.arizona.edu Boris Borcic asked: >>I have read in this group that Icon uses a backtracking >>mechanism very similar to Prolog. Would a user of both >>languages care to sketch Icon with Prolog as background ? >>What are the most significant differences ? ... and Dave Schaumann replied > Probably the most significant difference is that Icon is a (mostly) > imperative language. Thus, most Icon programs tend to be (mostly) > imperative. ... > It's been a long time since I did any Prolog programming, so I can't > speak directly to the relative strengths of each language, but I wouldn't > be to surprised if one could write a fairly complete Prolog interpreter > in Icon with relatively few lines of code (particularly since you have the > backtracking feature "for free"). * * * Gentlemen, as you know, the discussion about programming languages is like the old machos's memoirs about women: they are all the same, but it is better not to replace one by another too often, if you want really to learn something. Actually I would call Icon rather a functional language than imperative. 1. Everything is an expression, the assignment and other control structures included. (Well, OK, ALMOST everything, I know...) 2. You can store procedure (identifiers) and pass them as data, and then call them anywhere. 3. You can define local lexical closures, or "thunks", and calling them "co-expressions" doesn't change much. 4. co-exs (as generators) can be used to implement streams and other lazy structures, so you are not too far from Lazy Functionalists. Btw., this is a fascinating project for your students! It is probably easier to implement Prolog in Icon than in Lisp, but I wouldn't say that the Prolog backtracking is for free. You have to take into account that implementing Prolog means installing data structures which will emulate Prolog variables. And the backtracking in Prolog is not just the control backtracking, but total data amnesia as well. It is not straightforward to implement, but if you know the rules, you don't need the non-deterministic facilities in the implementation language. I would not agree completely with Richard Goerwitz who claims ... that in Icon ... > You can write programs > that function solely by something analogous to term unification, > and the like. A. Don't forget that unification is a two-way pattern matching, absent in Icon, unless the concept of "something analogous" is somehow abused. B. It is difficult to rewrite in Icon some Prolog clauses which profit from the fact that you can store a non-instantiated variable, and instantiate it afterwards. Sometimes it is possible, as de-referencing in Icon is deferred, and the concept of datum which is VARIABLE exists, but how many Icon users understand well the need and the usage of the "." operator? (Frankly, I don't...) (Just for the Guru himself: I think it is a light perversion to use for the dereferencing operator the same symbol which has been used in Snobol4 to denote just the reverse of it, i.e. 'name'...) Anyway, I love both languages (and a dozen others as well, like an old programming-language Don Juan) and living (for some time) in France, the country which is the mother of such international calamities as Prolog, Armagnac, Eiffel (the language and the tower, don't know which one is uglier...) I permit myself to shout: "Vivent les petites differences!" Jerzy Karczmarczuk Dept. of Computer Sci. University of Caen, France karczma@univ-caen.fr From icon-group-sender Fri May 14 04:49:37 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 18 May 1993 09:46:53 MST Received: by owl.cs.arizona.edu; Tue, 18 May 1993 09:46:52 MST Date: 14 May 93 04:49:37 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon vs Prolog, docs, availability ? Message-Id: <1993May14.044937.12543@midway.uchicago.edu> References: , <1993May14.020130.17872@organpipe.uug.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu dave@cs.arizona.edu (Dave Schaumann) writes: > Select a in (size of list) and i in L[a]. The loop terminates when > L[a] is empty for all a. > >This can be expressed very nicely in Icon as > > while a := 1 to *L & i := !L[a] do { > # do the loop stuff > } I might tend to write the loop stuff as applying to every !!L, which produces every element of every element of L, unless the code involved actual shortening of L and/or L's elements. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri May 14 16:29:56 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 18 May 1993 09:47:18 MST Received: by owl.cs.arizona.edu; Tue, 18 May 1993 09:47:17 MST Date: 14 May 93 16:29:56 GMT From: amethyst!organpipe.uug.arizona.edu!news@arizona.edu (Dave Schaumann) Organization: University of Arizona Subject: Re: Icon vs Prolog, docs, availability ? Message-Id: <1993May14.162956.25963@organpipe.uug.arizona.edu> References: , <1993May14.020130.17872@organpipe.uug.arizona.edu>, <1993May14.044937.12543@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May14.044937.12543@midway.uchicago.edu>, goer@ellis (Richard L. Goerwitz) writes: >dave@cs.arizona.edu (Dave Schaumann) writes: > >> Select a in (size of list) and i in L[a]. The loop terminates when >> L[a] is empty for all a. >> >>This can be expressed very nicely in Icon as >> >> while a := 1 to *L & i := !L[a] do { >> # do the loop stuff >> } > >I might tend to write the loop stuff as applying to every !!L, >which produces every element of every element of L, unless the >code involved actual shortening of L and/or L's elements. Actually, the loop *has* to shorten L (since I'm using while and not every). I could change to every and use your method, except that the contents of L changes during each iteration. It's also important to the algorithm to know which list "i" is taken from (ie, it needs to have the value of "a") -- Dave Schaumann dave@cs.arizona.edu From icon-group-sender Fri May 14 20:08:19 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 18 May 1993 18:05:21 MST Received: by owl.cs.arizona.edu; Tue, 18 May 1993 18:05:20 MST Date: 14 May 93 20:08:19 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!csd4.csd.uwm.edu!corre@ucbvax.Berkeley.EDU (Alan D Corre) Organization: Computing Services Division, University of Wisconsin - Milwaukee Subject: Grade Program with LaTeX Message-Id: <1t0u7jINNivi@uwm.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Since I am retiring this month, I am clearing away things I no longer need, both tangible and electronic. I thought some of you might be able to use the ideas in the following little grade calculation program, which has as its output a LaTeX input file. This is then submitted to the LaTeX processor which produces a nice looking table. It would be possible to enter the information from a file, to sort the resulting table by number and add other bells and whistles. (I use just the last four digits of the social security number.) Probably your fancy word processor can do an equally good or better job. But it might spark some ideas. As King Solomon said: Iron sharpens iron, and a man sharpens the countenance of his friend. I guess that's what the net is all about. *** procedure main() printinfo(getinfo()) end procedure getinfo() local infolist, socsec infolist := [] writes("Number of course? ") put(infolist,read()) writes("Section of course? ") put(infolist,read()) writes("Date of course? ") put(infolist,read()) writes("Enter Social Security Number. Period to finish. ") while (socsec := read()) ~== "." do { put(infolist,socsec) writes("First Exam? ") #enter a question mark if grade is unknown put(infolist,read()) writes("Second Exam? ") put(infolist,read()) writes("Third Exam? ") put(infolist,read()) writes("Enter Social Security Number. Period to finish. ")} return infolist end procedure printinfo(i) local outfile, n,total,flag n := 3 outfile := open(i[1] || i[2] || i[3] || ".tex","w") write(outfile,"\\documentstyle{article}") write(outfile,"\\begin{document}") write(outfile,"\\begin{center}") write(outfile,"Course Number ",i[1]," Section ",i[2]," \\\\[.25in]") write(outfile,"Semester ",i[3]," \\\\[.25in]") write(outfile,"\\begin{tabular}{|c|c|c|c|c|c|} \\hline") write(outfile,"S.S. & I & II & III & Total & Grade \\\\ \\hline") while n < *i do { total := 0 flag := &null writes(outfile,i[n +:= 1]," & ") every 1 to 3 do { writes(outfile,i[n +:= 1]," & ") if i[n] == "?" then flag := 1 if /flag then total +:= i[n]} if /flag then writes(outfile," ",total) writes(outfile," & ") if /flag then write (outfile,grade(total), " \\\\ \\hline") else write(outfile,"I \\\\ \\hline")} write(outfile,"\\end{tabular}") write(outfile,"\\end{center}") write(outfile,"\\end{document}") return end procedure grade(n) local g n := integer(n + 0.5) if n >= 63 then g := "A" else if n >= 48 then g := "B" else if n >= 33 then g := "C" else if n >= 18 then g := "D" else g := "F" return g end -- Alan D. Corre Department of Hebrew Studies University of Wisconsin-Milwaukee (414) 229-4245 PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.edu From icon-group-sender Wed May 19 18:19:10 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 08:00:43 MST Received: by owl.cs.arizona.edu; Thu, 20 May 1993 08:00:41 MST Date: 19 May 93 18:19:10 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: A bug? Or a feature? Message-Id: <1993May19.181910.14699@midway.uchicago.edu> References: <12743@sun13.scri.fsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu John Nall writes that the Icon manual says: > > X1 op:= X2 > "performs the operation X1 op X2 and assigns the result to X1 > > ...To wit: it actually: > > "performs the operation X1 op (X2) and assigns the result to X1" I see what you mean. The problem is with how you define X1 and X2. Here's the scoup: Think of X1 and X2 as expression 1 and expression 2. How do we group expressions? By operator precedence and newlines. What is the precedence of <:=, for example? It is the same as any assignment operator's. What is the precedence of >, say? It is the same as that of any comparison operator. Now we can answer the question of how the following expression groups: > i <:= j > k Since comparison has a higher precedence than assignment, we group (j > k) as one expression. Hence the correct grouping of the entire assignment expression is: i <:= (j > k) Ergo i is expression 1, and (j > k) is expression 2. The augmented assign- ment operator adds the result of expression 2 to expression 1, and assigns the result to expression 1 (if, in fact, expression 1 produces a variable). So the Icon book is, in fact, correct, using its own definitions. op:= is not a macro; it is a regular assignment operator. You just have to figure out how the surrounding expressions group. Note: What your comments indicate is that the Icon book's explanation, while cor- rect, may not be intuitive to everyone. Good question. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat May 15 19:16:59 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 08:01:56 MST Received: by owl.cs.arizona.edu; Thu, 20 May 1993 08:01:53 MST Date: 15 May 93 19:16:59 GMT From: dog.ee.lbl.gov!pasteur!agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: string stripping Message-Id: <1993May15.191659.22110@midway.uchicago.edu> References: <9305141710.AA04578@midway.uchicago.edu>, <1993May15.080016.8080@smds.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu rh@ishmael.UUCP (Richard Harter) writes: > >>Sean states: > >> If i have a string and i want to strip out certain characters >> (internal ones, so trim won't do it), ... > >>This is a good problem > >It seems to me that this is the sort of thing that would be a one liner >in languages that are strong in string processing. It is a one-liner. The posting you are responding to suggested a one- liner that seemed reasonably crisp: every base ||:= !full -- badchars. A simple idiom, although not crystal clear to the uninitiated (kind of like putting sed "s/\.-//g" in front of a newbie). The fact is that the longer scanning solutions were actually far more clear and elegant, and they demonstrate a general methodology for sol- ving string processing problems that is far more powerful and flexible than what you'll find in most supposed "string processing" languages. Not to demean languages that use regular expressions. Though cryptic and restricted in power, they are useful. Each tool has its own pur- pose. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat May 15 20:07:00 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 08:02:32 MST Received: by owl.cs.arizona.edu; Thu, 20 May 1993 08:02:31 MST Date: 15 May 93 20:07:00 GMT From: dog.ee.lbl.gov!pasteur!agate!howland.reston.ans.net!newsserver.jvnc.net!synapse.bms.com!watson.bms.com!rogers_m@ucbvax.Berkeley.EDU (MICHAEL ROGERS) Organization: Bristol Myers Squibb Pharmaceutical Research Institute Subject: Re: string stripping Message-Id: <15MAY199315070689@watson.bms.com> References: <9305141710.AA04578@midway.uchicago.edu>, <1993May15.080016.8080@smds.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May15.080016.8080@smds.com>, rh@ishmael.UUCP (Richard Harter) writes... [stuff deleted] >And so on, in the language of your choice. I sort of take it for granted >that any language which is strong in text manipulation will have primitive >operations that (a) can do string [and character] replacement, and (b) >optionally apply replacement either substring by substring or globally >across an entire string. > >As I say, I don't know Icon, so I can't evaluate the reasons why this >is "a good problem" rather than a "no brainer". Different languages >have different approaches, and an easy task in Icon might be a mass >of hair in another language. It would be interesting to see a discussion >of where the Icon approach "works" and, say, the Perl approach does not. I, too, would love to see a thread comparing Icon, perl, awk, whatever, and the relative merits & weaknesses of each. BTW, anyone know of a source or contact for licensing awkcc from the UNIX toolchest? Mike Rogers perl newbie, nascent w/ Icon rogers_m@bms.com >--- > >I have cross-posted this to comp.lang.misc, since it is in the nature >of a meta language discussion. > >-- >Richard Harter: SMDS Inc. Net address: rh@smds.com Phone: 508-369-7398 >US Mail: SMDS Inc., PO Box 555, Concord MA 01742. Fax: 508-369-8272 >In the fields of Hell where the grass grows high >Are the graves of dreams allowed to die. From icon-group-sender Wed May 19 18:21:25 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 08:03:18 MST Received: by owl.cs.arizona.edu; Thu, 20 May 1993 08:03:17 MST Date: 19 May 93 18:21:25 GMT From: agate!overload.lbl.gov!lll-winken.llnl.gov!fastrac.llnl.gov!wsrcc.com!hack.dragoman.com!wetware!spunky.RedBrick.COM!psinntp!psinntp!commpost!newshost!nick@ucbvax.Berkeley.EDU (Nicholas Jacobs) Organization: Merrill Lynch Municipal Analytics & Systems, NY Subject: Sockets for ICON? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Has anybody implemented a BSD socket interface for ICON? I'd be looking for both UDP and TCP sockets. Thanks, Nick -- nick@masdev.ml.com, uunet!toro!nick, (212) 449-1455 Merrill Lynch Municipal Analytics & Systems, NY "I have something to say! It's better to burn out than to fade away!" - Kurgan From icon-group-sender Thu May 20 01:22:30 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 15:41:54 MST Received: by owl.cs.arizona.edu; Thu, 20 May 1993 15:41:52 MST Date: 20 May 93 01:22:30 GMT From: world!ksr!tim@uunet.uu.net (Tim Peters) Organization: Kendall Square Research Corp. Subject: Re: A bug? Or a feature? Message-Id: <26810@ksr.com> References: <12743@sun13.scri.fsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <12743@sun13.scri.fsu.edu> nall@ibm12.scri.fsu.edu (John Nall) writes: > ... > The Icon reference manual says (and I quote): > > X1 op:= X2 > > "performs the operation X1 op X2 and assigns the result to X1 > > All well and good, and by and large it does exactly that. With a > slight variation, however. To wit: it actually: > > "performs the operation X1 op (X2) and assigns the result to X1" > ^ ^ > ... > A bug? Or a feature? A harmless ambiguity . I'm sure Icon's working as intended here, but there are many places in the language where a precise description of the semantics might scare off the manual's primary audience . There's another (well, at least one more) ambiguity in the text you quote, to wit how many times X1 is evaluated. An example to show the difference: global i1, i2 procedure main(switch) i1 := 1 i2 := 2 if *switch > 0 then { write( "pick() +:= 10" ) pick() +:= 10 } else { write( "pick() := pick() + 10" ) pick() := pick() + 10 } write( i1, " ", i2 ) end # procedure main procedure pick() static i initial i := 0 case i +:= 1 of { 1 : return i1 2 : return i2 } end # procedure pick If run without arguments, it prints pick() := pick() + 10 12 2 If run with an argument, pick() +:= 10 11 2 The point is that the left-hand side is evaluated exactly once in an augmented assignment, & I'm not sure The Bible ever says that except for an implication on pg 74 (where it notes that augmented assignment "is particularly useful for tables [because the table lookup is done only once]"). Both behaviors (evaluating the LHS once, & evaluating the RHS without regard to the LHS) are the norm for languages with augmented assignment, but I think it's been historically rare for language manuals to say so clearly. For a recent example of one that does, check out the explanations of augmented assignment in the ISO C standard. It will make you appreciate the friendly-though-incomplete explanation in the Icon manual . but-agreeing-that-a-pair-of-parens-in-the-text-would-help-clarify-one- of-the-potential-confusions-ly y'rs - tim Tim Peters tim@ksr.com not speaking for Kendall Square Research Corp From icon-group-sender Thu May 20 14:37:07 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Fri, 21 May 1993 10:50:18 MST Received: by owl.cs.arizona.edu; Fri, 21 May 1993 10:50:17 MST Date: 20 May 93 14:37:07 GMT From: agate!spool.mu.edu!uwm.edu!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: A bug? Or a feature? Message-Id: <1993May20.143707.20031@midway.uchicago.edu> References: <12743@sun13.scri.fsu.edu>, <26810@ksr.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <26810@ksr.com> tim@ksr.com (Tim Peters) writes, regarding the form X1 op:= X2: >There's another (well, at least one more) ambiguity in the text you >quote, to wit how many times X1 is evaluated. An example to show the >difference: > pick() +:= 10 > pick() := pick() + 10 > >procedure pick() > static i > initial i := 0 > case i +:= 1 of { > 1 : return i1 > 2 : return i2 > } >end ... >The point is that the left-hand side is evaluated exactly once in an >augmented assignment, & I'm not sure The Bible ever says that except for >an implication on pg 74... Another good point. What Icon does is invoke the function pick(), and when its value returns (at which point it is on the top of the stack), it simply duplicates that value. That value is a variable. The value is duplicated so it can be used once for assignment and once for ad- dition. Pick() is invoked once, in other words - like Tim says. I can imagine unpleasant side-effects if things didn't work this way. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu May 20 13:45:00 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sun, 23 May 1993 19:53:05 MST Received: by owl.cs.arizona.edu; Sun, 23 May 1993 19:53:03 MST Date: 20 May 93 13:45:00 GMT From: mercury.hsi.com!mlfarm!rosie!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: Icon on a mixed-architecture network Message-Id: <1993May20.134500.4321@mlfarm.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm wondering what is the best way to install Icon on a network with both Sun4 and Sun3 machines. We build Icon programs here with the space-saving Unix header #! /usr/local/bin/iconx at the top of the executable files. This makes for speedy and compact executables, but ignores the ICONX environment variable. Assuming machines on the network have the appropriate Sun3 or Sun4 iconx on their PATH, will the same executable run on either system? I don't think there are any byte-swapping nasties between Sun3 and Sun4 architectures. Second, are the prog.u1 and prog.u2 modules portable between these two architectures? In other words, could I use the same IPATH to a common library for both systems? Any other suggestions about setting up Icon on a mixed architecture network? Thanks. -- Ronald Florence ron@mlfarm.com From icon-group-sender Mon May 17 22:55:40 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sun, 23 May 1993 19:53:34 MST Received: by owl.cs.arizona.edu; Sun, 23 May 1993 19:53:33 MST Date: 17 May 93 22:55:40 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!caen!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Icon SLR(1) parser generator Message-Id: <1993May17.225540.23285@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Does anyone want to try out an (experimental) SLR(1) parser generator for Icon? It's going to need some work, but so far so good. Eventually I'll get around to LALR-ing it, but for the present it's a trim SLR(1) system. Don't be scared if you don't know what a parser generator is. The README file has a tutorial for complete newbies. If you want to be scared, be scared because I only finished writing this last week :-). If you know YACC and Icon, you can start writing code for this in about 5 minutes. Just skim the README file. Read the part on differences be- tween YACC and this package. Most are pretty superficial. Anyone wanting a copy should send a request to the address below. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon May 17 18:20:24 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sun, 23 May 1993 19:54:13 MST Received: by owl.cs.arizona.edu; Sun, 23 May 1993 19:54:11 MST Date: 17 May 93 18:20:24 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!usc!cs.utexas.edu!utnut!torn!nott!bnrgate!bnr.co.uk!pipex!sunic!psinntp!psinntp!nmtigw!peter@ucbvax.Berkeley.EDU (peter da silva) Organization: Network/development platform support, NMTI Subject: Re: string stripping Message-Id: References: <9305141710.AA04578@midway.uchicago.edu>, <1993May15.080016.8080@smds.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May15.080016.8080@smds.com> rh@ishmael.UUCP (Richard Harter) writes: > > If i have a string and i want to strip out certain characters > > (internal ones, so trim won't do it), ... > In Lakota I would write > set-string full {split -. (full)} This is too trivial an excersize. It's even a one-liner in C: {char*s,*t;for(s=t=full;*t=*s;s++,t+=*t!='.'&&*t!='-');} (grin) -- Peter da Silva `-_-' Network Management Technology Incorporated 'U` 12808 West Airport Blvd. Sugar Land, TX 77478 USA +1 713 274 5180 "Na sema Jambo mbwa kali yake leo?" From icon-group-sender Tue May 18 20:21:27 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 25 May 1993 07:55:42 MST Received: by owl.cs.arizona.edu; Tue, 25 May 1993 07:55:40 MST Date: 18 May 93 20:21:27 GMT From: walter!decadent.bellcore.com!norman@uunet.uu.net (Norman Ramsey) Organization: Bellcore Subject: seeking parser generator for icon Message-Id: <1993May18.202127.23115@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Has anyone implemented a parser generator that emits Icon code and has support for semantic actions? yacc-style would be ideal, but anything with semantic actions will do. I cooked something up a while back that accepts EBNF, but I'm not thrilled about trying to alter it to support semantic actions, especially if someone else has already done the work :-) Norman -- Norman Ramsey norman@bellcore.com From icon-group-sender Tue May 18 22:14:18 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 26 May 1993 12:26:52 MST Received: by owl.cs.arizona.edu; Wed, 26 May 1993 12:26:51 MST Date: 18 May 93 22:14:18 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: seeking parser generator for icon Message-Id: <1993May18.221418.5749@midway.uchicago.edu> References: <1993May18.202127.23115@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu norman@decadent.bellcore.com (Norman Ramsey) writes: > >Has anyone implemented a parser generator that emits Icon code and has >support for semantic actions? yacc-style would be ideal, but anything >with semantic actions will do. I cooked something up a while back >that accepts EBNF, but I'm not thrilled about trying to alter it to >support semantic actions, especially if someone else has already done >the work :-) Norman just wrote to me, and I have responded. But in case anyone else wonders, my recent posting about an Icon-based SLR(1) parser generator is exactly what he is after, with the one reservation that it uses an SLR table generation algorithm instead of an LALR one. It takes YACC- like input, and supports semantic actions, just like Norman wants. I repeat the offer that, if anyone wants a shell archive of this system, I'll be glad to mail it out, as long as recipients understand that it is new, and likely to have bugs. Unlike the last parser generator I posted (which was LR(1), and little more than a toy), this one is actually a practical system. For small-to- medium grammars the resulting parsers clip along well enough for inter- active use. Processing the grammar can take a while, though, especially if you turn on table compression. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri May 21 22:17:24 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 26 May 1993 12:26:56 MST Received: by owl.cs.arizona.edu; Wed, 26 May 1993 12:26:56 MST Date: 21 May 93 22:17:24 GMT From: portal!cup.portal.com!Eric-Amick@uunet.uu.net (Richard E Amick) Organization: The Portal System (TM) Subject: Re: Icon on a mixed-architecture network Message-Id: <81825@cup.portal.com> References: <1993May20.134500.4321@mlfarm.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >We build Icon programs here with the space-saving Unix header > > #! /usr/local/bin/iconx > >at the top of the executable files. This makes for speedy and compact >executables, but ignores the ICONX environment variable. Assuming >machines on the network have the appropriate Sun3 or Sun4 iconx on >their PATH, will the same executable run on either system? I don't >think there are any byte-swapping nasties between Sun3 and Sun4 >architectures. Another possibility is to change the Unix header to exec "${ICONX-iconx}" "$0" "$@" which will use the ICONX variable if it's defined, otherwise it searches the path. From icon-group-sender Thu May 27 06:31:18 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 27 May 1993 07:32:45 MST Received: by owl.cs.arizona.edu; Thu, 27 May 1993 07:32:44 MST Date: 27 May 1993 06:31:18 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Comparative Languages (MUMPS?) To: icon-group@cs.arizona.edu Message-Id: <01GYNRS810XE8WW871@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 Status: R Errors-To: icon-group-errors@cs.arizona.edu Icon seems to incorporate some of the best features of the best computer languages. It has probably exhausted it's grant money for further renovation but I've been putzing with another kind of string language. This is something Hospitals use extensively, namely MUMPS. I sat with a MUMPS guru for about an hour back in December and heard the party line, and asked him certain language design questions. MUMPS also makes the Icon claim of very quick development. It seemed to have all the functionality of Icon but in a very different form. MUMPS like Icon is designed around a virtual machine and has an interpreter, compiler, X-windows, easy types, automatic memory management and garbage collection. But the part that I think is really cool is an architecture independent file system. My understanding is probably a little warped, but here's my understanding of MUMPS data. It comes in 3 forms. LOCAL, GLOBAL, and STRUCTURE. LOCAL are your local variables, and procedures that disappear after the running program finishes. STRUCTURES are builtin data structures offered by the operating system. GLOBALS are handled like variables, but they're actually files, well sort of. They are files in that they don't go away after the program is done, or you log out. You don't have to open or close them, they're just there. All you have to do is reference them. The cool part is that they can be complex data like icon lists, and tables and procedures (programs). There is a programmer and user environment. The programmer environment can step through programs, use breakpoints, or run single expressions interactively. The user environment is tight with no programming access. MUMPS provides facilities to read and write to file systems and devices outside it's environment. While it can be used this way, I get the feeling these are designed for you to import your data into the environment, and export it to non-MUMPS environments. Here is a sample of what Icon might be like using a MUMPS global paradigm. procedure main() In := open("external.dat") # to import from outside $Reference := table(0) # $ maps Reference to a file available to all icon programs by name $Reference. while Line := read(In) do # in fact, the table is not { # initialized here, but just Name := Parse(Line,' ')[1] # declared for access. Old Adrs := Parse(Line,' ')[2] # contents still remembered $Reference[Name] := Adrs # but the init value might be different in different procedures. } close(In) end Later, this is run and $Reference is populated with data. Since it was loaded as a filed variable, a later program can reference it already loaded and in the table associative array mode. procedure main() $Reference := table(0) # maps in the data every Check := !Occurence do Crunch($Reference[Check]) end A list or set like structure could be initialized in this method too. Any comments concerning having some variables or types directly map to file system structures that are non-volatile from session to session? I think it helps because you don't have to clutter your code up with all kinds if open close and testing statements. Open and close would be used for exporting & importing data, manipulating pipes and x-windows. 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)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Tue May 25 04:39:09 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 27 May 1993 09:17:28 MST Received: by owl.cs.arizona.edu; Thu, 27 May 1993 09:17:26 MST Date: 25 May 93 04:39:09 GMT From: dog.ee.lbl.gov!network.ucsd.edu!munnari.oz.au!titan!trlluna!bruce.cs.monash.edu.au!lloyd@ucbvax.Berkeley.EDU (Lloyd Allison) Organization: Computer Science, Monash University, Australia Subject: Re: Yet another variation on queens (was Icon vs Prolog) Message-Id: References: <9305171538.AA58087@enlil.premenos.sf.ca.us>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu borbor@divsun.unige.ch (Boris Borcic) writes: ... >3) Write a 3D version of 1+2, e.g. N^2 queens in N^3 cubic "board" > (are there any 3d solutions to N^2 queens ? should one use plane > diagonals, 3d diagonals, or both ?) ... In general there are lots of solutions for N^2 queens on an N*N*N "board", but none if N<11, N=12 or N=14. For n=11 and N=13, all solutions are also solutions of the toroidal version, and they are all "linear" solutions. Conjecture that there are solutions to the toroidal problem iff the smallest factor of N is > 7. Q: what is the smallest N with a non-linear solution? %A L. Allison %A C. N. Yee %A M. McGaughey %T Three-dimensional queens problems. %R TR 89/130 %I Dept. Computer Science, Monash University, Australia %M AUG %D 1989 %K n-queens, queen, chess, 3D, TR 89 130 TR130 TR89/130 Lloyd Allison, Dept. Comp. Sci., Monash University, Australia 3168. lloyd@cs.monash.edu.au From icon-group-sender Thu May 27 18:17:08 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 27 May 1993 18:07:47 MST Received: by owl.cs.arizona.edu; Thu, 27 May 1993 18:07:49 MST Date: Thu, 27 May 93 18:17:08 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <668400@MTS.cc.Wayne.edu> Subject: String uniqueness Status: R Errors-To: icon-group-errors@cs.arizona.edu Does the Icon implementation store strings uniquely? I'm interested in knowing because it clearly affects the speed of string comparison and therefore the strategy for storing "symbols". If they are stored uniquely, I assume, string comparison is just comparison of a single pointer; if not, it requires scanning the strings character by character. Paul Abrahams reply to: abrahams@acm.org From icon-group-sender Fri May 28 07:54:02 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 28 May 1993 08:54:23 MST Received: by owl.cs.arizona.edu; Fri, 28 May 1993 08:54:21 MST Message-Id: <9305281446.AA47196@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: String uniqueness To: icon-group@cs.arizona.edu Date: Fri, 28 May 93 7:54:02 PDT In-Reply-To: <668400@MTS.cc.Wayne.edu>; from "Paul_Abrahams@MTS.cc.Wayne.edu" at May 27, 93 6:17 pm Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Paul Abrahams > > Does the Icon implementation store strings uniquely? I'm interested > in knowing because it clearly affects the speed of string comparison > and therefore the strategy for storing "symbols". If they are stored > uniquely, I assume, string comparison is just comparison of a single > pointer; if not, it requires scanning the strings character by character. No, strings are not stored uniquely. While clearly a win in some situations, I seem to recall that doing this all the time in a general language setting slows things down. Unfortunately, I don't have references to back up the claim. Ken Walker, kwalker@premenos.sf.ca.us ed for generally available, flexible text software. Commercial software for text analysis and manipulation covers only a fraction of research needs, and it is often expensive and hard to adapt or extend to fit a particular research problem. Software developed by individual researchers and labs is often experimental and hard to get, hard to install, under-documented, and sometimes unreliable. Above all, most of this software is incompatible. As a result, it is not at all uncommon for researchers to develop tailor-made systems that replicate much of the functionality of other systems and in turn create programs that cannot be re-used by others, and so on in an endless software waste cycle. The reusability of data is a much-discussed topic these days; similarly, we need "software reusability", to avoid the re-inventing of the wheel characteristic of much language-analytic research in the past three decades. The Text Software Initiative (TSI) is committed to solving this problem by working to o establish and publish guidelines and standards for the development of text software; o promulgate and coordinate the development of free TSI- conformant software. The scope of the TSI covers all areas of analysis and manipulation of all kinds of texts (written or spoken, mono-lingual or multi- lingual parallel, etc.), including markup of physical and logical text features, linguistic analysis and annotation, browsing and retrieval, statistical analysis, and other text-related tasks in research in computational linguistics, humanities computing, terminology and lexicography, speech, etc. The TSI software development effort is distributed, that is, anyone can contribute on a voluntary basis. This means that tools will be developed according to the contributors' priorities; however, the TSI is ultimately working towards the development of a comprehensive text handling system. To ensure software compatibility and reusability and enable distributed development, the TSI is committed to: o design and publish program interface conventions o determine and publish guidelines for programming style and documentation o stress separation of code and linguistic data to ensure (natural) language independence o emphasize breaking high-level text-handling tasks into more primitive, reusable functions o provide a library of primitive text-handling tools o maintain a task list and set priorities o circulate information such as progress reports, revisions to the standard, availability of new software, etc. o set up a mechanism for testing and evaluation o maintain mailing lists for comments, bug reports, suggestions, etc. The TSI works in relation with other standardization groups, notably the Text Encoding Initiative and the Expert Advisory Group on Language Engineering Standards (EAGLES). All TSI software is free in the sense defined in the Free Software Foundation's General Public License, which guarantees the freedom to copy, redistribute, and modify software, and protects this freedom by requiring those who pass on the software to include the rights to further redistribute it and see and change the code. Distribution of TSI software is accomplished in relation with other dissemination groups such as the Free Software Foundation, RELATOR, and the Linguistic Data Consortium. The TSI does not provide technical support, but organizes a network of voluntary consultants and support people. PROJECT COORDINATORS Nancy Ide, Vassar College, Poughkeepsie, New York, USA ide@cs.vassar.edu Jean Veronis, Universite de Provence/CNRS, Aix-en-Provence, France veronis@grtc.cnrs-mrs.fr GENERAL ADVISORY BOARD Susan Armstrong, ISSCO, Geneva Mark Liberman, Linguistic Data Consortium, University of Pennsylvania Makoto Nagao, Kyoto University Mark Olsen, ARTFL Project, University of Chicago Richard Stallman, Free Software Foundation, Cambridge, Massachusetts Donald Walker, Bellcore, Morristown New Jersey Antonio Zampolli, Istituto di Linguistica Computazionale, Pisa The TSI also includes a TECHNICAL ADVISORY BOARD of software developers. From icon-group-sender Sat May 29 02:27:04 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sat, 29 May 1993 09:25:27 MST Received: by owl.cs.arizona.edu; Sat, 29 May 1993 09:25:26 MST Date: Sat, 29 May 93 02:27:04 MST From: whm@grissom.sunquest.com (Bill Mitchell) Message-Id: <9305290927.AA02753@grissom.sunquest.com> To: icon-group@cs.arizona.edu Subject: Re: Comparative Languages (MUMPS?) Status: R Errors-To: icon-group-errors@cs.arizona.edu I've never worked with MUMPS, but I know of a company that uses it in a very large medical information system that is very successful. MUMPS is an old language, dating back to 1965 or so. MUMPS started as an operating system, i.e., the machine ran MUMPS, but now usually sits on top of an operating system. It's my opinion that MUMPS gets most of its punch from having a memory-managed string datatype and N-dimensional arrays that can be made persistent. (Voila -- instant hierarchical database!) Other factors are that MUMPS is a pretty simple language and appears to be easy to learn, and that a MUMPS environment typically provides an edit-run-edit-run cycle (i.e., no link step). However, there are some problems. All my MUMPS knowledge is second hand, so I hope somebody will correct me if I err. One problem is that the strings are *not* arbitrary length. I think the length defined by the standard is 256 chars, although some implementations allow up to 512 or perhaps longer. I don't know if arbitrary characters (e.g. a NUL) are allowed in strings or not. Program source is stored as persistent data, which is pretty cool, but raises problems with configuration management and version control. For example, if you replace routine "FOOBAR", *everybody* is then running with a new version of FOOBAR. I'm not sure if control structures like "if" and "while" are present in a traditional form or not. (For example, I've got a dim recollection that the clause of a do-loop must fit onto a single line of source.) A very common idiom is to store values as delimited fields. For example a person's name might be represented as "John/J/Smith". Typically, several levels of delimiters might be used. For example, [[1,2],[3,[4,5]]] in Icon might be represented as the string "/1!2/3!4#5/". A lot of computational energy seems to be expended on the assembly and disassembly of such strings. [[1,2],[3,[4,5]]] might also be represented as X(1) = "1/2" and X(2) = "3/4!5" or X(1,1) = 1, X(1,2) = 1, X(2,1) = 3, X(2,1,1) = 4 and X(2,1,2) = 5. Those subscripts could have been strings, if so desired. As far as I know, there's no really schema definition for the database -- the code defines the expected structure of the data. That means that you've got to be very careful with documentation of the format of everything in the database. If the schema changes, you go through the code with a fine tooth comb looking for uses of the old schema and rewrite as appropriate. MUMPS is typically implemented as an interpreter and some implementations don't fully analyze source until it is executed. It's therefore possible to hit a syntax error in production code. At one point in time there was a restriction on variable name lengths; I think it was a five or eight character max. I don't know if this still exists or not. A lot of successful commercial systems written in MUMPS are on the market, but I think MUMPS might give a person with a recent CS degree a severe case of culture shock! /------------------------------\ /----------------\ / Bill Mitchell \ / 7120 E. Kiva Way \ / Mitchell Software Engineering \O====/ Tucson, AZ, 85715 \ \ Consulting/Development/Training / \ 602-577-6431 / \ OO Methods/C++/C/Icon/UNIX / \ whm@mse.com / \------------------------------/ \----------------/ From icon-group-sender Sat May 22 12:41:52 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 31 May 1993 11:10:19 MST Received: by owl.cs.arizona.edu; Mon, 31 May 1993 11:10:18 MST Date: 22 May 93 12:41:52 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!wupost!tulane!usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@ucbvax.Berkeley.EDU (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: Icon on a mixed-architecture network Message-Id: <12770@sun13.scri.fsu.edu> References: <1993May20.134500.4321@mlfarm.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993May20.134500.4321@mlfarm.com> ron@mlfarm.com (Ronald Florence) writes: >I'm wondering what is the best way to install Icon on a network with >both Sun4 and Sun3 machines. ... >will the same executable run on either system? I don't >think there are any byte-swapping nasties between Sun3 and Sun4 >architectures. An interesting question. (I don't know the answer, by the way. Just musing...) When I first saw this question, my immediate reaction was "Of course the same executable will not run on either system! The Sun3 uses the 68xxx chip and the Sun4 uses the Sparc chip!" But then this was followed by the more rational thought that the file produced by icont is not a set of binary machine language programs, or at least I don't think it is. So by using an appropriate version of iconx (which is what the writer is talking about doing) it seems like it should work fine. As I say - just conjecture, as I don't know the answer. Anyoneknow? John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "You gotta know when to hold 'em/know when to fold 'em/ "know when to walk away/and know when to run..." From icon-group-sender Sun May 23 01:22:47 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 31 May 1993 11:10:35 MST Received: by owl.cs.arizona.edu; Mon, 31 May 1993 11:10:34 MST Date: 23 May 93 01:22:47 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon SLR(1) parser generator Message-Id: <1993May23.012247.29262@midway.uchicago.edu> References: <1993May17.225540.23285@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu goer@midway.uchicago.edu writes: >Does anyone want to try out an (experimental) SLR(1) parser generator >for Icon? Hmmm. I've mailed out a bunch of shell archives each day since I posted this, and I'm beginning to think it would be better just to put it up on alt.sources for now. Look for it there. I'll still mail out copies to anyone who asks. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun May 23 20:14:00 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 31 May 1993 11:10:58 MST Received: by owl.cs.arizona.edu; Mon, 31 May 1993 11:10:56 MST Date: 23 May 93 20:14:00 GMT From: cis.ohio-state.edu!math.ohio-state.edu!zaphod.mps.ohio-state.edu!malgudi.oar.net!ucbeh.san.uc.edu!ucunix.san.uc.edu!mandayrv@ucbvax.Berkeley.EDU (The Universal Hacker) Organization: University of Cincinnati Subject: Survey of set based languages Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi folks, I am doing a survey of high level languages based on sets. The only information I have currently is on the language SETL. I would appreciate any pointers to articles, magazines, books, etc. that will have more information on this issue. Thanks in advance -- ramanand@pumpkin.ece.uc.edu home: 513 281 9870 rmandaya@uceng.uc.edu office: 513 556 3025 mandayrv@ucunix.san.uc.edu ham: KB8GKL From icon-group-sender Mon May 31 11:43:54 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 31 May 1993 12:04:15 MST Received: by owl.cs.arizona.edu; Mon, 31 May 1993 12:04:14 MST Date: Mon, 31 May 1993 11:43:54 MST From: "Clint Jeffery" Message-Id: <199305311843.AA02129@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu Subject: Re: Icon on a mixed-architecture network Status: R Errors-To: icon-group-errors@cs.arizona.edu ron@mlfarm.com (Ronald Florence) writes: >I'm wondering what is the best way to install Icon on a network with >both Sun4 and Sun3 machines. ... >will the same executable run on either system? The easiest way to find out is probably to try it (and let us know!). In addition to the executable header and byte-order issues which you've already thought of, there are at least two more potential problems that come to mind: 1) word alignment: I believe Sparcs are longword aligned. 2) C structure layout: icode includes various data in C structure format, and the icont and iconx had better agree on what they look like in memory. From icon-group-sender Mon May 24 16:17:47 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Tue, 1 Jun 1993 15:03:45 MST Received: by owl.cs.arizona.edu; Tue, 1 Jun 1993 15:03:44 MST Date: 24 May 93 16:17:47 GMT From: mcsun!uknet!warwick!zaphod.crihan.fr!univ-lyon1.fr!scsing.switch.ch!news.unige.ch!NewsWatcher!user@uunet.uu.net (Boris Borcic) Organization: University of Geneva Subject: Yet another variation on queens (was Icon vs Prolog) Message-Id: References: <9305171538.AA58087@enlil.premenos.sf.ca.us> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu First of all, I would like to thank all who replied to my question on Icon and Prolog. In article <9305171538.AA58087@enlil.premenos.sf.ca.us>, Ken Walker wrote: [...] > Icon, on the other hand, > has more features and as an imperative languages gives you more > control and more flexibility. It might be interesting to look at > specific problems. > > Ken Walker, kwalker@premenos.sf.ca.us One example I have in mind is YAVQ : yet another variation on the queens problem. The problem : 1) Write a search algorithm that generates the first solution only (according to the lexicographic order on permutations), for each family of rotated and/or reflected solutions, by *pruning* the search tree ASAP rather than testing the generated solutions. 2) Write a search algorithm that chooses the next choicepoint among the remaining unoccupied rows *and* columns according to some criterion (say, that the breadth of the choicepoint is minimal). 3) Write a 3D version of 1+2, e.g. N^2 queens in N^3 cubic "board" (are there any 3d solutions to N^2 queens ? should one use plane diagonals, 3d diagonals, or both ?) Note that the number of symmetries usable to constrain the search raises from 8 in 2d to 48 in 3d. I have no code to propose, and indeed did not completely think this through. But I could find no easy way to maintain the data structure for implementing [2] (in the context of [1]) in Prolog, except by not using the in-built backtracking at all. If memory serves, the problem is both the absence of globals and the "total data amnesia" in Prolog, as noted by one of the previous posters. Regards, Boris Borcic From icon-group-sender Wed Jun 2 22:51:14 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 4 Jun 1993 15:12:24 MST Received: by owl.cs.arizona.edu; Fri, 4 Jun 1993 15:12:23 MST Date: 2 Jun 93 22:51:14 GMT From: agate!howland.reston.ans.net!usc!sdd.hp.com!portal!cup.portal.com!Eric-Amick@ucbvax.Berkeley.EDU (Richard E Amick) Organization: The Portal System (TM) Subject: Re: redirecting Icon output Message-Id: <82584@cup.portal.com> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >According to the Icon documentation, the -e option redirects output from >icont to the specified file. However, it doesn't seem to work. I have tried >the standard Unix redirection and pipe commands with no success. I am running >Icon v8.7 on a Sun workstation with SunOS 4.1.1. Any help would be greatly >appreciated. For what it's worth, -e doesn't do anything in version 8.10, either, but it's supposed to redirect just standard error, not standard output. To redirect standard error, use "2> filename" with the Bourne or Korn shells, and ">& filename" with the C shell. From icon-group-sender Mon May 31 21:53:19 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sat, 5 Jun 1993 18:52:17 MST Received: by owl.cs.arizona.edu; Sat, 5 Jun 1993 18:52:16 MST Date: 31 May 93 21:53:19 GMT From: mercury.hsi.com!mlfarm!auda!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: Re: Icon on a mixed-architecture network Message-Id: <1993May31.215319.710@mlfarm.com> References: <199305311843.AA02129@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu "Clint Jeffery" writes: In addition to the executable header and byte-order issues which you've already thought of, there are at least two more potential problems that come to mind: 1) word alignment: I believe Sparcs are longword aligned. 2) C structure layout: icode includes various data in C structure format, and the icont and iconx had better agree on what they look like in memory. To my astonishment and delight, the same executables work on both architectures (sparc and sun3). I use the compact headers on Icon executables #!/usr/local/bin/iconx and have the PATH environmental variables set up so a user on any machine gets the appropriate iconx. We put icon executables, along with shell scripts, in /usr/local/share/bin, which is shared by sparc and m68030 machines. Another big plus for Icon... -- Ronald Florence ron@mlfarm.com From icon-group-sender Wed Jun 2 14:03:47 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sun, 6 Jun 1993 21:01:50 MST Received: by owl.cs.arizona.edu; Sun, 6 Jun 1993 21:01:49 MST Date: 2 Jun 93 14:03:47 GMT From: cis.ohio-state.edu!math.ohio-state.edu!sdd.hp.com!saimiri.primate.wisc.edu!zazen!post.its.mcw.edu!not-for-mail@ucbvax.Berkeley.EDU (Chris Tenaglia) Organization: Medical College of Wisconsin (Milwaukee, WI) Subject: Re: Comparative Languages (MUMPS?) Message-Id: <1uic03INNah3@post.its.mcw.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Some of the limitations of MUMPs mentioned earlier may be true, (I haven't finished reading the manuals yet). I have never seen a pretty MUMPS program. It's almost like idiomatic icon. What I don't like is that the data is kept in a container file on the host OS, and is not very accessible from the outside. What I think is in it's favor is performance and scalability. One of our departments has a MUMPS database that is huge; one single 16GB file that crosses many striped disk drives and response time for searches and data entry by 300 simultaneous users is not more than one or two seconds. Of course the horsepower of a VAX6620 helps, but I think Icon might be hard pressed to implement such an application system and environment. By the way, I'm not switching to MUMPS as my favorite language. Most of MY work is ideal in Icon. But if I had to do something massive and multiuser, I think I might look at something like MUMPS because of its performance and scalability. Chris Tenaglia (system manager) | tenaglia@mis.mcw.edu Medical College of Wisconsin (MIS Dept) 8701 W. Watertown Plank Rd. Milwaukee, WI 53226 -- Chris Tenaglia (system manager) | tenaglia@mis.mcw.edu Medical College of Wisconsin | 8701 W. Watertown Plank Rd. | Ce que vous voyez est Milwaukee, WI 53226 (414)257-8765 | ce que vous obtenez ! From icon-group-sender Wed Jun 9 13:56:54 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 9 Jun 1993 12:43:44 MST Received: by owl.cs.arizona.edu; Wed, 9 Jun 1993 12:43:42 MST Date: Wed, 9 Jun 93 13:56:54 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <677397@MTS.cc.Wayne.edu> Subject: Initialization files for Icon programs Status: RO Errors-To: icon-group-errors@cs.arizona.edu Here's a problem I ran into recently, which probably occurs with many Icon programs. My program, on starting, reads in certain initialization files. I want to keep those files in the same directory as the program's icode file, i.e., the .icx file (or, for Unix, the "p" file for program p.icn). However, I don't want to require the program to know the full path name of the initialization files, since that might change according to where the program and its files have been installed. So here's the problem: how, within the program, can I determine the full path name of the icode file so that I can construct the full path name of the initialization files? I'm interested in the solution to this problem for three cases: DOS, OS/2, and Unix. Is it much easier in some systems than in others? Thanks. Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Thu Jun 10 04:38:21 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 11 Jun 1993 09:04:21 MST Received: by owl.cs.arizona.edu; Fri, 11 Jun 1993 09:04:20 MST Date: 10 Jun 93 04:38:21 GMT From: swrinde!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@gatech.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Initialization files for Icon programs Message-Id: <1993Jun10.043821.198@midway.uchicago.edu> References: <677397@MTS.cc.Wayne.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <677397@MTS.cc.Wayne.edu> Paul_Abrahams@MTS.cc.Wayne.edu writes: > >So here's the problem: how, within the program, can I determine the full >path name of the icode file so that I can construct the full path name of >the initialization files? Paul, I wonder why you'd want to do this, at least under UNIX. UNIX executables usually go in a bin directory. Initialization files go in a lib directory. They get hashed separately, and their permissions and ownership conventions differ. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Jun 11 16:36:35 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 11 Jun 1993 15:32:44 MST Received: by owl.cs.arizona.edu; Fri, 11 Jun 1993 15:32:43 MST Date: Fri, 11 Jun 1993 16:36:35 -0400 From: Mary F. Fernandez Message-Id: <9306112036.AA15264@cs.Princeton.EDU> To: icon-group@cs.arizona.edu Subject: Profiling Icon programs Status: R Errors-To: icon-group-errors@cs.arizona.edu Is profiling supported by either the interpreter or compiler? I think I read something about profiling in an Icon Newsletter but can't find the issue. Thanks, Mary Fernandez mff@cs.princeton.edu From icon-group-sender Mon Jun 7 17:49:10 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sun, 13 Jun 1993 13:23:25 MST Received: by owl.cs.arizona.edu; Sun, 13 Jun 1993 13:23:24 MST Date: 7 Jun 93 17:49:10 GMT From: agate!usenet.ins.cwru.edu!wariat.org!wariat.org!ppetto@ucbvax.Berkeley.EDU (Peter J. Petto) Organization: Akademia Pana Kleksa, Public Access Uni* Site Subject: Pattern-Matching Help Request Message-Id: <1993Jun7.174910.21523@wariat.org> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm looking for some help formulating a pattern-matching expression. It is to be used as part of a filter I use to make Usenet news articles more printable/readable. I'm looking for something that will test a string for a pattern analgous to the following regular expression: %From [A-Za-z0-9.]\@ I'm looking to replace part of an existing Icon program which now reads: if match("From usenet" | "From neoucom" | "From wariat", line) then... with something akin to the above that will match a wider (and unknown) set of senders such as: From andrew@... From upcsc4@... From the.universal.hacker@ etcetera (My local news software just changed and now shows the orignator of each news article, rather than the relay-route.) I'd appreciate any and all assistance. Thanks. --- Peter Petto | ppetto@wariat.org Bay Village, Ohio | 73125.617@compuserve.com From icon-group-sender Mon Jun 7 16:14:09 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sun, 13 Jun 1993 13:24:35 MST Received: by owl.cs.arizona.edu; Sun, 13 Jun 1993 13:24:34 MST Date: 7 Jun 93 16:14:09 GMT From: agate!howland.reston.ans.net!newsserver.jvnc.net!newsserver.cshl.org!newsserver.cshl.org!not-for-mail@ucbvax.Berkeley.EDU ( CSHL) Organization: Cold Spring Harbor Lab, NY Subject: Re: Survey of set based langu Message-Id: <1uvpghINN2h7@phage.cshl.org> References: <2e.90.48.0NBBF2A7@lill.frmug.fr.mugnet.org> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >I am doing a survey of high level languages based on sets. The only >information I have currently is on the language SETL. I would appreciate any >pointers to articles, magazines, books, etc. that will have more information >on this issue. > >Thanks in advance >-- >ramanand@pumpkin.ece.uc.edu home: 513 281 9870 >rmandaya@uceng.uc.edu office: 513 556 3025 >mandayrv@ucunix.san.uc.edu ham: KB8GKL The language APL is very much set based, only cast in the language of vectors and matrices. For example, {x|predicate(x)} is written predicate(x)/x. The newer APL2 is indeed based on the development of a "theory of arrays", modelled after Cantor's set theoretic axioms. APL2 and APL are/were very popular languages for solving very hard problems. The best source is APL Conference Proceedings (annual, ACM), particularly Trenchard More's papers on array theory. What has this got to do with Icon? Well, I've always thought Icon's flow control would complement APL's data parallel model rather nicely... -- Bill Chang (wchang@cshl.org) From icon-group-sender Mon Jun 7 21:49:33 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 14 Jun 1993 09:36:26 MST Received: by owl.cs.arizona.edu; Mon, 14 Jun 1993 09:36:25 MST Date: 7 Jun 93 21:49:33 GMT From: agate!howland.reston.ans.net!math.ohio-state.edu!caen!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Pattern-Matching Help Request Message-Id: <1993Jun7.214933.25646@midway.uchicago.edu> References: <1993Jun7.174910.21523@wariat.org> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu ppetto@wariat.org (Peter J. Petto) writes: > >I'm looking for something that will test a string for a pattern >analgous to the following regular expression: > > %From [A-Za-z0-9.]\@ You probably mean: %From [A-Za-z0-9.]*@ Somewhere you should say namechars := &letters ++ &digits ++ '.' so you can use this identifier the same as you would [A-Za-z0-9]. The key is that tab(many(x)) in Icon is the standard idiom for "move forward from the cur- rent position up to the first character not in x." The next matching func- tion then picks up where tab(many(x)) leaves off: if line ? (="%From ", tab(many(namechars)), ="@") then... Icon's string scanning functions are a bit more verbose than regular expres- sions, for better or for worse - but far more powerful. Conversion is always trivial once you get the hang of things. Icon sacrifices terseness and some speed for power, elegance, and consistency with the rest of the language. But I guess this is turning into a commentary on the relative merits of var- ious string-matching (sub-)languages. >I'd appreciate any and all assistance. Thanks. Hope I helped. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Jun 16 08:28:28 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 08:28:28 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 08:28:27 MST Via: uk.ac.manchester.computer-science; Wed, 16 Jun 1993 02:10:46 +0100 From: Steve Holden Date: Tue, 15 Jun 93 23:11:44 BST Message-Id: <1040.9306152211@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu, goer <@msuinfo,@uchinews:goer@ellis> Subject: Re: Pattern-Matching Help Request Status: R Errors-To: icon-group-errors@cs.arizona.edu Further to Richard Gorwitz's suggestion that if line ? (="%From ", tab(many(namechars)), ="@") then... be used to pattern-match senders' names, it is also, of course, possible to handle _particular_ recipients. The simplest way is to define a list and use that, e.g.: senders := ["steve","the.happy.hacker",...,"icon-group"] ... if line ? (="%From",=!senders,="@") then ... If you wanted to identify the paricular sender you could change the second expression in the mutual evaluation to an assignment, as in if line ? (="%From ", s := =!senders,="@") It would probably turn out to be efficient to use a set combined with the Goerwitz technique, as in senders := set(["steve","the.happy.hacker",...,"icon-group"]) ... if line ? (="%From ",member(senders,s:=tab(many(namechars))),="@") then ... One of the valuable features of the Icon language is the ability to enlarge an expression without changing its result to enhance the actions your code takes. regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Tue Jun 8 14:13:36 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 08:32:05 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 08:32:04 MST Date: 8 Jun 93 14:13:36 GMT From: mcsun!sun4nl!rulway.LeidenUniv.nl!ruls41.LeidenUniv.nl!ruiter@uunet.uu.net (Jan Peter de Ruiter) Organization: Leiden University Subject: compilable subset Message-Id: <1993Jun8.141336.25196@rulway.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu A lot of Icon features and constructs depend on Icon being interpreted. These features are very desirable, according to Icon users, and therefore a certain performance loss is tolerable. However, sometimes people like to have a higher performance. Someone in the Icon group once wrote that there is no "red hot" Icon compiler in written in Icon. (I think it was Richard Goerwitz) Being relatively unfamiliar with the tricky details of the implementation of Icon, my question is this: *Given* the constraint that The Given Language should be about as fast as, say, pascal, what Icon features should be removed/redefined in order to pull the trick. Mind you, I am not in any way suggesting changes to Icon, I'm just trying to find out what is the most "Iconish" language possible that can compete in speed with pascal (or C++, you get the idea...) As an example, backtracking and garbage collecting are probably (?) features that The Given Language should not have. However, the absence of declarations for strings & integers can probably be resolved in some way. I'd really like comments from people who are familiar with the implementation of Icon, and from people who have opinions on what features of Icon are distinctly "Iconish." If it turns out to be possible to define a language that is as fast as pascal, and a lot more convenient (in an Iconish fashion), I'd like to spend some time trying to implementing it. If it is not clear what my question entails, please post! I'll then try to clarify. Greetings, Jan ----------------------------------------------------- Jan de Ruiter Leiden University Dept. of Information Science for the Social Sciences The Netherlands ruiter@ruls41.leidenuniv.nl From icon-group-sender Wed Jun 16 09:33:24 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 08:32:56 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 08:32:54 MST Date: Wed, 16 Jun 93 09:33:24 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <682309@MTS.cc.Wayne.edu> Subject: Output to &error Status: RO Errors-To: icon-group-errors@cs.arizona.edu I executed the following program: procedure main() write(&error, "hello") end and got the output 0hello This happened both under DOS Icon and OS/2 Icon. What is that 0 all about? Also, under OS/2 Icon, I got a complaint about a missing message file after my program aborted. What is the name of the missing file, and where does it need to be? And lastly: are messages like this better sent to icon-project rather than to icon-group? Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Wed Jun 16 08:41:58 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 08:56:30 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 08:56:30 MST Date: Wed, 16 Jun 1993 08:41:58 MST From: "Ralph Griswold" Message-Id: <199306161541.AA02753@cheltenham.cs.arizona.edu> To: Paul_Abrahams@MTS.cc.Wayne.edu, icon-group@cs.arizona.edu Subject: Re: Output to &error Cc: gmt Status: R Errors-To: icon-group-errors@cs.arizona.edu For problems like this, we need to know the version of Icon you're using (the value of &version). Messages of this kind should be posted to icon-project@cs.arizona.edu. 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-9618 (fax) From icon-group-sender Wed Jun 16 09:01:48 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 11:03:57 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 11:03:56 MST Message-Id: <9306161600.AA46110@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Output to &error To: Paul_Abrahams@MTS.cc.Wayne.edu, icon-group@cs.arizona.edu Date: Wed, 16 Jun 93 9:01:48 PDT In-Reply-To: <682309@MTS.cc.Wayne.edu>; from "Paul_Abrahams@MTS.cc.Wayne.edu" at Jun 16, 93 9:33 am Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu Paul, I think you have the wrong keyword. Don't you want to write to &errout? Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Wed Jun 9 07:06:29 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 11:04:55 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 11:04:54 MST Date: 9 Jun 93 07:06:29 GMT From: munnari.oz.au!yoyo.aarnet.edu.au!arnie.systems.sa.gov.au!state.systems.sa.gov.au!enisaxg@tcgould.tn.cornell.edu Organization: State Systems, South Australia Subject: Icon for Solaris 2.1 Message-Id: <1993Jun9.163629.27235@state.systems.sa.gov.au> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is Icon v8.10 for Unix working on Solaris 2.1 with the SUNPRO C compiler? Any help would be appreciated. Thanks in advance, Alexander Gunjko [ gunjkoa@dep.sa.gov.au ] Systems Administrator South Australian Office of Planning and Urban Development. From icon-group-sender Wed Jun 16 15:15:22 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 15:20:18 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 15:20:17 MST Date: Wed, 16 Jun 93 15:15:22 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <682655@MTS.cc.Wayne.edu> Subject: Finding record component names Status: R Errors-To: icon-group-errors@cs.arizona.edu Given the name of a record type or, alternatively, an object of that type, is there a way to find out the names of the record components? For example, with the definition record complex(re,im) is there a way to determine that the components of a "complex" object are "re" and "im"? Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Wed Jun 16 13:26:48 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 16 Jun 1993 15:21:12 MST Received: by owl.cs.arizona.edu; Wed, 16 Jun 1993 15:21:10 MST Date: Wed, 16 Jun 1993 13:26:48 MST From: "Clint Jeffery" Message-Id: <199306162026.AA14224@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu In-Reply-To: (Jan Peter de Ruiter's message of 8 Jun 93 14:13:36 GMT <1993Jun8.141336.25196@rulway.LeidenUniv.nl> Subject: Re: compilable subset Status: R Errors-To: icon-group-errors@cs.arizona.edu I expect there will be a lot of opinions and answers to Jan de Ruiter's question about an Iconish language the speed of Pascal. Here are just a couple thoughts. Its not like no one has thought of speeding Icon up before. If you are going to remove generators and goal-directed evaluation as well as garbage collection in order to do it, though, your subset language is not much like Icon anymore. You might as well start with a Pascal compiler and modify it to have a few "friendly" Icon-like features. Anyhow, no one has ever convinced me that a red hot compiler for Icon cannot be done, it is just Very Hard. Ken Walker got us more than halfway there by building a working compiler with all the static information that is needed to do the job. Icon compiled programs already run quite a bit faster than the interpreter; the Icon compiler simply needs a large development effort put into further optimization of the generated code and the data representations used for common values. The problem now is finding someone truly obsessed with the problem, and obtaining funding for it. Clint Jeffery cjeffery@cs.arizona.edu