From icon-group-sender Wed Sep 23 21:20:30 1992 Received: by cheltenham.cs.arizona.edu; Thu, 24 Sep 1992 04:53:54 MST Date: 23 Sep 92 21:20:30 GMT From: wupost!tulane!rouge!mgr@decwrl.dec.com (Mark Radle) Organization: The Center for Advanced Computer Studies Subject: ftp site for icon Message-Id: <1992Sep23.212030.27534@usl.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Can anyone point me to a ftp site that contains the source code for icon. We are running a network of Sun ss2s with SunOS 4.1.2. Thanks in advance. Mark G. Radle mgr@cacs.usl.edu From icon-group-sender Wed Sep 23 23:25:54 1992 Received: by cheltenham.cs.arizona.edu; Fri, 25 Sep 1992 04:30:20 MST Date: 23 Sep 92 23:25:54 GMT From: agate!spool.mu.edu!darwin.sura.net!convex!news.oc.com!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: ftp site for icon Message-Id: <1992Sep23.232554.19736@midway.uchicago.edu> References: <1992Sep23.212030.27534@usl.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >Can anyone point me to a ftp site that contains the source code >for icon. We are running a network of Sun ss2s with SunOS 4.1.2. Try cs.arizona.edu. Use the interpreter for a first installation. The installation is set up for both interpreter and compiler. It's find to build the compiler. Just don't encourage users to use it until they are thoroughly familiar with Icon. It's an advanced tool. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Sep 25 21:05:58 1992 Received: by cheltenham.cs.arizona.edu; Sat, 26 Sep 1992 13:43:42 MST Date: 25 Sep 92 21:05:58 GMT From: dog.ee.lbl.gov!hellgate.utah.edu!caen!uwm.edu!linac!uchinews!iitmax!grace@ucbvax.Berkeley.EDU (Thom Grace) Organization: Illinois Institute of Technology Subject: Teaching Icon. Message-Id: <1992Sep25.210558.23811@iitmax.iit.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu A quick, survey-type question: Which colleges and universities teach Icon in one or more classes? We do so here at IIT, but I'm wondering how widespread Icon has become in the curriculum. Reply by email; save bandwidth. I'll summarize if there is interest. Remember - I'm only asking about Icon in the curriculum, not research projects, etc. Thanks! --- T. Grace (grace@iitmax.iit.edu) From icon-group-sender Tue Sep 29 06:29:25 1992 Received: by cheltenham.cs.arizona.edu; Tue, 29 Sep 1992 10:05:33 MST Via: uk.ac.edinburgh.festival; Tue, 29 Sep 1992 14:28:56 +0100 Date: 29 Sep 92 14:28:52 BST From: R J Hare Subject: Icon version 8.7 To: icon-group@cs.arizona.edu Message-Id: <9209291428.aa09933@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu Has anyone succeded in getting Icon version 8.7 to run on a Sequent running System 5 (PTX) yet? We had a go last week and so far have not succeeded. Thanks Roger Hare. From icon-group-sender Thu Oct 1 10:40:09 1992 Received: by cheltenham.cs.arizona.edu; Thu, 1 Oct 1992 13:04:36 MST Date: 01 Oct 1992 10:40:09 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Unix Logging Out To: icon-group@cs.arizona.edu Message-Id: <01GPFIYT5FTU8WWF6P@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 If I have a simple abc menu that looks something like : M : MAIL C : CHANGE PASSWORD L : LOGOUT Is there a way to log out cleanly. Unix seems to pop processes out all over the place. I use icon 8.7 under ultrix 4.2a. My background is chiefly VMS. There's probably a real simple answer I can't see because of my background. Thanks, 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 Oct 3 21:13:17 1992 Received: by cheltenham.cs.arizona.edu; Sat, 3 Oct 1992 19:58:28 MST Date: Sat, 3 Oct 92 21:13:17 CDT From: "Richard L. Goerwitz" Message-Id: <9210040213.AA13493@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: storing objects Status: R Errors-To: icon-group-errors@cs.arizona.edu Let's say that I have a large table that I want to store and recreate at run-time in a program. What is the best way of doing this? What I mean by "best" is primarily "fastest," and not "smallest." I normally use codeobj (from the IPL) for such tasks, but I note that in this in- stance, the tables in question take ten to twenty seconds to decode and turn into an actual table at run-time. Any better ideas? -Richard From icon-group-sender Sat Oct 3 20:57:41 1992 Received: by cheltenham.cs.arizona.edu; Sun, 4 Oct 1992 06:39:02 MST Date: Sat, 3 Oct 92 20:57:41 -0700 From: wgg@cs.UCSD.EDU (William Griswold) Message-Id: <9210040357.AA05603@gremlin> To: goer@midway.uchicago.edu, icon-group@cs.arizona.edu Subject: Re: storing objects Status: R Errors-To: icon-group-errors@cs.arizona.edu Richard, Well, you might be able to exploit the properties of your specific tables. For example, if your keys and elements are all ``printable'', then a simple scheme of writing out a list of (key,elem) pairs in some simple format would be easiest. However, if you have pointers in your objects, then you need some way of encoding pointers, which is much trickier to do something simple with. In particular, you need some way of being able to uniquely identifying an object so that you can recreate the pointer structure. You could do this by generating a unique label for every object, and then use the label in place of the object in the (key,elem) pairs: (key,label[elem]). You would then print a second table of (label[elem],elem) so you could reconstruct the original objects. Sorry if this seems a little vague. Bill Griswold UCSD, Computer Sci and Engr. wgg@cs.ucsd.edu From icon-group-sender Fri Oct 2 02:45:23 1992 Received: by cheltenham.cs.arizona.edu; Mon, 5 Oct 1992 05:45:07 MST Date: 2 Oct 92 02:45:23 GMT From: uchinews!ellis!goer@uunet.uu.net (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Unix Logging Out Message-Id: <1992Oct2.024523.2937@midway.uchicago.edu> References: <01GPFIYT5FTU8WWF6P@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 TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) writes: > >If I have a simple abc menu that looks something like : > > M : MAIL > C : CHANGE PASSWORD > L : LOGOUT > >Is there a way to log out cleanly? Under UNIX, processes like shells (i.e. command interpreters) normally get run right on login, and unless you "exec" a program (and overlay that shell), it waits for your application to finish, then resumes its work. Under normal circumstances, you can't log out from any of your login shell's child processes. You have to quit everything else, and jump back to the login shell and log out from there. You could get around this a) by finding your login shell and then killing it manually (a la system("kill -9 "||process_id) where pro- cess_id is the ID of your login shell. This is very un-UNIXish. It's normally presumed that one will not *want* to log out with processes still active. Does this make any sense? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Oct 5 12:16:43 1992 Received: by cheltenham.cs.arizona.edu; Mon, 5 Oct 1992 14:14:16 MST Message-Id: <199210051618.AA00842@optima.cs.arizona.edu> From: keil@apollo.hp.com Date: Mon, 5 Oct 1992 12:16:43 -0400 In-Reply-To: "Richard L. Goerwitz" "storing objects" (Oct 3, 9:13pm) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: "Richard L. Goerwitz" , icon-group@cs.arizona.edu Subject: Re: storing objects Status: R Errors-To: icon-group-errors@cs.arizona.edu >Let's say that I have a large table that I want to store and recreate >at run-time in a program. What is the best way of doing this? What >I mean by "best" is primarily "fastest," and not "smallest." >Any better ideas? >-Richard What is large? 1k, 10k, 100k elements? With the old scheme of non-expandable tables, I found that increasing the initial table size had a big effect for tables of over a thousand elements. I'm not sure where the breakover point is for the newer expandable table mechanism, but I suspect that if you make the initial table size at least as big as, if not twice that size of, your table, that things will go faster. At one point, back in the version sevens, I added a second parameter to table [table(x,size)] to set the initial size of the tablas needed. This seemed more elegant that just always using a larger table. On the other hand, with virtual memory systems, You may not care if the initial table size is always 10k elememts (if you decide to just staticly increase the initial allocation size.) -Mark From icon-group-sender Mon Oct 5 14:41:51 1992 Received: by cheltenham.cs.arizona.edu; Mon, 5 Oct 1992 15:44:59 MST Date: Mon, 5 Oct 92 14:41:51 -0700 From: wgg@cs.UCSD.EDU (William Griswold) Message-Id: <9210052141.AA13973@gremlin> To: goer@midway.uchicago.edu, icon-group@cs.arizona.edu, keil@apollo.hp.com Subject: Re: storing objects Status: R Errors-To: icon-group-errors@cs.arizona.edu >From: keil@apollo.hp.com >Date: Mon, 5 Oct 1992 12:16:43 -0400 >To: "Richard L. Goerwitz" , > icon-group@cs.arizona.edu >Subject: Re: storing objects > >>Let's say that I have a large table that I want to store and recreate >>at run-time in a program. What is the best way of doing this? What >>I mean by "best" is primarily "fastest," and not "smallest." >>Any better ideas? >>-Richard > > What is large? 1k, 10k, 100k elements? > With the old scheme of non-expandable tables, I found that increasing > the initial table size had a big effect for tables of over a thousand > elements. I'm not sure where the breakover point is for the newer > expandable table mechanism, but I suspect that if you make the initial > table size at least as big as, if not twice that size of, your table, > that things will go faster. At one point, back in the version sevens, > I added a second parameter to table [table(x,size)] to set the initial > size of the tablas needed. This seemed more elegant that just always using > a larger table. On the other hand, with virtual memory systems, > You may not care if the initial table size is always 10k elememts (if you > decide to just staticly increase the initial allocation size.) > >-Mark The new table mechanism actually expands the number of ``slots'' or ``buckets'' in the table as elements are added. This provides good table performance through about 2^16 (64k) elements for 32 bit machines, less on others. It is not hard to tweak the implementation to substantially increase that threshold for little cost in space (i.e., you can double the threshold for about 8 bytes in space for each table, I believe). The new mechanism also takes less space for small tables, reducing memory requirements for applications that use many small tables. Bill Griswold UCSD wgg@cs.ucsd.edu From icon-group-sender Sat Oct 3 04:14:43 1992 Received: by cheltenham.cs.arizona.edu; Tue, 6 Oct 1992 06:56:50 MST Date: 3 Oct 92 04:14:43 GMT From: cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!access.usask.ca!ccu.umanitoba.ca!rahardj@beaver.cs.washington.edu (Budi Rahardjo) Organization: University of Manitoba, Winnipeg, Canada Subject: Re: Unix Logging Out Message-Id: <1992Oct3.041443.21496@ccu.umanitoba.ca> References: <01GPFIYT5FTU8WWF6P@mis.mcw.edu>, <1992Oct2.024523.2937@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 TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) writes: > >If I have a simple abc menu that looks something like : > > M : MAIL > C : CHANGE PASSWORD > L : LOGOUT > >Is there a way to log out cleanly? You might want to try executing `kill -1 -1` if LOGOUT is selected. -- budi -- Budi Rahardjo Unix Support - Computer Services - University of Manitoba From icon-group-sender Mon Oct 5 03:07:06 1992 Received: by cheltenham.cs.arizona.edu; Tue, 6 Oct 1992 10:22:24 MST Date: 5 Oct 92 03:07:06 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: offending program Message-Id: <1992Oct5.030706.477@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 Abstract discussions aren't too useful, always. Here's an example of a simple program created by the parser generator whose tables I want to be able to store. The following example initializes itself by decoding a string encoded by "encode" (see codeobj.icn in the IPL). Should work with version 8 installations. For the compiler, uncom- ment the invocable declaration. I have compiled the program success- fully, but haven't gotten the executable to run. Compile, execute, and type something like "5 + 5," then hit a CR. -Richard ------------------------------- cut here -------------------------------- #invocable "ACT", "symbol", "TOK" global ID_tbl procedure main() iparse(&input) end procedure _0001(arg1) return end procedure _0003(arg1,arg2) return end procedure _0005(arg1) return end procedure _0007(arg1,arg2) line_number +:= 1 return write(arg1) end procedure _0009(arg1) if not (return \ID_tbl[arg1]) then write(&errout, "uninitialized variable, line ", line_number) fail end procedure _0011(arg1,arg2,arg3) initial ID_tbl := table() ID_tbl[arg1] := arg3 return arg3 end procedure _0013(arg1,arg2,arg3) return arg1 + arg3 end procedure _0015(arg1,arg2,arg3) return arg1 - arg3 end procedure _0017(arg1,arg2,arg3) return arg1 * arg3 end procedure _0019(arg1,arg2,arg3) return arg1 / arg3 end procedure _0021(arg1,arg2,arg3) return arg1 % arg3 end procedure _0023(arg1,arg2,arg3) return arg1 ^ arg3 end procedure _0025(arg1,arg2,arg3) return arg2 end procedure _0027(arg1) if find(".", arg1) then return real(arg1) else return integer(arg1) end # I use ximage for debugging; remove it if you don't need it. link codeobj, ximage record ACT(str, state, by_rule, sym, size) record symbol(str, terminal) record TOK(sym, str) global line_number, errors # # iparse: file -> ? # stream -> ? # # Where stream is an open file, and ? represents the user-defined # result of a completed parse of file, from the current location # up to the point where the parser executes an "accept" action. # # The second to fifth arguments are used on recursive calls from # the error handler, iparse_error. Ignore them, unless you are # sure of what you are doing! # procedure iparse(stream, state_stack, value_stack, next_token, err_state) local start_symbol, token, act, arglist static alst, glst #global line_number, errors initial { alst := decode("l7341Lla122T0n1s(lb21R3sACT5sshift1i80n0n0n2sCR_ lc21R3sACT5sshift1i50n0n0n2sIDld21R3sACT5sshift1i70n0n0n3sNU_ Mle21R3sACT5sshift1i90n0n0nlf31T0n1s$lg21R3sACT6saccept0n0n0_ n0nlh38T0n1s$li28R3sACT6sreduce0n5s_00011sS1i1lj163T0n1s$lk3_ 3R3sACT6sreduce0n5s_00036sstream1i11s(ll21R3sACT5sshift1i80n_ 0n0n2sCRlm21R3sACT5sshift1i50n0n0n2sIDln21R3sACT5sshift1i70n_ 0n0n3sNUMlo21R3sACT5sshift1i90n0n0nlp201T0n1s$lq31R3sACT6sre_ duce0n5s_00054scalc1i11s(lr31R3sACT6sreduce0n5s_00054scalc1i_ 12sCRls31R3sACT6sreduce0n5s_00054scalc1i12sIDlt31R3sACT6sred_ uce0n5s_00054scalc1i13sNUMlu31R3sACT6sreduce0n5s_00054scalc1_ i1lv216T0n1s%lw22R3sACT5sshift2i160n0n0n1s*lx22R3sACT5sshift_ 2i140n0n0n1s+ly22R3sACT5sshift2i120n0n0n1s-lz22R3sACT5sshift_ 2i130n0n0n1s/laa22R3sACT5sshift2i150n0n0n2sCRlab22R3sACT5ssh_ ift2i110n0n0n1s^lac22R3sACT5sshift2i170n0n0nlad314T0n1s%lae3_ 1R3sACT6sreduce0n5s_00094sexpr1i11s*laf31R3sACT6sreduce0n5s__ 00094sexpr1i11s+lag31R3sACT6sreduce0n5s_00094sexpr1i11s-lah3_ 1R3sACT6sreduce0n5s_00094sexpr1i11s/lai31R3sACT6sreduce0n5s__ 00094sexpr1i11s=laj22R3sACT5sshift2i180n0n0n2sCRlak31R3sACT6_ sreduce0n5s_00094sexpr1i11s^lal31R3sACT6sreduce0n5s_00094sex_ pr1i1lam98T0n1s(lan22R3sACT5sshift2i210n0n0n2sIDlao22R3sACT5_ sshift2i200n0n0n3sNUMlap22R3sACT5sshift2i220n0n0nlaq283T0n1s_ %lar31R3sACT6sreduce0n5s_00274sexpr1i11s*las31R3sACT6sreduce_ 0n5s_00274sexpr1i11s+lat31R3sACT6sreduce0n5s_00274sexpr1i11s_ -lau31R3sACT6sreduce0n5s_00274sexpr1i11s/lav31R3sACT6sreduce_ 0n5s_00274sexpr1i12sCRlaw31R3sACT6sreduce0n5s_00274sexpr1i11_ s^lax31R3sACT6sreduce0n5s_00274sexpr1i1lay44T0n1s$laz33R3sAC_ T6sreduce0n5s_00036sstream1i2lba206T0n1s$lbb31R3sACT6sreduce_ 0n5s_00074scalc1i21s(lbc31R3sACT6sreduce0n5s_00074scalc1i22s_ CRlbd31R3sACT6sreduce0n5s_00074scalc1i22sIDlbe31R3sACT6sredu_ ce0n5s_00074scalc1i23sNUMlbf31R3sACT6sreduce0n5s_00074scalc1_ i2lbg95T0n1s(lbh21R3sACT5sshift1i80n0n0n2sIDlbi21R3sACT5sshi_ ft1i70n0n0n3sNUMlbj21R3sACT5sshift1i90n0n0n3llbg3llbg3llbg3l_ lbg3llbg3llbglbk219T0n1s%lbl22R3sACT5sshift2i350n0n0n1s)lbm2_ 2R3sACT5sshift2i300n0n0n1s*lbn22R3sACT5sshift2i330n0n0n1s+lb_ o22R3sACT5sshift2i310n0n0n1s-lbp22R3sACT5sshift2i320n0n0n1s/_ lbq22R3sACT5sshift2i340n0n0n1s^lbr22R3sACT5sshift2i360n0n0nl_ bs313T0n1s%lbt31R3sACT6sreduce0n5s_00094sexpr1i11s)lbu31R3sA_ CT6sreduce0n5s_00094sexpr1i11s*lbv31R3sACT6sreduce0n5s_00094_ sexpr1i11s+lbw31R3sACT6sreduce0n5s_00094sexpr1i11s-lbx31R3sA_ CT6sreduce0n5s_00094sexpr1i11s/lby31R3sACT6sreduce0n5s_00094_ sexpr1i11s=lbz22R3sACT5sshift2i370n0n0n1s^lca31R3sACT6sreduc_ e0n5s_00094sexpr1i13llamlcb282T0n1s%lcc31R3sACT6sreduce0n5s__ 00274sexpr1i11s)lcd31R3sACT6sreduce0n5s_00274sexpr1i11s*lce3_ 1R3sACT6sreduce0n5s_00274sexpr1i11s+lcf31R3sACT6sreduce0n5s__ 00274sexpr1i11s-lcg31R3sACT6sreduce0n5s_00274sexpr1i11s/lch3_ 1R3sACT6sreduce0n5s_00274sexpr1i11s^lci31R3sACT6sreduce0n5s__ 00274sexpr1i1lcj247T0n1s%lck22R3sACT5sshift2i160n0n0n1s*lcl2_ 2R3sACT5sshift2i140n0n0n1s+lcm31R3sACT6sreduce0n5s_00134sexp_ r1i31s-lcn31R3sACT6sreduce0n5s_00134sexpr1i31s/lco22R3sACT5s_ shift2i150n0n0n2sCRlcp31R3sACT6sreduce0n5s_00134sexpr1i31s^l_ cq22R3sACT5sshift2i170n0n0nlcr247T0n1s%lcs22R3sACT5sshift2i1_ 60n0n0n1s*lct22R3sACT5sshift2i140n0n0n1s+lcu31R3sACT6sreduce_ 0n5s_00154sexpr1i31s-lcv31R3sACT6sreduce0n5s_00154sexpr1i31s_ /lcw22R3sACT5sshift2i150n0n0n2sCRlcx31R3sACT6sreduce0n5s_001_ 54sexpr1i31s^lcy22R3sACT5sshift2i170n0n0nlcz274T0n1s%lda31R3_ sACT6sreduce0n5s_00174sexpr1i31s*ldb31R3sACT6sreduce0n5s_001_ 74sexpr1i31s+ldc31R3sACT6sreduce0n5s_00174sexpr1i31s-ldd31R3_ sACT6sreduce0n5s_00174sexpr1i31s/lde31R3sACT6sreduce0n5s_001_ 74sexpr1i32sCRldf31R3sACT6sreduce0n5s_00174sexpr1i31s^ldg22R_ 3sACT5sshift2i170n0n0nldh274T0n1s%ldi31R3sACT6sreduce0n5s_00_ 194sexpr1i31s*ldj31R3sACT6sreduce0n5s_00194sexpr1i31s+ldk31R_ 3sACT6sreduce0n5s_00194sexpr1i31s-ldl31R3sACT6sreduce0n5s_00_ 194sexpr1i31s/ldm31R3sACT6sreduce0n5s_00194sexpr1i32sCRldn31_ R3sACT6sreduce0n5s_00194sexpr1i31s^ldo22R3sACT5sshift2i170n0_ n0nldp274T0n1s%ldq31R3sACT6sreduce0n5s_00214sexpr1i31s*ldr31_ R3sACT6sreduce0n5s_00214sexpr1i31s+lds31R3sACT6sreduce0n5s_0_ 0214sexpr1i31s-ldt31R3sACT6sreduce0n5s_00214sexpr1i31s/ldu31_ R3sACT6sreduce0n5s_00214sexpr1i32sCRldv31R3sACT6sreduce0n5s__ 00214sexpr1i31s^ldw22R3sACT5sshift2i170n0n0nldx283T0n1s%ldy3_ 1R3sACT6sreduce0n5s_00234sexpr1i31s*ldz31R3sACT6sreduce0n5s__ 00234sexpr1i31s+lea31R3sACT6sreduce0n5s_00234sexpr1i31s-leb3_ 1R3sACT6sreduce0n5s_00234sexpr1i31s/lec31R3sACT6sreduce0n5s__ 00234sexpr1i32sCRled31R3sACT6sreduce0n5s_00234sexpr1i31s^lee_ 31R3sACT6sreduce0n5s_00234sexpr1i3lef229T0n1s%leg22R3sACT5ss_ hift2i160n0n0n1s*leh22R3sACT5sshift2i140n0n0n1s+lei22R3sACT5_ sshift2i120n0n0n1s-lej22R3sACT5sshift2i130n0n0n1s/lek22R3sAC_ T5sshift2i150n0n0n2sCRlel31R3sACT6sreduce0n5s_00114sexpr1i31_ s^lem22R3sACT5sshift2i170n0n0nlen283T0n1s%leo31R3sACT6sreduc_ e0n5s_00254sexpr1i31s*lep31R3sACT6sreduce0n5s_00254sexpr1i31_ s+leq31R3sACT6sreduce0n5s_00254sexpr1i31s-ler31R3sACT6sreduc_ e0n5s_00254sexpr1i31s/les31R3sACT6sreduce0n5s_00254sexpr1i32_ sCRlet31R3sACT6sreduce0n5s_00254sexpr1i31s^leu31R3sACT6sredu_ ce0n5s_00254sexpr1i33llam3llam3llam3llam3llam3llam3llamlev21_ 9T0n1s%lew22R3sACT5sshift2i350n0n0n1s)lex22R3sACT5sshift2i46_ 0n0n0n1s*ley22R3sACT5sshift2i330n0n0n1s+lez22R3sACT5sshift2i_ 310n0n0n1s-lfa22R3sACT5sshift2i320n0n0n1s/lfb22R3sACT5sshift_ 2i340n0n0n1s^lfc22R3sACT5sshift2i360n0n0nlfd246T0n1s%lfe22R3_ sACT5sshift2i350n0n0n1s)lff31R3sACT6sreduce0n5s_00134sexpr1i_ 31s*lfg22R3sACT5sshift2i330n0n0n1s+lfh31R3sACT6sreduce0n5s_0_ 0134sexpr1i31s-lfi31R3sACT6sreduce0n5s_00134sexpr1i31s/lfj22_ R3sACT5sshift2i340n0n0n1s^lfk22R3sACT5sshift2i360n0n0nlfl246_ T0n1s%lfm22R3sACT5sshift2i350n0n0n1s)lfn31R3sACT6sreduce0n5s_ _00154sexpr1i31s*lfo22R3sACT5sshift2i330n0n0n1s+lfp31R3sACT6_ sreduce0n5s_00154sexpr1i31s-lfq31R3sACT6sreduce0n5s_00154sex_ pr1i31s/lfr22R3sACT5sshift2i340n0n0n1s^lfs22R3sACT5sshift2i3_ 60n0n0nlft273T0n1s%lfu31R3sACT6sreduce0n5s_00174sexpr1i31s)l_ fv31R3sACT6sreduce0n5s_00174sexpr1i31s*lfw31R3sACT6sreduce0n_ 5s_00174sexpr1i31s+lfx31R3sACT6sreduce0n5s_00174sexpr1i31s-l_ fy31R3sACT6sreduce0n5s_00174sexpr1i31s/lfz31R3sACT6sreduce0n_ 5s_00174sexpr1i31s^lga22R3sACT5sshift2i360n0n0nlgb273T0n1s%l_ gc31R3sACT6sreduce0n5s_00194sexpr1i31s)lgd31R3sACT6sreduce0n_ 5s_00194sexpr1i31s*lge31R3sACT6sreduce0n5s_00194sexpr1i31s+l_ gf31R3sACT6sreduce0n5s_00194sexpr1i31s-lgg31R3sACT6sreduce0n_ 5s_00194sexpr1i31s/lgh31R3sACT6sreduce0n5s_00194sexpr1i31s^l_ gi22R3sACT5sshift2i360n0n0nlgj273T0n1s%lgk31R3sACT6sreduce0n_ 5s_00214sexpr1i31s)lgl31R3sACT6sreduce0n5s_00214sexpr1i31s*l_ gm31R3sACT6sreduce0n5s_00214sexpr1i31s+lgn31R3sACT6sreduce0n_ 5s_00214sexpr1i31s-lgo31R3sACT6sreduce0n5s_00214sexpr1i31s/l_ gp31R3sACT6sreduce0n5s_00214sexpr1i31s^lgq22R3sACT5sshift2i3_ 60n0n0nlgr282T0n1s%lgs31R3sACT6sreduce0n5s_00234sexpr1i31s)l_ gt31R3sACT6sreduce0n5s_00234sexpr1i31s*lgu31R3sACT6sreduce0n_ 5s_00234sexpr1i31s+lgv31R3sACT6sreduce0n5s_00234sexpr1i31s-l_ gw31R3sACT6sreduce0n5s_00234sexpr1i31s/lgx31R3sACT6sreduce0n_ 5s_00234sexpr1i31s^lgy31R3sACT6sreduce0n5s_00234sexpr1i3lgz2_ 28T0n1s%lha22R3sACT5sshift2i350n0n0n1s)lhb31R3sACT6sreduce0n_ 5s_00114sexpr1i31s*lhc22R3sACT5sshift2i330n0n0n1s+lhd22R3sAC_ T5sshift2i310n0n0n1s-lhe22R3sACT5sshift2i320n0n0n1s/lhf22R3s_ ACT5sshift2i340n0n0n1s^lhg22R3sACT5sshift2i360n0n0nlhh282T0n_ 1s%lhi31R3sACT6sreduce0n5s_00254sexpr1i31s)lhj31R3sACT6sredu_ ce0n5s_00254sexpr1i31s*lhk31R3sACT6sreduce0n5s_00254sexpr1i3_ 1s+lhl31R3sACT6sreduce0n5s_00254sexpr1i31s-lhm31R3sACT6sredu_ ce0n5s_00254sexpr1i31s/lhn31R3sACT6sreduce0n5s_00254sexpr1i3_ 1s^lho31R3sACT6sreduce0n5s_00254sexpr1i3") glst := decode("lhp550Llhq37T0n1sS1i24scalc1i44sexpr1i66sstream_ 1i3lhr2T0nlhs2T0nlht32T0n4scalc1i44sexpr1i66sstream2i10lhu2T_ 0n0nlhv2T0nlhw12T0n4sexpr2i19lhx2T0nlhy2T0nlhz2T0nlia12T0n4s_ expr2i23lib12T0n4sexpr2i24lic12T0n4sexpr2i25lid12T0n4sexpr2i_ 26lie12T0n4sexpr2i27lif12T0n4sexpr2i28lig12T0n4sexpr2i290nli_ h2T0nlii12T0n4sexpr2i38lij2T0nlik2T0nlil2T0nlim2T0nlin2T0nli_ o2T0nlip2T0nliq2T0nlir2T0nlis12T0n4sexpr2i39lit12T0n4sexpr2i_ 40liu12T0n4sexpr2i41liv12T0n4sexpr2i42liw12T0n4sexpr2i43lix1_ 2T0n4sexpr2i44liy12T0n4sexpr2i450nliz2T0nlja2T0nljb2T0nljc2T_ 0nljd2T0nlje2T0nljf2T0nljg2T0n") # # Uncomment the following if you want a look at the state and goto # tables. If you aren't planning on looking at them, find the # procedure definition for dump_lists below, and delete it. Why # keep it around if it's not being used? # # dump_lists(&errout, alst, glst) } # # New, not recursive, invocation; reset stacks, line number and # error count. # start_symbol := "S" /err_state := 1 /state_stack := [1] & line_number := 0 & errors := 0 /value_stack := [] /next_token := create iparse_tokens(stream) while token := @next_token do { repeat { act := \alst[state_stack[1]][token.sym] | { # # You can replace this error handler with whatever you # like, and have it do whatever you like. # # (iparse_error increments global errors variable) return iparse_error(alst, state_stack, value_stack, token, next_token, err_state) } err_state := 0 case act.str of { "shift" : { # push the next state onto the state stack push(state_stack, act.state) # push the current token's literal value onto the # value stack push(value_stack, token.str) # break out of enclosing repeat loop break } "reduce" : { arglist := [] # # Pop as many elements off of the token stack as # there are symbols in the right-hand side of the # rule. Push these elements onto an argument list. # every 1 to act.size do { pop(state_stack) push(arglist, pop(value_stack)) } # # Check to goto list to see what state we should # be in, and push that state onto the state stack. # push(state_stack, glst[state_stack[1]][act.sym]) # # Call the code associated with the current # reduction, and push the result onto the stack. # For more results, push a coexpression instead. # push(value_stack, (proc(act.by_rule)!arglist)) | { # On failure, return the stacks to the state # they were in before the last reduction. pop(state_stack) return iparse_error(alst, state_stack, value_stack, token, next_token, err_state + 1) } } "accept" : { # # We're done. Return the last result. # return value_stack[1] } } } } write(&errout, "iparse: unexpected end of input") fail 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 above only pays attention to the sym field, although the # user might well want to use the actual text. # procedure iparse_tokens(stream) local token, c, whitespace, operators #global line_number whitespace := '\r\t \n' operators := '+-*/^()=' token := "" every c := !(!&input || "\n") do { if not any(whitespace ++ operators, c) then { token ||:= c } else { if integer(token) then suspend TOK("NUM", "" ~== token) else suspend TOK("ID", "" ~== token) if any(operators, c) then suspend TOK(c) else { if c == "\n" then { line_number +:= 1 suspend TOK("CR"|"CR") } } token := "" } } if integer(token) then suspend TOK("NUM", "" ~== token) else suspend TOK("ID", "" ~== token) suspend TOK("CR"|"$") end # # iparse_error: list x list x list x list x TOK x coexpression x integer -> ? # (alst, state_stack, value_stack, token_stack, token, # next_token, err_state) -> ? # # Where alst is the action list, where state_stack is the state # stack used by iparse, where token stack is the token stack used # by iparse, where token is the current lookahead TOK record, # where next_token is the coexpression from which we get our # tokens, and where err_state indicates how many recursive calls # we've made to the parser via the error handler without a # recovery. # # Recursively calls iparse, attempting to restart the parser after # an error. Increments global "errors" variable (a count of the # number of errors encountered, minus cascading series of errors). # procedure iparse_error(alst, state_stack, value_stack, token, next_token, err_state) local sym static tlst #global line_number, errors initial { tlst := decode("lgv35S1s+1s(1s%1s-1s=1s*1s/1s$1s)1s^3sNUM") } # # Check to see how many attempts we have made at a resync. If # this is a new error series, increment the global "errors" count. # if (err_state +:= 1) > 3 then stop("iparse_error: unable to resync after error; aborting") else if err_state = 1 then errors +:= 1 # GLOBAL # # Check to see if the grammar even has this pre-terminal. # if not member(tlst, token.sym) then write(&errout, "iparse_error: unknown token, ", token.sym, ", in line ", line_number) # Only note the first in a series of cascading errors. else if err_state = 1 then { write(&errout, "iparse_error: syntax error in line ", line_number, "; resynchronizing parser") } # # Now, try to shift in the next input token to see if we can # resync the parser. Stream argument is null because next_token # has already been created. # return iparse(&null, state_stack, value_stack, token_stack, next_token, err_state) end # # dump_lists: file x list x list -> (null) # (f, gl, al) -> (null) # # Where f is an open file, gl is the goto list, and al is the # action list. Writes to file f a human-readable dump of the goto # and action list. # procedure dump_lists(f, al, gl) local TAB, look_list, red_list, i, sym, act TAB := "\t" look_list := list() red_list := list() every i := 1 to *al do { every INSERT(look_list, key(\al[i])) if /al[i] then write(&errout, "dump_lists: warning! state ", i, " is null") } writes(f,TAB) every i := 1 to *look_list do writes(f,look_list[i], TAB) write(f) every i := 1 to *al do { writes(f,i, TAB) act := "" every sym := !look_list do { if \al[i][sym] then { writes(f,al[i][sym].str[1:3], al[i][sym].state) if al[i][sym].str == "reduce" then { INSERT(red_list, al[i][sym].sym) writes(f,al[i][sym].sym) } } writes(f,TAB) } write(f) } write(f) writes(f,TAB) every i := 1 to *red_list do writes(f,red_list[i], TAB) write(f) every i := 1 to *gl do { writes(f,i, TAB) act := "" every sym := !red_list do { if \(\gl[i])[sym] then writes(f,gl[i][sym]) writes(f,TAB) } write(f) } end # # INSERT: set or list x record -> set or list # (sset, rec) -> sset # # Where sset is a homogenous set or list of records, rec is a # record, and the return value is sset, with rec added, iff an # equivalent record was not there already. Otherwise, sset is # returned unchanged. INSERT(), _unlike insert(), FAILS IF REC # IS ALREADY PRESENT IN SSET. # # This procedure is used by dump_lists() above. If you delete # dump_lists(), delete this as well, as also Equiv() below. # procedure INSERT(sset, rec) local addto # # Decide how to add members to sset, depending on its type. # addto := { case type(sset) of { "set" : insert "list" : put default : stop("INSERT: wrong type argument (",type(sset),")") } } # Rudumentary error check to be sure the object to be inserted # into sset is of the same time as the objects already there. # if *sset > 0 then type(rec) == type(sset[1]) | stop("INSERT: unexpected type difference") # # If a rec-like item isn't in sset, add it to sset. # if Equiv(!sset, rec) then fail else return addto(sset, rec) end # # Equiv: struct x struct -> struct # (x1, x2) -> x2 # # Where x1 and x2 are arbitrary structures. Returns x2 if x1 and # x2 are structurally equivalent (even if not identical). Taken # from the IPL file "structs.icn." # # Equiv() is used by dump_lists() above. If you delete # dump_lists, delete this as well. # procedure Equiv(x1, x2, done) local code, i if x1 === x2 then return x2 # Covers everything but structures. if type(x1) ~== type(x2) then fail # Must be same type. if type(x1) == ("procedure" | "file")# Leave only those with sizes (null then fail # taken care of by first two tests). if *x1 ~= *x2 then fail /done := table() (/done[x1] := set()) | # Make set of equivalences if new. (if member(done[x1],x2) then return x2) # Records complicate things. image(x1) ? (code := (="record" | type(x1))) case code of { "list" | "record" : every i := 1 to *x1 do if not Equiv(x1[i],x2[i],done) then fail "table" : if not Equiv(sort(x1,3),sort(x2,3),done) then fail "set" : if not Equiv(sort(x1),sort(x2),done) then fail default : fail # Vaues of other types are different. } insert(done[x1],x2) # Equivalent; add to set. return x2 end -------------------------------- cut here -------------------------------- -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Oct 6 13:12:00 1992 Received: by cheltenham.cs.arizona.edu; Tue, 6 Oct 1992 10:22:54 MST Date: Tue, 6 Oct 92 13:12:00 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <508918@MTS.cc.Wayne.edu> Subject: Logging out from Unix using an Icon program Status: R Errors-To: icon-group-errors@cs.arizona.edu Chris Tenaglia asks: > If I have a simple abc menu that looks something like : > > M : MAIL > C : CHANGE PASSWORD > L : LOGOUT > > Is there a way to log out cleanly. Unix seems to pop processes out all over > the place. I use icon 8.7 under ultrix 4.2a. My background is chiefly VMS. > There's probably a real simple answer I can't see because of my background. I haven't been following all the replies to this question closely, but I've noticed several suggestions for using 'kill'. That seems to me to be a meat-cleaver approach. I'll assume that the context is that you're writing an Icon program to serve as a replacement login shell. (In non-Unixspeak, you're writing an Icon program that takes over when a user logs in and enables the user to carry out operations such as reading mail, changing hisorher password, and eventually logging out.) Under this assumption, there *is* a simple answer: call the program from your initialization file (.profile for the Bourne or Korn shells, .cshrc for the C shell) using the 'exec' command. The program will then replace the executing shell as your outermost process. When you exit from the Icon program, you'll also log out. Therefore, just tie the 'L' item in your menu to the Icon 'exit' function. Another strategy is to use a Bourne shell function or the C shell 'source' command with a little script that tests the exit code of the Icon program and does an exit if that code has a certain distinguished value. However, I don't know of any advantages that this method has over the simple one. Direct execution as provided by Bourne shell functions and C shell 'source' is essential; if you try this from a shell script, you'll merely exit from the script. Unix makes it very difficult to log out from a nested shell, deliberately so. You have to find your top-level process and kill it. I assume that for your purposes you don't have to log out from a nested shell. Paul Abrahams From icon-group-sender Sun Oct 4 20:38:26 1992 Received: by cheltenham.cs.arizona.edu; Wed, 7 Oct 1992 05:56:27 MST Date: 4 Oct 92 20:38:26 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: storing objects Message-Id: <1992Oct4.203826.22606@midway.uchicago.edu> References: <9210040357.AA05603@gremlin> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu wgg@CS.UCSD.EDU (William Griswold) writes: > >Well, you might be able to exploit the properties of your specific tables. >For example, if your keys and elements are all ``printable'', then... What they are are LR(1)-generated action and goto tables. If I don't opti- mize (or do so at run-time), then I can do what you suggest. The trouble is that one of the big optimizations that takes some time to sort out is based on the property that rows in the action table are often the same, so that one can store pointers to one single structure, instead of repeating identical rows. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Oct 9 02:24:21 1992 Received: by cheltenham.cs.arizona.edu; Sat, 10 Oct 1992 05:38:38 MST Date: 9 Oct 92 02:24:21 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!news.oc.com!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Private data in Icon modules Message-Id: <1992Oct9.022421.23811@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 In article pmoore@cix.compulink.co.uk writes: > >Sorry if this has appeared twice - I haven't seen it reach the outside >world, so I suspect my news poster has broken... > >I am considering writing a program in Icon, where a number of procedres >will be ideal candidates for separate compilation and incorporation into >a library of useful procedures. The main problem is that a number of the >functions involved need to make significant use of shared data, but I do >not want this shared data to be visible to users of the procedures... You know, ISI did an Icon implementation for UNIX/386 that has module- level scoping. It was (is) a great idea. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Oct 11 00:21:48 1992 Received: by cheltenham.cs.arizona.edu; Sun, 11 Oct 1992 05:17:59 MST Date: Sun, 11 Oct 92 0:21:48 PDT From: John Paolillo To: icon-group@cs.arizona.edu Subject: Linguistic Society of America -- Software Exhibit (call for submissions) Message-Id: Status: R Errors-To: icon-group-errors@cs.arizona.edu For those of you who are working on software having to do with natural language processing, grammars, textual analysis, corpus based studies and other linguistically relevant applications, please consider presenting your work (be it in Icon, Snobol C, Pascal, or any other language) for the LSA annual meeting in January this year (complete announcement follows). ---------------------------------------------------------------- PLEASE POST LSA SOFTWARE EXHIBIT The Linguistic Society will again sponsor a software exhibit at the Annual Meeting in Los Angeles, 7-10 January 1993. Coordinated by the Committee on Information and Communication Technology, the exhibit will be expanded to include a poster session, a presentation session, and a listing of software available but not being demonstrated at the meeting. Participation is limited to LSA members who have developed software of interest to the discipline. Submittal guidelines and forms were sent to all Linguistics Departments and Programs in the October mailing. Copies may also be requested from the LSA Secretariat, 1325 18th St, NW, Suite 211, Washington, DC 20036 (zzlsa@gallua.bitnet). The deadline for returning forms to the LSA Secretariat has been extended to 15 November 1992. ---------------------------------------------------------------------- To establish membership in the LSA, send your name, address and payment of $55.00 ($25.00 student, with signature, title and affiliation of professor affirming status; additional $10.00 for non-US members) to LSA, P.O.Box 64003, Baltimore, MD USA 21264. Membership includes subscription to the journal _Language_ (4 issues/yr) and the LSA Bulletin, and makes you elligible to participate in the LSA annual meeting. ---------------------------------------------------------------------- Let me unofficially add that we have a paucity of entries to date, and we are quite interested in seeing applications that were not presented at LSA last year. To give you an idea of what was presented last year, there were one or two parsers, HyperCard stacks designed to teach principles of phonetics and linguistics, an A-V parser written in Lisp, a concordance-builder for corpus-based studies.... In other words, if you're doing somehting language-related on a computer, you could probably present it. The most popular platforms are Mac and IBM/DOS, although some UNIX stuff was presented last year too. The software exhibit is quite new to LSA (as is computing awareness among general linguists). The field is on the verge of a new breakthrough as more and more linguists turn to computational tools for data collection, analysis and modelling. And LSA meeting costs are still reasonably low for a national academic conference. Please distribute this notice to any and all interested. I would like to hear that this notice, or a version of it, will be distributed to participants at ICEBOL 6 if that were possible too... (I'd do it myself if I could only be there). Thanks, John C. Paolillo University of Dallas From icon-group-sender Mon Oct 12 14:08:17 1992 Received: by cheltenham.cs.arizona.edu; Wed, 14 Oct 1992 04:08:06 MST Date: 12 Oct 92 14:08:17 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: confusing errors Message-Id: <1992Oct12.140817.25199@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 Hmmm. Anybody know offhand why the Icon translator should accept the following file... link sprint global run record walk ( crawl ) procedure main () ; end ...but barf on this: link sprint ; global run ; record walk ( crawl ) ; procedure main () ; end I guess I thought that reserved were initially parsed as identifiers, and then converted to reserved words by a table lookup process. That would make them able to begin and end expressions. Hence you'd expect automatic semicolon insertion after things like "link sprint" - right? I'm probably missing something silly, but I'm curious what it is. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Oct 12 17:36:04 1992 Received: by cheltenham.cs.arizona.edu; Wed, 14 Oct 1992 04:08:19 MST Date: 12 Oct 92 17:36:04 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: confusing errors Message-Id: <1992Oct12.173604.3765@midway.uchicago.edu> References: <1992Oct12.140817.25199@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 Not so confusing after all, actually. I just realized that "link," "global," etc. are not "beginners." That is, they don't trigger semicolon insertion after a preceding complete expres- sion. They don't need to. Hence global hi procedure main(); end is a perfectly valid Icon program. If anybody find the Icon tokenizer interesting (automatic semicolon inser- tion is really a great idea - why don't all languages do it?), then here's a fun program. Those with some savvy will recognize at once how this sort of thing could be useful for anyone implementing an Icon preprocessor or file compressor. Of course there are bugs. It was just written, and I've only tried it on a few files: global next_c record TOK(sym, str) procedure main() local separator separator := "" every T := \iparse_tokens(&input) do { if any(&digits ++ &letters ++ "._", (\T.str)[1]) & \T.sym ~== "DOT" then writes(separator) writes(T.str) if any(&digits ++ &letters ++ "_.", (\T.str)[-1]) & \T.sym ~== "DOT" then separator := " " else separator := "" } end 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 ! (!stream || "\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 } 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 largely just by checking the first # character. Whitespace begins with whitespace; # integer or real literals with digits, identifiers # and reserved words with underscores or letters, and # operators begin with everything not covered above. # 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 } } # 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 if next_token := iparse_tokens(stream, getchar) 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", ";") suspend next_token } else { # &trace := 0 fail } } # &trace := 0 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 preceding 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 { # NL can be the last char in the getchar stream; if it *is*, # then break out of the repeat loop next_c := @getchar | fail } # 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 (next_c := @getchar) == "0" while any(&digits, next_c) do { token ||:= next_c next_c := @getchar } 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 valid Icon operators formed by the # calling procedure. # 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) procedure recognop(l, s, i) local current_state, master_list 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]) } # *result = 0 if nothing the right length is found return result end 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 # # slashupto: cset x string x integer x integer -> integers # (c, s, i, j) -> Is (a generator) # where Is are the integer positions in s[i:j] before characters # in c that is not preceded by a backslash escape # procedure slashupto(c, s, i, j) if /s := &subject then /i := &pos else /i := 1 /j := *s + 1 /c := &cset c ++:= '\\' s[1:j] ? { tab(i) while tab(upto(c)) do { if ="\\" then { move(1) next } suspend .&pos move(1) } } end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Oct 13 11:31:31 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:34:01 MST Message-Id: <199210131550.AA16871@optima.cs.arizona.edu> To: icon-group-request@cs.arizona.edu From: UBY@CU.NIH.GOV Date: Tue, 13 Oct 1992 11:31:31 EDT Subject: How to skip comments? Status: RO Errors-To: icon-group-errors@cs.arizona.edu I have been trying to modify the concord.icn program from the Icon program library to produce cross-reference tables for SAS programs, but I am stumped about how to skip over comments. Comments in the SAS language are of the form /* ..... */. I have not been able to figure out how to skip the comments and still persuade A*B to parse as A and B. The relevent code is appended. Any suggestions would be greatly appreciated. Thanks, Jim Blakley UBY@NIHCU.BITNET An Icon novice in over his depth procedure item() local i, word, line static char1, sasvar, sas initial { char1 := '&%_' ++ &letters sasvar := char1 ++ &digits } while line := read() do { lineno +:= 1 write(right(lineno, 6), " ", line) line := map(line) # fold to lowercase i := 1 line ? { while tab(upto(sasvar)) do { word := tab(many(sasvar)) if member(keywords, word) then next # skip reserved words if word ? any(char1) then suspend word # skip numbers } } } end From icon-group-sender Thu Oct 15 12:05:15 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:34:27 MST Date: 15 Oct 92 12:05:15 GMT From: mcsun!Germany.EU.net!sbsvax!coli-gate.coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman@uunet.uu.net (Stephen Spackman) Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken Subject: Re: confusing errors Message-Id: References: <1992Oct12.140817.25199@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 <1992Oct12.173604.3765@midway.uchicago.edu> goer@ellis.uchicago.edu (Richard L. Goerwitz) writes: |If anybody find the Icon tokenizer interesting (automatic semicolon inser- |tion is really a great idea - why don't all languages do it?), then here's |a fun program. Makes about as much sense as automatic plus insertion or automatic atanh() insertion, if you ask me. Hi goer. ------------------------------------------------------------------------ stephen p spackman stephen@acm.org ------------------------------------------------------------------------ From icon-group-sender Wed Oct 14 05:03:20 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:34:41 MST Date: 14 Oct 92 05:03:20 GMT From: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!think.com!rpi!uwm.edu!linac!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: sortf - sortff? Message-Id: <1992Oct14.050320.9087@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 Version 8 of Icon has sortf. Seems useful. But what if you want to sort on more than one field (e.g. if field 5 is the same, use field 4, etc.)? What might be the most effective strategy for this sort of thing? (I have to do things like this fairly often, so it's not just an idle question.) -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Oct 16 21:17:23 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:34:55 MST Date: 16 Oct 1992 21:17:23 +0100 (CET) From: Borys To: ICON-GROUP@cs.arizona.edu Message-Id: <01GQ0NIL6R5E99GEGO@Arizona.edu> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm new in your group. I want to have some information abot icon language. Borys M. From icon-group-sender Thu Oct 15 16:56:11 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:35:23 MST Date: 15 Oct 92 16:56:11 GMT From: unixhub!linac!uchinews!ellis!goer@lll-winken.llnl.gov (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: confusing errors Message-Id: <1992Oct15.165611.4431@midway.uchicago.edu> References: <1992Oct12.173604.3765@midway.uchicago.edu>, , <1992Oct15.155939.2562@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: > >>...why don't all languages do it? >> >>Makes about as much sense as automatic plus insertion or automatic >>atanh() insertion, if you ask me. > >I didn't ask, Stephen... Actually, I did ask, albeit rhetorically. Apologies :-). > Some terminals map to nodes >in the abstract syntax tree; some only demarcate expressions. When and >if they are superfluous, they should be eliminated, as long as doing so >does not render the language more opaque... ...and does not dramatically increases the size of the grammar and/or its associated parse tables. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Oct 15 15:59:39 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 11:35:43 MST Date: 15 Oct 92 15:59:39 GMT From: elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@lll-winken.llnl.gov (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: confusing errors Message-Id: <1992Oct15.155939.2562@midway.uchicago.edu> References: <1992Oct12.140817.25199@midway.uchicago.edu>, <1992Oct12.173604.3765@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: >|If anybody find the Icon tokenizer interesting (automatic semicolon inser- >|tion is really a great idea - why don't all languages do it?), then here's >|a fun program. > >Makes about as much sense as automatic plus insertion or automatic >atanh() insertion, if you ask me. I didn't ask, Stephen, but since you interject I respond with a basic remark about tokens and their semantics: Some terminals map to nodes in the abstract syntax tree; some only demarcate expressions. When and if they are superfluous, they should be eliminated, as long as doing so does not render the language more opaque. Opacity is a subjective judgment, of course, so let's check to see if you know Icon in the first place. Can you illustrate where automatic semicolon insertion might render Icon source code less readable, or introduce unexpected behavior? I'm waiting.... -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Oct 19 14:17:00 1992 Received: by cheltenham.cs.arizona.edu; Mon, 19 Oct 1992 12:35:02 MST Message-Id: <199210191919.AA25581@optima.cs.arizona.edu> From: nowlin@iwtqg.att.com Date: Mon, 19 Oct 92 14:17 CDT To: att!cs.arizona.edu!icon-group Subject: Re: sorting on multiple fields Status: R Errors-To: icon-group-errors@cs.arizona.edu There must be something like this in the IPL but here's what I've used for years if I wanted to sort a list of records by various fields. It could also be used for lists of lists but the variable names would make that a little confusing. Jerry Nowlin ----------------------------------> cut here <-------------------------------- # This example program is to illustrate the recsort() procedure. It sorts # a UNIX style password file. The arguments to the program should be the # fields in each password entry to sort on in order of precedence. The # program has a built-in limit of the first 20 entries in the password file # but it can be removed to test the program on the whole password file. # Notice that the UID and GID fields are now forced to be numeric. Sorts # on these fields will work accordingly. record passwd(name,pass,uid,gid,info,logdir,shell) procedure main(args) if *args = 0 then stop("I need a numeric record index to sort on") users := [] in := open("/etc/passwd","r") every line := !in\20 do line ? { user := passwd() user.name := tab(upto(':')) & move(1) user.pass := tab(upto(':')) & move(1) user.uid := numeric(tab(upto(':'))) & move(1) user.gid := numeric(tab(upto(':'))) & move(1) user.info := tab(upto(':')) & move(1) user.logdir := tab(upto(':')) & move(1) user.shell := tab(0) put(users,user) } close(in) write("UNSORTED: ",image(users)," ",image(users[1])) every user := !users do write( user.name,":", user.pass,":", user.uid,":", user.gid,":",) #user.info,":", #user.logdir,":", #user.shell) stuff := recsort(users,args) write("\nSORTED: ",image(stuff)," ",image(stuff[1])) every user := !stuff do write( user.name,":", user.pass,":", user.uid,":", user.gid,":",) #user.info,":", #user.logdir,":", #user.shell) end # Sort the list of records passed in recs by the list of field indexes # passed in keys. A field index must be numeric and refer to one of the # fields in the record type being sorted. If a numeric field index is # negative the positive value will be used but the sorting done on that # field will be in reverse order. A sorted list of records is returned. procedure recsort(recs,keys) # Initialize a temporary table. tempt := table() # Get a sorting key. key := get(keys) # If the key is negative sort in reverse order. if key < 0 then { key := -key getpair := pull } else getpair := pop # Take every record in the recs list and add it to the table. every rec := !recs do # Each index to the table is a different sorting key. To # avoid losing records which have identical sorting keys # each value in the table must be a list of the records # that are indexed by a given sorting key. (/tempt[rec[key]] := [ rec ]) | put(tempt[rec[key]],rec) # Sort the table by the indexes (sorting keys). templ := sort(tempt,1) # Initialize a new records list. newrecs := [] # Take apart the pairs of lists generated by the sort. while pair := getpair(templ) do { # If there is more than one record in this value list and # there are additional keys to sort on recursively sort # this value list with the remaining keys. if *pair[2] > 1 & *keys > 0 then pair[2] := recsort(pair[2],copy(keys)) # Add each record from the value list to the temporary list. every put(newrecs,!pair[2]) } # Return the new sorted list of records. return newrecs end From icon-group-sender Mon Oct 19 09:34:39 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 04:39:01 MST Date: 19 Oct 92 09:34:39 GMT From: eru.mt.luth.se!lunic!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@bloom-beacon.mit.edu (Hakan Soderstrom) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Subject: iconx Bus error Message-Id: <1992Oct19.093439.18401@eua.ericsson.se> 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 plagued by a Bus error in iconx (version 8.6 under SunOS 4.1.1). The application reads and writes a file containing a data structure coded by the 'ximage' procedure (from the Icon Library). The data structure is written and read as a single line. It can be serveral kb. I think this is where it goes wrong. I post this to find out if somebody else already has investigated this. I am not used to finding bugs in Icon, so I will have to recompile iconx with debug flags on. I will report findings to this group. ------------------------------------------ Hakan Soderstrom From icon-group-sender Mon Oct 19 09:21:16 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 04:40:52 MST Date: 19 Oct 92 09:21:16 GMT From: eru.mt.luth.se!lunic!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@bloom-beacon.mit.edu (Hakan Soderstrom) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Subject: Re: sortf - sortff? Message-Id: <1992Oct19.092116.18168@eua.ericsson.se> References: <1992Oct14.050320.9087@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 9087@midway.uchicago.edu, goer@quads.uchicago.edu (Richard L. Goerwitz) writes: >Version 8 of Icon has sortf. Seems useful. But what if you want to 'sortf'? Ain't heard of no such thing. It's not in the Book either. When I do more complex sorting jobs I write a file and run Unix 'sort' on it. The output can be comfortably read if you invoke sort in the spirit of open ("/usr/bin/sort ", "rp") Or are we talking MS-DOS? Basic sorts on tables, sets, and lists is something I do all the time. Extremely useful. Icon is already on the verge of being weighed down by features, so I would not vote for a further complication of 'sort'. ------------------------------------------ Hakan Soderstrom From icon-group-sender Tue Oct 20 04:38:48 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 04:41:07 MST Date: Tue, 20 Oct 1992 04:38:48 MST From: "Ralph Griswold" Message-Id: <199210201138.AA09137@cheltenham.cs.arizona.edu> To: eru.mt.luth.se!lunic!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@bloom-beacon.mit.edu Subject: Re: iconx Bus error Cc: icon-group Status: R Errors-To: icon-group-errors@cs.arizona.edu You should get the current version of Icon, 8.7, before you expend any effort in running down problems in 8.6. In general, if you have such a problem and send us an offending program, we will look into it. 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 Fri Oct 2 02:45:23 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 09:17:32 MST Date: 2 Oct 92 02:45:23 GMT From: uchinews!ellis!goer@uunet.uu.net (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Unix Logging Out Message-Id: <1992Oct2.024523.2937@midway.uchicago.edu> References: <01GPFIYT5FTU8WWF6P@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 TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) writes: > >If I have a simple abc menu that looks something like : > > M : MAIL > C : CHANGE PASSWORD > L : LOGOUT > >Is there a way to log out cleanly? Under UNIX, processes like shells (i.e. command interpreters) normally get run right on login, and unless you "exec" a program (and overlay that shell), it waits for your application to finish, then resumes its work. Under normal circumstances, you can't log out from any of your login shell's child processes. You have to quit everything else, and jump back to the login shell and log out from there. You could get around this a) by finding your login shell and then killing it manually (a la system("kill -9 "||process_id) where pro- cess_id is the ID of your login shell. This is very un-UNIXish. It's normally presumed that one will not *want* to log out with processes still active. Does this make any sense? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Oct 19 16:24:16 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 09:17:38 MST Date: 19 Oct 92 16:24:16 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: sortf - sortff? Message-Id: <1992Oct19.162416.28966@midway.uchicago.edu> References: <1992Oct14.050320.9087@midway.uchicago.edu>, <1992Oct19.092116.18168@eua.ericsson.se> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu konhks@eua.ericsson.se writes: >>Version 8 of Icon has sortf. Seems useful. But what if you want to > >'sortf'? Ain't heard of no such thing. It's in the specs for the latest version. Sortf, I believe, is 8.6+. A very useful tool. I kinda wish it had arbitrary final arguments, i.e. sortf(struct, 1) would sort on field 1, while sortf(struct, 1, 2) would sort on field 1, and for objects with the same field one, on field 2 as well. This would be easy to prototype if there were, in addition to the === a >>>= and <<<= operator, defined to work on structures as well as cset, strings, ints, and reals. I think that symmetry requires such operators, and that, because there is no need to restrict sortf to one field, it should not be so restricted. I've written an Icon prototype of sortf that takes arbitrary arguments if anyone wants it. It calls sortf, though, to determine sort order, so it is slow. If there were <<<=, etc. I'd have been able to do a manual merge or quicksort+insertion sort, which might or might not have been faster. I still haven't fully figured RTL out, or I might have tried implementing it as part of the run-time system. >When I do more complex sorting jobs I write a file and run Unix 'sort' on it. That would be fine except that, under some conditions, it's considered bad programming practice to use platform-specific facilities. UNIX is certainly not the only OS I use, or plan to use, so in my particular case piping output through sort is not an ideal solution. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Oct 20 12:05:00 1992 Received: by cheltenham.cs.arizona.edu; Tue, 20 Oct 1992 18:42:45 MST Message-Id: <199210201711.AA23991@optima.cs.arizona.edu> From: nowlin@iwtqg.att.com Date: Tue, 20 Oct 92 12:05 CDT To: att!cs.arizona.edu!icon-group Subject: Re: logging off UNIX Status: R Errors-To: icon-group-errors@cs.arizona.edu > You could get around this a) by finding your login shell and then > killing it manually (a la system("kill -9 "||process_id) where pro- > cess_id is the ID of your login shell. I can't take it anymore. One of the first things UNIX novices learn is how to do a "kill -9". Most haven't a clue what this does but believe me - it's not a pretty sight. If you have to kill a process use a plain vanilla "kill" first. This uses the software termination signal (15) to notify the process in question it should terminate. This signal gives the process being killed a chance to return any resources it's using and clean up after itself before it dies. If that doesn't work try using a "kill -1" which send a hangup signal to the process. This is especially good for login shells since they usually set traps to ignore software termination but most of the time they can detect a hangup and clean up after themselves before logging you off. If neither of these work then a "kill -9" with the kill signal (we always called it terminate with extreme prejudice) is a last resort. The process being terminated has no chance to dodge this signal or cleanup their mess. I know this has nothing to do with Icon but I couldn't just continue to have people leave bloody little splotches all over their systems by using "kill -9". We need to put a stop to the senseless killing and work toward a kinder gentler UNIX. Jerry Nowlin From icon-group-sender Wed Oct 21 17:54:16 1992 Received: by cheltenham.cs.arizona.edu; Thu, 22 Oct 1992 05:59:49 MST From: mitch@rock.csd.sgi.com Date: Wed, 21 Oct 92 17:54:16 -0700 Original-From: mitch@rock.csd.sgi.com (Tom Mitchell) Message-Id: <9210220054.AA02378@rock.csd.sgi.com> To: nowlin@iwtqg.att.com Cc: att!cs.arizona.edu!icon-group In-Reply-To: nowlin@iwtqg.att.com's message of Tue, 20 Oct 92 12:05 CDT <199210201711.AA23991@optima.cs.arizona.edu> Subject: logging off UNIX Status: R Errors-To: icon-group-errors@cs.arizona.edu From: nowlin@iwtqg.att.com Date: Tue, 20 Oct 92 12:05 CDT > You could get around this a) by finding your login shell and then > killing it manually (a la system("kill -9 "||process_id) where pro- > cess_id is the ID of your login shell. I can't take it anymore. One of the first things UNIX novices learn is how to do a "kill -9". Most haven't a clue what this does but believe me - it's not a pretty sight. Yes, this is not a pretty sight. The man page used to say "kill with extreme prejudice". On most Unix systems kill and killall send a -9 by default. This is gross and nasty. Lots of people alias such things to "kill -HUP $* ; sleep 5; kill $*" to give the poor process 5 seconds to correctly clean up its TMP files network connections and so on... I like to think that the HUP signal is the best thing that the phone company could do when a phone line hangs up. With older modems and phone lines -- this was common enough that older programs do good things in the presence of a HUP signal. Too often new programmers omit signal handlers where signals can be used to turn on debug; exit gracefully; reset strange states; and so on. If you have to kill a process use a plain vanilla "kill" first. This uses the software termination signal (15) to notify the process in question it should terminate. This signal gives the process being killed a chance to return any resources it's using and clean up after itself before it dies. ----- a kinder gentler UNIX. Jerry Nowlin Good stuff Jerry... Exactly, From icon-group-sender Thu Oct 22 06:18:10 1992 Received: by cheltenham.cs.arizona.edu; Thu, 22 Oct 1992 06:00:08 MST Date: Thu, 22 Oct 92 06:18:10 -0400 From: isidev!nowlin@uunet.uu.net Message-Id: <9210221018.AA22763@relay1.UU.NET> To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET Subject: Re: skipping comments Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: uunet!arizona!CU.NIH.GOV!UBY > Date: Tue, 13 Oct 1992 11:31:31 EDT > Subject: How to skip comments? > > I have been trying to modify the concord.icn program from the Icon program > library to produce cross-reference tables for SAS programs, but I am > stumped about how to skip over comments. Comments in the SAS language are > of the form /* ..... */. I have not been able to figure out how to skip > the comments and still persuade A*B to parse as A and B. The relevent code > is appended. Any suggestions would be greatly appreciated. > > Thanks, > > Jim Blakley UBY@NIHCU.BITNET > > An Icon novice in over his depth I took the procedure you posted and extrapolated a main() procedure to test it with. Including a main() is a good idea when posting code. Sometimes no main() can obscure the meaning of code fragments. I assumed lineno and keywords were supposed to be global and just threw in some C keywords for testing. Then I added a new procedure called stripcom() that does what you want. It's been over eight years since I did any SAS but C uses the same commenting convention so I had plenty of code to test this on. See if this is what you had in mind. This could probably be done in a more iconic fashion but that would just make the code harder to follow and you said you're a novice. If you have questions let me know. I tried mailing directly but had no luck. Jerry Nowlin uunet!isidev!nowlin isidev!nowlin@uunet.uu.net --------------------------------> cut here <------------------------------- ##### ORIGINAL CODE procedure item() local i, word, line static char1, sasvar, sas initial { char1 := '&%_' ++ &letters sasvar := char1 ++ &digits } while line := read() do { lineno +:= 1 write(right(lineno, 6), " ", line) line := map(stripcom(line)) # fold to lowercase i := 1 line ? { while tab(upto(sasvar)) do { word := tab(many(sasvar)) if member(keywords, word) then next # skip reserved words if word ? any(char1) then suspend word # skip numbers } } } end ##### NEW CODE procedure stripcom(old) local new static incom, begcom, endcom initial { incom := &null ; begcom := "/*" ; endcom := "*/" } new := "" old ? while not pos(0) do { \incom & ((tab(find(endcom)) & incom := &null) | tab(0)) while new ||:= tab(find(begcom)) do { move(2) (tab(find(endcom)) & move(2) & incom := &null) | (tab(0) & incom := 1) } new ||:= tab(0) } return new end global lineno, keywords procedure main() lineno := 0 keywords:= set(["break","case","continue","do","else", "for","if","return","switch","while"]) every write(item()) end From icon-group-sender Sat Oct 3 04:14:43 1992 Received: by cheltenham.cs.arizona.edu; Sat, 24 Oct 1992 08:21:34 MST Date: 3 Oct 92 04:14:43 GMT From: cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!access.usask.ca!ccu.umanitoba.ca!rahardj@beaver.cs.washington.edu (Budi Rahardjo) Organization: University of Manitoba, Winnipeg, Canada Subject: Re: Unix Logging Out Message-Id: <1992Oct3.041443.21496@ccu.umanitoba.ca> References: <01GPFIYT5FTU8WWF6P@mis.mcw.edu>, <1992Oct2.024523.2937@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 TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) writes: > >If I have a simple abc menu that looks something like : > > M : MAIL > C : CHANGE PASSWORD > L : LOGOUT > >Is there a way to log out cleanly? You might want to try executing `kill -1 -1` if LOGOUT is selected. -- budi -- Budi Rahardjo Unix Support - Computer Services - University of Manitoba From icon-group-sender Tue Oct 20 03:29:23 1992 Received: by cheltenham.cs.arizona.edu; Sat, 24 Oct 1992 08:22:03 MST Date: 20 Oct 92 03:29:23 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: How to skip comments? Message-Id: <1992Oct20.032923.20595@midway.uchicago.edu> References: <199210131550.AA16871@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 In article <199210131550.AA16871@optima.cs.arizona.edu> UBY@CU.NIH.GOV writes: >I have been trying to modify the concord.icn program from the Icon program >library to produce cross-reference tables for SAS programs, but I am stumped >about how to skip over comments. Comments in the SAS language are of the form >/* ..... */. What you want to do is perhaps to create a little machine with four states, and use it in place of read(). I don't know what sort of machine you are using, but assuming that lines terminate with \n, you might write something like what I have below. Note that I haven't coded the routine to collect the text into lines. It just suspends characters that don't constitute part of the comments: procedure stripped_sas() local c, state state := 0 every c := !(!&input || "\n") do { case state of { 0 : { if c == "/" then state := 1 else suspend c } 1 : { if c == "*" then state := 2 else { suspend "/" | c state := 0 } } 2 : { if c == "*" then state := 3 } 3 : { if c == "/" then state := 0 else state := 2 } } } end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Oct 20 15:47:19 1992 Received: by cheltenham.cs.arizona.edu; Sun, 25 Oct 1992 06:46:00 MST Date: 20 Oct 92 15:47:19 GMT From: mcsun!ieunet!swift.cs.tcd.ie!gerry@uunet.uu.net Organization: Computer Science Department, Trinity College Dublin Subject: looking for SNOBOL Message-Id: <1992Oct20.154719.8513@swift.cs.tcd.ie> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi, Are there any freeware implementations of SNOBOL for UNIX on the internet? Does anybody have any experience with such programs? thanks, Gerry O'Brien, Dept. of Computer Science, Trinity College Dublin, gerry@cs.tcd.ie From icon-group-sender Sun Oct 4 20:38:26 1992 Received: by cheltenham.cs.arizona.edu; Sun, 25 Oct 1992 18:23:54 MST Date: 4 Oct 92 20:38:26 GMT From: agate!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: storing objects Message-Id: <1992Oct4.203826.22606@midway.uchicago.edu> References: <9210040357.AA05603@gremlin> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu wgg@CS.UCSD.EDU (William Griswold) writes: > >Well, you might be able to exploit the properties of your specific tables. >For example, if your keys and elements are all ``printable'', then... What they are are LR(1)-generated action and goto tables. If I don't opti- mize (or do so at run-time), then I can do what you suggest. The trouble is that one of the big optimizations that takes some time to sort out is based on the property that rows in the action table are often the same, so that one can store pointers to one single structure, instead of repeating identical rows. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Oct 26 11:03:21 1992 Received: by cheltenham.cs.arizona.edu; Mon, 26 Oct 1992 14:00:12 MST Date: 26 Oct 1992 11:03:21 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Unix Logging Out, all done To: icon-group@cs.arizona.edu Message-Id: <01GQEHDE1WG28WW0U0@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 I want to thank all of you for your suggestions. I divide them up into two categories. kill and exec. These were replies to a question I posted about being able to log out from within a program (menu) during an interactive session. In my case I want to tightly control an account by keeping it in a tight menu. This can be used to conserve disk, cpu, and improve security. kill did not always work, and it turns out to be a brute force method. It doesn't behave the same everywhere depending on ones version of unix. The plan that worked for me was to put 'exec menu' at the end of the .login script. Perhaps it's not 100 percent bulletproof, but for my intents and purposes it does what I want in the standard acceptable manner. I'm running icon v8.7 under ultrix 4.2a on a DEC 5240 workstation. 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 Fri Oct 23 16:46:21 1992 Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 09:34:08 MST Date: 23 Oct 92 16:46:21 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!spool.mu.edu!darwin.sura.net!paladin.american.edu!news.univie.ac.@!hp4at!mcsun!Germany.EU.net!sbsvax!coli-gate.coli.uni-sb (Stephen Spackman) Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken Subject: Re: confusing errors Message-Id: References: <1992Oct12.140817.25199@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 <1992Oct15.155939.2562@midway.uchicago.edu> goer@ellis.uchicago.edu (Richard L. Goerwitz) writes: |stephen@acm.org writes: |>|If anybody find the Icon tokenizer interesting (automatic semicolon inser- |>|tion is really a great idea - why don't all languages do it?), then here's |>|a fun program. |> |>Makes about as much sense as automatic plus insertion or automatic |>atanh() insertion, if you ask me. | |I didn't ask, Stephen, but since you interject I respond with a basic |remark about tokens and their semantics: Some terminals map to nodes |in the abstract syntax tree; some only demarcate expressions. When and |if they are superfluous, they should be eliminated, as long as doing so |does not render the language more opaque. But but but. The semicolon operator DOES have semantics: it explicitly evaluates and discards its left argument and returns its right! It's the most drastic operator in the book! Now *parentheses*, I grant, don't do anything at abstract syntax. Wanna make THOSE optional? |Opacity is a subjective judgment, of course, so let's check to see if |you know Icon in the first place. Can you illustrate where automatic |semicolon insertion might render Icon source code less readable, or |introduce unexpected behavior? I'm waiting.... Nono, not my point. It reduces regularity in the language, limits the ease with it can be read and written automatically, and increases the potential for errors to be introduced during the editing process. Readability and unexpected behaviour are not the only criteria - otherwise we'd use natural language prose cross-checked by requiring submission of source in english and two other natural languages related at a time depth of no less than three thousand years.... Now Icon isn't a language whose syntax fits on half a page anyway, so perhaps I shouldn't kick; but I can't help feeling that we should *start* demanding that languages be reasonably straightforward.... stephen From icon-group-sender Fri Oct 23 18:35:37 1992 Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 09:35:27 MST Date: 23 Oct 92 18:35:37 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: confusing errors Message-Id: <1992Oct23.183537.6160@midway.uchicago.edu> References: , <1992Oct15.155939.2562@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: >|>|If anybody find the Icon tokenizer interesting (automatic semicolon inser- >|>|tion is really a great idea - why don't all languages do it?), then here's >|>|a fun program. >|> >|>Makes about as much sense as automatic plus insertion or automatic >|>atanh() insertion, if you ask me. >| >|I didn't ask, Stephen, but since you interject I respond with a basic >|remark about tokens and their semantics: Some terminals map to nodes >|in the abstract syntax tree; some only demarcate expressions. When and >|if they are superfluous, they should be eliminated, as long as doing so >|does not render the language more opaque. > >But but but. The semicolon operator DOES have semantics: it explicitly >evaluates and discards its left argument and returns its right! It's the >most drastic operator in the book! Now *parentheses*, I grant, don't do >anything at abstract syntax. Wanna make THOSE optional? But but but! Parentheses serve to group expressions where the precedences or associativities are not clear. There are only a couple of declarations in Icon; just about everything else can be an expression. So there's no practical need for the semicolon: If anyone is confused, use parentheses. To bound an expression a line-break is quite enough. Just as clear as a semicolon. If one wants to compact several bounded expressions onto a single line, then the semicolon *may* be used. The following is perfectly legal Icon code: procedure main() write("hello world"); exit(0) end The following is also legal: procedure main() write("hello world") exit(0) end After you read Icon for a couple of weeks, superfluous semicolons start to seem like an annoying tick. There's no reason for them. The analyzer can figure things out perfectly well without them. >|Opacity is a subjective judgment, of course, so let's check to see if >|you know Icon in the first place. Can you illustrate where automatic >|semicolon insertion might render Icon source code less readable, or >|introduce unexpected behavior? I'm waiting.... > >Nono, not my point. It reduces regularity in the language, limits the >ease with it can be read and written automatically, and increases the >potential for errors to be introduced during the editing process. If you like regularity, just use LISP. It is very easy to read and write automatically, and its syntax is trivial. In fact, Icon is very easy to tokenize with automatic semicolon insertion, and I've never had any prob- lems reading or writing it. Not as regular as LISP, but then LISP code is really not all that readable unless formatted with great skill (and a smart editor). Syntactic regularity != usability. Maybe you are just baiting me, but the semicolon is not an operator with abstract semantics. It has semantics only in the sense that it directs the syntactic analyzer to map the concrete syntax to the abstract syntax in a certain way. If this action can be determined easily enough without the extra symbol, then why use it? Make it optional for those few cases where clarity would be served by its addition. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Oct 28 09:42:25 1992 Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 09:45:47 MST Date: Wed, 28 Oct 1992 09:42:25 MST From: "Ralph Griswold" Message-Id: <199210281642.AA24982@cheltenham.cs.arizona.edu> To: icon-group Subject: semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu I normally stay out of "discussions" like this, but I can't resist remarking that, in practice, the semicolon insertion performed by the Icon translator works well in practice, programmers like it, it's been touted as one of the nice little touches that makes Icon a pleasure to use, and I don't recall a single complaint about the feature from a practicing Icon programmer (once they understand it). The wisdom on idiomatic Icon programming is that semicolons should never appear (syntactically) in Icon programs. If you want to argue syntax, what semicolon insertion does is give line terminators syntactic significance. In most programs, an Icon programmer thinks of a newline (or whatever your favorite platform uses to terminate lines) in the same way programmers in languages with similar syntax think of semicolons. 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 Oct 28 16:00:53 1992 Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 17:20:18 MST Date: Wed, 28 Oct 92 16:00:53 MST From: whm@shepard.sunquest.com (Bill Mitchell) Message-Id: <9210282300.AA21824@shepard.sunquest.com> To: icon-group@cs.arizona.edu Subject: Re: semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu From: ralph@cs.arizona.edu Date: Wed, 28 Oct 92 09:42:25 MST Subject: semicolons ... The wisdom on idiomatic Icon programming is that semicolons should never appear (syntactically) in Icon programs. I got curious and searched all my Icon programs for semicolons. Grand total: one semicolon not counting occurrences in string and cset literals. I haven't followed the mail on this topic closely, so apologies if a repeat, but there is that problem with an operator that has both a binary and a unary form appearing at the end of line versus the beginning of the next line. Example: procedure main() return 1 + 2 end vs. procedure main() return 1 + 2 end (Try 'em with tracing on!) From icon-group-sender Wed Oct 28 17:26:20 1992 Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 17:26:27 MST Date: Wed, 28 Oct 1992 17:26:20 MST From: "Ralph Griswold" Message-Id: <199210290026.AA05706@cheltenham.cs.arizona.edu> To: icon-group Subject: semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu One way to think of this is to type RETURN (or whatever your keyboard uses to generate a line terminator) when you'd have to type a semicolon in a language with a similar syntax. The only problem then arises when you want to split a line where you don't want a semicolon. The rule is easy and quickly learned; don't break a line when you don't want it to be interpreted as a semicolon if the potential break place is at the end of a complete expression and the next line starts with a token that is legitimate to start an expression. For the most part, this translates into a simpler rule: Put a non-semicolon break after a comma or a binary operator. Thus, a + b not a + b That's really all there is to it, and it doesn't require a lot of thinking. 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 Thu Oct 29 09:11:08 1992 Received: by cheltenham.cs.arizona.edu; Thu, 29 Oct 1992 04:44:07 MST Date: Thu, 29 Oct 92 09:11:08 +0100 From: ms@informatik.uni-hannover.de (Michael Sperber) Message-Id: <9210290811.AA12866@wega.informatik.uni-hannover.de> To: ralph@cs.arizona.edu Cc: icon-group@cs.arizona.edu In-Reply-To: Ralph Griswold's message of Wed, 28 Oct 92 17:42:25 +0100 <199210281642.AA24982@cheltenham.cs.arizona.edu*MAILER@cdc2-gw.rrzn.uni-hannover.de> Subject: semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi there, I just noticed that 386 Icon 8.5 hangs when called from a program that uses the GNUish swapping library (such as MS_SH 2.0 or GNUish Make 3.58). Has anyone noticed or, better, fixed the problem? Is there a djgpp-compiled Icon out there? Any help would be appreciated. Cheers :-> Chispy From icon-group-sender Mon Oct 5 03:07:06 1992 Received: by cheltenham.cs.arizona.edu; Thu, 29 Oct 1992 04:44:14 MST Date: 5 Oct 92 03:07:06 GMT From: elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!uchinews!ellis!goer@ames.arc.nasa.gov (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: offending program Message-Id: <1992Oct5.030706.477@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Abstract discussions aren't too useful, always. Here's an example of a simple program created by the parser generator whose tables I want to be able to store. The following example initializes itself by decoding a string encoded by "encode" (see codeobj.icn in the IPL). Should work with version 8 installations. For the compiler, uncom- ment the invocable declaration. I have compiled the program success- fully, but haven't gotten the executable to run. Compile, execute, and type something like "5 + 5," then hit a CR. -Richard ------------------------------- cut here -------------------------------- #invocable "ACT", "symbol", "TOK" global ID_tbl procedure main() iparse(&input) end procedure _0001(arg1) return end procedure _0003(arg1,arg2) return end procedure _0005(arg1) return end procedure _0007(arg1,arg2) line_number +:= 1 return write(arg1) end procedure _0009(arg1) if not (return \ID_tbl[arg1]) then write(&errout, "uninitialized variable, line ", line_number) fail end procedure _0011(arg1,arg2,arg3) initial ID_tbl := table() ID_tbl[arg1] := arg3 return arg3 end procedure _0013(arg1,arg2,arg3) return arg1 + arg3 end procedure _0015(arg1,arg2,arg3) return arg1 - arg3 end procedure _0017(arg1,arg2,arg3) return arg1 * arg3 end procedure _0019(arg1,arg2,arg3) return arg1 / arg3 end procedure _0021(arg1,arg2,arg3) return arg1 % arg3 end procedure _0023(arg1,arg2,arg3) return arg1 ^ arg3 end procedure _0025(arg1,arg2,arg3) return arg2 end procedure _0027(arg1) if find(".", arg1) then return real(arg1) else return integer(arg1) end # I use ximage for debugging; remove it if you don't need it. link codeobj, ximage record ACT(str, state, by_rule, sym, size) record symbol(str, terminal) record TOK(sym, str) global line_number, errors # # iparse: file -> ? # stream -> ? # # Where stream is an open file, and ? represents the user-defined # result of a completed parse of file, from the current location # up to the point where the parser executes an "accept" action. # # The second to fifth arguments are used on recursive calls from # the error handler, iparse_error. Ignore them, unless you are # sure of what you are doing! # procedure iparse(stream, state_stack, value_stack, next_token, err_state) local start_symbol, token, act, arglist static alst, glst #global line_number, errors initial { alst := decode("l7341Lla122T0n1s(lb21R3sACT5sshift1i80n0n0n2sCR_ lc21R3sACT5sshift1i50n0n0n2sIDld21R3sACT5sshift1i70n0n0n3sNU_ Mle21R3sACT5sshift1i90n0n0nlf31T0n1s$lg21R3sACT6saccept0n0n0_ n0nlh38T0n1s$li28R3sACT6sreduce0n5s_00011sS1i1lj163T0n1s$lk3_ 3R3sACT6sreduce0n5s_00036sstream1i11s(ll21R3sACT5sshift1i80n_ 0n0n2sCRlm21R3sACT5sshift1i50n0n0n2sIDln21R3sACT5sshift1i70n_ 0n0n3sNUMlo21R3sACT5sshift1i90n0n0nlp201T0n1s$lq31R3sACT6sre_ duce0n5s_00054scalc1i11s(lr31R3sACT6sreduce0n5s_00054scalc1i_ 12sCRls31R3sACT6sreduce0n5s_00054scalc1i12sIDlt31R3sACT6sred_ uce0n5s_00054scalc1i13sNUMlu31R3sACT6sreduce0n5s_00054scalc1_ i1lv216T0n1s%lw22R3sACT5sshift2i160n0n0n1s*lx22R3sACT5sshift_ 2i140n0n0n1s+ly22R3sACT5sshift2i120n0n0n1s-lz22R3sACT5sshift_ 2i130n0n0n1s/laa22R3sACT5sshift2i150n0n0n2sCRlab22R3sACT5ssh_ ift2i110n0n0n1s^lac22R3sACT5sshift2i170n0n0nlad314T0n1s%lae3_ 1R3sACT6sreduce0n5s_00094sexpr1i11s*laf31R3sACT6sreduce0n5s__ 00094sexpr1i11s+lag31R3sACT6sreduce0n5s_00094sexpr1i11s-lah3_ 1R3sACT6sreduce0n5s_00094sexpr1i11s/lai31R3sACT6sreduce0n5s__ 00094sexpr1i11s=laj22R3sACT5sshift2i180n0n0n2sCRlak31R3sACT6_ sreduce0n5s_00094sexpr1i11s^lal31R3sACT6sreduce0n5s_00094sex_ pr1i1lam98T0n1s(lan22R3sACT5sshift2i210n0n0n2sIDlao22R3sACT5_ sshift2i200n0n0n3sNUMlap22R3sACT5sshift2i220n0n0nlaq283T0n1s_ %lar31R3sACT6sreduce0n5s_00274sexpr1i11s*las31R3sACT6sreduce_ 0n5s_00274sexpr1i11s+lat31R3sACT6sreduce0n5s_00274sexpr1i11s_ -lau31R3sACT6sreduce0n5s_00274sexpr1i11s/lav31R3sACT6sreduce_ 0n5s_00274sexpr1i12sCRlaw31R3sACT6sreduce0n5s_00274sexpr1i11_ s^lax31R3sACT6sreduce0n5s_00274sexpr1i1lay44T0n1s$laz33R3sAC_ T6sreduce0n5s_00036sstream1i2lba206T0n1s$lbb31R3sACT6sreduce_ 0n5s_00074scalc1i21s(lbc31R3sACT6sreduce0n5s_00074scalc1i22s_ CRlbd31R3sACT6sreduce0n5s_00074scalc1i22sIDlbe31R3sACT6sredu_ ce0n5s_00074scalc1i23sNUMlbf31R3sACT6sreduce0n5s_00074scalc1_ i2lbg95T0n1s(lbh21R3sACT5sshift1i80n0n0n2sIDlbi21R3sACT5sshi_ ft1i70n0n0n3sNUMlbj21R3sACT5sshift1i90n0n0n3llbg3llbg3llbg3l_ lbg3llbg3llbglbk219T0n1s%lbl22R3sACT5sshift2i350n0n0n1s)lbm2_ 2R3sACT5sshift2i300n0n0n1s*lbn22R3sACT5sshift2i330n0n0n1s+lb_ o22R3sACT5sshift2i310n0n0n1s-lbp22R3sACT5sshift2i320n0n0n1s/_ lbq22R3sACT5sshift2i340n0n0n1s^lbr22R3sACT5sshift2i360n0n0nl_ bs313T0n1s%lbt31R3sACT6sreduce0n5s_00094sexpr1i11s)lbu31R3sA_ CT6sreduce0n5s_00094sexpr1i11s*lbv31R3sACT6sreduce0n5s_00094_ sexpr1i11s+lbw31R3sACT6sreduce0n5s_00094sexpr1i11s-lbx31R3sA_ CT6sreduce0n5s_00094sexpr1i11s/lby31R3sACT6sreduce0n5s_00094_ sexpr1i11s=lbz22R3sACT5sshift2i370n0n0n1s^lca31R3sACT6sreduc_ e0n5s_00094sexpr1i13llamlcb282T0n1s%lcc31R3sACT6sreduce0n5s__ 00274sexpr1i11s)lcd31R3sACT6sreduce0n5s_00274sexpr1i11s*lce3_ 1R3sACT6sreduce0n5s_00274sexpr1i11s+lcf31R3sACT6sreduce0n5s__ 00274sexpr1i11s-lcg31R3sACT6sreduce0n5s_00274sexpr1i11s/lch3_ 1R3sACT6sreduce0n5s_00274sexpr1i11s^lci31R3sACT6sreduce0n5s__ 00274sexpr1i1lcj247T0n1s%lck22R3sACT5sshift2i160n0n0n1s*lcl2_ 2R3sACT5sshift2i140n0n0n1s+lcm31R3sACT6sreduce0n5s_00134sexp_ r1i31s-lcn31R3sACT6sreduce0n5s_00134sexpr1i31s/lco22R3sACT5s_ shift2i150n0n0n2sCRlcp31R3sACT6sreduce0n5s_00134sexpr1i31s^l_ cq22R3sACT5sshift2i170n0n0nlcr247T0n1s%lcs22R3sACT5sshift2i1_ 60n0n0n1s*lct22R3sACT5sshift2i140n0n0n1s+lcu31R3sACT6sreduce_ 0n5s_00154sexpr1i31s-lcv31R3sACT6sreduce0n5s_00154sexpr1i31s_ /lcw22R3sACT5sshift2i150n0n0n2sCRlcx31R3sACT6sreduce0n5s_001_ 54sexpr1i31s^lcy22R3sACT5sshift2i170n0n0nlcz274T0n1s%lda31R3_ sACT6sreduce0n5s_00174sexpr1i31s*ldb31R3sACT6sreduce0n5s_001_ 74sexpr1i31s+ldc31R3sACT6sreduce0n5s_00174sexpr1i31s-ldd31R3_ sACT6sreduce0n5s_00174sexpr1i31s/lde31R3sACT6sreduce0n5s_001_ 74sexpr1i32sCRldf31R3sACT6sreduce0n5s_00174sexpr1i31s^ldg22R_ 3sACT5sshift2i170n0n0nldh274T0n1s%ldi31R3sACT6sreduce0n5s_00_ 194sexpr1i31s*ldj31R3sACT6sreduce0n5s_00194sexpr1i31s+ldk31R_ 3sACT6sreduce0n5s_00194sexpr1i31s-ldl31R3sACT6sreduce0n5s_00_ 194sexpr1i31s/ldm31R3sACT6sreduce0n5s_00194sexpr1i32sCRldn31_ R3sACT6sreduce0n5s_00194sexpr1i31s^ldo22R3sACT5sshift2i170n0_ n0nldp274T0n1s%ldq31R3sACT6sreduce0n5s_00214sexpr1i31s*ldr31_ R3sACT6sreduce0n5s_00214sexpr1i31s+lds31R3sACT6sreduce0n5s_0_ 0214sexpr1i31s-ldt31R3sACT6sreduce0n5s_00214sexpr1i31s/ldu31_ R3sACT6sreduce0n5s_00214sexpr1i32sCRldv31R3sACT6sreduce0n5s__ 00214sexpr1i31s^ldw22R3sACT5sshift2i170n0n0nldx283T0n1s%ldy3_ 1R3sACT6sreduce0n5s_00234sexpr1i31s*ldz31R3sACT6sreduce0n5s__ 00234sexpr1i31s+lea31R3sACT6sreduce0n5s_00234sexpr1i31s-leb3_ 1R3sACT6sreduce0n5s_00234sexpr1i31s/lec31R3sACT6sreduce0n5s__ 00234sexpr1i32sCRled31R3sACT6sreduce0n5s_00234sexpr1i31s^lee_ 31R3sACT6sreduce0n5s_00234sexpr1i3lef229T0n1s%leg22R3sACT5ss_ hift2i160n0n0n1s*leh22R3sACT5sshift2i140n0n0n1s+lei22R3sACT5_ sshift2i120n0n0n1s-lej22R3sACT5sshift2i130n0n0n1s/lek22R3sAC_ T5sshift2i150n0n0n2sCRlel31R3sACT6sreduce0n5s_00114sexpr1i31_ s^lem22R3sACT5sshift2i170n0n0nlen283T0n1s%leo31R3sACT6sreduc_ e0n5s_00254sexpr1i31s*lep31R3sACT6sreduce0n5s_00254sexpr1i31_ s+leq31R3sACT6sreduce0n5s_00254sexpr1i31s-ler31R3sACT6sreduc_ e0n5s_00254sexpr1i31s/les31R3sACT6sreduce0n5s_00254sexpr1i32_ sCRlet31R3sACT6sreduce0n5s_00254sexpr1i31s^leu31R3sACT6sredu_ ce0n5s_00254sexpr1i33llam3llam3llam3llam3llam3llam3llamlev21_ 9T0n1s%lew22R3sACT5sshift2i350n0n0n1s)lex22R3sACT5sshift2i46_ 0n0n0n1s*ley22R3sACT5sshift2i330n0n0n1s+lez22R3sACT5sshift2i_ 310n0n0n1s-lfa22R3sACT5sshift2i320n0n0n1s/lfb22R3sACT5sshift_ 2i340n0n0n1s^lfc22R3sACT5sshift2i360n0n0nlfd246T0n1s%lfe22R3_ sACT5sshift2i350n0n0n1s)lff31R3sACT6sreduce0n5s_00134sexpr1i_ 31s*lfg22R3sACT5sshift2i330n0n0n1s+lfh31R3sACT6sreduce0n5s_0_ 0134sexpr1i31s-lfi31R3sACT6sreduce0n5s_00134sexpr1i31s/lfj22_ R3sACT5sshift2i340n0n0n1s^lfk22R3sACT5sshift2i360n0n0nlfl246_ T0n1s%lfm22R3sACT5sshift2i350n0n0n1s)lfn31R3sACT6sreduce0n5s_ _00154sexpr1i31s*lfo22R3sACT5sshift2i330n0n0n1s+lfp31R3sACT6_ sreduce0n5s_00154sexpr1i31s-lfq31R3sACT6sreduce0n5s_00154sex_ pr1i31s/lfr22R3sACT5sshift2i340n0n0n1s^lfs22R3sACT5sshift2i3_ 60n0n0nlft273T0n1s%lfu31R3sACT6sreduce0n5s_00174sexpr1i31s)l_ fv31R3sACT6sreduce0n5s_00174sexpr1i31s*lfw31R3sACT6sreduce0n_ 5s_00174sexpr1i31s+lfx31R3sACT6sreduce0n5s_00174sexpr1i31s-l_ fy31R3sACT6sreduce0n5s_00174sexpr1i31s/lfz31R3sACT6sreduce0n_ 5s_00174sexpr1i31s^lga22R3sACT5sshift2i360n0n0nlgb273T0n1s%l_ gc31R3sACT6sreduce0n5s_00194sexpr1i31s)lgd31R3sACT6sreduce0n_ 5s_00194sexpr1i31s*lge31R3sACT6sreduce0n5s_00194sexpr1i31s+l_ gf31R3sACT6sreduce0n5s_00194sexpr1i31s-lgg31R3sACT6sreduce0n_ 5s_00194sexpr1i31s/lgh31R3sACT6sreduce0n5s_00194sexpr1i31s^l_ gi22R3sACT5sshift2i360n0n0nlgj273T0n1s%lgk31R3sACT6sreduce0n_ 5s_00214sexpr1i31s)lgl31R3sACT6sreduce0n5s_00214sexpr1i31s*l_ gm31R3sACT6sreduce0n5s_00214sexpr1i31s+lgn31R3sACT6sreduce0n_ 5s_00214sexpr1i31s-lgo31R3sACT6sreduce0n5s_00214sexpr1i31s/l_ gp31R3sACT6sreduce0n5s_00214sexpr1i31s^lgq22R3sACT5sshift2i3_ 60n0n0nlgr282T0n1s%lgs31R3sACT6sreduce0n5s_00234sexpr1i31s)l_ gt31R3sACT6sreduce0n5s_00234sexpr1i31s*lgu31R3sACT6sreduce0n_ 5s_00234sexpr1i31s+lgv31R3sACT6sreduce0n5s_00234sexpr1i31s-l_ gw31R3sACT6sreduce0n5s_00234sexpr1i31s/lgx31R3sACT6sreduce0n_ 5s_00234sexpr1i31s^lgy31R3sACT6sreduce0n5s_00234sexpr1i3lgz2_ 28T0n1s%lha22R3sACT5sshift2i350n0n0n1s)lhb31R3sACT6sreduce0n_ 5s_00114sexpr1i31s*lhc22R3sACT5sshift2i330n0n0n1s+lhd22R3sAC_ T5sshift2i310n0n0n1s-lhe22R3sACT5sshift2i320n0n0n1s/lhf22R3s_ ACT5sshift2i340n0n0n1s^lhg22R3sACT5sshift2i360n0n0nlhh282T0n_ 1s%lhi31R3sACT6sreduce0n5s_00254sexpr1i31s)lhj31R3sACT6sredu_ ce0n5s_00254sexpr1i31s*lhk31R3sACT6sreduce0n5s_00254sexpr1i3_ 1s+lhl31R3sACT6sreduce0n5s_00254sexpr1i31s-lhm31R3sACT6sredu_ ce0n5s_00254sexpr1i31s/lhn31R3sACT6sreduce0n5s_00254sexpr1i3_ 1s^lho31R3sACT6sreduce0n5s_00254sexpr1i3") glst := decode("lhp550Llhq37T0n1sS1i24scalc1i44sexpr1i66sstream_ 1i3lhr2T0nlhs2T0nlht32T0n4scalc1i44sexpr1i66sstream2i10lhu2T_ 0n0nlhv2T0nlhw12T0n4sexpr2i19lhx2T0nlhy2T0nlhz2T0nlia12T0n4s_ expr2i23lib12T0n4sexpr2i24lic12T0n4sexpr2i25lid12T0n4sexpr2i_ 26lie12T0n4sexpr2i27lif12T0n4sexpr2i28lig12T0n4sexpr2i290nli_ h2T0nlii12T0n4sexpr2i38lij2T0nlik2T0nlil2T0nlim2T0nlin2T0nli_ o2T0nlip2T0nliq2T0nlir2T0nlis12T0n4sexpr2i39lit12T0n4sexpr2i_ 40liu12T0n4sexpr2i41liv12T0n4sexpr2i42liw12T0n4sexpr2i43lix1_ 2T0n4sexpr2i44liy12T0n4sexpr2i450nliz2T0nlja2T0nljb2T0nljc2T_ 0nljd2T0nlje2T0nljf2T0nljg2T0n") # # Uncomment the following if you want a look at the state and goto # tables. If you aren't planning on looking at them, find the # procedure definition for dump_lists below, and delete it. Why # keep it around if it's not being used? # # dump_lists(&errout, alst, glst) } # # New, not recursive, invocation; reset stacks, line number and # error count. # start_symbol := "S" /err_state := 1 /state_stack := [1] & line_number := 0 & errors := 0 /value_stack := [] /next_token := create iparse_tokens(stream) while token := @next_token do { repeat { act := \alst[state_stack[1]][token.sym] | { # # You can replace this error handler with whatever you # like, and have it do whatever you like. # # (iparse_error increments global errors variable) return iparse_error(alst, state_stack, value_stack, token, next_token, err_state) } err_state := 0 case act.str of { "shift" : { # push the next state onto the state stack push(state_stack, act.state) # push the current token's literal value onto the # value stack push(value_stack, token.str) # break out of enclosing repeat loop break } "reduce" : { arglist := [] # # Pop as many elements off of the token stack as # there are symbols in the right-hand side of the # rule. Push these elements onto an argument list. # every 1 to act.size do { pop(state_stack) push(arglist, pop(value_stack)) } # # Check to goto list to see what state we should # be in, and push that state onto the state stack. # push(state_stack, glst[state_stack[1]][act.sym]) # # Call the code associated with the current # reduction, and push the result onto the stack. # For more results, push a coexpression instead. # push(value_stack, (proc(act.by_rule)!arglist)) | { # On failure, return the stacks to the state # they were in before the last reduction. pop(state_stack) return iparse_error(alst, state_stack, value_stack, token, next_token, err_state + 1) } } "accept" : { # # We're done. Return the last result. # return value_stack[1] } } } } write(&errout, "iparse: unexpected end of input") fail 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 above only pays attention to the sym field, although the # user might well want to use the actual text. # procedure iparse_tokens(stream) local token, c, whitespace, operators #global line_number whitespace := '\r\t \n' operators := '+-*/^()=' token := "" every c := !(!&input || "\n") do { if not any(whitespace ++ operators, c) then { token ||:= c } else { if integer(token) then suspend TOK("NUM", "" ~== token) else suspend TOK("ID", "" ~== token) if any(operators, c) then suspend TOK(c) else { if c == "\n" then { line_number +:= 1 suspend TOK("CR"|"CR") } } token := "" } } if integer(token) then suspend TOK("NUM", "" ~== token) else suspend TOK("ID", "" ~== token) suspend TOK("CR"|"$") end # # iparse_error: list x list x list x list x TOK x coexpression x integer -> ? # (alst, state_stack, value_stack, token_stack, token, # next_token, err_state) -> ? # # Where alst is the action list, where state_stack is the state # stack used by iparse, where token stack is the token stack used # by iparse, where token is the current lookahead TOK record, # where next_token is the coexpression from which we get our # tokens, and where err_state indicates how many recursive calls # we've made to the parser via the error handler without a # recovery. # # Recursively calls iparse, attempting to restart the parser after # an error. Increments global "errors" variable (a count of the # number of errors encountered, minus cascading series of errors). # procedure iparse_error(alst, state_stack, value_stack, token, next_token, err_state) local sym static tlst #global line_number, errors initial { tlst := decode("lgv35S1s+1s(1s%1s-1s=1s*1s/1s$1s)1s^3sNUM") } # # Check to see how many attempts we have made at a resync. If # this is a new error series, increment the global "errors" count. # if (err_state +:= 1) > 3 then stop("iparse_error: unable to resync after error; aborting") else if err_state = 1 then errors +:= 1 # GLOBAL # # Check to see if the grammar even has this pre-terminal. # if not member(tlst, token.sym) then write(&errout, "iparse_error: unknown token, ", token.sym, ", in line ", line_number) # Only note the first in a series of cascading errors. else if err_state = 1 then { write(&errout, "iparse_error: syntax error in line ", line_number, "; resynchronizing parser") } # # Now, try to shift in the next input token to see if we can # resync the parser. Stream argument is null because next_token # has already been created. # return iparse(&null, state_stack, value_stack, token_stack, next_token, err_state) end # # dump_lists: file x list x list -> (null) # (f, gl, al) -> (null) # # Where f is an open file, gl is the goto list, and al is the # action list. Writes to file f a human-readable dump of the goto # and action list. # procedure dump_lists(f, al, gl) local TAB, look_list, red_list, i, sym, act TAB := "\t" look_list := list() red_list := list() every i := 1 to *al do { every INSERT(look_list, key(\al[i])) if /al[i] then write(&errout, "dump_lists: warning! state ", i, " is null") } writes(f,TAB) every i := 1 to *look_list do writes(f,look_list[i], TAB) write(f) every i := 1 to *al do { writes(f,i, TAB) act := "" every sym := !look_list do { if \al[i][sym] then { writes(f,al[i][sym].str[1:3], al[i][sym].state) if al[i][sym].str == "reduce" then { INSERT(red_list, al[i][sym].sym) writes(f,al[i][sym].sym) } } writes(f,TAB) } write(f) } write(f) writes(f,TAB) every i := 1 to *red_list do writes(f,red_list[i], TAB) write(f) every i := 1 to *gl do { writes(f,i, TAB) act := "" every sym := !red_list do { if \(\gl[i])[sym] then writes(f,gl[i][sym]) writes(f,TAB) } write(f) } end # # INSERT: set or list x record -> set or list # (sset, rec) -> sset # # Where sset is a homogenous set or list of records, rec is a # record, and the return value is sset, with rec added, iff an # equivalent record was not there already. Otherwise, sset is # returned unchanged. INSERT(), _unlike insert(), FAILS IF REC # IS ALREADY PRESENT IN SSET. # # This procedure is used by dump_lists() above. If you delete # dump_lists(), delete this as well, as also Equiv() below. # procedure INSERT(sset, rec) local addto # # Decide how to add members to sset, depending on its type. # addto := { case type(sset) of { "set" : insert "list" : put default : stop("INSERT: wrong type argument (",type(sset),")") } } # Rudumentary error check to be sure the object to be inserted # into sset is of the same time as the objects already there. # if *sset > 0 then type(rec) == type(sset[1]) | stop("INSERT: unexpected type difference") # # If a rec-like item isn't in sset, add it to sset. # if Equiv(!sset, rec) then fail else return addto(sset, rec) end # # Equiv: struct x struct -> struct # (x1, x2) -> x2 # # Where x1 and x2 are arbitrary structures. Returns x2 if x1 and # x2 are structurally equivalent (even if not identical). Taken # from the IPL file "structs.icn." # # Equiv() is used by dump_lists() above. If you delete # dump_lists, delete this as well. # procedure Equiv(x1, x2, done) local code, i if x1 === x2 then return x2 # Covers everything but structures. if type(x1) ~== type(x2) then fail # Must be same type. if type(x1) == ("procedure" | "file")# Leave only those with sizes (null then fail # taken care of by first two tests). if *x1 ~= *x2 then fail /done := table() (/done[x1] := set()) | # Make set of equivalences if new. (if member(done[x1],x2) then return x2) # Records complicate things. image(x1) ? (code := (="record" | type(x1))) case code of { "list" | "record" : every i := 1 to *x1 do if not Equiv(x1[i],x2[i],done) then fail "table" : if not Equiv(sort(x1,3),sort(x2,3),done) then fail "set" : if not Equiv(sort(x1),sort(x2),done) then fail default : fail # Vaues of other types are different. } insert(done[x1],x2) # Equivalent; add to set. return x2 end -------------------------------- cut here -------------------------------- -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Oct 28 12:39:22 1992 Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 10:29:13 MST Date: 28 Oct 92 12:39:22 GMT From: mcsun!Germany.EU.net!sbsvax!coli-gate.coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman@uunet.uu.net (Stephen Spackman) Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken Subject: Re: confusing errors 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 In article <1992Oct23.183537.6160@midway.uchicago.edu> goer@ellis.uchicago.edu (Richard L. Goerwitz) writes: |If you like regularity, just use LISP. It is very easy to read and write |automatically, and its syntax is trivial. In fact, Icon is very easy to |tokenize with automatic semicolon insertion, and I've never had any prob- |lems reading or writing it. Not as regular as LISP, but then LISP code |is really not all that readable unless formatted with great skill (and a |smart editor). Syntactic regularity != usability. But syntactic IRregularity != usability, either; in fact it definitely degrades it. Just because one abysmal language (Lisp) has it but is still terrible, doesn't mean that we should abandon it as a goal! In fact, Lisp derives perhaps most of the few advantages it has from this regularity, as language designers would do well to note. It's the *particular choice* of regular syntax that is the problem. Now a language like Icon just doesn't commit to any easily explainable syntax - perhaps avoiding criticisms about its design, but only by the smokescreen method! [note to the audience: goer and I know each other reasonably well. Feel free to take this comment with a pinch of rhetorical salt.] |Maybe you are just baiting me, but the semicolon is not an operator with |abstract semantics. It has semantics only in the sense that it directs the |syntactic analyzer to map the concrete syntax to the abstract syntax in a |certain way. ???? It's probably hopeless to direct you to the revised report on algol 68 [this isn't a random insult, if you've seen the document you'll know exactly what I mean - it isn't exactly very readable], but if it doesn't have semantics somewthing is BADLY wrong with this language. It doesn't mean, "first do this, then do that"? Sounds like a pretty basic operation to me, and NOT one I'd like left implicit, since it involves the discarding of a result from its left argument, something that in many programming styles is probably an error unless explicitly declared otherwise. Tell me, can you characterise for me the circumstances under which a newline will NOT be interpreted as a go-on operator? When IS it safe to break an expression? And, really, WHY would I ever want "throw away what I just did" to be the DEFAULT operation? ------------------------------------------------------------------------ stephen p spackman stephen@acm.org ------------------------------------------------------------------------ From icon-group-sender Fri Oct 30 11:05:59 1992 Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 11:12:21 MST Date: Fri, 30 Oct 1992 11:05:59 MST From: "Kenneth Walker" Message-Id: <199210301805.AA28185@optima.cs.arizona.edu> To: icon-group Subject: Re: confusing errors Status: R Errors-To: icon-group-errors@cs.arizona.edu I agree that the semicolon control structure does have semantics. If you look at the ucode produced by icont -c, you'll see code to implement the semantics. This code not only discards the value of the left operand, it discards any suspended generators from the operand. From icon-group-sender Fri Oct 30 11:12:45 1992 Date: Fri, 30 Oct 1992 11:12:45 MST From: icon-group-sender Message-Id: <199210301812.AA27034@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 11:12:45 MST Status: R Errors-To: icon-group-errors@cs.arizona.edu Apparently-To: icon-group-addresses end of lines seems like a hack stuck onto the language. But from a programming perspective, it seems to me to be quite elegant - I need only remember one simple rule about where to break lines. This is perhaps a very simple analogy to natural languages: in terms of formal theory they are a nightmare to deal with, but people find them very nice to use. Ken Walker kwalker@cs.arizona.edu uunet!arizona!kwalker From icon-group-sender Thu Oct 29 08:11:08 1992 Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 20:00:25 MST Date: 29 Oct 92 08:11:08 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Michael Sperber) Subject: semicolons Message-Id: <9210290811.AA12866@wega.informatik.uni-hannover.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi there, I just noticed that 386 Icon 8.5 hangs when called from a program that uses the GNUish swapping library (such as MS_SH 2.0 or GNUish Make 3.58). Has anyone noticed or, better, fixed the problem? Is there a djgpp-compiled Icon out there? Any help would be appreciated. Cheers :-> Chispy From icon-group-sender Wed Oct 28 16:17:55 1992 Received: by cheltenham.cs.arizona.edu; Fri, 30 Oct 1992 20:58:57 MST Date: 28 Oct 92 16:17:55 GMT From: uchinews!ellis!goer@handies.ucar.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: confusing errors Message-Id: <1992Oct28.161755.26390@midway.uchicago.edu> References: , <1992Oct23.183537.6160@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: > >Now a language like Icon just doesn't commit to any easily explainable >syntax - perhaps avoiding criticisms about its design, but only by the >smokescreen method! Actually, its syntax is very much like that of any Algol-like language. If you get a chance some time, just take a look in the latest grammar specs in _The Icon Programming Language_. Some people (hackers mostly) are turned off by its Pascal-ish look (because of course anything Pas- calish looking must be evil :-)). >|Maybe you are just baiting me, but the semicolon is not an operator with >|abstract semantics. It has semantics only in the sense that it directs the >|syntactic analyzer to map the concrete syntax to the abstract syntax in a >|certain way. > >???? It's probably hopeless to direct you to the revised report on algol >68 [this isn't a random insult, if you've seen the document you'll know >exactly what I mean - it isn't exactly very readable], but if it doesn't >have semantics somewthing is BADLY wrong with this language. I'm making what I thought was a common distinction between concrete and abstract syntax (see, e.g., Aho-Sethi-Ullman, section 2.5). Some operators only have relevance on the concrete level. My point is that if such operators can easily be dispensed with, we should do so. >Tell me, can you characterise for me the circumstances under which a >newline will NOT be interpreted as a go-on operator? When IS it safe to >break an expression? This is the key question. It's really quite simple, and requires the ad- dition of only about two hundred characters to the lexer. Tokens can either begin or end an expression (or both or neither). This is intuitive. For instance, if we get the operator := at the end of a line, then obviously the expression isn't complete. If, however, we get := and then an identi- fier, then a newline, we have a complete expression and a SEMICOL (that's what the Icon tokenizer calls it, I think) token can be emitted. It's all quite simple, and results in code that isn't cluttered with superfluous directives. You might think that this arrangement results in strange er- rors, but in practice, one rarely makes an error that leads to unexpected groupings. In lvalue := rvalue, one might spell rvalue wrong. One almost never leaves rvalue out accidentally, though. I can attest to this from much experience. Try working with a language for a few weeks that has automatic semicolon insertion, and see whether you want to go back. This argument can't be settled in the abstract. Here's an example of where a newline should be ignored. Any Icon programmer immediately recognizes the correct grouping, as I suspect even non Icon programmers would. The semicolon after the string is wholly useless, though if you like it you can put it there: procedure main() ident := "this is an overlong line that just won't fit above, so I put it here" write(ident) end Here is an example of where semicolons are completely superfluous. Can you imagine a language that was so poorly designed that you had to insert a useless operator all the time? procedure main() ident := "hello"; write(ident); end procedure main() ident := "hello" write(ident) end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat Oct 31 07:56:52 1992 Received: by cheltenham.cs.arizona.edu; Sat, 31 Oct 1992 08:03:07 MST Date: 31 Oct 1992 07:56:52 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: confusing errors To: icon-group@cs.arizona.edu Message-Id: <01GQL9G7YK4291VWW7@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 And now a comment from someone who doesn't have a CS degree and hasn't taken classes on compiler/language design. flame on ;-) I was programmer of BASIC and ASSEMBLER for 15 years. That's all I knew. I tried to learn Pascal, I tried to learn C. Other than horrible typed variables, the next stumbling block to learning them was those pesky semicolons. We used to joke to each other, " program not working? just generously pepper it with some more semicolons!" I picked up a little FORTRAN during that painful time. I also read about Icon in Byte or Omni (I can't remember anymore). Finally one day I was able to justify to management to spend $50 to buy Icon 6.0 and the book, (instead of a proprietary string language for $10,000). I read book in a week. I wrote programs the next week. The code actually was structured! No pesky semicolons, no pesky typed variables, declarations, addresses, or pointers. The 360 assembler we used (our own home brew) had nothing to permit multiple statements on a line. And of course everything had to fit in 71 bytes, have a blank, and then an 8 digit sequence number for such is the world of HOLLERITH. In BASIC there was either a \ or : to permit more than one statement per line. This seems to me to be the icon use of a semicolon. On rare occasions it's handy to me to bunch a mess of assignments together. x1 := ?horiz ; y1 := ?verti ; z1 := ?depth x2 := ?horiz ; y2 := ?verti ; z2 := ?depth I like that as kind of a grouping tool. But I would dread having to terminate every statement/operation/expression with a semicolon. That would make the code 'ugly' and cause those of us from certain backgrounds to make a lot more mistakes. To me semicolons are a throw back to the old days when compiler designers weren't as smart as they are now. I say strict semicolon terminators belong in the chad hopper with the 300 baud acoustic coupler modems and other artifacts. Oh well, pardon my flames, but I couldn't bear to see Icon turned into a PASCAL, C, PL/M, or ADA. p.s. my degree is in scientific photography 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 Sun Nov 1 00:05:55 1992 Received: by cheltenham.cs.arizona.edu; Mon, 2 Nov 1992 06:12:55 MST Date: 1 Nov 92 00:05:55 GMT From: access.usask.ca!sue!hercules.cs.uregina.ca!skagos@decwrl.dec.com (P. Takis Skagos) Organization: University of Regina, SK, Canada Subject: Character manipulation Message-Id: <1992Nov01.000555.788292@sue.cc.uregina.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hello, While Icon is *GREAT* at manipulating data on a line-by-line basis, it, I feel, lacks somewhat in the character-by-character manipulation arena. I was wondering if someone knows of a character manipulation library that is available via ftp. Any help would truly be appreciated. Thanks! P. Takis Skagos (skagos@cs.uregina.ca) From icon-group-sender Mon Nov 2 07:35:00 1992 Received: by cheltenham.cs.arizona.edu; Mon, 2 Nov 1992 09:12:22 MST Message-Id: <199211021340.AA17081@optima.cs.arizona.edu> From: nowlin@iwtqg.att.com Date: Mon, 2 Nov 92 07:35 CST To: att!cs.arizona.edu!icon-group Subject: Re: char manipulation Status: R Errors-To: icon-group-errors@cs.arizona.edu > While Icon is *GREAT* at manipulating data on a line-by-line basis, > it, I feel, lacks somewhat in the character-by-character manipulation > arena. I was wondering if someone knows of a character manipulation > library that is available via ftp. Any help would truly be appreciated. > Thanks! > > P. Takis Skagos > (skagos@cs.uregina.ca) Throw out an example of what you mean by character-by-character manipulation and a language that you feel can do what you want. There's not enough info in the above let me offer help. Jerry Nowlin From icon-group-sender Sun Nov 1 09:59:17 1992 Received: by cheltenham.cs.arizona.edu; Mon, 2 Nov 1992 09:12:34 MST Date: 1 Nov 92 09:59:17 GMT From: agate!doc.ic.ac.uk!uknet!strath-cs!fulcrum!bham!news.cs.bham.ac.uk!percy!aps@ucbvax.Berkeley.EDU (Alan P Sexton) Organization: University of Birmingham Subject: Re: semicolons Message-Id: <1992Nov1.095917@cs.bham.ac.uk> References: <199210281642.AA24982@cheltenham.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 <199210281642.AA24982@cheltenham.cs.arizona.edu>, ralph@cs.arizona.edu (Ralph Griswold) writes: |> I normally stay out of "discussions" like this, but I can't resist |> remarking that, in practice, the semicolon insertion performed |> by the Icon translator works well in practice, programmers like it, |> it's been touted as one of the nice little touches that makes |> Icon a pleasure to use, and I don't recall a single complaint |> about the feature from a practicing Icon programmer (once they |> understand it). |> |> The wisdom on idiomatic Icon programming is that semicolons should |> never appear (syntactically) in Icon programs. |> |> If you want to argue syntax, what semicolon insertion does is |> give line terminators syntactic significance. In most programs, |> an Icon programmer thinks of a newline (or whatever your favorite |> platform uses to terminate lines) in the same way programmers |> in languages with similar syntax think of semicolons. |> |> 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) Have you looked at how Turing handles this problem? It is a pascal/euclid/modula/C-like language where (among other things) they got rid of unnecessary syntax (nothing like ``program x'' etc.) In particular semicolons are not necessary (they still allow them for the benefit of those who can't seem to program without them). The interesting part is that they are not handled by semicolon insertion: newlines are just whitespace. Careful design of the grammar and use of a `maximal scan' principle, ensures unambiguous parsing. The whole thing has a formal definition and semantics (and was designed with these objectives in mind) c.f. ``The Turing Programming Language: Design and Definition'' R.Holt, P.Matthews, J. Rosselet, J.Cordy Prentice Hall 1988, ISBN: 0-13-933136-0 Alan P. Sexton, Tel: 021-414 3703 University of Birmingham, School of Computer Science Edgbaston, Birmingham B15 2TT, England A.P.Sexton@cs.bham.ac.uk From icon-group-sender Mon Nov 2 03:19:51 1992 Received: by cheltenham.cs.arizona.edu; Tue, 3 Nov 1992 05:03:16 MST Date: 2 Nov 92 03:19:51 GMT From: sun-barr!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@ames.arc.nasa.gov (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Character manipulation Message-Id: <1992Nov2.031951.18774@midway.uchicago.edu> References: <1992Nov01.000555.788292@sue.cc.uregina.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu skagos@hercules.cs.uregina.ca (P. Takis Skagos) writes: > > While Icon is *GREAT* at manipulating data on a line-by-line basis, >it, I feel, lacks somewhat in the character-by-character manipulation >arena. This is quite true. It certainly tends to encourage us to read files line by line, and perform operations on those lines via scanning. If we must do things on a char-by-char basis (as, for example, tokenizing), then we can either a) figure out a way to bit off chunks that can be scanned, or b) use Icon as a kind of poor-man's C. Too much of b and we obviously shouldn't be using Icon. (Every language has it's strong and weak points.) Maybe if you'd post an example of what you'd like to do, we can col- lectively solve the problem. It's always nice when people post ques- tions about real-world problems. One thing that's worth thinking about is whether string scanning could be extended to cover files. That would solve your problem. Seems like a great idea to me. Really great. It's something the Icon Pro- ject has been talking about. Any bright students at the U of Arizona looking for class projects :-). Would take some interesting buffering and a lot of fseeks. But wouldn't it be neat to have scanning usable on character streams as well as strings? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Nov 3 06:06:52 1992 Received: by cheltenham.cs.arizona.edu; Tue, 3 Nov 1992 05:03:39 MST Via: uk.ac.manchester.computer-science; Tue, 3 Nov 1992 07:11:22 +0000 From: Steve Holden Date: Tue, 3 Nov 92 06:06:52 GMT Message-Id: <3873.9211030606@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: Semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu I only have a first-class honours degree in Computer Science, so I may not understand this discussion properly, but it seems to _me_ that anyone who argues against the semi-colon insertion probably would prefer Algol 68. Good luck to them, I say. If they don't know what a dangling operator looks like even when it's dangling in front of them then they should be taken off the icon list immediately :-) regards Steve From icon-group-sender Fri Oct 30 17:57:49 1992 Received: by cheltenham.cs.arizona.edu; Tue, 3 Nov 1992 12:29:08 MST Date: 30 Oct 92 17:57:49 GMT From: ucivax!omalley@ucbvax.Berkeley.EDU (Owen O'Malley) Organization: UC Irvine Department of ICS Subject: Re: semicolons Message-Id: <2AF1779D.15473@ics.uci.edu> References: <199210290026.AA05706@cheltenham.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 Personally, I like using semicolons and think they increase readability. The compiler/interpreter does a good job of determining where to put automatic semicolons, but it is harder for me to read a series of non-semicoloned lines especially when some of the statements are on more than one line. I don't mind the feature of optional semicolons (mostly because I've never been burned by the compiler inserting a semicolon where I didn't want one), but I almost always use them. -- Owen O'Malley From icon-group-sender Tue Nov 3 14:00:00 1992 Received: by cheltenham.cs.arizona.edu; Tue, 3 Nov 1992 16:44:33 MST Message-Id: <199211032038.AA22280@optima.cs.arizona.edu> From: nowlin@iwtqg.att.com Date: Tue, 3 Nov 92 14:00 CST To: att!cs.arizona.edu!icon-group Subject: Re: semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu > Personally, I like using semicolons and think they increase > readability. The compiler/interpreter does a good job of determining > where to put automatic semicolons, but it is harder for me to read a > series of non-semicoloned lines especially when some of the statements > are on more than one line. I don't mind the feature of optional > semicolons (mostly because I've never been burned by the compiler > inserting a semicolon where I didn't want one), but I almost always > use them. I have an idea. Suppose we cobble up a version of Icon that requires semicolons to make those of you who feel the need for some kind of syntactic security blanket happy. But I'd even go further. Why not a version of Icon that requires expressions to start in column ten and comments to start in column one. Then we could require type declarations and add gotos to the language. Heck, we could even require that it be submitted on punched cards and that your output be on paper. Maybe paper tape instead of cards. Maybe it could only run on PDP machines and you have to enter the program by toggling the switches on the front panel. Maybe ... Seem like we're going the wrong direction here? Jerry Nowlin From icon-group-sender Wed Nov 4 07:05:19 1992 Received: by cheltenham.cs.arizona.edu; Wed, 4 Nov 1992 09:05:46 MST Date: Wed, 4 Nov 92 15:03 MET From: JANPETER@mpi.nl Subject: file scanning To: icon-group@cs.arizona.edu Message-Id: <01GQRAOSOAB48WWBJA@KUNRC1.URC.KUN.NL> X-Envelope-To: icon-group@cs.arizona.edu X-Vms-To: IN%"icon-group@cs.arizona.edu" Comments: Sent using PMDF-822 V3.0, routing is done by KUNRC1 Status: R Errors-To: icon-group-errors@cs.arizona.edu Richard Goerwitz writes: >One thing that's worth thinking about is whether string scanning could >be extended to cover files. That would solve your problem. Seems >like a great idea to me. Really great. It's something the Icon Pro- >ject has been talking about. Any bright students at the U of Arizona >looking for class projects :-). Would take some interesting buffering >and a lot of fseeks. But wouldn't it be neat to have scanning usable >on character streams as well as strings? This was somewhat surprising to me, because I already do string scanning on files. I'll explain how, and I'm eager to receive comments on the proposed method. The method works great on Ultrix, and MSDOS (386) platforms, so I gather it's kosher Icon. The basic tric is to use the ! generator twice. Suppose we just want to print all successive characters in a text file. The text file is: The man the woman the dog bit hit chose to be free. Now one way to scan the entire file (as if it's one string, so to speak) is this: procedure main() inputfile := open("filename") !!inputfile ? while write(move(1)) end the output is: The man the woman thedog bit hit chose to be free. If this looks simple, that's because it is simple, but I wonder: Is this what is meant by scanning a character stream, or have I understood the problem wrongly? Jan P. de Ruiter Max Planck Institute for Psycholinguistics janpeter@mpi.nl From icon-group-sender Thu Nov 5 10:13:58 1992 Received: by cheltenham.cs.arizona.edu; Thu, 5 Nov 1992 12:17:22 MST Date: Thu, 5 Nov 92 10:13:58 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <523344@MTS.cc.Wayne.edu> Subject: Semicolons and newlines Status: R Errors-To: icon-group-errors@cs.arizona.edu Personally, I very much like the way that Icon handles semicolons and newlines. To appreciate it, it helps to look at some history in the Hegelian terms of thesis, antithesis, and synthesis. (Idle query: am I the first person to mention Hegel in this newsgroup?) In the early days of programming languages, Fortran was dominant. The Fortran convention is that a newline ends a statement, with an "escape hatch" in the form of continuation cards. People generally found the continuation cards to be an awkward and uncomfortable convention, and also were looking for a way of placing more than one statement on a line. That thesis--that newlines end statements, but with an escape hatch--led to the antithesis: that newlines should be ignored altogether and that a particular character, the semicolon, should be used either to separate or to terminate statements. That was the approach of Algol 60, Pascal, and their numerous successors (which did disagree on the terminator versus separator question). That approach is still dominant today. It is tolerable, but hardly optimal. Icon, of course, introduced the synthesis: the idea that newlines indeed ought to be meaningful, but that by themselves they were not sufficient as a method of ending statements. (Let's ignore for the purposes of this discussion the fact that Icon is an expression language.) I don't know whether Ralph originated this idea, since it also appears in awk. It seems to me that the synthesis has gotten it right: that newlines are too useful to be ignored and are indeed the natural way of ending a statement, but that we need some way of overriding the significance of newlines both to place several statements on a single line and to allow statements to span lines. One drawback to the Icon approach, but an unavoidable one, is that it is more natural to begin a continuation line with an operator than to end the previous line with an operator. (Or so it seems to me, based perhaps on my mathematical background; in mathematical writing, continuation lines of equations usually begin with operators.) Another drawback in extending the idea to other languages is that it's necessary for the lexical scanner to be able to distinguish operators from other lexical elements. That may not be easy in a language that allows identifiers to be defined as operators. For example, the Icon lexical scanner has to be able to distinguish between x := not + z and x := knot + z The second of these gets an inserted semicolon, but the first does not. If Icon allowed me to define "knot" as an operator, it would be in trouble. Paul Abrahams From icon-group-sender Tue Nov 3 17:27:37 1992 Received: by cheltenham.cs.arizona.edu; Thu, 5 Nov 1992 12:17:41 MST Date: 3 Nov 92 17:27:37 GMT From: rpi!utcsri!newsflash.concordia.ca!ccu.umanitoba.ca!access.usask.ca!sue!hercules.cs.uregina.ca!skagos@gatech.edu (P. Takis Skagos) Organization: University of Regina, SK, Canada Subject: Re: Character manipulation Message-Id: <1992Nov03.172737.619209@sue.cc.uregina.ca> References: <1992Nov01.000555.788292@sue.cc.uregina.ca>, <1992Nov2.031951.18774@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 Well ... my character manipulation problems concerned parsing out lines and performing all sorts of substitutions and stuff (pre-processing a file). It is do-able with all the line scanning features of Icon, but it is a real drag. Oh well. P. Takis Skagos (skagos@hercules.cs.uregina.ca) From icon-group-sender Tue Nov 3 16:06:46 1992 Received: by cheltenham.cs.arizona.edu; Thu, 5 Nov 1992 13:42:56 MST Date: 3 Nov 92 16:06:46 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!emory!europa.asd.contel.com!paladin.american.edu!news.univie.ac.@!hp4at!mcsun!Germany.EU.net!rrz.uni-koeln.de!unidui!math.fu-berlin.de! (Martin Neitzel) Organization: Inst. f. Informatik, TU Braunschweig, FRG Subject: Re: confusing errors Message-Id: <1992Nov3.160646.21642@ips.cs.tu-bs.de> References: , <1992Oct23.183537.6160@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 > it [the Algol68 Revised Report] isn't exactly very readable Sorry, I just beg to differ. Of course, you should read a gentle introduction into two-level-grammars beforehand (Cleaveland/Uzgaliz excellent book on "Grammars for Programming Languages" comes to mind). On the topic of ";"s: Icon programmers have to be careful about their lexical/syntactical formulations anyway. The hamming distance between formaly correct and in some way executable programs is rather short. Any Icon programmer has to keep a steady eye on things like operator precedendes and parentheses, correct spelling of identifiers, and more, so I wouldn't see any ;-rule as another significant, additional burden. This is not intended to deride Icon's syntax. Every bonus has its price, and what is what is often in the eye of the beholder. Martin Neitzel From icon-group-sender Tue Nov 3 07:14:38 1992 Received: by cheltenham.cs.arizona.edu; Fri, 6 Nov 1992 05:21:07 MST Date: 3 Nov 92 07:14:38 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!csn!raven!rcd@ucbvax.Berkeley.EDU (Dick Dunn) Organization: eklektix - Boulder, Colorado Subject: Re: semicolons Message-Id: <1992Nov3.071438@eklektix.com> References: <199210290026.AA05706@cheltenham.cs.arizona.edu>, <2AF1779D.15473@ics.uci.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu omalley@spare.ics.uci.edu (Owen O'Malley) writes: >Personally, I like using semicolons and think they increase >readability... I think it might benefit the discussion if you'd explain this! Why do you find that it increases readability to add an unnecessary character?? Is it perhaps more a matter of tradition? -- Dick Dunn rcd@raven.eklektix.com -or- raven!rcd Boulder, Colorado ...Simpler is better. From icon-group-sender Wed Nov 4 02:00:47 1992 Received: by cheltenham.cs.arizona.edu; Fri, 6 Nov 1992 12:13:16 MST Date: 4 Nov 92 02:00:47 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Character manipulation Message-Id: <1992Nov4.020047.3235@midway.uchicago.edu> References: <1992Nov01.000555.788292@sue.cc.uregina.ca>, <1992Nov2.031951.18774@midway.uchicago.edu>, <1992Nov03.172737.619209@sue.cc.uregina.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu skagos@hercules.cs.uregina.ca (P. Takis Skagos) writes: >Well ... my character manipulation problems concerned parsing out >lines and performing all sorts of substitutions and stuff (pre-processing >a file). It is do-able with all the line scanning features of Icon, >but it is a real drag. Oh well. Give us some examples! -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Nov 4 12:43:32 1992 Received: by cheltenham.cs.arizona.edu; Fri, 6 Nov 1992 16:12:34 MST Date: 4 Nov 92 12:43:32 GMT From: mcsun!uknet!news.cs.bham.ac.uk!percy!aps@uunet.uu.net (Alan P Sexton) Organization: University of Birmingham Subject: debugify, icon8.7 and __debug_proc Message-Id: <1992Nov4.124332@cs.bham.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I recall seeing a message saying that debugify doesn't work with Icon 8.7. I just tried it and it failed due to incorrect hardcoded ID's for the &file and &line keywords being used in debugify.icn (presumably they were correct for older versions). On fixing that it seemed to work properly. Is there some other big problem? Does anyone have a more sophisticated __debug_proc? (e.g. single stepping, nexting, source code display etc.)? It looks very easy to write it oneself but I have this other program that I have to get working first... By the way, I'm very impressed by the debugify package: when I have time I'll have fun playing with it. Alan P. Sexton, Tel: 021-414 3703 University of Birmingham, School of Computer Science Edgbaston, Birmingham B15 2TT, England A.P.Sexton@cs.bham.ac.uk From icon-group-sender Thu Nov 5 04:45:27 1992 Received: by cheltenham.cs.arizona.edu; Sat, 7 Nov 1992 05:55:09 MST Date: 5 Nov 92 04:45:27 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Character manipulation Message-Id: <1992Nov5.044527.14981@midway.uchicago.edu> References: <1992Nov03.172737.619209@sue.cc.uregina.ca>, <1992Nov4.020047.3235@midway.uchicago.edu>, <1992Nov04.213857.23013@sue.cc.uregina.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu skagos@hercules.cs.uregina.ca (P. Takis Skagos) writes: >>>Well ... my character manipulation problems concerned parsing out >>>lines and performing all sorts of substitutions and stuff (pre-processing >>>a file). > >>Give us some examples! > >I cannot give examples ... part of this is for a class assignment ... Hint: Look back in your news history a few weeks (if it goes back that far). Just recently we talked about stripping out /* C-style comments */. It's a classic problem. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Nov 5 04:55:57 1992 Received: by cheltenham.cs.arizona.edu; Sat, 7 Nov 1992 05:55:54 MST Date: 5 Nov 92 04:55:57 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: file scanning Message-Id: <1992Nov5.045557.15162@midway.uchicago.edu> References: <01GQRAOSOAB48WWBJA@KUNRC1.URC.KUN.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 thing that's worth thinking about is whether string scanning could >>be extended to cover files. That would solve your problem. > >This was somewhat surprising to me, because I already do string >scanning on files. > > !!inputfile ? while write(move(1)) This only gives us a character at a time, and isn't really and dif- ferent than saying "while c := reads(inputfile) do (something with c)." This really isn't scanning (where you can move to arbitrary positions, perform analytical and synthetic operations, etc.). What we are talking about is overloading the ? operator so that it can take an expression on its left that produces either a string or a file, so that if a file were produced, functions like move() would still work. To work well, this would take a lot of seeking, and per- haps a little creative buffering, plus a whole lot of work on the machinery of scanning. I think it's a neat idea, and I don't see how it would be the least bit un-Iconish. It would sure make tokenizing a lot easier. Even Icon's own tokenizer wouldn't work with scanning, but rather needs a character-driven finite-state machine. Ken, Ralph, Clint, etc.: How hard would it really be to implement file scanning? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Nov 4 01:10:54 1992 Received: by cheltenham.cs.arizona.edu; Sat, 7 Nov 1992 16:17:48 MST Date: 4 Nov 92 01:10:54 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!mucs!m1!bevan@ucbvax.Berkeley.EDU (Stephen J Bevan) Organization: Department of Computer Science, University of Manchester Subject: readability of the algol68 report (was Re: confusing errors) 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 In article <1992Nov3.160646.21642@ips.cs.tu-bs.de> neitzel@ips.cs.tu-bs.de (Martin Neitzel) writes: > it [the Algol68 Revised Report] isn't exactly very readable Sorry, I just beg to differ. Of course, you should read a gentle introduction into two-level-grammars beforehand (Cleaveland/Uzgaliz excellent book on "Grammars for Programming Languages" comes to mind). I beg to differ with your differing. The method is certainly elegant, however I don't think it is particularly _readable_. The implicationsw of the aliasing that can occur are quite subtle and it takes a _lot_ of effort to follow them. To me, van Wijngaarden grammars are a minimalist approach to defining a language. A (probably bad) analogy would be using SKI combinators as your programming language, foundationally/theoretically very nice but a bugger to work with practically. Give me a denotational or operational definition any day; they also have the advantage that they are easier to turn into interpreters/compilers. bevan From icon-group-sender Wed Nov 4 15:00:12 1992 Received: by cheltenham.cs.arizona.edu; Sun, 8 Nov 1992 10:48:35 MST Date: 4 Nov 92 15:00:12 GMT From: mcsun!uknet!news.cs.bham.ac.uk!percy!aps@uunet.uu.net (Alan P Sexton) Organization: University of Birmingham Subject: Re: debugify, icon8.7 and __debug_proc Message-Id: <1992Nov4.150012@cs.bham.ac.uk> References: <1992Nov4.124332@cs.bham.ac.uk> 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 <1992Nov4.124332@cs.bham.ac.uk>, aps@cs.bham.ac.uk (Alan P Sexton) writes: |> |> Does anyone have a more sophisticated __debug_proc? (e.g. single stepping, |> nexting, source code display etc.)? Sorry, I didn't notice that the standard debug does singlestepping by default, and it took about 5 lines to add source code display - but I'm still interested if anyone has put some real effort into a new __debug_proc. Alan P. Sexton, Tel: 021-414 3703 University of Birmingham, School of Computer Science Edgbaston, Birmingham B15 2TT, England A.P.Sexton@cs.bham.ac.uk From icon-group-sender Mon Nov 9 15:02:35 1992 Received: by cheltenham.cs.arizona.edu; Mon, 9 Nov 1992 18:50:54 MST Date: Mon, 9 Nov 1992 15:02:35 MST From: "Kenneth Walker" Message-Id: <199211092202.AA25256@optima.cs.arizona.edu> To: icon-group Subject: Re: file scanning Status: R Errors-To: icon-group-errors@cs.arizona.edu > Date: 5 Nov 92 04:55:57 GMT > > Ken, Ralph, Clint, etc.: How hard would it really be to implement > file scanning? Kelvin Nilsen's Conicon has a stream data type the subsumes files and supports a type of scanning. His scanning doesn't have tab() and move() instead it has probe() and advance() which aslo replace read(). While you can backtrack during scanning, I think there are limitations on explicitly scanning backwards. He allows for infinite streams along the lines of Unix pipes. I know he does some careful buffering to make things work. For files that support seek(), it should be possible to do scanning with buffering as you suggested. It means that every file must be buffered within the Icon run-time system and all string analysis functions have to be changed to work on files and extend the buffer when needed. Note that seeking backwards in a file using translation mode on systems that have multi-character line termination (like MS-DOS) may be a little tricky. There is the question of where you put the buffer. Putting it in the string region makes some string handling operations easier; portions of the input are normal strings. However, it may be necessary to copy the buffer to the end of the region to extent it. How do you decide how much to copy? Suppose you backtrack past a point where you did a read-ahead to extend the buffer; you probably don't want to loose the read-ahead. How do you handle that? I haven't look closely at Kelvin's work in several years, so I don't recall how he does these things. But it doesn't sound trivial. Ken Walker kwalker@cs.arizona.edu uunet!arizona!kwalker From icon-group-sender Wed Nov 4 21:38:57 1992 Received: by cheltenham.cs.arizona.edu; Tue, 10 Nov 1992 04:51:12 MST Date: 4 Nov 92 21:38:57 GMT From: access.usask.ca!sue!hercules.cs.uregina.ca!skagos@decwrl.dec.com (P. Takis Skagos) Organization: University of Regina, SK, Canada Subject: Re: Character manipulation Message-Id: <1992Nov04.213857.23013@sue.cc.uregina.ca> References: <1992Nov2.031951.18774@midway.uchicago.edu>, <1992Nov03.172737.619209@sue.cc.uregina.ca>, <1992Nov4.020047.3235@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 <1992Nov4.020047.3235@midway.uchicago.edu> goer@midway.uchicago.edu writes: >skagos@hercules.cs.uregina.ca (P. Takis Skagos) writes: >>Well ... my character manipulation problems concerned parsing out >>lines and performing all sorts of substitutions and stuff (pre-processing >>a file). It is do-able with all the line scanning features of Icon, >>but it is a real drag. Oh well. > >Give us some examples! I cannot give examples ... part of this is for a class assignment ... and if I post the code I've written so far, others might copy it. UGH! Anyway, what the problem concerns is parsing a Pascal program and removing any white space that is not required (comments, spaces, tabs, etc.). Actually, the only place in Pascal that spaces are required ar around key-words (BEGIN, END, IF, WHILE, etc ...) and within quote-delimeters (ex: write('hi there') ). I've written the program in about 31 lines of Icon ... by reading a line in at a time and then using line indexing (ie: line[i:j]) to format it the way I want it. However, this involves having to constantly check previous and next characters in the line (around our current position in the line). I just think that there must be an easier way to do this. Anyway, to appease you code-freaks :-) I will post my code after the assignment is handed in ... the 12'th or something like that, but for now, I cannot post it .... Sorry. P. Takis Skagos (skagos@cs.uregina.ca) From icon-group-sender Fri Nov 6 20:43:38 1992 Received: by cheltenham.cs.arizona.edu; Tue, 10 Nov 1992 06:11:29 MST Date: 6 Nov 92 20:43:38 GMT From: agate!usenet.ins.cwru.edu!wariat!ppetto@ames.arc.nasa.gov (Peter J. Petto) Organization: Akademia Pana Kleksa, Public Access Uni* Site Subject: More Than LineAtATime Message-Id: <1992Nov6.204338.1332@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 Can anyone direct me to an example Icon routine that will assemble lines into a string (paragraph) that can be scanned for patterns that "straddle" the original lines -- and a complementary routine to break the paragraph string back up into lines of less than a specified margin value? While I'm asking, I might as well go for the high blue sky. How about a routine that will check hyphenated words against a list (dictionary) to see if the hyphens can be eliminated. (For use with the above.) I'd appreciate any advice I can get; I will summarize and post all that I receive. --- Peter Petto | ppetto@wariat.org Bay Village, Ohio | 73125.617@compuserve.com From icon-group-sender Wed Nov 4 23:18:02 1992 Received: by cheltenham.cs.arizona.edu; Tue, 10 Nov 1992 08:30:11 MST Date: 4 Nov 92 23:18:02 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!doc.ic.ac.uk!uknet!pavo.csi.cam.ac.uk!pipex!demon!ketlux.demon.co.uk!ketlux@ucbvax.Berkeley.EDU ("Geoffrey A. Stephenson") Organization: ket Subject: semicolons Message-Id: <720925064snx@ketlux.demon.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 To Nowlin I hope that's fanfold paper tape your talking about. Those were the days...{:> -- Geoff Stephenson at ketlux@ketlux.demon.co.uk fax to +352 318154 All thought draws life from contacts and exchanges. Fernand Braudel From icon-group-sender Mon Nov 9 15:24:23 1992 Received: by cheltenham.cs.arizona.edu; Tue, 10 Nov 1992 20:22:10 MST Date: 9 Nov 92 15:24:23 GMT From: csn!stortek!LSTC2VM.stortek.com!WILLS@handies.ucar.edu (Cheyenne Wills) Organization: StorageTek SW Engineering Subject: Re: More Than LineAtATime Message-Id: <1689A7640.WILLS@LSTC2VM.stortek.com> References: <1992Nov6.204338.1332@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 With all the talk of processing strings across line boundries and performing character scanning etc. I have an example that might address some of those. The following program was written to strip comments and blank lines from a C program. It handles the case where comments (or blank lines) might occur within quoted strings. Anyway... Enjoy ========================================================================= # # Removes all C comments and blank lines from a C file. # # cmd syntax: infile outfile # global outline global in,out,quotechar,process procedure main(args) # Build the input and output fileids fidi := args[1] fido := args[2] in := open(fidi,"r") | stop("Unable to open ",fidi," for input") out := open(fido,"w") | stop("Unable to open ",fido," for output") outline := "" # Start with an empty line process := standard # And "standard" input processing while line := trim(read(in)) do { # Read a line from input if *line == 0 then next # Throw away empty lines line ||:= "\n" # Add a newline (for later) line ? while not pos(0) do # Scan the line using current process() # process } flush() # Flush anything we have left close(in) # close files close(out) end # # "Standard" string filter. # # This procedure looks for quotes, and start of comments. # When it finds a quoted string, it sets the current process to inquote # When it finds a comment, it sets the current process to incomment # # Moves scanned data to output. # procedure standard() # Write all data upto a quote or start of a comment OR the end # of a line. If writing to the end of a line, return. outwrite( tab(upto('"\'/'))) | (outwrite(tab(0)) & return) # Found either the start of a comment or the start of a quote if ="/*" then # Check for start of a comment. process := incomment # Yep -- process is now in a comment. else if any('\'"') then { # Check for start of a quoted string quotechar := move(1) # Yep -- Get the quote delimiter process := inquote # Set processing for quoted strings outwrite(quotechar) # and dump quote char out. } else outwrite(move(1)) # False alarm -- just a "/" -- write it. return # And return end # # Process a quoted string. The string delimiter is in quotechar. # Will set process back to standard when the quotechar is found. # Handles C escaped characters # procedure inquote() # Write everything upto either the quote char or backslash # OR write to the end of the line and return. outwrite( tab(upto( quotechar ++ '\\')) ) | (outwrite(tab(0)) & return) # If we have an escaped character.. then just dump it and return outwrite(="\\") & outwrite(move(1)) & return outwrite( =quotechar ) # Write the quote char (hopefully) process := standard # set process back to standard. return # And return. end # # Process a comment. Just throw data away until we find the # comment end string. When end of comment is reached, set process # back to standard. # procedure incomment() tab(upto('*')) | # Skip upto either an asterisk OR (tab(0) & return) # skip the rest of the line and return. if ="*/" then process := standard # reset back to standard on EOC else move(1) # otherwise throw the "*" away return # And return end # # Put data to the output file. Will not write blank lines. # procedure outwrite(data) local xout,rest outline ||:= data # Append the data to the current buffer xout := "" rest := "" outline ? { # Scan the current buffer xout := tab(upto('\n')) & move(1) # Split on newlines rest := tab(0) } xout := trim(xout) # Trim trailing blanks if *xout > 0 then write(out,xout) # If not an empty string then write outline := rest # and set the output buffer to return # the remaining data and return. end # # Flush any remaining data from our output buffer. # procedure flush() local xout,rest xout := "" rest := "" while *outline > 0 do { # Keep processing as long as there is outline ? { # data left in the buffer. xout := tab(upto('\n')) & move(1) # Split on newlines rest := tab(0) } xout := trim(xout) # Trim trailing blanks if *xout > 0 then write(out,xout) # If not an empty string then outline := rest # Write it out. And continue with } # the rest of the data. return # Return when all done.. end ========================================================================= +---------------------------------------+-------------------------------+ | +-----+ | Cheyenne Wills | | | | "From here on up it is | Storage Technology Corporation| | | +--+--+ downhill all the way" | 2270 South 88th St. | | | | | | | Louisville, Co. 80028-4232 | | +--+--+ | | | | | | | Cheyenne_Wills@stortek.com | | +-----+ | cheyenne@witsend.stortek.com | +---------------------------------------+-------------------------------+ From icon-group-sender Mon Nov 9 08:14:04 1992 Received: by cheltenham.cs.arizona.edu; Wed, 11 Nov 1992 07:55:19 MST Date: 9 Nov 92 08:14:04 GMT From: munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!usage!syacus!ron@tcgould.tn.cornell.edu (Ron Williams) Organization: ACUS Australian Centre for Unisys Software, Sydney Subject: icon program examples Message-Id: <1992Nov9.081404.1640@syacus.acus.oz.au> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I recently acquired the icon executables, and source, but apart from the test suite, there appears to be little in the way of examples. I wonder if I simply missed seeing what is there? Could someone please direct me to any source written in icon that is freely available? I desperately need examples. thanks in advance... -- Ron Williams ACSnet : ron@syacus.acus.oz Ph : +61 2 390-1366 Internet : ron@syacus.acus.OZ.AU Fax: +61 2 390-1391 UUCP : uunet!munnari!syacus.acus.oz.au!ron Standard Disclaimers Apply From icon-group-sender Fri Nov 6 04:40:10 1992 Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 05:29:17 MST Date: 6 Nov 92 04:40:10 GMT From: srt@arizona.edu (Scott R. Trappe) Subject: Rationale for sortf() second argument? Message-Id: <25952@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 The sortf() function in Icon V8.7 is defined as: sortf(X,i) Produces a sorted list of the elements of X. The results are similar to those of sort(X,i), except that among lists and among records, structure values are ordered by comparing their ith fields. Can someone explain to me why the second argument to the sortf() function is an integer index of the field in the record to sort on, instead of a string containing the field name? As defined, this function seems to be very dangerous, since adding, deleting, or re-ordering fields in a record could change which field is used as the key. The programmer must manually inspect each use of sortf() and verify that either it is not being used on data structures containing the affected record type, or that the field index is unaffected by the change. It would seem that specifying the field name as a string is far safer; it makes it obvious which field is used as the key, makes the program insensitive to adding or re-ordering fields in the record, and should the field be deleted, could result in a run-time error. It would seem to also improve program readability, since in the typical case the field name would be a literal string in the sortf() function. As it stands now, one has to go find the record declaration and count the fields to find out which field is the key. This is even more problematical if one is using an Icon pre-processor such as Idol that adds extra fields to the BEGINNING of the record: without knowledge of the transformations that the preprocessor makes, it is impossible to use the sortf() function. Worse, changes to the pre-processor could silently break "correct" code. There seems to me to be precedent in Icon for supplying language identifiers in strings; witness the proc() and args() functions. Indeed, in the very same report where the sortf() function is described, there is a description of a new feature whereby field selection can be done with a string operand, for example: record.["field1"] can be used to mean: record.field1 Scott Trappe From icon-group-sender Thu Nov 12 09:58:55 1992 Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 10:22:42 MST Date: Thu, 12 Nov 1992 09:58:55 MST From: "Gregg Townsend" Message-Id: <199211121658.AA02526@owl.cs.arizona.edu> To: icon-group@cs.arizona.edu, srt@arizona.edu Subject: Re: Rationale for sortf() second argument? Status: R Errors-To: icon-group-errors@cs.arizona.edu From icon-group-sender Thu Nov 12 05:29:31 1992 Can someone explain to me why the second argument to the sortf() function is an integer index of the field in the record to sort on, instead of a string containing the field name? Not really. The awful truth is that I didn't even think of that when I wrote and contributed the implementation of sortf(). Your points are well taken. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Tue Nov 10 13:31:18 1992 Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 16:09:21 MST Date: 10 Nov 92 13:31:18 GMT From: destroyer!news.iastate.edu!kelvin@gumby.wisc.edu (Kelvin Don Nilsen) Organization: Iowa State University, Ames IA Subject: Re: file scanning Message-Id: References: <199211092202.AA25256@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 In <199211092202.AA25256@optima.cs.arizona.edu> "Kenneth Walker" writes: >Kelvin Nilsen's Conicon has a stream data type the subsumes files and >supports a type of scanning. His scanning doesn't have tab() and move() >instead it has probe() and advance() which aslo replace read(). While >you can backtrack during scanning, I think there are limitations on >explicitly scanning backwards. He allows for infinite streams along the >lines of Unix pipes. I know he does some careful buffering to make >things work. patterns that require backtracking keep a pointer to the backtracking point in the suspended scanning expression's activation frame. this prevents the garbage collector from reclaiming that part of the stream that might need to be revisited. once control leaves the bounded expression that holds the suspended scanning expression, the backtrack point no longer exist, and the garbage collector is free to reclaim that part of the stream that is known never to be visited again. >For files that support seek(), it should be possible to do scanning >with buffering as you suggested. It means that every file must be >buffered within the Icon run-time system and all string analysis >functions have to be changed to work on files and extend the buffer >when needed. Note that seeking backwards in a file using translation >mode on systems that have multi-character line termination (like >MS-DOS) may be a little tricky. i avoided backward seeks by placing restrictions on the legal argument values for advance() and probe(). in particular, it was not legal to specify negative indices. >There is the question of where you put the buffer. Putting it in the >string region makes some string handling operations easier; portions >of the input are normal strings. However, it may be necessary to copy >the buffer to the end of the region to extent it. How do you decide how >much to copy? Suppose you backtrack past a point where you did a read-ahead >to extend the buffer; you probably don't want to loose the read-ahead. >How do you handle that? I haven't look closely at Kelvin's work in >several years, so I don't recall how he does these things. But it doesn't >sound trivial. in my work, i was experimenting with language design as well as implementation techniques. i did not use icon's traditional garbage collector. the closest Icon analog to the data structures i used is a list of strings. in the event that your pattern spans the boundary between two list elements, the underlying implementation replaces one of the two neighboring elements with the catenation of the two and removes the second list element. in theory, this could be done entirely within Icon, but you would need to implement all of Icon's built-in scanning functions from scratch. it would likely run much slower than traditional scanning, but perhaps you are willing to tolerate the performance problems in return for the increased expressive power. Kelvin Nilsen/Dept. of Computer Science/Iowa State University/Ames, IA 50011 (515) 294-2259 kelvin@cs.iastate.edu uunet!kelvin@cs.iastate.edu -- Kelvin Nilsen/Dept. of Computer Science/Iowa State University/Ames, IA 50011 (515) 294-2259 kelvin@cs.iastate.edu uunet!kelvin@cs.iastate.edu From icon-group-sender Thu Nov 12 18:36:19 1992 Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 19:43:36 MST Date: Thu, 12 Nov 92 18:36:19 -0500 From: isidev!nowlin@uunet.uu.net Message-Id: <9211122336.AA23580@relay2.UU.NET> To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET Subject: Re rationale for sortf() Status: R Errors-To: icon-group-errors@cs.arizona.edu > The sortf() function in Icon V8.7 is defined as: > > sortf(X,i) Produces a sorted list of the elements of X. The > results are similar to those of sort(X,i), > except that among lists and among records, > structure values are ordered by comparing their > ith fields. > > Can someone explain to me why the second argument to the sortf() function is > an integer index of the field in the record to sort on, instead of a string > containing the field name? The sortf() function works on lists in addition to records. It remains flexible enough to do both by using an integer index. If you specified field names with a string you would lose the ability to sort lists of lists. I suppose you could overload the second argument so that integers worked for both types of structures but a string in the context of a list would generate a run-time error. Not worth it. You can define tables with field names as key and the record index as value and just use that in place of field name arguments to sortf(). When you change record definitions you would have to change tables values. This won't help with Idol unfortunately. Maybe Idol could put extra fields at the end of records to avoid obscuring known index values? Jerry Nowlin From icon-group-sender Tue Nov 10 16:10:57 1992 Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 05:28:47 MST Date: 10 Nov 92 16:10:57 GMT From: agate!spool.mu.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: file scanning Message-Id: <1992Nov10.161057.8331@midway.uchicago.edu> References: <199211092202.AA25256@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 Several folks questioned whether what I really wanted was file scanning. The answer is "yes." Icon is good for text and language processing, but to do this everything has to go through a tokenizing stage. Icon's string scanning mechanism relies heavily on strings as chunks taken from files, broken up by newlines. Sadly, we typically can't break up a file when tokenizing. We have to treat it as a stream of characters. If that stream could be scanned, then Icon would be quite useful for all stages of text and natural langauge processing. Right now, it's okay, but you have to do one of two things: a) use it like a poor man's C, or b) try to con- struct input so that it can be snipped off at each newline for the purposes of tokenizing. Ironically, Icon itself cannot be tokenized in this way. Incidentally, I'm not the first to suggest that scanning be generalized to files. I recall reading this suggestion in an old Arizona tech report. The real crux with file scanning, it would seem, is what to do when the file in question doesn't support backwards seeks. Also, how in Icon could the stream be buffered in such a way as to store backtracking points? Actually, I'd tend to say, "Don't buffer anything other than a few chars." After all, when tokenizing, normally nobody uses more than a few characters of pushback, and we normally use only one lookahead character. If people want to seek back and forth through large files, then let them. For things like pipes and other non-backwards-seekable objects, I would not care par- ticularly if there were simply an error message. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Nov 10 16:10:57 1992 Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 05:29:20 MST Date: 10 Nov 92 16:10:57 GMT From: agate!spool.mu.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: file scanning Message-Id: <1992Nov10.161057.8331@midway.uchicago.edu> References: <199211092202.AA25256@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 Several folks questioned whether what I really wanted was file scanning. The answer is "yes." Icon is good for text and language processing, but to do this everything has to go through a tokenizing stage. Icon's string scanning mechanism relies heavily on strings as chunks taken from files, broken up by newlines. Sadly, we typically can't break up a file when tokenizing. We have to treat it as a stream of characters. If that stream could be scanned, then Icon would be quite useful for all stages of text and natural langauge processing. Right now, it's okay, but you have to do one of two things: a) use it like a poor man's C, or b) try to con- struct input so that it can be snipped off at each newline for the purposes of tokenizing. Ironically, Icon itself cannot be tokenized in this way. Incidentally, I'm not the first to suggest that scanning be generalized to files. I recall reading this suggestion in an old Arizona tech report. The real crux with file scanning, it would seem, is what to do when the file in question doesn't support backwards seeks. Also, how in Icon could the stream be buffered in such a way as to store backtracking points? Actually, I'd tend to say, "Don't buffer anything other than a few chars." After all, when tokenizing, normally nobody uses more than a few characters of pushback, and we normally use only one lookahead character. If people want to seek back and forth through large files, then let them. For things like pipes and other non-backwards-seekable objects, I would not care par- ticularly if there were simply an error message. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Nov 12 22:19:21 1992 Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 05:29:29 MST Date: Thu, 12 Nov 1992 22:19:21 MST From: "President Clinton Jeffery" Message-Id: <199211130519.AA22161@chuckwalla.cs.arizona.edu> To: isidev!nowlin@uunet.uu.net Cc: icon-group In-Reply-To: isidev!nowlin@uunet.uu.net's message of Thu, 12 Nov 92 18:36:19 -0500 <9211122336.AA23580@relay2.UU.NET> Subject: Re rationale for sortf() Status: R Errors-To: icon-group-errors@cs.arizona.edu Jerry Nowlin writes: > You can define tables with field names as key and the record index as value > and just use that in place of field name arguments to sortf(). When you > change record definitions you would have to change tables values. This > won't help with Idol unfortunately. Maybe Idol could put extra fields at > the end of records to avoid obscuring known index values? An interesting thought. There is no reason the two "extra fields" could not be put at the back. But current default behavior notwithstanding, objects are not supposed to be transparent and allow any old function to access their internal fields; a sortf() that would be technically correct for Idol would call a procedure (method, really) to access the key, and there are real technical reasons why sortf() doesn't call back out to an Icon procedure (or Idol method) in the present implementation -- none of Icon's built-in functions do that, in fact. Writing a built-in Icon function that calls procedures is our user-grailquest for the week; in the meantime sorters of lists of objects would do well to consider adapting Bob Alexander's elegant isort procedure from the Icon program library. From icon-group-sender Fri Nov 13 04:01:17 1992 Date: Fri, 13 Nov 1992 04:01:17 MST Message-Id: <199211131230.AA28219@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 05:30:23 MST From: Subject: CFP: Conf. on Prog. Languages and System Architectures Status: R Errors-To: icon-group-errors@cs.arizona.edu Apparently-To: icon-group-addresses Dear Sir/ Madam please help us advertising our "Conference on Programming Languages and System Architectures with a special session in honor of Niklaus Wirth on his 60th birthday" by publicizing the following text. Thank you very much for your help and best regards! Prof. J. Gutknecht ETH Zentrum CH-8092 Zurich gutknecht@inf.ethz.ch ======================================= Call for Papers Conference on Programming Languages and System Architectures with a special session in honor of Niklaus Wirth on his 60th birthday 2th - 4th March, 1994 ETH Zurich, Switzerland The conference will provide an international forum for the presentation and discussion of recent research in the areas of programming languages and system architectures. Authors are invited to submit papers describing original research related to these areas. Particularly encouraged are contributions discussing their mutual influence. Also, unrefereed contributions of 5-20 min. duration, and of a technical and/or personal nature are solicited for an afternoon session honoring N. Wirth. Subjects of special interest include, but are not restricted to: Programming language design and history, Programming environments, Programming methods, Operating systems, Compiler construction, Innovative system architectures Send two copies of technical contributions to the program chair. Submissions should not exceed 15 pages and must not have been published or submitted for publication elsewhere. Where possible, include the e-mail address and fax number of the contact author. Potential contributors to the special session in honor of Niklaus Wirth should contact the program chair for more information. Proceedings will be published by Springer Verlag in the Lecture Notes in Computer Science series and will be distributed at the conference. Program Committee J. Gutknecht (Chair) ETH Zentrum CH-8092 Zurich, Switzerland e-mail: gutknecht@inf.ethz.ch e-fax: (+41 1) 251 96 78 R. P. Cook, Microsoft, Redmond, WA G. Coray, EPF Lausanne, CH O. J. Dahl, University of Oslo, N E. W. Dijkstra, Univ. of Texas, Austin, TX G. Goos, Techn. Univ, Karlsruhe, D S. Graham, Univ. of California, Berkeley, CA D. Gries, Cornell University, Ithaca, NY D. Hanson, Princeton Univ, Princeton, NJ B. Kernighan, AT&T Bell Labs, Murray Hill, NJ B. W. Lampson, DEC CRL, Cambridge, MA J. Ludewig, Techn. Univ., Stuttgart, D J. Misra, Univ. of Texas, Austin, TX H. Moessenboeck, ETH Zurich, CH R. Needham, Cambridge University, GB S. Owicki, DEC SRC, Palo Alto, CA G. Pomberger, Universitaet Linz, A P. Rechenberg, Universitaet Linz, A M. Reiser, IBM Research, Zuerich, CH B. Sanders, ETH Zurich, CH P. Schulthess, Universitaet Ulm, D A. Shaw, Univ. of Washington, Seattle, WA P. D. Terry, Rhodes University, Grahamstown, SA L. Tesler, Apple Corp, Cupertino, CA J. Welsh, Univ. of Queensland, Brisbane, AU N. Wirth, ETH Zurich, CH Key Dates Deadline for receipt of submissions: 1st August, 1993 Acceptance notification: 1st November, 1993 Deadline for camera-ready final papers: 15th December, 1993 From icon-group-sender Fri Nov 13 12:27:32 1992 Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 11:31:46 MST Date: Fri, 13 Nov 92 12:27:32 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <527005@MTS.cc.Wayne.edu> Subject: Second argument to sortf Status: R Errors-To: icon-group-errors@cs.arizona.edu Greg Townsend has told us that he just didn't think of the possibility of using a field name as the second argument to sortf when he built it. Given that it's too late to redo the design, what's the best way to provide this obviously useful functionality? (1) Perhaps the implementation could be modified, as Jerry Nowlin suggested, to overload the second argument so that a field name would be interpreted as the key field. (2) But an even neater approach, which wouldn't require modifying sortf at all, would be an Icon function fieldpos(rectype, fld) that would take a record type and field name as inputs and would yield the field position as output. Such a function would probably have other uses as well. Paul Abrahams From icon-group-sender Sun Nov 15 10:49:26 1992 Received: by cheltenham.cs.arizona.edu; Mon, 16 Nov 1992 05:25:18 MST Date: Sun, 15 Nov 92 10:49:26 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <527502@MTS.cc.Wayne.edu> Subject: Second thoughts on semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu For a long time I've liked the Icon convention that the end of a line acts as a semicolon unless the last token on the line is an operator. There's no doubt that it makes programs easier to write. But I am having some second thoughts about this convention, because I think it hinders making programs easier to read. I don't think semicolons at the ends of lines affect readability one way or the other, but that by itself doesn't argue against the Icon convention. But the Icon convention does preclude breaking an expression before rather than after an operator, and therefore precludes the program style, which corresponds to the mathematical conventions, where continuation lines start with an operator. The Icon conventions are too heavily embedded in existing code for me to suggest that they should be changed. But the downside of the Icon convention is something that language designers should ponder. Paul Abrahams From icon-group-sender Mon Nov 16 08:26:47 1992 Received: by cheltenham.cs.arizona.edu; Mon, 16 Nov 1992 15:21:06 MST Date: 16 Nov 1992 08:26:47 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: semicolons revisited? To: icon-group@cs.arizona.edu Message-Id: <01GR7NMCR9G291WHNT@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 case any one really really likes semicolons on a string processing language DEC now offers TPU (text processing utility) for its VAX and RISC boxes. Asoft offers nu/TPU for other platforms. TPU has a lot of icon and snobol string concepts yet it enforces semicolons at the end of the statements. But like pascal it also uses begin and end instead of curly braces for blocking. No generators, no fail/succeess handling. But it has an interesting property. All variables declared have scope local to their procedures. All variables created by operations (not predeclared) have global scope. This language is the foundation of an editor called EVE. It allows one to do string programming in a full screen editor environment. I've used it to customize my editor to do herculean feats. I still prefer icon for stream crunching, front ending, and game design. The lack of semicolons, required declarations, and datatypes are the features that drew me to icon, and that improve my productivity. 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 Fri Nov 13 02:28:31 1992 Received: by cheltenham.cs.arizona.edu; Tue, 17 Nov 1992 05:49:07 MST Date: 13 Nov 92 02:28:31 GMT From: sun-barr!cs.utexas.edu!uwm.edu!linac!uchinews!ellis!goer@ames.arc.nasa.gov (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Rationale for sortf() second argument? Message-Id: <1992Nov13.022831.26740@midway.uchicago.edu> References: <199211121658.AA02526@owl.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 "Gregg Townsend" writes: > > Can someone explain to me why the second argument to the sortf() function > is an integer index of the field in the record to sort on, instead of a > string containing the field name? > >Not really. The awful truth is that I didn't even think of that when I wrote >and contributed the implementation of sortf(). Your points are well taken. Don't sell yourself short, Gregg. Integer offsets are much more general than field names. They can be applied to lists as well as records. I'm quite happy, myself, with how things worked out, although it's clear that there are many possibilities for me to screw things up. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Nov 16 14:26:47 1992 Received: by cheltenham.cs.arizona.edu; Tue, 17 Nov 1992 05:49:31 MST Date: 16 Nov 92 14:26:47 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: semicolons revisited? Message-Id: <01GR7NMCR9G291WHNT@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 In case any one really really likes semicolons on a string processing language DEC now offers TPU (text processing utility) for its VAX and RISC boxes. Asoft offers nu/TPU for other platforms. TPU has a lot of icon and snobol string concepts yet it enforces semicolons at the end of the statements. But like pascal it also uses begin and end instead of curly braces for blocking. No generators, no fail/succeess handling. But it has an interesting property. All variables declared have scope local to their procedures. All variables created by operations (not predeclared) have global scope. This language is the foundation of an editor called EVE. It allows one to do string programming in a full screen editor environment. I've used it to customize my editor to do herculean feats. I still prefer icon for stream crunching, front ending, and game design. The lack of semicolons, required declarations, and datatypes are the features that drew me to icon, and that improve my productivity. 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 Nov 17 10:50:06 1992 Received: by cheltenham.cs.arizona.edu; Tue, 17 Nov 1992 11:34:31 MST Date: Tue, 17 Nov 92 10:50:06 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <528466@MTS.cc.Wayne.edu> Subject: Field names of a record type Status: R Errors-To: icon-group-errors@cs.arizona.edu I recently proposed a builtin Icon function that would convert field names to their corresponding positions, as a way of constructing the desired second argument to sortf. That led me to the following question: does such a function need to be built in? Surprisingly, it seems so. Putting it another way: given the name of an Icon record type, is there a straightforward way to list the names of its fields in the same order as they appear in its definition? So far I haven't found one. Paul Abrahams From icon-group-sender Tue Nov 17 13:25:11 1992 Received: by cheltenham.cs.arizona.edu; Tue, 17 Nov 1992 14:42:10 MST Date: Tue, 17 Nov 1992 13:25:11 MST From: "Clint Jeffery" Message-Id: <199211172025.AA26141@chuckwalla.cs.arizona.edu> To: Paul_Abrahams@MTS.cc.Wayne.edu Cc: icon-group@cs.arizona.edu In-Reply-To: Paul_Abrahams@MTS.cc.Wayne.edu's message of Tue, 17 Nov 92 10:50:06 EST <528466@MTS.cc.Wayne.edu> Subject: Field names of a record type Status: R Errors-To: icon-group-errors@cs.arizona.edu Paul Abrahams writes: given the name of an Icon record type, is there a straightforward way to list the names of its fields in the same order as they appear in its definition? So far I haven't found one. While you are waiting for that built-in function, the following program demonstrates a technique that does what you ask. Normally I wouldn't start from a *name* of a record type, but that's how you stated the problem. Folks who don't believe in semi-colon insertion, let me know if you have trouble reading this. record r (alpha, beta, c) procedure main() every write(fieldnames("r")) end procedure fieldnames(r) R := r() every i := 1 to *R do { s := name(R[i]) suspend s[find(".",s)+1:0] } end From icon-group-sender Wed Nov 18 14:40:44 1992 Received: by cheltenham.cs.arizona.edu; Wed, 18 Nov 1992 14:10:13 MST Date: Wed, 18 Nov 92 14:40:44 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <529141@MTS.cc.Wayne.edu> Subject: Second argument to softf Status: R Errors-To: icon-group-errors@cs.arizona.edu Thanks to Clint Jeffery for providing the missing link needed to specify the second argument of sortf as a field name. Applying the "name" function to a record object of record type R, you can determine the field occupying the i'th position of the record. Inverting this procedure, you can determine the position (as an integer) of a field name. Once you've done that, you have the second argument to sortf that you need. Clint commented: << Folks who don't believe in semi-colon insertion, let me know if you have trouble reading this. >> Yes, but a program (Icon or otherwise) with semicolons is also easy to read. The semicolons don't interfere, at least for me. I certainly agree that a program is easier to *write* without semicolons. However, as I said in an earlier post, the Icon treatment of newlines precludes certain convenient conventions for line continuations. Paul Abrahams From icon-group-sender Wed Nov 18 14:10:06 1992 Received: by cheltenham.cs.arizona.edu; Wed, 18 Nov 1992 14:10:30 MST Date: Wed, 18 Nov 1992 14:10:06 MST From: "Ralph Griswold" Message-Id: <199211182110.AA11937@cheltenham.cs.arizona.edu> To: Paul_Abrahams@MTS.cc.Wayne.edu, icon-group@cs.arizona.edu Subject: Re: Second argument to softf Status: R Errors-To: icon-group-errors@cs.arizona.edu With semicolons, programmers tend to string a bunch of statements together on one long line. This often makes programs harder to read than if they were written one statement per line with a more vertical layout. On more than one occassion, I've reformatted programs for publication by breaking up long multi-statement lines into single lines. For me, at least, using lines to separate statements not only makes programs easier to write; it makes them easier to read. For Icon, read "expressions" for "statements". The point is the same. 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 Nov 18 22:16:48 1992 Received: by cheltenham.cs.arizona.edu; Thu, 19 Nov 1992 05:57:05 MST Date: Wed, 18 Nov 92 22:16:48 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <529434@MTS.cc.Wayne.edu> Subject: Readability of semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu Ralph Griswold commented: << With semicolons, programmers tend to string a bunch of statements together on one long line. This often makes programs harder to read than if they were written one statement per line with a more vertical layout. >> Yes, but you can also string a bunch of statements together on one line in Icon, or write statements one per line in some other language. So the Icon convention seems to me at least to be neutral with respect to this aspect of readability. Paul Abrahams From icon-group-sender Thu Nov 19 06:00:42 1992 Received: by cheltenham.cs.arizona.edu; Thu, 19 Nov 1992 07:49:09 MST Date: Thu, 19 Nov 1992 06:00:42 MST From: "Ralph Griswold" Message-Id: <199211191300.AA18993@cheltenham.cs.arizona.edu> To: Paul_Abrahams@MTS.cc.Wayne.edu, icon-group@cs.arizona.edu Subject: Re: Readability of semicolons Status: R Errors-To: icon-group-errors@cs.arizona.edu Yes, of course you *can* string things together on one line in Icon. But the use of lines rather than semicolons to separate expressions encourages a more readable style. Rick Fonorow once noted that it's never necessary to have any semicolons in an Icon program (except in literals). If you use that as a style guide, you tend to get more readable programs. From icon-group-sender Fri Nov 20 12:48:54 1992 Received: by cheltenham.cs.arizona.edu; Fri, 20 Nov 1992 11:12:02 MST Date: Fri, 20 Nov 92 12:48:54 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <530200@MTS.cc.Wayne.edu> Subject: Scanning a list of items Status: R Errors-To: icon-group-errors@cs.arizona.edu The Icon Analyst #15 describes several versions of code to scan and process a list of items. The list has the form of a string with markers between items but without a marker after the last item. An unattractive solution is text ||:= marker text ? { while process(tab(find(marker))) do =marker } A better solution suggested by the Analyst is text ? { while process(tab(find(marker)|0)) do =marker | break } But here's another alternative, which is what I've usually done: (text || marker) ? { while process(tab(find(marker))) do =marker } As to which of the alternatives is better, de gustibus non est disputandum. Paul Abrahams From icon-group-sender Fri Nov 20 12:49:16 1992 Received: by cheltenham.cs.arizona.edu; Fri, 20 Nov 1992 11:12:08 MST Date: Fri, 20 Nov 92 12:49:16 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <530202@MTS.cc.Wayne.edu> Subject: Icon templates for MultiEdit? Status: R Errors-To: icon-group-errors@cs.arizona.edu I wonder if anyone has created Icon templates for MultiEdit, a popular program editor for the PC. (American Cybernetics, which markets MultiEdit, is located in Tempe, just up the road from the Icon Project.) Paul Abrahams From icon-group-sender Wed Nov 25 08:48:11 1992 Received: by cheltenham.cs.arizona.edu; Wed, 25 Nov 1992 12:28:48 MST Date: 25 Nov 1992 08:48:11 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: HOLIDAY GAME OFFERING To: icon-group@cs.arizona.edu Message-Id: <01GRK95P6NRM8WWAXD@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 I keeping with my self proclaimed tradition of offering icon games on the holidays here's a little something. It's a horse race game. I've run it on VAX/VMS (icon 8.7), UNIX (icon 8.7), and MS-DOS (icon 8.5). It uses ansi sequences for screen management, so I expect to get flamed there. In fact if run on a PC, ansi.sys should be loaded through config.sys. It's not intended to be production quality, but rather as a sample of icon programming. I am trying to improve commenting to make it easier for others to figure out. Perhaps some of the adventurous may want to improve it. I think it's fun. Enjoy! | Ce que vous voyes est ce que vous obtenez. 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 # # FILE : HR.ICN # DESC : HORSE RACE GAME WRITTEN IN ICON # DATA : HORSES : LINE1 = HORSE NAME # LINE2 = ODDS # LINE3.= ASCII PICTURE # # UPDATE BY WHAT # 07-NOV-1992 TENAGLIA INITIAL WRITE # 08-NOV-1992 TENAGLIA PERFECTED THE ARITHMETIC # 13-NOV-1992 TENAGLIA SOME FINISHING TOUCHES # 15-NOV-1992 TENAGLIA THROW IN POTENTIAL ACCIDENTS # global horse1, horse2, horse3, # horses are global players, money, bets, # player info is global vectors, leg1, leg2, leg3, # track parameters front, back, y1 , y2, y3, # horse parameters pos1, pos2, pos3, # more horse parameters oops1, oops2, oops3 # accident flags ###################################################################### procedure main() banner() if ready() == "no" then stop("Game Over.") # ask if ready players := get_players() # get player name list money := table(100) # everyone starts w/$100 &random := map(&clock,":","0") # randomize repeat { if ready() == "no" then break writes("\e[2J\e[H") # clear old junk off screen repeat # CHOOSE 3 FRESH HORSES { horse1 := get_horse() # get first horse list horse2 := get_horse() # get second horse list horse3 := get_horse() # get third horse list if horse1[1] == horse2[1] | # disallow duplicates horse2[1] == horse3[1] | # because a horse can't horse3[1] == horse1[1] then next # race against himself break # continue... } bets := get_bet() # bets initially 0 winner := race() # race the horses, get winner pay(winner) # pay winner(s) if any } done() end # # # ask if ready to play the game, return yes or no # procedure ready() static pass,sh initial { pass := 0 # initialize pass counter sh := "\e[1;7m \e[0;1;33;44m" # initialize a shadow for box } if (pass +:= 1) = 1 then { writes("\e[0;1;33;44m\e[2J\e[H") write(" +----------------------------------------------------------+") write(" | WELCOME TO ICON PARK VIRTUAL RACE TRACK |",sh) write(" | |",sh) write(" | The following game allow one or more players to bet on |",sh) write(" | three Cyberspace steeds that will run on an ANSI VT100 |",sh) write(" | dirt track. Of course the bets are Cyberspace dollars, |",sh) write(" | which have no real world value. We use only the oldest |",sh) write(" | escape sequences to condition the track surface, which |",sh) write(" | may not appeal to TEK crowds, and I'm sure some fans |",sh) write(" | will hurl curses. C'est la vie! |",sh) write(" | |",sh) write(" +----------------------------------------------------------+",sh) write(" \e[1;7m \e[0;1;33;44m") write("") write(" Are we ready to enter our names, and begin?") answer := map(input("Enter yes or no:")) if answer[1] == "n" then return "no" else return "yes" } end # # get the names of the players # procedure get_players() people := [] counter := 1 write("\nEnter Player Names. Enter blank when done.") repeat { (who := input(" Player #" || counter || ":")) | break if trim(who) == "" then break put(people,who) counter +:= 1 } if *people < 1 then stop("Not enough players. Need at least one.") return people end # # # build a horse list structure # procedure get_horse() static stable,photos initial { photos := [pick1(),pick2(),pick3(), pick4(),pick5(),pick6()] stable := ["Incredible Hash", "Random Number", "Floppy Crash", "RAM Dump", "Programmers Nightmare", "Spaghetti Code", "Infinite Loop", "User Blues", "See Plus Plus", "Press Any Key", "Paradigm Shift", "Adricks' Abend", "Client Server", "Network Storm", "Mr. Cobol", "Forgotten Password", "Hackers' Byte", "Chad Hollerith", "ASCII Question", "EBCDIC Object", "Recursive Instance", "RunTime Error"] } name := ?stable # pick a horse name odds := 1 + real((?30)/real(10.0)) # calculate the odds tmp := ?photos # choose a photo file pic := [name,odds] every put(pic,!tmp) return pic end # # # obtain bets from the players # procedure get_bet() (&features == "MS-DOS") | writes("\e[?25h") bets := table(0) summation := 0 every person := !players do { if money[person] <= 0 then next summation +:= money[person] write("\e[2J\e[H",person,", enter your bet. You have $",money[person],"\n") write("1. ",left(horse1[1],32)," odds = ",horse1[2]," : 1") write("2. ",left(horse2[1],32)," \" = ",horse2[2]," : 1") write("3. ",left(horse3[1],32)," \" = ",horse3[2]," : 1") write("\n (enter 5 on 2 for $5 on ",horse2[1],")\n") wager := trim(map(input("Your decision : "))) if wager == "" then next if wager == "q" then done() items := parse(wager,' ') if not(numeric(items[1])) | not(numeric(items[3])) then { input("\7Wager Improperly Entered. No wager made. Press RETURN") next } if (*items ~= 3) | (items[2] ~== "on") | (items[1] > money[person]) | (1 > items[3] > 3) then { input("\7Wager Improperly Entered. No wager made. Press RETURN") next } bets[person] := wager money[person] -:= parse(wager,' ')[1] } if summation = 0 then { write("\e[2J\e[HICON PARK CYBER RACE TRACK BIDS YOU ADIEU\n") write("It looks you'all lost all your money here today.") write("Take it easy now. Better luck next time") stop("Game Over") } input("Done Entering Wagers. Press RETURN to Continue.") end # # # determine the victor and pay out winnings. if there is a tie # then nothing gets payed out (bets are refunded) # procedure pay(victor) (&features == "MS-DOS") | writes("\e[?25h") # turn on cursor again winner := case victor of { 1 : horse1 2 : horse2 3 : horse3 default : ["tie"] } if victor = 4 then { writes(at(12,14),"All The Steeds Fell Down! Too many injuries!\7") wait(1) writes(at(12,14),"The judges are coming to a decision....") wait(2) writes(at(12,14),"All bets will be refunded. Sorry.......") check := sort(bets,1) every pair := !check do { name := pair[1] wager := pair[2] odds := winner[2] prize := parse(bets[name],' ')[1] money[name] +:= integer(prize) } test := map(input(at(13,1) || "Press RETURN to Continue.")) if test[1] == "q" then done() return } if winner[1] == "tie" then { writes(at(12,14),"It was a photo finish!\7") wait(1) writes(at(12,14),"The judges are coming to a decision....") wait(2) writes(at(12,14),"All bets will be refunded. Sorry.......") check := sort(bets,1) every pair := !check do { name := pair[1] wager := pair[2] odds := winner[2] prize := parse(bets[name],' ')[1] money[name] +:= integer(prize) } test := map(input(at(13,1) || "Press RETURN to Continue.")) if test[1] == "q" then done() return } else { writes(at(12,14),winner[1]," WINS! ") writes(at(victor+21,1),"\e[1;5;33;44m",victor," : ",left(winner[1],32),"\e[0;1;33;44m") wait(2) writes(at(12,14),"And now for a closeup of the winner....") wait(3) y := 4 writes(at((y+:=1),40),"+",repl("-",35),"+") every i := 3 to *winner do writes(at((y+:=1),40),"|",left(winner[i],35),"|") writes(at(y,40),"+",repl("-",35),"+") } check := sort(bets,1) every pair := !check do { name := pair[1] wager := pair[2] nag := parse(wager,' ')[3] if nag = victor then { odds := winner[2] prize := odds * parse(bets[name],' ')[1] money[name] +:= integer(prize) } } test := map(input(at(13,1) || "Press RETURN to Continue.")) if test[1] == "q" then { # # evaluate results from todays races # write("\e[2J\e[HICON PARK CYBER RACE TRACK BIDS YOU ADIEU\n") write(" We all started with $100. And now for the results...\n") every player := !players do { winnings := money[player] if winnings < 100 then msg := "Looks like you lost some $ today." if winnings = 0 then msg := "Lost all your money today." if winnings = 100 then msg := "Looks like you broke even today." if winnings > 100 then msg := "Looks like a winner. Stop at the IRS window please!" if winnings > 300 then msg := "Wow! The IRS agent will escort you to his office." write("OK ",player,", you have $",winnings," left. ",msg) } } end # # # run the race and return the winning horse # (1, 2, or 3) # procedure race() vectors := draw_track() # # set up starting positions # pos1 := 1 pos2 := 1 pos3 := 1 # # select lanes to run in # y1 := 5 y2 := 7 y3 := 9 # # set up for the legs of the race, 3 normal + 3 accidentsal # leg1 := 1 leg2 := 1 leg3 := 1 # # set up accident multipliers # oops1 := 1 oops2 := 1 oops3 := 1 # # designate vector milestones, marking legs of the race # diamx := 68 diamy := 10 finish := 146 # # design horse bodies from different vantage points # front := list(6) front[1] := "#^" front[2] := "V" front[3] := "#' " front[4] := "_X " front[5] := "X" front[6] := "_X " back := list(6) back[1] := " `#" back[2] := "/" back[3] := "^#" back[4] := " X_" back[5] := "X" back[6] := " X_" # # display the starting positions and fire the gun to begin! # (&features == "MS-DOS") | writes("\e[?25l") # deactivate cursor writes(at(5,1),back[1],1,front[1]) # horse 1 writes(at(22,6),left(horse1[1],32)," / ",horse1[2]," : 1 / ") writes(at(7,1),back[1],2,front[1]) # horse 2 writes(at(23,6),left(horse2[1],32)," / ",horse2[2]," : 1 / ") writes(at(9,1),back[1],3,front[1]) # horse 3 writes(at(24,6),left(horse3[1],32)," / ",horse3[2]," : 1 / ") writes(at(12,14),"ON YOUR MARK... GET SET...") wait(1) writes("\7",at(12,14),"AND THEY'RE OFF! ") # # run the race # repeat { case &features of { "VMS" : delay(500) # delay 10,000/sec VMS "UNIX": delay(50) # delay 1,000/sec UNIX default : platform := &features # not on DOS icon 8.5 } inc1 := ?3-1 * oops1 if oops1 = 1 then pos1 +:= inc1 inc2 := ?3-1 * oops2 if oops2 = 1 then pos2 +:= inc2 inc3 := ?3-1 * oops3 if oops3 = 1 then pos3 +:= inc3 if (pos1 >= 68) & (leg1 = 1) then leg1 := 2 if (pos2 >= 68) & (leg2 = 1) then leg2 := 2 if (pos3 >= 68) & (leg3 = 1) then leg3 := 2 if (pos1 > 78) & (leg1 = 2) then leg1 := 3 if (pos2 > 78) & (leg2 = 2) then leg2 := 3 if (pos3 > 78) & (leg3 = 2) then leg3 := 3 if (78 >= pos1 >= 68) then y1 +:= inc1 if (78 >= pos2 >= 68) then y2 +:= inc2 if (78 >= pos3 >= 68) then y3 +:= inc3 if y1 > 15 then y1 := 15 if y2 > 17 then y2 := 17 if y3 > 19 then y3 := 19 result := accident() display() if result = 0 then return 4 if (pos1 >= finish) & (pos2 < finish) & (pos3 < finish) then return 1 if (pos2 >= finish) & (pos1 < finish) & (pos3 < finish) then return 2 if (pos3 >= finish) & (pos1 < finish) & (pos2 < finish) then return 3 if (pos1 >= finish) & (pos2 >= finish) | (pos2 >= finish) & (pos3 >= finish) | (pos3 >= finish) & (pos1 >= finish) then return 0 } end # # # display the horses at different legs of the race # procedure display() static oldy1,oldy2,oldy3,blanks initial { oldy1 := 5 oldy2 := 7 oldy3 := 9 blanks:= " " } if leg1 = 2 then { writes(at(5,68),blanks) writes(at(oldy1,68),blanks) if y1 < 12 then { writes(at(y1,68)," ",back[2]," ") writes(at(y1+1,68)," 1 ") writes(at(y1+2,68)," ",front[2]," ") } oldy1 := y1 } else { writes(at(y1,vectors[pos1]),back[leg1],1,front[leg1]) } if leg2 = 2 then { writes(at(7,68),blanks) writes(at(oldy2,68),blanks) if y2 < 14 then { writes(at(y2,69)," ",back[2]," ") writes(at(y2+1,69)," 2 ") writes(at(y2+2,69)," ",front[2]," ") } oldy2 := y2 } else { writes(at(y2,vectors[pos2]),back[leg2],2,front[leg2]) } if leg3 = 2 then { writes(at(9,68),blanks) writes(at(oldy3,68),blanks) if y3 < 16 then { writes(at(y3,70)," ",back[2]," ") writes(at(y3+1,70)," 3 ") writes(at(y3+2,70)," ",front[2]," ") } oldy3 := y3 } else { writes(at(y3,vectors[pos3]),back[leg3],3,front[leg3]) } end # # simulate rare freakish accidents # procedure accident() if (?2000 = 111) & (leg1 ~= 2) then { oops1 := 0 leg1 +:= 3 write(at(13,1),"\7OH NO! ",horse1[1]," fell down!") } if (?2000 = 111) & (leg2 ~= 2) then { oops2 := 0 leg2 +:= 3 write(at(13,1),"\7OH NO! ",horse2[1]," fell down!") } if (?2000 = 111) & (leg3 ~= 2) then { oops3 := 0 leg3 +:= 3 write(at(13,1),"\7OH NO! ",horse3[1]," fell down!") } if oops1+oops2+oops3 = 0 then return 0 return 1 end # # # return a list of track x positions # procedure draw_track() static pavement initial pavement := copy(mktrack()) offset := [] every i := 1 to 68 do put(offset,i) every i := 1 to 10 do put(offset,72) every i := 68 to 1 by -1 do put(offset,i) offset |||:= [1,1,1,1,1] writes("\e[0;1;33;44m\e[2J\e[H") every i := 1 to *pavement do writes(at(i,1),pavement[i]) return offset end # # generate racing track # procedure mktrack() track := [] put(track," WELCOME TO ICON PARK CYBER STEED RACE TRACK") put(track,"") put(track,"___________________________________________________________________________") put(track," \\") put(track,"`#1#^ \\") put(track," \\") put(track,"`#2#^ \\") put(track," |") put(track,"`#3#^ |") put(track,"_________________________________________________________________ |") put(track," \\ |") put(track,"Commentator: | |") put(track," | |") put(track,"_________________________________________________________________/ |") put(track," |") put(track," |") put(track," /") put(track," /") put(track," /") put(track," /") put(track,"__________________________________________________________________________/") put(track,"1 :") put(track,"2 :") put(track,"3 :") return track end # # final wrapup procedure, summarize winnings # procedure done() write("\e[2J\e[HICON PARK CYBER RACE TRACK BIDS YOU ADIEU\n") write(" We all started with $100. And now for the results...\n") every player := !players do { winnings := money[player] if winnings < 100 then msg := "\nLooks like you lost some $ today.\n" if winnings = 100 then msg := "\nLooks like you broke even today.\n" if winnings > 100 then msg := "\nLooks like a winner. Stop at the IRS window please!\n" write("OK ",player,", you have $",winnings," left. ",msg) } stop("Game Over.") end # # # generate horse 1 portraite # procedure pick1() pferd := [] put(pferd,"") put(pferd," /\\") put(pferd," |||/ \\") put(pferd," / \\\\") put(pferd," / \\\\\\\\") put(pferd," / o \\\\\\\\\\\\") put(pferd," / \\\\\\\\\\\\") put(pferd," / \\\\\\\\\\\\\\") put(pferd," / \\\\\\\\\\\\") put(pferd," O /-----\\ \\\\\\\\\\___") put(pferd," \\/|_/ \\") put(pferd," \\") put(pferd," \\") put(pferd," \\") return pferd end # # generate horse 2 portraite # procedure pick2() pferd := [] put(pferd,"") put(pferd," /\\") put(pferd," |||/ \\") put(pferd," / \\\\") put(pferd," / / \\\\\\\\") put(pferd," / O \\\\\\\\") put(pferd," / \\\\\\\\") put(pferd," / \\\\\\\\") put(pferd," / \\\\\\\\") put(pferd," o /----\\\\ \\\\\\\\\\___") put(pferd," \\/|_/ \\\\") put(pferd," \\\\\\") put(pferd," \\") put(pferd," \\") put(pferd,"") return pferd end # # generate horse 3 portraite # procedure pick3() pferd := [] put(pferd," \\/ ") put(pferd," \\ /||| ") put(pferd," \\ / ") put(pferd," \\\\ / ") put(pferd," \\\\\\ o / ") put(pferd," \\\\\\\\ / ") put(pferd," \\\\\\\\\\ / ") put(pferd," \\\\\\\\\\ / ") put(pferd," ___\\\\\\\\ \\\\-----/ O") put(pferd," \\\\ /_|/\\ ") put(pferd," \\ ") put(pferd," \\ ") put(pferd," \\ ") put(pferd,"") return pferd end # # # generate horse 4 portraite # procedure pick4() pferd := [] put(pferd," \\/ ") put(pferd," \\\\//||| ") put(pferd," \\\\ / ") put(pferd," \\\\\\ / / ") put(pferd," \\\\\\ O / ") put(pferd," \\\\\\ / ") put(pferd," \\\\\\ / ") put(pferd," \\\\\\ /") put(pferd," ___\\\\\\ \\----/ o") put(pferd," \\\\ /_|/\\ ") put(pferd," \\\\ ") put(pferd," \\ ") put(pferd," \\ ") put(pferd,"") return pferd end # # generate horse 5 portraite # procedure pick5() pferd := [] put(pferd," /\\ /\\") put(pferd," | ||||| |") put(pferd," | ||| |") put(pferd," | || |\\") put(pferd," | | \\") put(pferd," | 0 0 | |\\") put(pferd," | | |\\") put(pferd," | | |\\") put(pferd," | | |\\") put(pferd," | | |") put(pferd," | o o |\\") put(pferd," \\ ____ / \\") put(pferd," \\______/ \\") put(pferd,"") return pferd end # # generate horse 6 portraite # procedure pick6() pferd := [] put(pferd," \\/ \\/ ") put(pferd," | ||||| | ") put(pferd," | ||| | ") put(pferd," \\| || | ") put(pferd," \\ | | ") put(pferd," \\| | 0 0 | ") put(pferd," \\| | | ") put(pferd," \\| | | ") put(pferd," \\| | | ") put(pferd," | | | ") put(pferd," \\| o o | ") put(pferd," \\ / ____ \\") put(pferd," \\ /______\\ ") put(pferd,"") return pferd end procedure banner() write("\e[0;1;33;44m\e[2J\e[H") write("###############################################################################") write(" ") write(" **** * * **** ***** **** **** ***** ***** ***** **** ") write(" * * * * * * * * * * * * * * ") write(" * * **** *** **** *** * *** *** * * ") write(" * * * * * * * * * * * * * ") write(" **** * **** ***** * * **** * ***** ***** **** ") write(" ") write(" **** * **** *** * * **** ") write(" * * * * * * ** * * ") write(" **** ***** * * * * * * *** ") write(" * * * * * * * ** * * ") write(" * * * * **** *** * * **** ") write(" ") write(" \e[1;5m by tenaglia\e[0;1;33;44m") write(" ") write("###############################################################################") wait(3) end # # # move cursor to specified screen position # procedure at(row,column) return "\e[" || row || ";" || column || "f" end # # procedure to wait n seconds # procedure wait(n) secs := &clock[-2:0] + n if secs > 60 then secs -:= 60 repeat { now := &clock[-2:0] if now = secs then break } return end # # this procedure prompts for an input string # procedure input(prompt) writes(prompt) return read() end # # parse a string into a list with respect to a delimiter # procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end ######################### END OF HORSE RACE GAME ########################### From icon-group-sender Wed Dec 2 10:45:32 1992 Received: by cheltenham.cs.arizona.edu; Wed, 2 Dec 1992 12:32:56 MST Date: Wed, 2 Dec 92 10:45:32 -0700 From: sbw@turing.cse.nau.edu (Steve Wampler) Message-Id: <9212021745.AA02051@turing.cse.nau.edu> To: goer@midway.uchicago.edu, icon-group@cs.arizona.edu Subject: Re: Is a long jump in icon possible ? Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1992Nov30.200950.16632@midway.uchicago.edu> you write: |> Frank Kirschner writes: |> > |> >Is a long jump in icon possible ? |> |> Nope. One thing people periodically complain about is that Icon has |> no way of handling events (including errors), except perhaps kbhit(), |> unless you go to the X extensions. I don't know how the X extensions |> handle errors. |> |> I'll bet that a longjump facility won't get into Icon because it would |> require lots of OS-dependent code. You never know, though. If you |> have the Icon implementation book, you could take a look to see what |> would need to be done. |> Never, say 'nope'. You *can* do long jumps, after a fashion. Consider the following approach: procedure main() do_work := create A() if @do_work == "jump" then # .... end procedure A() B() end procedure B() if erorr_condition then @&main end However, this approach has never been formally developed (no guidelines for how to be systematic about it... Incidently, I *think* the newer features of Icon (the ability to trap error conditions do give quite a bit of additional flexibility in regards to exception handing... From icon-group-sender Mon Nov 9 08:14:04 1992 Received: by cheltenham.cs.arizona.edu; Thu, 3 Dec 1992 07:01:29 MST Date: 9 Nov 92 08:14:04 GMT From: munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!usage!syacus!ron@tcgould.tn.cornell.edu (Ron Williams) Organization: ACUS Australian Centre for Unisys Software, Sydney Subject: icon program examples Message-Id: <1992Nov9.081404.1640@syacus.acus.oz.au> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I recently acquired the icon executables, and source, but apart from the test suite, there appears to be little in the way of examples. I wonder if I simply missed seeing what is there? Could someone please direct me to any source written in icon that is freely available? I desperately need examples. thanks in advance... -- Ron Williams ACSnet : ron@syacus.acus.oz Ph : +61 2 390-1366 Internet : ron@syacus.acus.OZ.AU Fax: +61 2 390-1391 UUCP : uunet!munnari!syacus.acus.oz.au!ron Standard Disclaimers Apply From icon-group-sender Thu Dec 3 08:03:42 1992 Received: by cheltenham.cs.arizona.edu; Thu, 3 Dec 1992 09:17:49 MST Date: Thu, 3 Dec 1992 08:03:42 MST From: "Cliff Hathaway" Message-Id: <199212031503.AA27873@javelina.cs.arizona.edu> To: icon-group Subject: Re: icon program examples Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!usage!syacus!ron@tcgould.tn.cornell.edu (Ron Williams) > Organization: ACUS Australian Centre for Unisys Software, Sydney > Subject: icon program examples > Message-Id: <1992Nov9.081404.1640@syacus.acus.oz.au> > To: icon-group@cs.arizona.edu > I recently acquired the icon executables, and source, but apart from the > test suite, there appears to be little in the way of examples. I wonder if > I simply missed seeing what is there? Could someone please direct me to > any source written in icon that is freely available? I desperately need > examples. > > thanks in advance... > > -- > Ron Williams ACSnet : ron@syacus.acus.oz > Ph : +61 2 390-1366 Internet : ron@syacus.acus.OZ.AU > Fax: +61 2 390-1391 UUCP : uunet!munnari!syacus.acus.oz.au!ron > Standard Disclaimers Apply Ron -- There are Icon library packages available via ftp from cs.arizona.edu. The contents of each package are generally the same, just the format of the file (lzh, hqx, cpio, arc, zoo) varies to accomodate various operating systems. The library contains around 700KB of source code for useful programs and procedures written in Icon. These can also be ordered on diskettes for US$15, plus a US$5 shipping charge outside of the US, Canada and Mexico, or obtained via our ftpmail server. Send an email message to ftpmail@cs.arizona.edu, with the word help in the body to receive further instructions on using the ftpmail server. Cliff Hathaway Dept. of Computer Science (602)621-4291 University of Arizona cliff@cs.arizona.edu (internet) Tucson, Ariz. 85721 {cmcl2,noao,uunet}!arizona!cliff (uucp) From icon-group-sender Fri Nov 13 17:27:32 1992 Received: by cheltenham.cs.arizona.edu; Tue, 8 Dec 1992 09:51:44 MST Date: 13 Nov 92 17:27:32 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: Second argument to sortf Message-Id: <527005@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 Greg Townsend has told us that he just didn't think of the possibility of using a field name as the second argument to sortf when he built it. Given that it's too late to redo the design, what's the best way to provide this obviously useful functionality? (1) Perhaps the implementation could be modified, as Jerry Nowlin suggested, to overload the second argument so that a field name would be interpreted as the key field. (2) But an even neater approach, which wouldn't require modifying sortf at all, would be an Icon function fieldpos(rectype, fld) that would take a record type and field name as inputs and would yield the field position as output. Such a function would probably have other uses as well. Paul Abrahams From icon-group-sender Fri Nov 13 05:19:21 1992 Received: by cheltenham.cs.arizona.edu; Tue, 8 Dec 1992 09:51:52 MST Date: 13 Nov 92 05:19:21 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (President Clinton Jeffery) Subject: Re rationale for sortf() Message-Id: <199211130519.AA22161@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 Jerry Nowlin writes: > You can define tables with field names as key and the record index as value > and just use that in place of field name arguments to sortf(). When you > change record definitions you would have to change tables values. This > won't help with Idol unfortunately. Maybe Idol could put extra fields at > the end of records to avoid obscuring known index values? An interesting thought. There is no reason the two "extra fields" could not be put at the back. But current default behavior notwithstanding, objects are not supposed to be transparent and allow any old function to access their internal fields; a sortf() that would be technically correct for Idol would call a procedure (method, really) to access the key, and there are real technical reasons why sortf() doesn't call back out to an Icon procedure (or Idol method) in the present implementation -- none of Icon's built-in functions do that, in fact. Writing a built-in Icon function that calls procedures is our user-grailquest for the week; in the meantime sorters of lists of objects would do well to consider adapting Bob Alexander's elegant isort procedure from the Icon program library. From icon-group-sender Fri Nov 13 11:01:17 1992 Received: by cheltenham.cs.arizona.edu; Tue, 8 Dec 1992 09:52:08 MST Date: 13 Nov 92 11:01:17 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: CFP: Conf. on Prog. Languages and System Architectures Message-Id: <199211131230.AA28219@cheltenham.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 Dear Sir/ Madam please help us advertising our "Conference on Programming Languages and System Architectures with a special session in honor of Niklaus Wirth on his 60th birthday" by publicizing the following text. Thank you very much for your help and best regards! Prof. J. Gutknecht ETH Zentrum CH-8092 Zurich gutknecht@inf.ethz.ch ======================================= Call for Papers Conference on Programming Languages and System Architectures with a special session in honor of Niklaus Wirth on his 60th birthday 2th - 4th March, 1994 ETH Zurich, Switzerland The conference will provide an international forum for the presentation and discussion of recent research in the areas of programming languages and system architectures. Authors are invited to submit papers describing original research related to these areas. Particularly encouraged are contributions discussing their mutual influence. Also, unrefereed contributions of 5-20 min. duration, and of a technical and/or personal nature are solicited for an afternoon session honoring N. Wirth. Subjects of special interest include, but are not restricted to: Programming language design and history, Programming environments, Programming methods, Operating systems, Compiler construction, Innovative system architectures Send two copies of technical contributions to the program chair. Submissions should not exceed 15 pages and must not have been published or submitted for publication elsewhere. Where possible, include the e-mail address and fax number of the contact author. Potential contributors to the special session in honor of Niklaus Wirth should contact the program chair for more information. Proceedings will be published by Springer Verlag in the Lecture Notes in Computer Science series and will be distributed at the conference. Program Committee J. Gutknecht (Chair) ETH Zentrum CH-8092 Zurich, Switzerland e-mail: gutknecht@inf.ethz.ch e-fax: (+41 1) 251 96 78 R. P. Cook, Microsoft, Redmond, WA G. Coray, EPF Lausanne, CH O. J. Dahl, University of Oslo, N E. W. Dijkstra, Univ. of Texas, Austin, TX G. Goos, Techn. Univ, Karlsruhe, D S. Graham, Univ. of California, Berkeley, CA D. Gries, Cornell University, Ithaca, NY D. Hanson, Princeton Univ, Princeton, NJ B. Kernighan, AT&T Bell Labs, Murray Hill, NJ B. W. Lampson, DEC CRL, Cambridge, MA J. Ludewig, Techn. Univ., Stuttgart, D J. Misra, Univ. of Texas, Austin, TX H. Moessenboeck, ETH Zurich, CH R. Needham, Cambridge University, GB S. Owicki, DEC SRC, Palo Alto, CA G. Pomberger, Universitaet Linz, A P. Rechenberg, Universitaet Linz, A M. Reiser, IBM Research, Zuerich, CH B. Sanders, ETH Zurich, CH P. Schulthess, Universitaet Ulm, D A. Shaw, Univ. of Washington, Seattle, WA P. D. Terry, Rhodes University, Grahamstown, SA L. Tesler, Apple Corp, Cupertino, CA J. Welsh, Univ. of Queensland, Brisbane, AU N. Wirth, ETH Zurich, CH Key Dates Deadline for receipt of submissions: 1st August, 1993 Acceptance notification: 1st November, 1993 Deadline for camera-ready final papers: 15th December, 1993 From icon-group-sender Tue Dec 8 09:58:57 1992 Received: by cheltenham.cs.arizona.edu; Tue, 8 Dec 1992 10:13:51 MST Date: Tue, 8 Dec 1992 09:58:57 MST From: "Gregg Townsend" Message-Id: <199212081658.AA20087@owl.cs.arizona.edu> To: icon-group Subject: Re: sortf() (new comment) Status: R Errors-To: icon-group-errors@cs.arizona.edu Another point is that finding field x (by name) of a record is relatively expensive, and this would have to be done on every comparison operation. Icon couldn't turn sortf(l,"foo") into sortf(l,3) in the general case because the list could be heterogeneous. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Wed Dec 9 09:28:27 1992 Received: by cheltenham.cs.arizona.edu; Wed, 9 Dec 1992 06:15:49 MST Date: Wed, 9 Dec 92 09:28:27 GMT From: ruiter@ruls41.leidenuniv.nl (Jan Peter de Ruiter) Message-Id: <9212090928.AA06254@ruls41.LeidenUniv.nl> To: icon-group@cs.arizona.edu Subject: History Cc: ruiter@ruls41.LeidenUniv.nl Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm not entirely sure, but haven't we had the previous two letters before? I had a distinct kind of "aha-erlebnis" when I read the discussion of the sortf function, received this morning. Jan P. A. de Ruiter ruiter@rulfsw.leidenuniv.nl From icon-group-sender Mon Dec 14 07:46:26 1992 Received: by cheltenham.cs.arizona.edu; Mon, 14 Dec 1992 05:16:13 MST Date: 14 Dec 92 07:46:26 GMT From: portal!cup.portal.com!langalf@uunet.uu.net (Larry A Schrupp) Organization: The Portal System (TM) Subject: Wanted: SNOBOL4 SIL macros for 68000 processor Message-Id: <71652@cup.portal.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 wish to implement SNOBOL4 on two 68000 based computers (An Amiga 2000, and a VMEbus 68040 running UniFLEX). I have Version 3.11 source for the SIL (Macro Implementation of SNOBOL4), as well as the IBM 360 version of the macros and system subroutines. Does anyone have a 68000 implementation of the macros and subroutines (for any system) they would be willing to share? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Larry A. Schrupp langalf@cup.portal.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From icon-group-sender Tue Dec 15 10:44:24 1992 Received: by cheltenham.cs.arizona.edu; Tue, 15 Dec 1992 05:28:56 MST Via: uk.ac.edinburgh.festival; Tue, 15 Dec 1992 10:44:33 +0000 Date: 15 Dec 92 10:44:24 GMT From: R J Hare Subject: Problem with XIcon syntax. To: icon-group@cs.arizona.edu Message-Id: <9212151044.aa28611@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu I have a minor problem with XIcon syntax - can anyone help? I wish to execute a loop, the culmination of which is the drawing of a single point in the XWindow. I wish to be able to terminate execution of the loop and move to the next phase of the program at any point (ie: with the picture incomplete) by pressing a button on my mouse. I reackon the code should look something like this: procedure main() . every i:=1 to n do {if XEvent(window)==&lpress then break # force a break if lb is pressed . loop code culminating in XDrawPoint(window,x,y)}} . remainder of code . end This seems to get in some sort of hung-up situation - I see no points being drawn in my window and pressing the left mouse button doesn't seem to exit from the loop either. The following code works, but doesn't seem so intuitive: every i:=1 to n do {if (events:=XPending(window) & *events > 0) # force a then if XEvents(window)==&lpress # break if left then break # button pressed . loop code culminating in XDrawPoint(window,x,y)}} . remainder of code . end Should the first form of the code work, or what? Thanks. Roger Hare. From icon-group-sender Tue Dec 15 11:06:51 1992 Received: by cheltenham.cs.arizona.edu; Wed, 16 Dec 1992 05:58:28 MST Date: 15 Dec 92 11:06:51 GMT From: enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@ucbvax.Berkeley.EDU (Hakan Soderstrom) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Subject: Bus error termination Message-Id: <1992Dec15.110651.6444@eua.ericsson.se> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu A month ago or so I reported that an Icon program terminated with bus error. I was then advised of the existence of version 8.7 of Icon and promptly installed it. The problem did not go away. I found, however, that the problem vanished if I made STRSIZE large enough. Is this a known problem: that a too small STRSIZE can go undetected and cause a bus error? --- ------------------------------------------ Hakan Soderstrom (contractor) From icon-group-sender Thu Dec 17 10:36:21 1992 Received: by cheltenham.cs.arizona.edu; Thu, 17 Dec 1992 06:01:47 MST Via: uk.ac.edinburgh.festival; Thu, 17 Dec 1992 10:36:27 +0000 Date: 17 Dec 92 10:36:21 GMT From: R J Hare Subject: Bus Error To: icon-group@cs.arizona.edu Message-Id: <9212171036.aa13225@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu I have just encountered the bus error reported here yesterday, for the first time. I have increased my STRSIZE to 100000, but he error still occurs. I would like to ask what size the original poster increased STRSIZE to? Apologies for posting this question here, but someones mailer somewhere is mangling my reply when I try to reply direct to the original poster. Thanks. Roger Hare. From icon-group-sender Thu Dec 17 09:30:10 1992 Received: by cheltenham.cs.arizona.edu; Thu, 17 Dec 1992 12:38:52 MST Date: Thu, 17 Dec 92 09:30:10 -0800 From: wgg@cs.UCSD.EDU (William Griswold) Message-Id: <9212171730.AA26944@gremlin> To: ercn72@festival.ed.ac.uk, icon-group@cs.arizona.edu Subject: Re: Bus Error Status: R Errors-To: icon-group-errors@cs.arizona.edu You never know if you've hit "the" bus error. There are probably several latent bugs that could cause a bus error. Increasing the STRSIZE may not help you. A potential cause of a bus error is exhausting the stack (too many recursive calls), which can overflow into another memory region. You might try increasing your default stack size (I believe there is one default for &main, and another for all other coexpressions; if you are using coexpressions heavily, consider increasing the default stack size for coexpressions). Bill Griswold From icon-group-sender Tue Dec 15 18:17:59 1992 Received: by cheltenham.cs.arizona.edu; Fri, 18 Dec 1992 05:41:41 MST Date: 15 Dec 92 18:17:59 GMT From: ucivax!gateway@ucbvax.Berkeley.EDU (Owen O'Malley) Subject: Iconc problem Message-Id: <22111.724443467@porte-de-st-ouen.ics.uci.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 fairly large icon program that is showing some strange behavior. The program always works under the interpreter, but it doesn't under the compiler. In particular, in most test cases execute correctly (even under the compiler) but on some large testcases a few of the strings get corrupted. More specifically, the output files have a few lines of \0's (ie. the nul character) which most of the system utilities die on. It looks to me like a memory corruption problem. Are static areas used by the compiler that might be running out of room? I would appreciate any help, since the large test cases are exactly when I would like to use the compiled version. Thanks, Owen O'Malley Department of ICS | omalley@ics.uci.edu (ARPA) UC Irvine | {ucbvax|sdcsvax}!ucivax!omalley (UUCP) Irvine, CA 92717 | oomalley@uci (BITNET) From icon-group-sender Tue Dec 15 17:52:10 1992 Received: by cheltenham.cs.arizona.edu; Fri, 18 Dec 1992 05:42:13 MST Date: 15 Dec 92 17:52:10 GMT From: uchinews!ellis!goer@handies.ucar.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Bus error termination Message-Id: <1992Dec15.175210.3683@midway.uchicago.edu> References: <1992Dec15.110651.6444@eua.ericsson.se> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu konhks@eua.ericsson.se writes: >A month ago or so I reported that an Icon program terminated with bus error. >I was then advised of the existence of version 8.7 of Icon and promptly >installed it. The problem did not go away. I don't remember exactly what you said in your previous message, but generally it's easier for the rest of us to help if you list your platform, compiler, optimization level, and the features you enabled when you created Icon. In addition a small sample program to illustrate the problem would be useful. Does the bus error happen any time Icon is fired up? Did you try compiling Icon with optimizations turned off? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Dec 16 05:42:11 1992 Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 18 Dec 1992 10:02:03 MST Received: by owl.cs.arizona.edu; Fri, 18 Dec 1992 10:02:02 MST Date: 16 Dec 92 05:42:11 GMT From: agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Iconc problem Message-Id: <1992Dec16.054211.25548@midway.uchicago.edu> References: <22111.724443467@porte-de-st-ouen.ics.uci.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu omalley@ics.uci.edu writes: > I have a fairly large icon program that is showing some strange >behavior. The program always works under the interpreter, but it >doesn't under the compiler. About half the time I use the compiler, programs bomb. It's a neat system, but it's just not maintained the way the interpreter is, and it's still somewhat experimental. The interpreter is really our mainstay (sorta like for LISP and PROLOG programmers). Try compiling your program with various Icon optimizations turned off. Check the iconc man page on how to do this. When you figure out what causes the problem, mail in a bug report to the Icon Pro- ject (the usual - a test program that shows where the misbehavior occurs, and a list of your platform and Icon implementation fea- tures, along with a brief list of what you did when you built Icon [i.e. did you use the standard configs, a prepacked binary, etc.?]). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Dec 18 15:36:03 1992 Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 18 Dec 1992 18:05:35 MST Received: by owl.cs.arizona.edu; Fri, 18 Dec 1992 18:05:34 MST Date: Fri, 18 Dec 1992 15:36:03 MST From: "Clint Jeffery" Message-Id: <199212182236.AA09826@chuckwalla.cs.arizona.edu> To: agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU Cc: icon-group@cs.arizona.edu In-Reply-To: (Richard L. Goerwitz's message of 16 Dec 92 05:42:11 GMT <1992Dec16.054211.25548@midway.uchicago.edu> Subject: Iconc problem Status: R Errors-To: icon-group-errors@cs.arizona.edu > Richard Goerwitz writes: About half the time I use the compiler, programs bomb. It's a neat system, but it's just not maintained the way the interpreter is, and it's still somewhat experimental. The interpreter is really our mainstay (sorta like for LISP and PROLOG programmers). I don't think maintenance is the main issue. The compiler is 20,000 (?) lines of code that is almost "new". The interpreter is less lines of code that has been in constant use for around a decade. Ten years from now, if the compiler is buggy, it will be because it hasn't received the attention that the interpreter has up to this point. Clint From icon-group-sender Thu Dec 17 18:35:34 1992 Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 20 Dec 1992 18:02:39 MST Received: by owl.cs.arizona.edu; Sun, 20 Dec 1992 18:02:36 MST Date: 17 Dec 92 18:35:34 GMT From: yuma!wendt@purdue.edu (alan l wendt) Organization: Colorado State University, Computer Science Department Subject: Very small program development environment 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 Aplogies for posting C source to this Icon group. This is a modified version of mcc, which allows you to fix syntax errors quickly in Icon programs. It runs icont and stores the error output. It then pops you back into an editor positioned at the first syntax error. In order to use it with icont, you must define the following environment variables: COMPILER=icont ERRORPATTERN='File %f; Line %l # %m' Then just "mcc foo.icn" will put you into a icont-edit loop until you abort out. Alan Wendt -------------------------------------------------------------------------------- # to unbundle, sh this file echo unbundling Makefile 1>&2 cat >Makefile <<'AlBeRtEiNsTeIn' # If you're on 4.2 or earlier, use the first line; else the second. CFLAGS= -g -DBSD #CFLAGS=-O mcc: mcc.o regex.o cc $(CFLAGS) -o mcc mcc.o regex.o all: mcc mcc.1 install: all @echo copy mcc and mcc.1 to the appropriate directories. AlBeRtEiNsTeIn echo unbundling mcc.c 1>&2 cat >mcc.c <<'AlBeRtEiNsTeIn' /* Program: mcc * By: Brent Callaghan * Date: July 1984 * * Function: Runs the C compiler, passing all command line * arguments. If the compiler returns a non-zero * result, the syntax errors are merged with the * source and the user's editor is invoked. The * cursor is placed on the first line in error. * Exit from the editor re-invokes the C compiler. * This loop continues until the C compiler exits * to the linker, the source file is not changed, * or the user kills mcc with a keyboard interrupt * after exiting the editor. * * Environment variables EDITOR and COMPILER may * be used to set an alternative editor or compiler. * * ~~~ PUBLIC DOMAIN ~~~ * * This program may be freely used and distributed * but I would rather you did not sell it. * ************************************************************ */ /* bugs: 1. only edits the first source file with errors. */ /* 2. copies the temporary back onto the original even if */ /* the original is newer */ #if 0 Mcc (Merge C Compiler) behaves just like a C for an error free compile. However, if the compiler finds syntax errors, it merges the error messages with the source and invokes your editor (default is vi) on the merged file. On exiting the editor it strips the merged messages and if the source file was modified it re-runs the compiler for another try. This posting contains a shell script and a C program with identical functionality. The C program is noticeably faster. Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 691 6188 #endif #include #include #include #include #include #ifdef BSD #include #define strchr index #define strrchr rindex #else #include #endif extern char * getenv(); static char *errname = "/tmp/errXXXXXX"; static char mergename[128]; static char *srcname; static char *editor, *edname, *compiler; static int pid, viedit, firsterr; static int chksum1, chksum2; static int filevar, linevar, msgvar; extern char *re_comp(); static char errpat[1024], errpato[1024]; static char *errdfa; extern char *braslist[], *braelist[]; /* * Form 16 bit checksum of source line */ int checksum(sum, line) register int sum; register char *line; { while (*line++) { if (sum & 1) sum = (sum >> 1) + 0x8000; else sum >>= 1; sum = (sum + *line) & 0xFFFF; } return sum; } int runc(argv, errname) char **argv; char *errname; { int status; switch (pid = fork()) { case 0: /* child */ (void) freopen(errname, "w", stderr); execvp(compiler, argv); perror("Couldn't exec compiler"); exit (1); case -1: /* Error */ perror("Couldn't fork compiler"); exit (1); default: /* Parent */ while (wait(&status) != pid); /* wait for compile to finish */ break; } return ((status >> 8) & 0xFF); } void listerrs(errname) char *errname; { FILE *errfile; char errline[BUFSIZ + 1]; if ((errfile = fopen(errname, "r")) == NULL) return; while (fgets(errline, BUFSIZ, errfile) != NULL) (void) fputs(errline, stderr); (void) fclose(errfile); (void) unlink(errname); } void edit(mergename) char *mergename; { int status; char sfirsterr[6]; switch (pid = fork()) { case 0: /* Child */ if (viedit) { (void) sprintf(sfirsterr, "+%d", firsterr); (void) printf(" vi %s %s\n", sfirsterr, mergename); execlp(editor, "vi", sfirsterr, mergename, NULL); } else { (void) printf(" %s %s\n", edname, mergename); execlp(editor, edname, mergename, NULL); } perror("Couldn't exec editor"); listerrs(errname); exit (1); case -1: /* Error */ perror("Couldn't fork editor"); listerrs(errname); exit (1); default: /* Parent */ while (wait(&status) != pid); /* wait for editor to finish */ break; } } int errinfo(errfile, srcname, errmsg) FILE *errfile; char *srcname, *errmsg; { static char errline[BUFSIZ + 1]; char slineno[8]; char *p1; for (;;) { /* get next line from error message file */ if (fgets(errline, BUFSIZ, errfile) == NULL) return 0; errline[strlen(errline) - 1] = '\0'; /* trim newline */ p1 = errline; /* does it match the pattern? */ if (re_exec(p1, errdfa)) { sprintf(srcname, "%.*s", braelist[filevar] - braslist[filevar], braslist[filevar]); sprintf(slineno, "%.*s", braelist[linevar] - braslist[linevar], braslist[linevar]); sprintf(errmsg, "%.*s", braelist[msgvar] - braslist[msgvar], braslist[msgvar]); return atoi(slineno); } } } char *merge(errname, mergename) char *errname, *mergename; { FILE *errfile, *srcfile, *mergefile; int eof = 0, slineno, elineno, elines; static char firstname[128]; char srcline[BUFSIZ + 1]; char srcname[128], errmsg[80]; if ((errfile = fopen(errname, "r")) == NULL) { perror(errname); exit (1); } if ((firsterr = errinfo(errfile, srcname, errmsg)) == 0) return NULL; if (access(srcname, 2) < 0) /* writeable ? */ return NULL; if ((srcfile = fopen(srcname, "r")) == NULL) { perror(srcname); exit (1); } if (*mergename == '\0') { char *p = strrchr(srcname, '/'); if (p == NULL) p = srcname; else p++; (void) sprintf(mergename, "/tmp/%d.%s", getpid(), p); } if ((mergefile = fopen(mergename, "w")) == NULL) { perror(mergename); exit (1); } slineno = 0; elineno = firsterr; elines = 0; (void) strcpy(firstname, srcname); chksum1 = 0; if (!viedit) { (void) fprintf(mergefile, ">>>><<<< (%d)\n", firsterr + 1); elines++; } while (!eof) { if (!(eof = (fgets(srcline, BUFSIZ, srcfile) == NULL))) { chksum1 = checksum(chksum1, srcline); (void) fputs(srcline, mergefile); } slineno++; while (slineno == elineno) { elines++; (void) fprintf(mergefile, ">>>> %s <<<<", errmsg); if ((elineno = errinfo(errfile, srcname, errmsg)) == 0 || strcmp(firstname, srcname) != 0) (void) fprintf(mergefile, " (last error)\n"); else (void) fprintf(mergefile, " (%d)\n", elineno + elines); } } (void) fclose(errfile); (void) fclose(srcfile); (void) fclose(mergefile); return (firstname); } /* * Strip out merged error messages and compute checksum */ void unmerge(mergename, srcname) char *mergename, *srcname; { FILE *mergefile, *srcfile; char *p, srcline[BUFSIZ + 1]; struct stat merge, src; if (stat(mergename, &merge) != 0) { perror(mergename); exit(1); } if (stat(srcname, &src) != 0) { perror(srcname); exit(1); } if (merge.st_mtime < src.st_mtime) { /* src is newer, don't */ return; /* crong it from tmp */ } if ((mergefile = fopen(mergename, "r")) == NULL) { perror(mergename); exit (1); } if ((srcfile = fopen(srcname, "w")) == NULL) { perror(srcname); exit (1); } chksum2 = 0; while (fgets(srcline, BUFSIZ, mergefile) != NULL) { for (p = srcline; isspace(*p); p++); if (strncmp(p, ">>>>", 4) != 0) { chksum2 = checksum(chksum2, srcline); (void) fputs(srcline, srcfile); } } (void) fclose(mergefile); (void) fclose(srcfile); } void quit() { (void) kill(pid, SIGTERM); (void) unlink(errname); (void) unlink(mergename); exit (1); } main(argc, argv) int argc; char *argv[]; { char *p, *s, *d; int i, status, nvars; if ((editor = getenv("EDITOR")) == NULL) editor = "vi"; edname = (edname = strrchr(editor, '/')) == NULL ? editor : edname + 1; viedit = strcmp(edname, "vi") == 0; if ((compiler = getenv("COMPILER")) == NULL) compiler = "cc"; argv[0] = compiler; (void) mktemp(errname); signal(SIGINT, quit); signal(SIGTERM, quit); signal(SIGHUP, quit); if (p = getenv("ERRORPATTERN")) strcpy(errpat, p); nvars = 0; /* preprocess pattern to turn %f and %l into \(.*\) so that regex */ /* will remember the file and line numbers. */ for (s = errpat, d = errpato; *s;) { if (*s == '%' && s[1] == 'f') { *d++ = '\\'; *d++ = '('; *d++ = '.'; *d++ = '*'; *d++ = '\\'; *d++ = ')'; filevar = nvars++; s += 2; } else if (*s == '%' && s[1] == 'm') { *d++ = '\\'; *d++ = '('; *d++ = '.'; *d++ = '*'; *d++ = '\\'; *d++ = ')'; msgvar = nvars++; s += 2; } else if (*s == '%' && s[1] == 'l') { *d++ = '\\'; *d++ = '('; *d++ = '['; *d++ = '0'; *d++ = '-'; *d++ = '9'; *d++ = ']'; *d++ = '*'; *d++ = '\\'; *d++ = ')'; s += 2; linevar = nvars++; } else *d++ = *s++; } errdfa = re_comp(errpato); while (status = runc(argv, errname)) { if ((srcname = merge(errname, mergename)) == NULL) { listerrs(errname); exit (status); /* couldn't merge */ } edit(mergename); (void) unlink(errname); signal(SIGINT, SIG_IGN); signal(SIGTERM, SIG_IGN); signal(SIGHUP, SIG_IGN); unmerge(mergename, srcname); (void) unlink(mergename); signal(SIGINT, quit); signal(SIGTERM, quit); signal(SIGHUP, quit); if (chksum1 == chksum2) /* file unchanged ? */ break; putchar(' '); for (i = 0; i < argc; i++) (void) printf("%s ", argv[i]); putchar('\n'); } listerrs(errname); (void) unlink(errname); exit (status); } char *alloc(siz) { char *calloc(); char *r; r = calloc(1, siz); if (!r) { fprintf(stderr, "no memory\n"); exit(0); } return r; } AlBeRtEiNsTeIn echo unbundling regex.c 1>&2 cat >regex.c <<'AlBeRtEiNsTeIn' /* @(#)regex.c 4.1 (Berkeley) 12/21/80 */ # /* * routines to do regular expression matching * * Entry points: * * re_comp(s) * char *s; * ... returns 0 if the string s was compiled successfully, * a pointer to an error message otherwise. * If passed 0 or a null string returns without changing * the currently compiled re (see note 11 below). * * re_exec(s) * char *s; * ... returns 1 if the string s matches the last compiled regular * expression, * 0 if the string s failed to match the last compiled * regular expression, and * -1 if the compiled regular expression was invalid * (indicating an internal error). * * The strings passed to both re_comp and re_exec may have trailing or * embedded newline characters; they are terminated by nulls. * * The identity of the author of these routines is lost in antiquity; * this is essentially the same as the re code in the original V6 ed. * * The regular expressions recognized are described below. This description * is essentially the same as that for ed. * * A regular expression specifies a set of strings of characters. * A member of this set of strings is said to be matched by * the regular expression. In the following specification for * regular expressions the word `character' means any character but NUL. * * 1. Any character except a special character matches itself. * Special characters are the regular expression delimiter plus * \ [ . and sometimes ^ * $. * 2. A . matches any character. * 3. A \ followed by any character except a digit or ( ) * matches that character. * 4. A nonempty string s bracketed [s] (or [^s]) matches any * character in (or not in) s. In s, \ has no special meaning, * and ] may only appear as the first letter. A substring * a-b, with a and b in ascending ASCII order, stands for * the inclusive range of ASCII characters. * 5. A regular expression of form 1-4 followed by * matches a * sequence of 0 or more matches of the regular expression. * 6. A regular expression, x, of form 1-8, bracketed \(x\) * matches what x matches. * 7. A \ followed by a digit n matches a copy of the string that the * bracketed regular expression beginning with the nth \( matched. * 8. A regular expression of form 1-8, x, followed by a regular * expression of form 1-7, y matches a match for x followed by * a match for y, with the x match being as long as possible * while still permitting a y match. * 9. A regular expression of form 1-8 preceded by ^ (or followed * by $), is constrained to matches that begin at the left * (or end at the right) end of a line. * 10. A regular expression of form 1-9 picks out the longest among * the leftmost matches in a line. * 11. An empty regular expression stands for a copy of the last * regular expression encountered. */ /* * constants for re's */ #define CBRA 1 #define CCHR 2 #define CDOT 4 #define CCL 6 #define NCCL 8 #define CEOF 11 #define CKET 12 #define CBACK 18 #define CSTAR 01 #define ESIZE 512 #define NBRA 9 static char *names[] = { "?", "\\(", "char", "char*", ".", ".*", "[", "[*", "[^", "[^*", "?", "$", "\\)", "?", "?", "?", "?", "?", "\\" }; char expbuf[ESIZE], *braslist[NBRA], *braelist[NBRA]; static char circf = 1; /* * compile the regular expression argument into a dfa */ char * re_comp(sp) register char *sp; { char *alloc(); register int c; register char *ep = expbuf; int cclcnt, numbra = 0; char *lastep = 0; char bracket[NBRA]; char *bracketp = &bracket[0]; static char *retoolong = "Regular expression too long"; #define comerr(msg) {expbuf[0] = 0; numbra = 0; printf(msg); return(0); } if (sp == 0 || *sp == '\0') { if (*ep == 0) comerr("No previous regular expression\n"); return(0); } /* if (*sp == '^') { * circf = 1; * sp++; * } * else circf = 0; */ for (;;) { if (ep >= &expbuf[ESIZE]) comerr(retoolong); if ((c = *sp++) == '\0') { if (bracketp != bracket) comerr("unmatched \\("); *ep++ = CEOF; *ep++ = 0; sp = alloc(ep - expbuf); for (numbra = 0; numbra < ep - expbuf; numbra++) { sp[numbra] = expbuf[numbra]; } return sp; } if (c != '*') lastep = ep; switch (c) { case '.': *ep++ = CDOT; continue; case '*': if (lastep == 0 || *lastep == CBRA || *lastep == CKET) goto defchar; *lastep |= CSTAR; continue; case '[': *ep++ = CCL; *ep++ = 0; cclcnt = 1; if ((c = *sp++) == '^') { c = *sp++; ep[-2] = NCCL; } do { if (c == '\0') comerr("missing ]"); if (c == '-' && ep [-1] != 0) { if ((c = *sp++) == ']') { *ep++ = '-'; cclcnt++; break; } while (ep[-1] < c) { *ep = ep[-1] + 1; ep++; cclcnt++; if (ep >= &expbuf[ESIZE]) comerr(retoolong); } } *ep++ = c; cclcnt++; if (ep >= &expbuf[ESIZE]) comerr(retoolong); } while ((c = *sp++) != ']'); lastep[1] = cclcnt; continue; case '\\': if ((c = *sp++) == '(') { if (numbra >= NBRA) comerr("too many \\(\\) pairs"); *bracketp++ = numbra; *ep++ = CBRA; *ep++ = numbra; numbra++; continue; } if (c == ')') { if (bracketp <= bracket) comerr("unmatched \\)"); *ep++ = CKET; *ep++ = *--bracketp; continue; } if (c >= '1' && c < ('1' + NBRA)) { *ep++ = CBACK; *ep++ = c - '1'; continue; } *ep++ = CCHR; *ep++ = c; continue; defchar: default: *ep++ = CCHR; *ep++ = c; } } } /* * match the argument string against the compiled re */ int re_exec(subject, pattern, fromline) register char *subject; register char *pattern; { register int c; int rv; for (c = 0; c < NBRA; c++) { braslist[c] = 0; braelist[c] = 0; } if (circf) { c = (advance(subject, pattern)); /* printf("return %d from %d\n", c, fromline); */ return c; } /* * fast check for first character */ if (*pattern == CCHR) { c = pattern[1]; do { if (*subject != c) continue; if (rv = advance(subject, pattern)) { /* printf("return %d from %d\n", rv, fromline); */ return(rv); } } while (*subject++); /* printf("return 0 from %d\n", fromline); */ return(0); } /* * regular algorithm */ do if (rv = advance(subject, pattern)) { /* printf("return %d from %d\n", rv, fromline); */ return(rv); } while (*subject++); /* printf("return 0 from %d\n", fromline); */ return(0); } /* * try to match the next thing in the dfa */ static int advance(lp, ep) register char *lp, *ep; { register char *curlp; int ct, i; int rv; for (;;) switch (*ep++) { case CCHR: if (*ep++ == *lp++) continue; return(0); case CDOT: if (*lp++) continue; return(0); case CEOF: if (*lp == 0) return(1); return(0); case CCL: if (cclass(ep, *lp++, 1)) { ep += *ep; continue; } return(0); case NCCL: if (cclass(ep, *lp++, 0)) { ep += *ep; continue; } return(0); case CBRA: braslist[*ep++] = lp; continue; case CKET: braelist[*ep++] = lp; continue; case CBACK: if (braelist[i = *ep++] == 0) return(-1); if (backref(i, lp)) { lp += braelist[i] - braslist[i]; continue; } return(0); case CBACK|CSTAR: if (braelist[i = *ep++] == 0) return(-1); curlp = lp; ct = braelist[i] - braslist[i]; while (backref(i, lp)) lp += ct; while (lp >= curlp) { if (rv = advance(lp, ep)) return(rv); lp -= ct; } continue; case CDOT|CSTAR: curlp = lp; while (*lp++) ; goto star; case CCHR|CSTAR: curlp = lp; while (*lp++ == *ep) ; ep++; goto star; case CCL|CSTAR: case NCCL|CSTAR: curlp = lp; while (cclass(ep, *lp++, ep[-1] == (CCL|CSTAR))) ; ep += *ep; goto star; star: do { lp--; if (rv = advance(lp, ep)) return(rv); } while (lp > curlp); return(0); default: printf("oops %d\n", *(ep - 1)); return(-1); } } backref(i, lp) register int i; register char *lp; { register char *bp; bp = braslist[i]; while (*bp++ == *lp++) if (bp >= braelist[i]) return(1); return(0); } int cclass(set, c, af) register char *set, c; int af; { register int n; if (c == 0) return(0); n = *set++; while (--n) if (*set++ == c) return(af); return(! af); } AlBeRtEiNsTeIn From icon-group-sender Fri Dec 18 08:49:21 1992 Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 20 Dec 1992 18:04:42 MST Received: by owl.cs.arizona.edu; Sun, 20 Dec 1992 18:04:41 MST Date: 18 Dec 92 08:49:21 GMT From: enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@ucbvax.Berkeley.EDU (Hakan Soderstrom) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Subject: Re: Bus Error Message-Id: <1992Dec18.084921.2511@eua.ericsson.se> References: <9212171730.AA26944@gremlin> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Thanks to Bill Griswold for mentioning some of the mechanisms that may cause a bus error. My problem occurs in a program segment where coexpressions are used heavily. (I don't have the Icon program library at hand, but it is the procedures, by Ralph Griswold I seem to remember, that convert any data structure to a string, and back again.) The problem appears when the volume and 'knottiness' of the data structure increases, so I'd rather not post a sample. In addition, I have a vague impression that in a previous experiment some other memory related environment variable made the bus error go away. I have become accustomed to Icon as extremely reliable. Still, it is known that stack overflow can go undetected. So I tend to believe that in this case heavily recursive use of coexpressions cause the stack to grow into some other memory region. This is the kind of situation where there is no a priori upper bound on neither the number of active coexpressions nor the depth of recursion. I will re-implement this (small) part of the application. -- Finally, a re-statement of the problem for those who wonder (and for Richard Goerwitz :-) I have an Icon program which I run under SunOS 4.1.1 on SPARC 1+ hardware. I run Icon 8.7 created by gcc 2.1 with -O turned on. This program has been known to terminate with bus error for some input data. It behaved the same under Icon 8.6 as under 8.7. The problem went away when I increased STRSIZE. So my question was, is it a known problem that too small a STRSIZE may go undetected and cause a bus error under Unix? ------------------------------------------ Hakan Soderstrom (contractor) From icon-group-sender Fri Dec 25 08:44:16 1992 Received: by cheltenham.cs.arizona.edu; Sat, 26 Dec 1992 07:02:03 MST Date: 25 Dec 1992 08:44:16 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Happy Holidays To: icon-group@cs.arizona.edu Message-Id: <01GSQ5VICQ6A8WW2L6@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 Hello Colleagues! Chris (kringle) Tenaglia is leaving a little goodie to put under your directory tree. Here is a cheap attempt at a Missile Command game. I've run it under Icon V8.7 under VMS, Unix, and V8.5 under MS-DOS. Here are some things you'll need to know. There is a delay() procedure that keeps the game running at a steady pace. delay() is built into V8.7 on VMS and unix. Under DOS you'll need to roll your own. Funny thing is that VMS delay is 1000 per second and unix is different (maybe 100 per second). Also it does that horrible thing known as ansi escape sequences. Also to play use 7, 8, and 9 to launch a missile. 7 is leftward, 8 is straight, and 9 is right. A bug in the ultrix version (kbhit() and getch()) requires double pressing the buttons. I think q will quit the game early. Have Fun! 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 # # FILE : MC.ICN # DESC : SORT OF A MISSILE COMMAND GAME # # UPDATE BY WHAT # 17-NOV-1992 TENAGLIA BEGIN INITIAL WRITE # global bonus, # bonus missile threshhold score, # number of missiles shot down munitions, # munitions supply (# of defensive missiles) missilef, # whether enemy missile is launched flag missilex, # x position of enemy missile missiley, # y position of enemy missile incm, # x increment of enemy missile abmf, # whether defensive missile fired flag abmx, # x position of defensive missile abmy, # y position of defensive missile abmix # x increment of defensive missle procedure main() infrastructure() # set up defaults, globals, and munitions banner() # output initial banner repeat { draw_base() # initially draw base repeat { enemy_launch() # possible enemy attack friendly_fire() # possible defensive attack animate() # draw action if any sense_status() # sense status delay(1000) # pace the game } } stop("\7\e[0m",at(12,24),"Game Over. \e[5mInsert another quarter.\e[0m\e[?25h\e=") end # # set up all the initial defaults # procedure infrastructure() bonus := 22 missilef := 0 missilex := 0 missiley := 0 incm := 0 abmf := 0 abmx := 0 abmy := 0 score := 0 &random := map(&clock,":","0") munitions:= 10 + ?5 end # # draw the initial environment # procedure draw_base() write("\e[?25l\e>\e[?5l\e[0;1;33;44m\e[2J\e[H S.D.I. OUTPOST [TACTICAL SITUATION DISPLAY]") writes(at(23,1),repl("#",79)) writes(at(24,1),repl("=",79)) writes(at(24,39),"/ \\",at(23,40),"^") writes(at(24,5)," Missiles Left : ",munitions," ") writes(at(24,60)," Score : ",score," ") end # # check and occasionally launch a missile # procedure enemy_launch() (?50 = 33) | fail if missilef = 1 then fail missilex := 1 missiley := 1 + ?10 missilef := 1 incm := ?3 end # # coordinate launch of defensive missiles # procedure friendly_fire() kbhit() | fail press := getch() if abmf = 1 then { case press of { "1" | "4" | "7" | "l" | "L" : abmix := -2 "2" | "5" | "8" | "s" | "S" : abmix := 0 "3" | "6" | "9" | "r" | "R" : abmix := 2 "q" | "Q" | "\e" : stop("\e[2J\e[H") default : writes("\7") } } else { ambf := 1 abmx := 40 abmy := 22 case press of { "1" | "4" | "7" | "l" | "L" : abmix := -2 "2" | "5" | "8" | "s" | "S" : abmix := 0 "3" | "6" | "9" | "r" | "R" : abmix := 2 "q" | "Q" | "\e": stop("\e[2J\e[H",at(12,24),"Game Over. \e[5mInsert another quarter.\e[0m\e[?25h\e=") default : { writes("\7") fail } } if munitions <= 0 then stop(at(12,24),"Game Over. \e[5mInsert Another Quarter!\e[0m\e=\e[?25h") munitions -:= 1 abmf := 1 writes(at(24,5)," Missiles Left : ",munitions," ") } end # # fly the missiles # procedure animate() static old_abmx, old_abmy, old_missilex, old_missiley initial { old_abmx := 0 old_abmy := 0 old_missilez := 0 old_missiley := 0 } # # move the defensive missile if launched # if abmf = 1 then { writes(at(abmy,abmx),"*",at(old_abmy,old_abmx)," ") old_abmx := abmx old_abmy := abmy abmx +:= abmix abmy -:= 1 if abmy < 2 then { writes(at(old_abmy,old_abmx)," ") abmf := 0 abmx := 0 abmy := 0 } } # # move the offensive missile if launched # if missilef = 1 then { writes(at(missiley,missilex)," =>") missilex +:= incm if missilex > 76 then { writes(at(missiley,76),"\e[K") missilef := 0 missilex := 0 missiley := 0 incm := 0 } } end # # sense for hits and handle explosions # procedure sense_status() static junk initial junk := ["=%!*@", "%^&(!", "(@^$^", "*)@%$", "@&%^(#"] if missilef=1 & abmf=1 then { if abmy=missiley & (missilex < abmx < missilex+6) then { every 1 to 3 do { writes(at(abmy,abmx-4),"\e[?5h<<<<>>>>") ; delay(2000) # reverse screen writes(at(abmy,abmx-4),"\e[?5l>>>><<<<") ; delay(2000) # normal screen } every j := abmy to 22 do { writes(at(j,abmx-3),?junk) delay(1000) } if abmx > 67 then abmx := 67 # handle edge of screen problem writes(at(23,abmx-3),"********") ; delay(1000) writes(at(22,abmx-3),"\e[?5h||||||||") ; delay(1000) writes(at(21,abmx-5),"\e[?5l. . . . . . .") ; delay(1000) every j := 20 to abmy by -1 do writes(at(j,abmx-6),"\e[K") wait(2) score +:= incm * (15 - missiley) if score > bonus then { writes(at(12,30),"\7\e[5mBONUS MISSILE EARNED!\e[0m") bonus +:= 33 munitions +:= 1 delay(30000) } draw_base() abmf := 0 abmx := 0 abmy := 0 missilef := 0 missilex := 0 missiley := 0 } } end # # output initial banner for this game # procedure banner() write("\e[0;1;33;44m\e[2J\e[H ") write(" ") write("###############################################################################") write(" ") write(" *** * * ***** **** *** **** ***** ") write(" * * * * * * * * * * * ") write(" * * * * * **** * * *** * ") write(" * * * * * * * * * * ") write(" *** *** * * *** **** * ") write(" ") write(" **** **** *** ") write(" * * * * ") write(" **** * * * ") write(" * * * * ") write(" **** ** **** ** *** ** ") write(" ") write(" ") write("###############################################################################") wait(3) end # # move cursor to specified screen position # procedure at(row,column) return "\e[" || row || ";" || column || "f" end # # procedure to wait n seconds # procedure wait(n) delay(n * 10000) return ## secs := &clock[-2:0] + n ## if secs > 58 then secs -:= 60 ## repeat ## { ## now := &clock[-2:0] ## if now > secs then break ## } ## return end ################################################################## # # # THIS PROCEDURE PULLS ALL THE ELEMENTS (TOKENS) OUT OF A LINE # # BUFFER AND RETURNS THEM IN A LIST. A VARIABLE NAMED 'CHARS' # # CAN BE STATICALLY DEFINED HERE OR GLOBAL. IT IS A CSET THAT # # CONTAINS THE VALID CHARACTERS THAT CAN COMPOSE THE ELEMENTS # # ONE WISHES TO EXTRACT. # # # ################################################################## procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end ################################################################## # # # THIS PROCEDURE IS TERRIBLY HANDY IN PROMPTING AND GETTING # # AN INPUT STRING # # # ################################################################## procedure input(prompt) writes(prompt) return read() end From icon-group-sender Tue Dec 15 11:06:51 1992 Received: by cheltenham.cs.arizona.edu; Sat, 26 Dec 1992 07:02:19 MST Date: 15 Dec 92 11:06:51 GMT From: mcsun!sunic!sics.se!eua.ericsson.se!euas27c34!konhks@uunet.uu.net (Hakan Soderstrom) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Subject: Bus error termination Message-Id: <1992Dec15.110651.6444@eua.ericsson.se> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu A month ago or so I reported that an Icon program terminated with bus error. I was then advised of the existence of version 8.7 of Icon and promptly installed it. The problem did not go away. I found, however, that the problem vanished if I made STRSIZE large enough. Is this a known problem: that a too small STRSIZE can go undetected and cause a bus error? --- ------------------------------------------ Hakan Soderstrom (contractor)