From icon-group-sender Sun Jan 3 21:19:56 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Jan 1993 04:33:43 MST Date: 3 Jan 93 21:19:56 GMT From: agate!netsys!pagesat!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: parser generator, part 4 Message-Id: <1993Jan3.211956.28640@midway.uchicago.edu> References: <1993Jan3.211757.28395@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 ---- Cut Here and feed the following to sh ---- #!/bin/sh # this is ibpag.04 (part 4 of a multipart archive) # do not concatenate these parts, unpack them in order with /bin/sh # file itokens.icn continued # if test ! -r _shar_seq_.tmp; then echo 'Please unpack part 1 first!' exit 1 fi (read Scheck if test "$Scheck" != 4; then echo Please unpack part "$Scheck" next! exit 1 else exit 0 fi ) < _shar_seq_.tmp || exit 1 if test ! -f _shar_wnt_.tmp; then echo 'x - still skipping itokens.icn' else echo 'x - continuing file itokens.icn' sed 's/^X//' << 'SHAR_EOF' >> 'itokens.icn' && X# non-whitespace character, whitespace being defined as X# membership of a given character in the whitespace argument (a X# cset). X# Xprocedure do_whitespace(getchar, whitespace) X X# write(&errout, "it's junk") X while any(whitespace, next_c) do X next_c := @getchar X return X Xend X X X# X# do_identifier: coexpression x table -> TOK record X# (getchar, reserved_tbl) -> t X# X# Where getchar is the coexpression that pops off characters from X# the input stream, reserved_tbl is a table of reserved words X# (keys = the string values, values = the names qua symbols in X# the grammar), and t is a TOK record containing all subsequent X# letters, digits, or underscores after next_c (which must be a X# letter or underscore). Note that next_c is global and gets X# reset by do_identifier. X# Xprocedure do_identifier(getchar, reserved_tbl) X X local token X # global next_c X X# write(&errout, "it's an indentifier") X token := next_c X while any(&letters ++ &digits ++ '_', next_c := @getchar) X do token ||:= next_c X return TOK(\reserved_tbl[token], token) | TOK("IDENT", token) X Xend X X X# X# do_operator: coexpression x list -> TOK record X# getchar x operators -> t X# X# Where getchar is the coexpression that produces the next X# character on the input stream, and t is a TOK record X# describing the operator just scanned. Calls recognop, which X# creates a DFSA to recognize valid Icon operators. Arg2 X# (operators) is the list of lists containing valid Icon operator X# string values and names (see above). X# Xprocedure do_operator(getchar, operators) X X local token, elem X X token := next_c X X # Go until recognop fails. X while elem := recognop(operators, token, 1) do X token ||:= (next_c := @getchar) X# write(&errout, ximage(elem)) X if *\elem = 1 then X return TOK(elem[1][2], elem[1][1]) X else fail X Xend X X Xrecord dfstn_state(b, e, tbl) Xrecord start_state(b, e, tbl, master_list) X# X# recognop: list x string x integer -> list X# (l, s, i) -> l2 X# X# Where l is the list of lists created by the calling procedure X# (each element contains a token string value, name, and X# beginner/ender string), where s is a string possibly X# corresponding to a token in the list, where i is the position X# in the elements of l where the operator string values are X# recorded, and where l2 is a list of elements from l that X# contain operators for which string s is an exact match. X# Fails if there are no operators that s is a prefix of, but X# returns an empty list if there just aren't any that happen to X# match exactly. X# X# What this does is let the calling procedure just keep adding X# characters to s until recognop fails, then check the last list X# it returned to see if it is of length 1. If it is, then it X# contains list with the vital stats for the operator last X# recognized. If it is of length 0, then string s did not X# contain any recognizable operator. X# Xprocedure recognop(l, s, i) X X local current_state, master_list, c, result, j X static dfstn_table X initial dfstn_table := table() X X /i := 1 X # See if we've created an automaton for l already. X /dfstn_table[l] := start_state(1, *l, &null, &null) & { X dfstn_table[l].master_list := sortf(l, i) X } X X current_state := dfstn_table[l] X # Save master_list, as current_state will change later on. X master_list := current_state.master_list X X s ? { X while c := move(1) do { X X # Null means that this part of the automaton isn't X # complete. X # X if /current_state.tbl then X create_arcs(master_list, i, current_state, &pos) X X # If the table has been clobbered, then there are no arcs X # leading out of the current state. Fail. X # X if current_state.tbl === 0 then X fail X X# write(&errout, "c = ", image(c)) X# write(&errout, "table for current state = ", X# ximage(current_state.tbl)) X X # If we get to here, the current state has arcs leading X # out of it. See if c is one of them. If so, make the X # node to which arc c is connected the current state. X # Otherwise fail. X # X current_state := \current_state.tbl[c] | fail X } X } X X # Return possible completions. X # X result := list() X every j := current_state.b to current_state.e do { X if *master_list[j][i] = *s then X put(result, master_list[j]) X } X # return empty list if nothing the right length is found X return result X Xend X X X# X# create_arcs: fill out a table of arcs leading out of the current X# state, and place that table in the tbl field for X# current_state X# Xprocedure create_arcs(master_list, field, current_state, POS) X X local elem, i, first_char, old_first_char X X current_state.tbl := table() X old_first_char := "" X X every elem := master_list[i := current_state.b to current_state.e][field] X do { X X # Get the first character for the current position (note that X # we're one character behind the calling routine; hence X # POS-1). X # X first_char := elem[POS-1] | next X X # If we have a new first character, create a new arc out of X # the current state. X # X if first_char ~== old_first_char then { X # Store the start position for the current character. X current_state.tbl[first_char] := dfstn_state(i) X # Store the end position for the old character. X (\current_state.tbl[old_first_char]).e := i-1 X old_first_char := first_char X } X } X (\current_state.tbl[old_first_char]).e := i X X # Clobber table with 0 if no arcs were added. X current_state.tbl := (*current_state.tbl = 0) X return current_state X Xend SHAR_EOF echo 'File itokens.icn is complete' && true || echo 'restore of itokens.icn failed' rm -f _shar_wnt_.tmp fi # ============= debugme.icn ============== if test -f 'debugme.icn' -a X"$1" != X"-c"; then echo 'x - skipping debugme.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting debugme.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'debugme.icn' && Xlink structs X X# X# dump_lists: file x list x list -> (null) X# (f, gl, al) -> (null) X# X# Where f is an open file, gl is the goto list, and al is the X# action list. Writes to file f a human-readable dump of the goto X# and action list. X# Xprocedure dump_lists(f, al, gl) X X local TAB, look_list, red_list, i, sym, act X X TAB := "\t" X look_list := list() X red_list := list() X X every i := 1 to *al do { X every INSERT(look_list, key(\al[i])) X if /al[i] then X write(&errout, "dump_lists: warning! state ", i, " is null") X } X X writes(f, TAB) X every i := 1 to *look_list do X writes(f, look_list[i], TAB) X write(f) X every i := 1 to *al do { X writes(f, i, TAB) X act := "" X every sym := !look_list do { X if \al[i][sym] then { X # al[i][sym][1] will fail for the accept action; hence X # the "". Otherwise al[i][sym][1] selects that state X # field of a SH or RE record. X writes(f, map(type(al[i][sym])), al[i][sym][1] | "") X if type(al[i][sym]) == "RE" then { X INSERT(red_list, al[i][sym].sym) X writes(f, al[i][sym].sym) X } X } X writes(f,TAB) X } X write(f) X } X write(f) X X writes(f, TAB) X every i := 1 to *red_list do X writes(f, red_list[i], TAB) X write(f) X every i := 1 to *gl do { X writes(f, i, TAB) X act := "" X every sym := !red_list do { X if \(\gl[i])[sym] then X writes(f, gl[i][sym]) X writes(f, TAB) X } X write(f) X } X Xend X X# X# INSERT: set or list x record -> set or list X# (sset, rec) -> sset X# X# Where sset is a homogenous set or list of records, rec is a X# record, and the return value is sset, with rec added, iff an X# equivalent record was not there already. Otherwise, sset is X# returned unchanged. INSERT(), _unlike insert(), FAILS IF REC X# IS ALREADY PRESENT IN SSET. X# X# This procedure is used by dump_lists() above. If you delete X# dump_lists(), delete this as well, as also Equiv() below. X# Xprocedure INSERT(sset, rec) X X local addto, Eq X # X # Decide how to add members to sset, depending on its type. X # X case type(sset) of { X "set" : { addto := insert; Eq := equiv } X "list" : { addto := put; Eq := Equiv } X default : stop("INSERT: wrong type argument (",type(sset),")") X } X X # Rudumentary error check to be sure the object to be inserted X # into sset is of the same time as the objects already there. X # X if *sset > 0 then X type(rec) == type(sset[1]) | X stop("INSERT: unexpected type difference") X X # X # If a rec-like item isn't in sset, add it to sset. X # X if Eq(!sset, rec) then fail X else return addto(sset, rec) X Xend X X X# X# Equiv: struct x struct -> struct X# (x1, x2) -> x2 X# X# Where x1 and x2 are arbitrary structures. Returns x2 if x1 and X# x2 are structurally equivalent (even if not identical). Taken X# from the IPL file "structs.icn," and gutted so that it assumes X# all structures are "ordered" (i.e. not sets or tables). Has no X# way of handling procedures or files, either. (Pretty limited, X# huh?) X# Xprocedure Equiv(x1, x2, done) X X local code, i X X if x1 === x2 then return x2 # Covers everything but structures. X if type(x1) ~== type(x2) then fail # Must be same type. X if *x1 ~= *x2 then fail X X image(x1) ? (code := (="record" | type(x1))) X case code of { X "list" | "record" : X every i := *x1 to 1 by -1 do X Equiv(x1[i],x2[i]) | fail X "set" | "table" : stop("error: Equiv used (wrongly) for equiv.") X "procedure" | "file" : stop("error: Equiv used (wrongly) for equiv.") X default : fail X } X return x2 X Xend SHAR_EOF true || echo 'restore of debugme.icn failed' rm -f _shar_wnt_.tmp fi # ============= errors.icn ============== if test -f 'errors.icn' -a X"$1" != X"-c"; then echo 'x - skipping errors.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting errors.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'errors.icn' && X# X# oh_no: print error message to stderr & abort X# Xprocedure oh_no(s, n) X X local i, msg X static errlist X initial { X errlist := [[1, "malformed LHS"], X [2, "unexpected termination of right-hand side"], X [3, "missing left parenthesis"], X [4, "malformed start_symbol declaration"], X [5, "unexpected end of input"], X [6, "invalid symbol spec in right-hand side"], X [7, "rule declaration within another rule"], X [8, "procedure declaration within a rule"], X [9, "unmatched left parenthesis"], X [10, "mangled right-hand side"], X [11, "missing priority"], X [12, "missing associativity"], X X [50, "illegal conflict for nonassociative rules"], X [51, "reduce/reduce conflict"], X [52, "symbol lacks termination in the grammar"] X ] X } X every i := 1 to *errlist do X if errlist[i][1] = n then msg := errlist[i][2] X writes(&errout, "error ", n, " (", msg, ")") X if \s then { X write(&errout, ": ") X every write("\t", rewrap(s) | rewrap()) X } X else write(&errout, "") X exit(n) X Xend SHAR_EOF true || echo 'restore of errors.icn failed' rm -f _shar_wnt_.tmp fi # ============= slashupto.icn ============== if test -f 'slashupto.icn' -a X"$1" != X"-c"; then echo 'x - skipping slashupto.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting slashupto.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'slashupto.icn' && X############################################################################ X# X# Name: slashupto.icn X# X# Title: slashupto (upto with backslash escaping) X# X# Author: Richard L. Goerwitz X# X# Version: 1.2 X# X############################################################################ X# X# Slashupto works just like upto, except that it ignores backslash X# escaped characters. I can't even begin to express how often I've X# run into problems applying Icon's string scanning facilities to X# to input that uses backslash escaping. Normally, I tokenize first, X# and then work with lists. With slashupto() I can now postpone or X# even eliminate the traditional tokenizing step, and let Icon's X# string scanning facilities to more of the work. X# X# If you're confused: X# X# Typically UNIX utilities (and probably others) use backslashes to X# "escape" (i.e. remove the special meaning of) metacharacters. For X# instance, UNIX shells normally accept "*" as a shorthand for "any X# series of zero or more characters. You can make the "*" a literal X# "*," with no special meaning, by prepending a backslash. The rou- X# tine slashupto() understands these backslashing conventions. You X# can use it to find the "*" and other special characters because it X# will ignore "escaped" characters. X# X############################################################################ X# X# Links: none X# X# See also: slashbal.icn X# X############################################################################ X X# X# slashupto: cset x string x integer x integer -> integers X# (c, s, i, j) -> Is (a generator) X# where Is are the integer positions in s[i:j] before characters X# in c that is not preceded by a backslash escape X# Xprocedure slashupto(c, s, i, j) X X if /s := &subject X then /i := &pos X else /i := 1 X /j := *s + 1 X X /c := &cset X c ++:= '\\' X s[1:j] ? { X tab(i) X while tab(upto(c)) do { X if ="\\" then { X move(1) X next X } X suspend .&pos X move(1) X } X } X Xend X SHAR_EOF true || echo 'restore of slashupto.icn failed' rm -f _shar_wnt_.tmp fi # ============= rewrap.icn ============== if test -f 'rewrap.icn' -a X"$1" != X"-c"; then echo 'x - skipping rewrap.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting rewrap.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'rewrap.icn' && X############################################################################ X# X# Name: rewrap.icn X# X# Title: advanced line rewrap utility X# X# Author: Richard L. Goerwitz X# X# Version: 1.4 X# X############################################################################ X# X# The procedure rewrap(s,i), included in this file, reformats text X# fed to it into strings < i in length. Rewrap utilizes a static X# buffer, so it can be called repeatedly with different s arguments, X# and still produce homogenous output. This buffer is flushed by X# calling rewrap with a null first argument. The default for X# argument 2 (i) is 70. X# X# Here's a simple example of how rewrap could be used. The following X# program reads the standard input, producing fully rewrapped output. X# X# procedure main() X# every write(rewrap(!&input)) X# write(rewrap()) X# end X# X# Naturally, in practice you would want to do things like check for in- X# dentation or blank lines in order to wrap only on a paragraph-by para- X# graph basis, as in X# X# procedure main() X# while line := read(&input) do { X# if line == "" then { X# write("" ~== rewrap()) X# write(line) X# } else { X# if match("\t", line) then { X# write(rewrap()) X# write(rewrap(line)) X# } else { X# write(rewrap(line)) X# } X# } X# } X# end X# X# Fill-prefixes can be implemented simply by prepending them to the X# output of rewrap: X# X# i := 70; fill_prefix := " > " X# while line := read(input_file) do { X# line ?:= (f_bit := tab(many('> ')) | "", tab(0)) X# write(fill_prefix || f_bit || rewrap(line, i - *fill_prefix)) X# etc. X# X# Obviously, these examples are fairly simplistic. Putting them to X# actual use would certainly require a few environment-specific X# modifications and/or extensions. Still, I hope they offer some X# indication of the kinds of applications rewrap might be used in. X# X# Note: If you want leading and trailing tabs removed, map them to X# spaces first. Rewrap only fools with spaces, leaving tabs intact. X# This can be changed easily enough, by running its input through the X# Icon detab() function. X# X############################################################################ X# X# See also: wrap.icn X# X############################################################################ X X Xprocedure rewrap(s,i) X X local extra_bit, line X static old_line X initial old_line := "" X X # Default column to wrap on is 70. X /i := 70 X # Flush buffer on null first argument. X if /s then { X extra_bit := old_line X old_line := "" X return "" ~== extra_bit X } X X # Prepend to s anything that is in the buffer (leftovers from the last s). X s ?:= { tab(many(' ')); old_line || trim(tab(0)) } X X # If the line isn't long enough, just add everything to old_line. X if *s < i then old_line := s || " " & fail X X s ? { X X # While it is possible to find places to break s, do so. X while any(' -',line := EndToFront(i),-1) do { X # Clean up and suspend the last piece of s tabbed over. X line ?:= (tab(many(' ')), trim(tab(0))) X if *&subject - &pos + *line > i X then suspend line X else { X old_line := "" X return line || tab(0) X } X } X X # Keep the extra section of s in a buffer. X old_line := tab(0) X X # If the reason the remaining section of s was unrewrapable was X # that it was too long, and couldn't be broken up, then just return X # the thing as-is. X if *old_line > i then { X old_line ? { X if extra_bit := tab(upto(' -')+1) || (tab(many(' ')) | "") X then old_line := tab(0) X else extra_bit := old_line & old_line := "" X return trim(extra_bit) X } X } X # Otherwise, clean up the buffer for prepending to the next s. X else { X # If old_line is blank, then don't mess with it. Otherwise, X # add whatever is needed in order to link it with the next s. X if old_line ~== "" then { X # If old_line ends in a dash, then there's no need to add a X # space to it. X if old_line[-1] ~== "-" X then old_line ||:= " " X } X } X } X Xend X X X Xprocedure EndToFront(i) X # Goes with rewrap(s,i) X *&subject+1 - &pos >= i | fail X suspend &subject[.&pos:&pos <- &pos+i to &pos by -1] Xend SHAR_EOF true || echo 'restore of rewrap.icn failed' rm -f _shar_wnt_.tmp fi # ============= strip.icn ============== if test -f 'strip.icn' -a X"$1" != X"-c"; then echo 'x - skipping strip.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting strip.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'strip.icn' && X############################################################################ X# X# Name: strip.icn X# X# Title: strip characters from a string X# X# Author: Richard L. Goerwitz X# X# Version: 1.1 X# X############################################################################ X# X# strip(s,c) - strip characters c from string s X# X############################################################################ X# X# Links: none X# X############################################################################ X X Xprocedure strip(s,c) X X # Return string s stripped of characters c. Succeed whether X # any characters c were found in s or not. X X local s2 X X s2 := "" X s ? { X while s2 ||:= tab(upto(c)) X do tab(many(c)) X s2 ||:= tab(0) X } X X return s2 X Xend SHAR_EOF true || echo 'restore of strip.icn failed' rm -f _shar_wnt_.tmp fi # ============= Makefile.dist ============== if test -f 'Makefile.dist' -a X"$1" != X"-c"; then echo 'x - skipping Makefile.dist (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting Makefile.dist (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.dist' && X############################################################################ X# X# Name: %M% X# X# Title: public makefile for IBPAG X# X# Author: Richard L. Goerwitz X# X# Version: %I% X# X############################################################################ X X# X# Change this only if you have some bizzarre naming conflict (which is X# very unlikely, given the quirky name!). X# XPROGNAME = ibpag X X X########################################################################## X# X# User-modifiable section. Read carefully! You will almost X# certainly have to change some settings here. X# X X# X# Destination directory for binaries. Owner and group for public X# executables. Leave the trailing slash off of directory name. X# X# DESTDIR = $(HOME)/bin XDESTDIR = /usr/local/bin X# OWNER = me XOWNER = root X# GROUP = my_group XGROUP = root X X# X# Name of your icon compiler and compiler flags. X# XICONC = /usr/icon/v8/bin/icont X# ICONC = /usr/icon/v8/bin/iconc X X# X# If you get messages like "out of X table space," then you have X# version 8.0 or less of the interpreter, and will need to adjust the X# various internal tables manually with -S arguments. See the icont X# documentation. Otherwise, no flags are strictly necessary. X# XIFLAGS = -u X X# X# Change these only if you're pretty sure of what you're doing. X# XSHELL = /bin/sh XMAKE = make X X X########################################################################### X# X# Don't change anything below this line. X# X XSRC = $(PROGNAME).icn maketbls.icn preproc.icn itokens.icn debugme.icn \ X errors.icn slashupto.icn rewrap.icn strip.icn X X# X# Main target X# Xall: $(PROGNAME) X X$(PROGNAME): $(SRC) X $(ICONC) $(IFLAGS) -o $(PROGNAME) $(SRC) X X# X# Cleanup X# Xclean: X rm -f core *.u1 *.u2 X Xclobber: clean X -rm -f $(PROGNAME) *~ SHAR_EOF true || echo 'restore of Makefile.dist failed' rm -f _shar_wnt_.tmp fi rm -f _shar_seq_.tmp echo You have unpacked the last part exit 0 -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Jan 3 21:18:44 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Jan 1993 04:33:54 MST Date: 3 Jan 93 21:18:44 GMT From: agate!netsys!pagesat!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: parser generator, part 2 Message-Id: <1993Jan3.211844.28467@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 ---- Cut Here and feed the following to sh ---- #!/bin/sh # this is ibpag.02 (part 2 of a multipart archive) # do not concatenate these parts, unpack them in order with /bin/sh # file ibpag.icn continued # if test ! -r _shar_seq_.tmp; then echo 'Please unpack part 1 first!' exit 1 fi (read Scheck if test "$Scheck" != 2; then echo Please unpack part "$Scheck" next! exit 1 else exit 0 fi ) < _shar_seq_.tmp || exit 1 if test ! -f _shar_wnt_.tmp; then echo 'x - still skipping ibpag.icn' else echo 'x - continuing file ibpag.icn' sed 's/^X//' << 'SHAR_EOF' >> 'ibpag.icn' && X write(f2, "\t\t # be in, and push that state onto the state stack.") X write(f2, "\t\t #") X write(f2, "\t\t push(state_stack,") X write(f2, "\t\t\t glst[state_stack[1]][act.sym])") X write(f2, "\t\t #") X write(f2, "\t\t # Call the code associated with the current") X write(f2, "\t\t # reduction, and push the result onto the stack.") X write(f2, "\t\t # For more results, push a coexpression instead.") X write(f2, "\t\t #") X write(f2, "\t\t push(value_stack, (proc(act.procname)!arglist)) | {") X write(f2, "\t\t\t# On failure, return the stacks to the state") X write(f2, "\t\t\t# they were just after the last reduction (i.e.") X write(f2, "\t\t\t# before any tokens for the current production") X write(f2, "\t\t\t# were pushed onto the stack).") X write(f2, "\t\t\tpop(state_stack)") X write(f2, "\t\t\treturn iparse_error(alst, state_stack, value_stack,") X write(f2, "\t\t\t\t\t token, next_token, err_state + 1)") X write(f2, "\t\t }") X write(f2, "\t\t}") X write(f2, "\t\t\"AC\" : {") X write(f2, "\t\t #") X write(f2, "\t\t # We're done. Return the last result.") X write(f2, "\t\t #") X write(f2, "\t\t return value_stack[1]") X write(f2, "\t }") X write(f2, "\t }") X write(f2, "\t}") X write(f2, " }") X write(f2, " write(&errout, \"iparse: unexpected end of input\")") X write(f2, " fail") X write(f2, "") X write(f2, "end") X write(f2, "") X write(f2, "") X write(f2, "#") X write(f2, "# iparse_error: list x list x list x TOK x coexpression x integer -> ?") X write(f2, "# (alst, state_stack, value_stack, token,") X write(f2, "#\t\t\t next_token, err_state) -> ?") X write(f2, "#") X write(f2, "# Where alst is the action list, where state_stack is the state") X write(f2, "# stack used by iparse, where value stack is the value stack used") X write(f2, "# by iparse, where token is the current lookahead TOK record,") X write(f2, "# where next_token is the coexpression from which we get our") X write(f2, "# tokens, and where err_state indicates how many recursive calls") X write(f2, "# we've made to the parser via the error handler without a") X write(f2, "# recovery.") X write(f2, "#") X write(f2, "# Recursively calls iparse, attempting to restart the parser after") X write(f2, "# an error. Increments global \"errors\" variable (a count of the") X write(f2, "# number of errors encountered, minus cascading series of errors).") X write(f2, "#") X write(f2, "procedure iparse_error(alst, state_stack, value_stack,") X write(f2, "\t\t token, next_token, err_state)") X write(f2, "") X write(f2, " local sym, i, state_stack2, value_stack2, next_token2") X write(f2, " static tlst") X write(f2, " #global line_number, errors") X write(f2, " initial {") X every lname := "tlst" do { X encode(variable(lname)) ? { X writes(f2, "\t", lname, " := decode(\"") X if write(f2, move(47), "_") then { X while write(f2, "\t ",move(60), "_") X write(f2, "\t ", tab(0), "\")") X } X else write(f2, tab(0), "\")") X } X } X write(f2, " }") X write(f2, "") X write(f2, " #") X write(f2, " # Check to see how many attempts we have made at a resync. If") X write(f2, " # this is a new error series, increment the global \"errors\" count.") X write(f2, " #") X write(f2, " if err_state > 3 then {") X write(f2, "\tif \\fail_on_error then fail") X write(f2, "\telse stop(\"iparse_error: unable to resync after error; aborting\")") X write(f2, " }") X write(f2, " if err_state = 1 then") X write(f2, "\terrors +:= 1\t\t# errors is global") X write(f2, "") X write(f2, " # If \"error\" is in tlst, then there are error productions in the") X write(f2, " # grammar. See if we can back into one from here. Don't try this") X write(f2, " # for error states greater than 1. Otherwise we'll get a") X write(f2, " # cascading series of stack truncations.") X write(f2, " #") X write(f2, " if err_state = 1 then {") X write(f2, "\tif member(tlst, \"error\") then {") X write(f2, "\t every i := 1 to 2 do {") X write(f2, "\t\tif \\alst[state_stack[i]][\"error\"] then {") X write(f2, "\t\t state_stack2 := state_stack[i:0] | break") X write(f2, "\t\t value_stack2 := value_stack[i:0]") X write(f2, "\t\t next_token2 := create TOK(\"error\") | token | |@next_token") X write(f2, "\t\t return iparse(&null, state_stack2, value_stack2,") X write(f2, "\t\t\t\t next_token2, err_state)") X write(f2, "\t\t}") X write(f2, "\t }") X write(f2, "\t}") X write(f2, " }") X write(f2, "") X write(f2, " if \\fail_on_error then fail") X write(f2, " #") X write(f2, " # Check to see if the grammar even has this pre-terminal.") X write(f2, " #") X write(f2, " if not member(tlst, token.sym) then {") X write(f2, "\twrites(&errout, \"iparse_error: unknown token, \", token.sym)") X write(f2, "\twrite(\", in line \", 0 < \\line_number) | write()") X write(f2, " }") X write(f2, " # Only note the first in a series of cascading errors.") X write(f2, " else if err_state = 1 then {") X write(f2, "\twrites(&errout, \"iparse_error: syntax error\")") X write(f2, "\twrite(\" line \", 0 < \\line_number) | write()") X write(f2, " }") X write(f2, "") X write(f2, " #") X write(f2, " # Now, try to shift in the next input token to see if we can") X write(f2, " # resync the parser. Stream argument is null because next_token") X write(f2, " # has already been created.") X write(f2, " #") X write(f2, " return iparse(&null, state_stack, value_stack, next_token, err_state)") X write(f2, "") X write(f2, "end") X write(f2, "link structs") X write(f2, "") X write(f2, "#") X write(f2, "# dump_lists: file x list x list -> (null)") X write(f2, "# (f, gl, al) -> (null)") X write(f2, "#") X write(f2, "# Where f is an open file, gl is the goto list, and al is the") X write(f2, "# action list. Writes to file f a human-readable dump of the goto") X write(f2, "# and action list.") X write(f2, "#") X write(f2, "procedure dump_lists(f, al, gl)") X write(f2, "") X write(f2, " local TAB, look_list, red_list, i, sym, act") X write(f2, "") X write(f2, " TAB := \"\\t\"") X write(f2, " look_list := list()") X write(f2, " red_list := list()") X write(f2, "") X write(f2, " every i := 1 to *al do {") X write(f2, "\tevery INSERT(look_list, key(\\al[i]))") X write(f2, "\tif /al[i] then") X write(f2, "\t write(&errout, \"dump_lists: warning! state \", i, \" is null\")") X write(f2, " }") X write(f2, "") X write(f2, " writes(f, TAB)") X write(f2, " every i := 1 to *look_list do") X write(f2, "\twrites(f, look_list[i], TAB)") X write(f2, " write(f)") X write(f2, " every i := 1 to *al do {") X write(f2, "\twrites(f, i, TAB)") X write(f2, "\tact := \"\"") X write(f2, "\tevery sym := !look_list do {") X write(f2, "\t if \\al[i][sym] then {") X write(f2, "\t\t# al[i][sym][1] will fail for the accept action; hence") X write(f2, "\t\t# the \"\". Otherwise al[i][sym][1] selects that state") X write(f2, "\t\t# field of a SH or RE record.") X write(f2, "\t\twrites(f, map(type(al[i][sym])), al[i][sym][1] | \"\")") X write(f2, "\t\tif type(al[i][sym]) == \"RE\" then {") X write(f2, "\t\t INSERT(red_list, al[i][sym].sym)") X write(f2, "\t\t writes(f, al[i][sym].sym)") X write(f2, "\t\t}") X write(f2, "\t }") X write(f2, "\t writes(f,TAB)") X write(f2, "\t}") X write(f2, "\twrite(f)") X write(f2, " }") X write(f2, " write(f)") X write(f2, "") X write(f2, " writes(f, TAB)") X write(f2, " every i := 1 to *red_list do") X write(f2, "\twrites(f, red_list[i], TAB)") X write(f2, " write(f)") X write(f2, " every i := 1 to *gl do {") X write(f2, "\twrites(f, i, TAB)") X write(f2, "\tact := \"\"") X write(f2, "\tevery sym := !red_list do {") X write(f2, "\t if \\(\\gl[i])[sym] then") X write(f2, "\t\twrites(f, gl[i][sym])") X write(f2, "\t writes(f, TAB)") X write(f2, "\t}") X write(f2, "\twrite(f)") X write(f2, " }") X write(f2, "") X write(f2, "end") X write(f2, "") X write(f2, "#") X write(f2, "# INSERT: set or list x record -> set or list") X write(f2, "# \t (sset, rec) -> sset") X write(f2, "#") X write(f2, "# Where sset is a homogenous set or list of records, rec is a") X write(f2, "# record, and the return value is sset, with rec added, iff an") X write(f2, "# equivalent record was not there already. Otherwise, sset is") X write(f2, "# returned unchanged. INSERT(), _unlike insert(), FAILS IF REC") X write(f2, "# IS ALREADY PRESENT IN SSET.") X write(f2, "#") X write(f2, "# This procedure is used by dump_lists() above. If you delete") X write(f2, "# dump_lists(), delete this as well, as also Equiv() below.") X write(f2, "#") X write(f2, "procedure INSERT(sset, rec)") X write(f2, "") X write(f2, " local addto, Eq") X write(f2, " #") X write(f2, " # Decide how to add members to sset, depending on its type.") X write(f2, " #") X write(f2, "\tcase type(sset) of {") X write(f2, "\t \"set\" : { addto := insert; Eq := equiv }") X write(f2, "\t \"list\" : { addto := put; Eq := Equiv }") X write(f2, "\t default : stop(\"INSERT: wrong type argument (\",type(sset),\")\")") X write(f2, "\t}") X write(f2, "") X write(f2, " # Rudumentary error check to be sure the object to be inserted") X write(f2, " # into sset is of the same time as the objects already there.") X write(f2, " #") X write(f2, " if *sset > 0 then") X write(f2, "\ttype(rec) == type(sset[1]) |") X write(f2, "\t stop(\"INSERT: unexpected type difference\")") X write(f2, "") X write(f2, " #") X write(f2, " # If a rec-like item isn't in sset, add it to sset.") X write(f2, " #") X write(f2, " if Eq(!sset, rec) then fail") X write(f2, " else return addto(sset, rec)") X write(f2, "") X write(f2, "end") X write(f2, "\t") X write(f2, "") X write(f2, "#") X write(f2, "# Equiv: struct x struct -> struct") X write(f2, "# (x1, x2) -> x2") X write(f2, "#") X write(f2, "# Where x1 and x2 are arbitrary structures. Returns x2 if x1 and") X write(f2, "# x2 are structurally equivalent (even if not identical). Taken") X write(f2, "# from the IPL file \"structs.icn,\" and gutted so that it assumes") X write(f2, "# all structures are \"ordered\" (i.e. not sets or tables). Has no") X write(f2, "# way of handling procedures or files, either. (Pretty limited,") X write(f2, "# huh?)") X write(f2, "#") X write(f2, "procedure Equiv(x1, x2, done)") X write(f2, "") X write(f2, " local code, i") X write(f2, "") X write(f2, " if x1 === x2 then return x2\t\t# Covers everything but structures.") X write(f2, " if type(x1) ~== type(x2) then fail\t# Must be same type.") X write(f2, " if *x1 ~= *x2 then fail") X write(f2, "") X write(f2, " image(x1) ? (code := (=\"record\" | type(x1)))") X write(f2, " case code of {") X write(f2, " \"list\" | \"record\" :") X write(f2, "\t every i := *x1 to 1 by -1 do") X write(f2, "\t Equiv(x1[i],x2[i]) | fail") X write(f2, " \"set\" | \"table\" : stop(\"error: Equiv used (wrongly) for equiv.\")") X write(f2, " \"procedure\" | \"file\" : stop(\"error: Equiv used (wrongly) for equiv.\")") X write(f2, " default : fail") X write(f2, " }") X write(f2, " return x2") X write(f2, "") X write(f2, "end") X X if \DEBUG then X dump_lists(&errout, alst, glst) X if \VERBOSE then X write(&errout, "Done.") X Xend SHAR_EOF echo 'File ibpag.icn is complete' && true || echo 'restore of ibpag.icn failed' rm -f _shar_wnt_.tmp fi # ============= maketbls.icn ============== if test -f 'maketbls.icn' -a X"$1" != X"-c"; then echo 'x - skipping maketbls.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting maketbls.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'maketbls.icn' && X############################################################################ X# X# Name: maketbls.icn X# X# Title: make (state & goto) tables for IBPAG X# X# Author: Richard L. Goerwitz X# X# Version: 1.27 X# X############################################################################ X# X# Given a table of productions (global, ptbl; see makeptbl.icn), X# CONST_TABLE (below) creates a state and goto table, which ibpag.icn X# then merges with the original source file. X# X############################################################################ X# X# Links: codeobj, rewrap X# X# See also: ibpag.icn, preproc.icn X# X############################################################################ X X# link codeobj, rewrap Xlink codeobj X Xrecord item(LHS, RHS, POS, LOOK, by_rule) Xrecord ACT(str, state, by_rule, POS, sym, size) X X# Declared in preproc.icn - X# record symbol(str, terminal) X# record rule(LHS, RHS, priority, associativity, procname) X X# start_symbol is set to "S" by default in CONST_STATES() Xglobal ptbl, alst, glst, start_symbol X# declared in ibpag.icn X# global DEBUG, VERBOSE X X# X# CONST_TABLE: -> (null) X# X# Operates entirely via side-effects. Alst will become the action X# list and glst will become the goto list. The action list is X# used to determine whether to shift, reduce, or accept; the goto X# list indicates what state to go to after a reduction. Their X# format, in general, is: Offset = state; value = table of X# directives. They are, in other words, lists of tables. X# Xprocedure CONST_TABLE() X X local C, i, j, l, it, act, next_state X static big_item X initial big_item := X item(start_symbol || "'", [symbol(start_symbol)], 2, "$", rule(,,1)) X X C := CONST_STATES() X alst := list(*C); every !alst := table() X glst := list(*C); every !glst := table() X X every l := C[i := 1 to *C] do { X if \VERBOSE then X write(&errout, "CONST_TABLE: entering actions for state ", i) X every it := !l do { X # If we have a complete production, enter a reduce action X # into the action list. A special sub-case of reduce is X # accept (which occurs when the state contains (S' -> S., X # $)). X if it.POS > *it.RHS then { X if Equiv(it, big_item) X then act := ACT("accept", &null, it.by_rule, it.POS) X else act := ACT("reduce", &null, it.by_rule, it.POS) X # Check to see if we have a conflict; if so, resolve. X if not (/alst[i][it.LOOK] := act) then X resolve(alst, act, it.LOOK, i) X } X else { X # If it's a terminal, see if GOTO_ITEMS for that X # symbol and the current state = another state; if so, X # enter shift + a jump to that state into the action X # list. X if \it.RHS[it.POS].terminal then { X next_state := GOTO_ITEMS(l, it.RHS[it.POS]) X if Equiv(next_state, C[j := 1 to *C]) then { X# C[j] := next_state X # create an action to enter into the action list X act := ACT("shift", j, it.by_rule, it.POS) X # If the table entry is occupied, resolve conflict. X if not (/alst[i][it.RHS[it.POS].str] := act) then X resolve(alst, act, it.RHS[it.POS].str, i) X } X } X } X } X } X X glst := list(*C) X # Do we ever get conflicts here? X every l := C[i := 1 to *C] do { X if \VERBOSE then X write(&errout, "CONST_TABLE: entering gotos for state ", i) X every it := !l do { X \it.RHS[it.POS].terminal & next X next_state := GOTO_ITEMS(l, it.RHS[it.POS]) X if Equiv(next_state, C[j := 1 to *C]) then { X# C[j] := next_state X # If the dot is at the end of the RHS, then we can't X # enter any goto for that state. There has to be a X # nonterminal after the dot. X if it.RHS[it.POS] then { X /glst[i] := table() X glst[i][it.RHS[it.POS].str] := j X } X } X } X } X X return X Xend X X X# X# resolve: resolve conflicts in action list X# X# Abort on reduce/reduce conflicts. There is no reason why these X# should be present in the grammar. Resolve shift/reduce X# conflicts in favor of a shift, in cases where the priorities are X# the same, unless the first rule is left associative (which X# implies a reduce). Shift/reduce conflicts for rules without an X# associativity are errors, and bring about termination of X# processing. X# Xprocedure resolve(l, act, subscr, i) X X if Equiv(l[i][subscr], act) X then fail X # Use the rule with the highest priority. X if l[i][subscr].by_rule.priority ~= act.by_rule.priority then { X if \VERBOSE then X show_conflict(act, l[i][subscr], subscr, i) X if l[i][subscr].by_rule.priority < act.by_rule.priority then { X l[i][subscr] := act X if \VERBOSE then X write(&errout, "first rule's precedence is higher") X } else { X if \VERBOSE then X write(&errout, "second rule's precedence is higher") X } X } X # precedences are the same; resolve via associativity and defaults X else { X # X # If the priorities are the same, then resolve the conflict or X # abort. X # X # Still to be done: Handle associativities. X # X case act.str of { X "shift" : { X if l[i][subscr].str == "reduce" then { X if \VERBOSE then { X show_conflict(act, l[i][subscr], subscr, i) X write(&errout, "first rule is ", X act.by_rule.associativity, " associative") X if act.by_rule.associativity ~== X l[i][subscr].by_rule.associativity X then write(&errout, "associativities differ!") X } X case act.by_rule.associativity of { X "none" : oh_no(&null, 50) X "left" : if \VERBOSE then X write(&errout, "resolving in favor of reduce") X "right": { X l[i][subscr] := act X if \VERBOSE then X write(&errout, "resolving in favor of shift") X } X } X } X # else do nothing - X # Shift-shift conflicts are not errors. A shift is a X # shift. X } X "reduce" : { X if l[i][subscr].str == "reduce" then { X # Flag reduce-reduce conflicts as errors for now. X # Yacc uses the first rule in the grammar. X show_conflict(act, l[i][subscr], subscr, i) X oh_no(&null, 51) X } X else { X if \VERBOSE then { X show_conflict(act, l[i][subscr], subscr, i) X write(&errout, "first rule is ", X act.by_rule.associativity, " associative") X if act.by_rule.associativity ~== X l[i][subscr].by_rule.associativity X then write(&errout, "associativities differ!") X } X case act.by_rule.associativity of { X "none" : oh_no(&null, 50) X "right": if \VERBOSE then X write(&errout, "resolving in favor of shift") X "left" : { X l[i][subscr] := act X if \VERBOSE then X write(&errout, "resolving in favor of reduce") X } X } X } X } X } X } X return X Xend X X X# X# CONST_STATES: -> list of lists X# -> C X# X# Where C is a list of lists containing item records. Each list X# in C represents a state. Uses the global table ptbl, which is X# of the form keys = LHS, values = lists of rule records. X# X# Calls itself recursively, and in this case takes one argument. X# On the first call introduces the production (S' -> .S, $), which X# is used as the first state in C from which the others are built. X# X# Argument two (i) is used for recursive calls and should be X# ignored. X# Xprocedure CONST_STATES(C, i) X X local C2, it, sym, item_list, next_items X # global ptbl, start_symbol X X # write(&errout, "CONST_STATES: performing closure on S'") X /C := [ CLOSURE([item(start_symbol || "'", X [symbol(start_symbol)], 1, "$", rule(,,1))]) ] X C2 := copy(C) X /i := 0 X X every item_list := C[i := i+1 to *C] do { X if \VERBOSE then X write(&errout, "CONST_STATES: examining item list #", i) X if \DEBUG then X write(&errout, item_list_2_string(C[i])) X next_items := list() X every it := !item_list do X INSERT(next_items, it.RHS[it.POS]) X every sym := !next_items do X INSERT(C2, GOTO_ITEMS(item_list, sym)) X } X if *C2 > *C X then return CONST_STATES(C2, i) X else return C X Xend X X X# X# FIRST(RHS): list of symbol records -> set X# (RHS) -> fset X# X# Where RHS is the remaining symbols in some item after the "dot," X# where fset is a set of strings representing terminals beginning X# sequences derivable from X. (A production is a statement in the X# grammar of the form LHS -> RHS, where LHS is a nonterminal X# symbol, and RHS is a sequence of zero or more terminal or X# nonterminal symbols; here productions are implemented via rule X# records.) If passed an empty RHS, FIRST returns another empty X# list. X# X# FIRST() uses the global grammar table ptbl. X# X# The structure of ptbl: key = LHS (string), value = rule list X# i.e. list of rule records). Keys are always nonterminals, as X# there is no need to record terminals (they appear only in the X# RHS of rules). X# Xprocedure FIRST(RHS, seen) X X local X, fset, i, check_later_list, chunk X #global ptbl X X # write(&errout, ximage(RHS)) X fset := set() X X every X := !RHS do { X X delete(fset, "") X X # If X is a terminal symbol, just stick it into fset. X if \X.terminal then X insert(fset, X.str) X else { X # X # X is not a terminal, check to see if X -> aA is a X # production (where a is a terminal, and A is any series X # of terminals, nonterminals, or nothing at all...). X # X /seen := set() X insert(seen, X.str) X check_later_list := [] X every i := 1 to *ptbl[X.str] do { X if \ptbl[X.str][i].RHS[1].terminal X then insert(fset, ptbl[X.str][i].RHS[1].str) X else { X if ptbl[X.str][i].RHS[1].str == X.str X then INSERT(check_later_list, ptbl[X.str][i]) X else { X member(seen, ptbl[X.str][i].RHS[1].str) & next X # X # For productions X -> Y1, Y2...Yn, where Y is a X # nonterminal, compute FIRST recursively for the X # list [Y1, Y2, ...]. If Y1 is equivalent to X, X # then store that rule so that if FIRST(X) X # otherwise contains an epsilon move, we can go X # back and calculate FIRST(Y2), and so on. X # Keep track of what nonterminals we've already X # seen, so as not to calculate any twice. X # X fset ++:= FIRST(ptbl[X.str][i].RHS, seen) X } X } X } X } X # X # If fset contains e at this point, go back and try again, X # then first try to compute FIRST() for elements 2 and later X # of productions in the check_later_list. Otherwise, try X # computing FIRST for the next symbol in RHS. If this fails, X # then resign ourselves to e belonging in fset. X # X if not member(fset, "") then break X else { X every i := 1 to *check_later_list do { X chunk := check_later_list[i].RHS[2:0] | next X while (/chunk[1].terminal, chunk[1].str == X.str) do X pop(chunk) | { break next } X fset ++:= FIRST(chunk, seen) X } X next X } X } X X # writes(&errout, "returning ") X # every writes(&errout, !fset, " ") X # write(&errout) X return fset X Xend X X X# X# CLOSURE: list -> list X# (item_list) -> closure_list X# X# Where item_list and closure_list are list of item records. X# CLOSURE uses ptbl (global, created via makeptbl). Ptbl is a X# table, keys = LHS, values = lists of rule records. CLOSURE X# uses two additional arguments on recursive calls. Don't use X# them yourself! X# X# CLOSURE breaks the items in item_list into smaller items, X# and combines these with the items already in item_list, re- X# turning a new list including both the members of item_list X# and the new members. X# Xprocedure CLOSURE(item_list, i, added) X X local it, terminals, terminal, tmpset, r, LHS X #global ptbl X X if \DEBUG then { X write(&errout, "CLOSURE: CLOSing item list") X write(&errout, item_list_2_string(item_list)) X } X X /i := 0 X /added := table() X every it := item_list[i := i+1 to *item_list] do { X X # write(&errout, "CLOSURE: performing closure on item ", i) X # X # Put the as-yet unexpanded parts of item_list can be expanded X # into new items, and add them to the full closure list. Keep X # track of LHSs we've already seen. Loops are possible! X # X # If the dot stands before a terminal, then go to the next X # item. X repeat { X if \it.RHS[it.POS].terminal then { X # X # If an epsilon move is next, then increment POS, and X # look at it again. If we leave the POS alone, then X # later a shift action will be entered into the action X # table for an epsilon token. Since there are no X # epsilon tokens, this will break our parse! X # X if it.RHS[it.POS].str == "" then { X it.POS +:= 1 X next X } else { break next } # don't expand nonterminals! X } else { X # X # If the "dot" is at the end of the RHS, it.RHS[it.POS] X # will fail. If it does fail, get the next it. If it X # succeeds, then just do a plain break and continue X # with the expansion process. X # X if LHS := it.RHS[it.POS].str X then break else { break next } X } X } X # If we get to here, the dot is at a nonterminal, so expand! X # Record LHSs we've alread seen. X /added[LHS] := set() X X # LHS is a string, RHS is a list of symbols; FIRST(X) returns X # a list of strings (no need to use symbols here, since we X # know everything in FIRST(X) is a terminal) X # X # write(ximage(ptbl)); write(ximage(LHS)); write(ximage(it)) X # X tmpset := set() X every r := !ptbl[LHS] do { X # Change perhaps to: if *it.RHS - it.POS = 0 then { X # i.e. if the dot's at the end of the RHS... X if *it.RHS[it.POS+1:0] = 0 then { X # X # Check to see if we've already done all the X # productions for the current LHS and the lookahead X # symbol being used. X # X member(added[LHS], it.LOOK) | { X put(item_list, item(LHS, r.RHS, 1, it.LOOK, r)) X # X # Keep track of lookahead symbols seen for this LHS. X insert(tmpset, it.LOOK) X } X } else { X terminals := FIRST(it.RHS[it.POS+1:0]) X if delete(terminals, member(terminals, "")) then { X member(added[LHS], it.LOOK) | { X put(item_list, item(LHS, r.RHS, 1, it.LOOK, r)) X insert(tmpset, it.LOOK) X } X } X every terminal := !terminals do { X member(added[LHS], terminal) | { X put(item_list, item(LHS, r.RHS, 1, terminal, r)) X insert(tmpset, terminal) X } X } X } X } X # X # Record all the lookahead symbols seen for this LHS. On X # subsequent recursive calls, we won't bother to redo work X # already done! Afterwards, loop back for another item. X # X added[LHS] ++:= tmpset X } X X if *item_list > i then { X if \DEBUG then X write(&errout, "CLOSURE: calling closure recursively") X return CLOSURE(item_list, i, added) X } else { X # write(&errout, "CLOSURE: finished recursive calls") X # X # Sortff sorts on field 5, then 4 (where the 5th field is the X # same), then 3. It can take any no. of args. We only need X # 3, though. The sort order ensures that any time we perform X # a closure on an item list, that item list will have a X # consistent order. This makes it possible to check whether a X # given item list already exists using Equiv. X return sortff(item_list, 5, 4, 3) X } X Xend X X X# X# GOTO_ITEMS: list x symbol record -> list X# (item_list, X) -> item_list_2 X# X# Where item_list_2 is the list of all items (A -> aX.b) where X X# is a symbol, such that (A -> a.Xb) is in item_list. Fails if X# item.POS for every item in item_list is greater than *item.RHS; X# fails also if X is not equivalent to any item.RHS[item.POS] in X# item_list. X# Xprocedure GOTO_ITEMS(item_list, X) X X local it, it2, item_list_2 X static item_terminal_table, item_nonterminal_table X initial { X item_terminal_table := table() X item_nonterminal_table := table() X } X X # See if we've already performed this same calculation. X # X if \X.terminal X then item_list_2 := \(\item_terminal_table[item_list])[X.str] X else item_list_2 := \(\item_nonterminal_table[item_list])[X.str] X if \item_list_2 then return item_list_2 X X item_list_2 := list() X every it := !item_list do { X # Subscripting operation fails if the dot's at end. X if Equiv(it.RHS[it.POS], X) X then { X it2 := copy(it) X it2.POS +:= 1 X put(item_list_2, it2) X } X } X X item_list_2 := CLOSURE(item_list_2) X # X # Keep track of item lists and symbols we've already seen. X # X if \X.terminal then { X /item_terminal_table[item_list] := table() X /item_terminal_table[item_list][X.str] := item_list_2 X } else { X /item_nonterminal_table[item_list] := table() X /item_nonterminal_table[item_list][X.str] := item_list_2 X } X X if *item_list_2 > 0 then X return item_list_2 X else fail X Xend X X X# X# item_list_2_string: item list -> string X# X# Turn an item list into a human readable list of items, indented X# four spaces from the left-hand margin. X# Xprocedure item_list_2_string(l) X X local s X X # Make sure we have the expected type entries in l. X type(l[1]) == "item" | X stop("error (item_list_2_string): wrong type list") X X s := "" X every s ||:= " " || rule_2_string(!l) || "\n" X return trim(s, '\n') X Xend X X X# X# rule_2_string: item or rule record -> string X# X# Utility for making item and rule records human-readable. X# Xprocedure rule_2_string(r, action) X X local r_string, sym X X if r_string := \r.LHS || " ::= " then { X every sym := !r.RHS do { X if \sym.terminal X then r_string ||:= sym.str || " " X else r_string ||:= "<" || sym.str || "> " X } X } X # Accept action has no left or right-hand side. X else r_string := "(accept) " X X if type(r) == "item" X then r_string ||:= "POS "|| r.POS || "; lookahead " || r.LOOK X else if \action X then r_string ||:= "POS "|| action.POS || " (action = "|| action.str || ")" X X return trim(r_string) X Xend X X X# X# show_conflict: deep psychological thriller X# Xprocedure show_conflict(action1, action2, token, i) X X write(&errout, "shift/reduce conflict, state ", i, X ", lookahead ", token, ":") X # action parameters may be null X write(&errout, "\t1: ", rule_2_string(action1.by_rule, action1)) X write(&errout, "\t2: ", rule_2_string(action2.by_rule, action2)) X Xend X X X# X# sortff: like sortf() except takes unlimited no. of field args X# Xprocedure sortff(arglst[]) X X local sortfield, i, old_i SHAR_EOF true || echo 'restore of maketbls.icn failed' fi echo 'End of part 2' echo 'File maketbls.icn is continued in part 3' echo 3 > _shar_seq_.tmp exit 0 -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Jan 3 21:19:20 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Jan 1993 04:34:01 MST Date: 3 Jan 93 21:19:20 GMT From: agate!netsys!pagesat!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: parser generator, part 3 Message-Id: <1993Jan3.211920.28528@midway.uchicago.edu> References: <1993Jan3.211757.28395@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 ---- Cut Here and feed the following to sh ---- #!/bin/sh # this is ibpag.03 (part 3 of a multipart archive) # do not concatenate these parts, unpack them in order with /bin/sh # file maketbls.icn continued # if test ! -r _shar_seq_.tmp; then echo 'Please unpack part 1 first!' exit 1 fi (read Scheck if test "$Scheck" != 3; then echo Please unpack part "$Scheck" next! exit 1 else exit 0 fi ) < _shar_seq_.tmp || exit 1 if test ! -f _shar_wnt_.tmp; then echo 'x - still skipping maketbls.icn' else echo 'x - continuing file maketbls.icn' sed 's/^X//' << 'SHAR_EOF' >> 'maketbls.icn' && X X *arglst[1] <= 1 | *arglst = 1 & { return arglst[1] } X sortfield := arglst[2] | { return sortf(arglst[1]) } X arglst[1] := sortf(arglst[1], sortfield) X X old_i := 1 X every i := old_i+1 to *arglst[1] do { X if not (arglst[1][old_i][sortfield] === arglst[1][i][sortfield]) X then { X return sortff!(push(arglst[3:0], arglst[1][old_i : i])) ||| X sortff!(push(arglst[2:0], arglst[1][i : 0])) X } X } X return sortff!(push(arglst[3:0], arglst[1])) X Xend SHAR_EOF echo 'File maketbls.icn is complete' && true || echo 'restore of maketbls.icn failed' rm -f _shar_wnt_.tmp fi # ============= preproc.icn ============== if test -f 'preproc.icn' -a X"$1" != X"-c"; then echo 'x - skipping preproc.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting preproc.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'preproc.icn' && X############################################################################ X# X# Name: preproc.icn X# X# Title: file preprocessing utilities for IBPAG X# X# Author: Richard L. Goerwitz X# X# Version: 1.18 X# X############################################################################ X# X# This file contains the preprocessing subsystem for IBPAG. X# Essentially, the routines contained here read the file, find the X# defines, do macro substitutions, find the start_symbol declaration X# (if there is one), and find and store rule definitions, outputting X# Icon procedures in their place. The stored rule definitions later X# get used by CONST_STATES, and turned into a parser. X# X############################################################################ X# X# Links: none X# X# See also: ibpag.icn, maketbls.icn, debugme.icn, and esp. itokens.icn X# X############################################################################ X X# ximage is only for debugging X# link ximage X X# declared in maketbls.icn X# global ptbl, start_symbol, line_number X Xrecord symbol(str, terminal) Xrecord rule(LHS, RHS, priority, associativity, procname) X X# X# makeptbl: file -> table X# (f) -> ptbl X# X# Where f is a file containing IBPAG source code, and ptbl is a X# table of the productions contained in f; writes a preprocessed X# version of f to f2 (stdout by default) as a side-effect (an X# important one, nonetheless). If a "start_symbol X" declaration X# is encountered, it also sets the start-symbol to "X" (default is X# "S"). X# X# The structure of ptbl: key = LHS (string), value = rule list X# (i.e. list of rule records). Keys are always nonterminals, as X# there is no need to record terminals (they appear only in the X# RHS of rules). X# X# Ptbl is global, so there really isn't any need to return it. It X# is used by almost every routine in maketbls.icn. X# Xprocedure makeptbl(f, f2) X X local rulenum, state, separator, T, r, astr, new_r, RHS X # global ptbl, start_symbol X initial { X start_symbol := "S" X ptbl := table() X } X X rulenum := 0 X state := 0 X separator := "" X # X # Iparse_tokens is in itokens.icn and suspends TOK records X # having a sym and str field. The sym field contains symbol X # names; the str field contains their actual string values in the X # source file. X # X every T := \iparse_tokens(f) do { X X # X # Check for null sym field (iparse_tokens uses TOK(&null, X # "\n") to signal the presence of a syntactically meaningless X # newline; we want to print it later on so as to maintain the X # original line structure), but we don't want to actually X # parse it here. X # X if \T.sym then { X X # Note that this little automaton passes its input through X # only under certain conditions in states 0 and 8. X # Otherwise it is either reading a rule or a start_symbol X # definition. X # X case state of { X X 0 : { X # Typical case: We are looking for the start of X # the next start_symbol or rule declaration. If X # neither is found, do nuttin' except to pass the X # T record on to the printing routine below. X # X case T.sym of { X "STARTSYM" : { X state := 9 X next X } X "RULE" : { X r := rule(,,,,"_" || right(rulenum +:= 1, 5, "0")) X state := 1 X next X } X default : &null X } X } X X 1 : { X # We are in a rule def. Look for the priority X # next. If we don't get an INTLIT or REALLIT, X # then assign a default priority, and see if we X # have an IDENT. If so, then see if it's the X # associativity; if so, set the associativity; if X # not, assign a default associativity and then see X # if we have a rule LHS. If not, then we have an X # error. X # X if T.sym == ("INTLIT"|"REALLIT") then { X r.priority := real(T.str) X state := 2 X next X } else if T.sym == "IDENT" then { X # if you change the default priority here, do X # it in maketbls.icn, too (e.g. rule(,,1)) X r.priority := 1 X if T.str == ("left"|"right"|"none") X then { X r.associativity := T.str X state := 3 X next X } else { X r.associativity := "none" # default X r.LHS := T.str X state := 4 X next X } X } else oh_no("line "|| line_number, 11) X } X X 2 : { X # We have our priority; now get the associativity X # (looks to the tokenizer like an identifier). If X # the identifier doesn't have a string value of X # "right," "left," or "none," then assign a X # default associativity, and assume that the X # identifier is the LHS of a rule. X # X T.sym == "IDENT" | oh_no("line "|| line_number, 12) X if T.str == ("left"|"right"|"none") then { X r.associativity := T.str X state := 3 X next X } else { X r.associativity := "none" # default X r.LHS := T.str X state := 4 X next X } X } X X 3 : { X # Now read the LHS of the rule. X # X if T.sym == "IDENT" then { X r.LHS := T.str X state := 4 X next X } else oh_no("line "|| line_number, 1) X } X X 4 : { X # Now go for the RHS of the rule (which looks like X # the argument list to an Icon procedure). X # X if T.sym == "LPAREN" then { X r.RHS := [] X state := 5 X next X } else oh_no("line "|| line_number, 3) X } X X 5 : { X # We have the left parenthesis; now read the X # arguments. Note that the smallest argument list X # possible is the empty string, i.e. (""). The X # alternation operator, |, is permitted, but has X # different semantics than it does for Icon code. X # X case T.sym of { X "IDENT" : put(r.RHS, symbol(T.str)) & X state := 6 X "STRINGLIT" : put(r.RHS, symbol(no_quotes(T.str), 1)) & X state := 6 X default : oh_no("line "|| line_number, 2) X } X next X } X X 6 : { X # We have just read an element for the RHS of a X # rule; now we either close the current position X # with a comma, close the entire RHS with a X # parend, or insert an(other) alternative, via the X # BAR, for the last element. X # X case T.sym of { X "BAR" : r.RHS[-1] := [r.RHS[-1]] & X state := 7 X "COMMA" : state := 5 X "RPAREN" : { X astr := "" X every astr ||:= "arg" || (1 to *r.RHS) || "," X astr := trim(astr, ',') X write(f2, "procedure ", r.procname, "(", astr, ")") X separator := "" X every RHS := expand_rhs(r.RHS) do { X new_r := copy(r) X new_r.RHS := RHS X /ptbl[new_r.LHS] := [] X put(ptbl[new_r.LHS], new_r) X } X state := 8 X } X default : oh_no("line "|| line_number, 10) X } X next X } X X 7 : { X # Like state 5, only for elements encountered X # after a BAR. These get stuffed into a list, and X # later turned into RHSs that are identical except X # in cases where a BAR specified alternates for a X # given position. See expand_rhs(). X # X case T.sym of { X "IDENT" : put(r.RHS[-1], symbol(T.str)) & X state := 6 X "STRINGLIT" : put(r.RHS[-1], X symbol(no_quotes(T.str), 1)) & X state := 6 X default : oh_no("line "|| line_number, 6) X } X next X } X X 8 : { X # We're done the rule definition. We are again X # passing tokens through to the printing routine X # below. We're still looking for an "end" X # keyword, though. When we get it, go back to X # state 0. X # X case T.sym of { X "RULE" : oh_no("line "||line_number, 7) X "PROCEDURE" : oh_no("line "||line_number, 8) X "END" : state := 0 X default : &null X } X # Don't go for another token yet. NO "next"! X } X X 9 : { X # This state is selected by a preceding X # "START_SYMBOL" symbol. We don't pass input X # through (note the "next" below). Input gets X # passed through again when we hit state 0. X # X if T.sym == "IDENT" then { X start_symbol := T.str X state := 0 X next X } else oh_no("line "||line_number, 4) X } X } X } X X # This is the "printing" routine mentioned above... X # X # NB: Newlines that don't need to be present are signalled by X # a null sym field. See the procedure do_newline(). If this X # modelled the real Icon tokenizer, such newlines would be X # ignored. X # X if any(&digits ++ &letters ++'_.', \T.str, 1, 2) & \T.sym ~=="DOT" X then writes(f2, separator) X X writes(f2, T.str) X X if any(&digits ++ &letters ++'_.', \T.str,-1, 0) & \T.sym ~=="DOT" X then separator := " " else separator := "" X } X X# write(ximage(ptbl)) X # Ptbl is global, so this really isn't necessary. X return ptbl X Xend X X X# X# no_quotes: string -> string X# s -> s2 X# X# Where s is the literal value of some STRINGLIT, and s2 is that X# same literal value, with the enclosing quotation markes X# removed. E.g. "\"ab\"" -> "ab". X# Xprocedure no_quotes(s) X return s ? 2(="\"", tab(-1), ="\"") Xend X X X# X# expand_rhs: list -> list X# X# Expand_rhs takes a list in which the elements are either X# symbols or lists of symbols, and produces lists with only X# symbols. E.g. X# X# [[[symbol1], symbol2], symbol3] -> [symbol1, symbol3] X# [symbol2, symbol3] X# Xprocedure expand_rhs(RHS) X *RHS = 0 & { return RHS } X suspend [expand_elem(RHS[1])] ||| expand_rhs(RHS[2:0]) Xend X# X# Xprocedure expand_elem(elem) X if type(elem) == "symbol" X then return elem X else { X suspend expand_elem(elem[1]) X suspend elem[2] X } Xend X SHAR_EOF true || echo 'restore of preproc.icn failed' rm -f _shar_wnt_.tmp fi # ============= itokens.icn ============== if test -f 'itokens.icn' -a X"$1" != X"-c"; then echo 'x - skipping itokens.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting itokens.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'itokens.icn' && X############################################################################ X# X# Name: itokens.icn X# X# Title: itokens (Icon source-file tokenizer) X# X# Author: Richard L. Goerwitz X# X# Version: 1.7 X# X############################################################################ X# X# This file contains a tokenizer to be used for Icon source files. X# Normally it would be incorporated into a package utilizing IBPAG, X# but it has a stub main procedure that makes it potentially a X# standalone package as well. X# X############################################################################ X# X# Links: slashupto X# X# Requires: coexpressions X# X############################################################################ X X#link ximage X#link slashupto #make sure you have version 1.2 or above X Xglobal next_c, line_number Xrecord TOK(sym, str) X X# X# stub main for testing X# X#procedure main() X# X# local separator X# separator := "" X# every T := \iparse_tokens(&input) do { X# # X# # Newlines that don't need to be present are signalled by a X# # null sym field. See the procedure do_newline(). If this X# # modelled the real Icon tokenizer, such newlines would be X# # ignored, and no token (not even a dummy token) would be X# # suspended. X# # X# if any(&digits ++ &letters ++ '_.', \T.str, 1, 2) & \T.sym ~== "DOT" X# then writes(separator) X# writes(T.str) X# if any(&digits ++ &letters ++ '_.', \T.str, -1, 0) & \T.sym ~== "DOT" X# then separator := " " else separator := "" X# } X# X#end X X# X# iparse_tokens: file -> TOK records (a generator) X# (stream) -> tokens X# X# Where file is an open input stream, and tokens are TOK records X# holding both the token type and actual token text. X# X# TOK records contain two parts, a preterminal symbol (the first X# "sym" field), and the actual text of the token ("str"). The X# parser only pays attention to the sym field, although the X# strings themselves get pushed onto the value stack. X# X# Note the following kludge: Unlike real Icon tokenizers, this X# procedure returns syntactially meaningless newlines as TOK X# records with a null sym field. Normally they would be ignored. X# I wanted to return them so they could be printed on the output X# stream, thus preserving the line structure of the original X# file, and making later diagnostic messages more usable. X# Xprocedure iparse_tokens(stream, getchar) X X local elem, whitespace, last_token, token, primitives, reserveds X static be_tbl, reserved_tbl, operators X initial { X X # Primitive Tokens X # X primitives := [ X ["identifier", "IDENT", "be"], X ["integer-literal", "INTLIT", "be"], X ["real-literal", "REALLIT", "be"], X ["string-literal", "STRINGLIT", "be"], X ["cset-literal", "CSETLIT", "be"], X ["end-of-file", "EOFX", "" ]] X X # Reserved Words X # X reserveds := [ X ["break", "BREAK", "be"], X ["by", "BY", "" ], X ["case", "CASE", "b" ], X ["create", "CREATE", "b" ], X ["default", "DEFAULT", "b" ], X ["do", "DO", "" ], X ["else", "ELSE", "" ], X ["end", "END", "b" ], X ["every", "EVERY", "b" ], X ["fail", "FAIL", "be"], X ["global", "GLOBAL", "" ], X ["if", "IF", "b" ], X ["initial", "INITIAL", "b" ], X ["invocable", "INVOCABLE", "" ], X ["link", "LINK", "" ], X ["local", "LOCAL", "b" ], X ["next", "NEXT", "be"], X ["not", "NOT", "b" ], X ["of", "OF", "" ], X ["procedure", "PROCEDURE", "" ], X ["record", "RECORD", "" ], X ["repeat", "REPEAT", "b" ], X ["return", "RETURN", "be"], X # Keyword beginning a rule definition. Like "procedure." X ["rule", "RULE", "" ], #<-NB X # Keyword beginning a start-symbol declaration. X ["start_symbol", "STARTSYM", "" ], X ["static", "STATIC", "b" ], X ["suspend", "SUSPEND", "be"], X ["then", "THEN", "" ], X ["to", "TO", "" ], X ["until", "UNTIL", "b" ], X ["while", "WHILE", "b" ]] X X # Operators X # X operators := [ X [":=", "ASSIGN", "" ], X ["@", "AT", "b" ], X ["@:=", "AUGACT", "" ], X ["&:=", "AUGAND", "" ], X ["=:=", "AUGEQ", "" ], X ["===:=", "AUGEQV", "" ], X [">=:=", "AUGGE", "" ], X [">:=", "AUGGT", "" ], X ["<=:=", "AUGLE", "" ], X ["<:=", "AUGLT", "" ], X ["~=:=", "AUGNE", "" ], X ["~===:=", "AUGNEQV", "" ], X ["==:=", "AUGSEQ", "" ], X [">>=:=", "AUGSGE", "" ], X [">>:=", "AUGSGT", "" ], X ["<<=:=", "AUGSLE", "" ], X ["<<:=", "AUGSLT", "" ], X ["~==:=", "AUGSNE", "" ], X ["\\", "BACKSLASH", "b" ], X ["!", "BANG", "b" ], X ["|", "BAR", "b" ], X ["^", "CARET", "b" ], X ["^:=", "CARETASGN", "b" ], X [":", "COLON", "" ], X [",", "COMMA", "" ], X ["||", "CONCAT", "b" ], X ["||:=", "CONCATASGN","" ], X ["&", "CONJUNC", "b" ], X [".", "DOT", "b" ], X ["--", "DIFF", "b" ], X ["--:=", "DIFFASGN", "" ], X ["===", "EQUIV", "b" ], X ["**", "INTER", "b" ], X ["**:=", "INTERASGN", "" ], X ["{", "LBRACE", "b" ], X ["[", "LBRACK", "b" ], X ["|||", "LCONCAT", "b" ], X ["|||:=", "LCONCATASGN","" ], X ["==", "LEXEQ", "b" ], X [">>=", "LEXGE", "" ], X [">>", "LEXGT", "" ], X ["<<=", "LEXLE", "" ], X ["<<", "LEXLT", "" ], X ["~==", "LEXNE", "b" ], X ["(", "LPAREN", "b" ], X ["-:", "MCOLON", "" ], X ["-", "MINUS", "b" ], X ["-:=", "MINUSASGN", "" ], X ["%", "MOD", "" ], X ["%:=", "MODASGN", "" ], X ["~===", "NOTEQUIV", "b" ], X ["=", "NUMEQ", "b" ], X [">=", "NUMGE", "" ], X [">", "NUMGT", "" ], X ["<=", "NUMLE", "" ], X ["<", "NUMLT", "" ], X ["~=", "NUMNE", "b" ], X ["+:", "PCOLON", "" ], X ["+", "PLUS", "b" ], X ["+:=", "PLUSASGN", "" ], X ["?", "QMARK", "b" ], X ["<-", "REVASSIGN", "" ], X ["<->", "REVSWAP", "" ], X ["}", "RBRACE", "e" ], X ["]", "RBRACK", "e" ], X [")", "RPAREN", "e" ], X [";", "SEMICOL", "" ], X ["?:=", "SCANASGN", "" ], X ["/", "SLASH", "b" ], X ["/:=", "SLASHASGN", "" ], X ["*", "STAR", "b" ], X ["*:=", "STARASGN", "" ], X [":=:", "SWAP", "" ], X ["~", "TILDE", "b" ], X ["++", "UNION", "b" ], X ["++:=", "UNIONASGN", "" ], X ["$(", "LBRACE", "b" ], X ["$)", "RBRACE", "e" ], X ["$<", "LBRACK", "b" ], X ["$>", "RBRACK", "e" ]] X X # static be_tbl, reserved_tbl X reserved_tbl := table() X every elem := !reserveds do X insert(reserved_tbl, elem[1], elem[2]) X be_tbl := table() X every elem := !primitives | !reserveds | !operators do { X insert(be_tbl, elem[2], elem[3]) X } X } X X /getchar := create { X line_number := 0 X ! ( 1(!stream, line_number +:=1) || "\n" ) X } X whitespace := ' \t' X /next_c := @getchar X X repeat { X case next_c of { X X "." : { X # Could be a real literal *or* a dot operator. Check X # following character to see if it's a digit. If so, X # it's a real literal. We can only get away with X # doing the dot here because it is not a substring of X # any longer identifier. If this gets changed, we'll X # have to move this code into do_operator(). X # X last_token := do_dot(getchar) X suspend last_token X# write(&errout, "next_c == ", image(next_c)) X next X } X X "\n" : { X # If do_newline fails, it means we're at the end of X # the input stream, and we should break out of the X # repeat loop. X # X every last_token := do_newline(getchar, last_token, be_tbl) X do suspend last_token X if next_c === &null then break X next X } X X "\#" : { X # Just a comment. Strip it by reading every character X # up to the next newline. The global var next_c X # should *always* == "\n" when this is done. X # X do_number_sign(getchar) X# write(&errout, "next_c == ", image(next_c)) X next X } X X "\"" : { X # Suspend as STRINGLIT everything from here up to the X # next non-backslashed quotation mark, inclusive X # (accounting for the _ line-continuation convention). X # X last_token := do_quotation_mark(getchar) X suspend last_token X# write(&errout, "next_c == ", image(next_c)) X next X } X X "'" : { X # Suspend as CSETLIT everything from here up to the X # next non-backslashed apostrophe, inclusive. X # X last_token := do_apostrophe(getchar) X suspend last_token X# write(&errout, "next_c == ", image(next_c)) X next X } X X &null : oh_no(&null, 5) # unexpected EOF message X X default : { X # If we get to here, we have either whitespace, an X # integer or real literal, an identifier or reserved X # word (both get handled by do_identifier), or an X # operator. The question of which we have can be X # determined by checking the first character. X # X if any(whitespace, next_c) then { X # Like all of the TOK forming procedures, X # do_whitespace resets next_c. X do_whitespace(getchar, whitespace) X # don't suspend any tokens X next X } X if any(&digits, next_c) then { X last_token := do_digits(getchar) X suspend last_token X next X } X if any(&letters ++ '_', next_c) then { X last_token := do_identifier(getchar, reserved_tbl) X suspend last_token X next X } X# write(&errout, "it's an operator") X last_token := do_operator(getchar, operators) X suspend last_token X next X } X } X } X X # If stream argument is nonnull, then we are in the top-level X # iparse_tokens(). If not, then we are in a recursive call, and X # we should not emit all this end-of-file crap. X # X if \stream then { X suspend TOK("EOFX") X return TOK("$") X } X else fail X Xend X X X# X# do_dot: coexpression -> TOK record X# getchar -> t X# X# Where getchar is the coexpression that produces the next X# character from the input stream and t is a token record whose X# sym field contains either "REALLIT" or "DOT". Essentially, X# do_dot checks the next char on the input stream to see if it's X# an integer. Since the preceding char was a dot, an integer X# tips us off that we have a real literal. Otherwise, it's just X# a dot operator. Note that do_dot resets next_c for the next X# cycle through the main case loop in the calling procedure. X# Xprocedure do_dot(getchar) X X local token X # global next_c X X# write(&errout, "it's a dot") X X # If dot's followed by a digit, then we have a real literal. X # X if any(&digits, next_c := @getchar) then { X# write(&errout, "dot -> it's a real literal") X token := "." || next_c X while any(&digits, next_c := @getchar) do X token ||:= next_c X if token ||:= (next_c == ("e"|"E")) then { X while (next_c := @getchar) == "0" X while any(&digits, next_c) do { X token ||:= next_c X next_c = @getchar X } X } X return TOK("REALLIT", token) X } X X # Dot not followed by an integer; so we just have a dot operator, X # and not a real literal. X # X# write(&errout, "dot -> just a plain dot") X return TOK("DOT", ".") X Xend X X X# X# do_newline: coexpression x TOK record x table -> TOK records X# (getchar, last_token, be_tbl) -> Ts (a generator) X# X# Where getchar is the coexpression that returns the next X# character from the input stream, last_token is the last TOK X# record suspended by the calling procedure, be_tbl is a table of X# tokens and their "beginner/ender" status, and Ts are TOK X# records. Note that do_newline resets next_c. Do_newline is a X# mess. What it does is check the last token suspended by the X# calling procedure to see if it was a beginner or ender. It X# then gets the next token by calling iparse_tokens again. If X# the next token is a beginner and the last token is an ender, X# then we have to suspend a SEMICOL token. In either event, both X# the last and next token are suspended. X# Xprocedure do_newline(getchar, last_token, be_tbl) X X local next_token X # global next_c X X# write(&errout, "it's a newline") X X # Go past any additional newlines. X # X while next_c == "\n" do { X # NL can be the last char in the getchar stream; if it *is*, X # then signal that it's time to break out of the repeat loop X # in the calling procedure. X # X next_c := @getchar | { X next_c := &null X fail X } X suspend TOK(&null, next_c == "\n") X } X X # If there was a last token (i.e. if a newline wasn't the first X # character of significance in the input stream), then check to X # see if it was an ender. If so, then check to see if the next X # token is a beginner. If so, then suspend a TOK("SEMICOL") X # record before suspending the next token. X # X if find("e", be_tbl[(\last_token).sym]) then { X# write(&errout, "calling iparse_tokens via do_newline") X# &trace := -1 X # First arg to iparse_tokens can be null here. X if next_token := iparse_tokens(&null, getchar) X then { X# write(&errout, "call of iparse_tokens via do_newline yields ", X# ximage(next_token)) X if find("b", be_tbl[next_token.sym]) X then suspend TOK("SEMICOL", "\n") X # X # See below. If this were like the real Icon parser, X # the following line would be commented out. X # X else suspend TOK(&null, "\n") X return next_token X } X else { X # X # If this were a *real* Icon tokenizer, it would not emit X # any record here, but would simply fail. Instead, we'll X # emit a dummy record with a null sym field. X # X return TOK(&null, "\n") X# &trace := 0 X# fail X } X } X X # See above. Again, if this were like Icon's own tokenizer, we X # would just fail here, and not return any TOK record. X # X# &trace := 0 X return TOK(&null, "\n") X# fail X Xend X X X# X# do_number_sign: coexpression -> &null X# getchar -> X# X# Where getchar is the coexpression that pops characters off the X# main input stream. Sets the global variable next_c. This X# procedure simply reads characters until it gets a newline, then X# returns with next_c == "\n". Since the starting character was X# a number sign, this has the effect of stripping comments. X# Xprocedure do_number_sign(getchar) X X # global next_c X X# write(&errout, "it's a number sign") X while next_c ~== "\n" do { X next_c := @getchar X } X X # Return to calling procedure to cycle around again with the new X # next_c already set. Next_c should always be "\n" at this point. X return X Xend X X X# X# do_quotation_mark: coexpression -> TOK record X# getchar -> t X# X# Where getchar is the coexpression that yields another character X# from the input stream, and t is a TOK record with "STRINGLIT" X# as its sym field. Puts everything upto and including the next X# non-backslashed quotation mark into the str field. Handles the X# underscore continuation convention. X# Xprocedure do_quotation_mark(getchar) X X local token X # global next_c X X # write(&errout, "it's a string literal") X token := "\"" X while next_c := @getchar do { X if next_c == "\n" & token[-1] == "_" then { X token := token[1:-1] X next X } else { X if slashupto("\"", token ||:= next_c, 2) X then { X next_c := @getchar X # resume outermost (repeat) loop in calling procedure, X # with the new (here explicitly set) next_c X return TOK("STRINGLIT", token) X } X } X } X Xend X X X# X# do_apostrophe: coexpression -> TOK record X# getchar -> t X# X# Where getchar is the coexpression that yields another character X# from the input stream, and t is a TOK record with "CSETLIT" X# as its sym field. Puts everything upto and including the next X# non-backslashed apostrope into the str field. X# Xprocedure do_apostrophe(getchar) X X local token X # global next_c X X# write(&errout, "it's a cset literal") X token := "'" X while next_c := @getchar do { X if slashupto("'", token ||:= next_c, 2) X then { X next_c := @getchar X # Return & resume outermost containing loop in calling X # procedure w/ new next_c. X return TOK("CSETLIT", token) X } X } X Xend X X X# X# do_digits: coexpression -> TOK record X# getchar -> t X# X# Where getchar is the coexpression that produces the next char X# on the input stream, and where t is a TOK record containing X# either "REALLIT" or "INTLIT" in its sym field, and the text of X# the numeric literal in its str field. X# Xprocedure do_digits(getchar) X X local token, tok_record X # global next_c X X # Assume integer literal until proven otherwise.... X tok_record := TOK("INTLIT") X X# write(&errout, "it's an integer or real literal") X token := ("0" ~== next_c) | "" X while any(&digits, next_c := @getchar) do X token ||:= next_c X if token ||:= (next_c == ("R"|"r")) then { X while any(&digits, next_c := @getchar) do X token ||:= next_c X } else { X if token ||:= (next_c == ".") then { X while any(&digits, next_c := @getchar) do X token ||:= next_c X tok_record := TOK("REALLIT") X } X if token ||:= (next_c == ("e"|"E")) then { X while any(&digits, next_c := @getchar) do X token ||:= next_c X tok_record := TOK("REALLIT") X } X } X tok_record.str := ("" ~== token) | 0 X return tok_record X Xend X X X# X# do_whitespace: coexpression x cset -> &null X# getchar x whitespace -> &null X# X# Where getchar is the coexpression producing the next char on X# the input stream. Do_whitespace just repeats until it finds a SHAR_EOF true || echo 'restore of itokens.icn failed' fi echo 'End of part 3' echo 'File itokens.icn is continued in part 4' echo 4 > _shar_seq_.tmp exit 0 -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sun Jan 3 21:17:57 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Jan 1993 04:34:12 MST Date: 3 Jan 93 21:17:57 GMT From: agate!spool.mu.edu!olivea!pagesat!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: parser generator, part 1 Message-Id: <1993Jan3.211757.28395@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 Warning - Don't bother unpacking this file unless a) you know what a parser generator is, and b) you are interested in thinking about how one should look for Icon. -Richard Goerwitz ---- Cut Here and feed the following to sh ---- #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 01/03/1993 20:21 UTC by richard@zenu # Source directory /u/richard/Ibpag # # existing files will NOT be overwritten unless -c is specified # This format requires very little intelligence at unshar time. # "if test", "cat", "rm", "echo", "true", and "sed" may be needed. # # This is part 1 of a multipart archive # do not concatenate these parts, unpack them in order with /bin/sh # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 41902 -rw-r--r-- ibpag.icn # 18563 -r--r--r-- maketbls.icn # 9627 -r--r--r-- preproc.icn # 25415 -r--r--r-- itokens.icn # 3663 -r--r--r-- debugme.icn # 1190 -r--r--r-- errors.icn # 2062 -r--r--r-- slashupto.icn # 4314 -r--r--r-- rewrap.icn # 762 -r--r--r-- strip.icn # 1752 -rw-r--r-- Makefile.dist # if test -r _shar_seq_.tmp; then echo 'Must unpack archives in sequence!' echo Please unpack part `cat _shar_seq_.tmp` next exit 1 fi # ============= ibpag.icn ============== if test -f 'ibpag.icn' -a X"$1" != X"-c"; then echo 'x - skipping ibpag.icn (File already exists)' rm -f _shar_wnt_.tmp else > _shar_wnt_.tmp echo 'x - extracting ibpag.icn (Text)' sed 's/^X//' << 'SHAR_EOF' > 'ibpag.icn' && X############################################################################ X# X# Name: ibpag.src X# X# Title: Icon-based parser generator X# X# Author: Richard L. Goerwitz X# X# Version: 1.21 X# X############################################################################ X# X# X# General Description: X# X# IBPAG is a simple tool for generating parsers from grammar X# specifications. Sounds pretty mundane, but those who have never X# used a parser generator will perhaps be surprised to find that this X# kind of tool forms the basis of most modern programming language X# implementations. Parser generators are also used in preprocessors, X# transducers, compilers, interpreters, calculators and in fact for X# just about any situation where some form of structured input needs X# to be converted into some form of structured output. X# X# IBPAG is not a full, working system. In particular, startup X# times for compiled IBPAG programs is very slow, since I can't find X# a good way of writing/reconstructing the necessary structures. For X# applications where a startup delay is not a problem, IBPAG will X# work fine. What IBPAG is supposed to be is a very preliminary X# crack at designing a parser generator for Icon. It really ought to X# be redone in C some day, and its error handling facilities need to X# be tested better. It also ought to be redone as an LALR (and not X# LR) parser, and some method of storing parse tables ought to be X# found that permits fast/easy reconstruction at run-time. This X# version has to be regarded as in beta testing. I doubt I'll ever X# take it, however, much further - at least in its present form. X# X# X# More technical description: X# X# Technically speaking, IBPAG is a preprocessor that accepts a X# Icon-like source file from the standard input containing grammar X# productions and actions, converts them into parsing tables and X# associated code, and then adds to this an LR parser, tokenizer, X# error handler, and a few debugging tools. Writes the combination X# to the standard output, along with the necessary action and goto X# tables. The tables are generated using a very general (but also X# very sluggish) LR(1) algorithm. IBPAG is not terribly practical X# for most micros. It was written as an excercize by me (a linguist X# with far too little CS training) while auditing a compiler course X# as a some-time diversion from many dissertation rewrites... X# X# Cycles and epsilon moves are handled correctly (to my X# knowledge). Shift-reduce conflicts are handled in the normal way X# (i.e. pick the rule with the highest priority, and, in cases where X# the priority is the same, check the associativities; flag X# reduce/reduce conflicts as errors, and for shift/reduce conflicts X# pick shift by default [shift/shift conflicts don't matter, since we X# shift in either case, and no reduction takes place]). X# X# X# Running IBPAG: X# X# Invoking IBPAG is very, very simple. There are just two X# (optional) command-line switches: X# X# ibpag [-d] [-v] < inputfile > outputfile X# X# Where the -d switch causes profuse debugging messages to be X# displayed, and the -v switch ("verbose") causes somewhat more X# restrained messages to be emitted. -d implies -v. Inputfile is an X# IBPAG source file (see below on its format). Outputfile is an LR X# parser with appropriate tables, generated from the specs contained X# in inputfile. X# X# For more information how to set up IBPAG files and incorporate X# them into larger Icon programs, see the section just below, "How to X# use IBPAG." X# X############################################################################ X# X# X# How to use IBPAG X# ________________ X# X# X# I. Prerequisites X# X# The only prerequisites to using IBPAG are a knowledge of how to X# write a basic LR-parsable context-free grammar and a familiarity X# with the Icon programming language. IBPAG source files use X# essentially the same syntax as Icon source files. In a couple of X# cases, though the semantics of are quite different. IBPAG is X# essentially just a preprocessor. IBPAG-specific constructs, X# therefore, should be seen, not as Icon expressions, but as X# directives to the preprocessor, specifying how to construct the X# actual output code. X# X# In the sections that follow, I will discuss how to set up an X# IBPAG file, i.e. how to declare a start symbol and write rules. X# The issue of the tokenizer will then be addressed, along with a X# treatment of epsilon, and two reserved tokens: $ and error. X# Finally the overall compatibility of IBPAG and Icon code will be X# discussed, as well as how to start the IBPAG parser from the Icon X# code. If you still have problems and/or questions, try reading the X# UNIX manual page on YACC. IBPAG and YACC have some superficial X# similarities that may be helpful in sorting out why IBPAG works the X# way it does. Alternatively write to me, Richard Goerwitz, via X# e-mail at goer@midway.uchicago.edu. I'll be glad to field X# questions and provide anyone with the latest version I have X# on-hand. Doubtless there will be many bugs to find, and I'll be X# happy to fix any that get reported. At some point, the entire X# table generating process (in maketbls.icn) will need to be ripped X# out, and replaced with one of the new, faster LR(1) (or perhaps X# LALR) algorithms. X# X# X# II. The start symbol X# X# All context-free grammars have a start-symbol, i.e. a terminal X# that can be considered the "goal" of a parse. Because cycles (and X# bugs) in the grammar can make it hard for IBPAG to determine what X# the start symbol is, it must be declared. This is done with a X# start-symbol declaration, which has the following form: X# X# ::= start_symbol identifier X# X# If no start-symbol declaration appears in an IBPAG source file, X# IBPAG assumes S as the start symbol. X# X# X# III. Rule declarations X# X# The heart of the IBPAG source file is the rule declaration. X# Basically, rule declarations tell IBPAG the structure of the grammar X# it is to assume when generating a parser. They also tell it what X# rules to associate with what Icon code. Rule declarations look a X# lot like procedure declarations, except that they begin with "rule" X# instead of "procedure" and must specify a priority and X# associativity. For those with formalistic leanings, the format of X# the rule declaration is as follows (opt = optional): X# X# ::= ... end X# ::= rule \ X# ( ) X# ::= integer-literal (opt) X# ::= left | right | none (opt) X# ::= identifier X# ::= | , X# ::= | \| X# ::= identifier | string-literal X# X# The "..." indicates material that is precisely the same as for a X# standard Icon procedure declaration. The only difference between a X# rule and a procedure (syntactically, that is) is in the header. X# Superficially, rule and procedure headers look a lot alike. The X# rule headers, though, have extra elements (optional priority and X# associativity). They also interpret arguments in the option list X# quite differently than Icon does. In particular, these arguments X# are either strings, identifiers, or any combination of these X# separated by a bar. Strings correspond to terminals, identifiers X# to nonterminals. The bar will be discussed below. X# X# For those with a more practical bent, here is a sample rule X# definition: X# X# rule 1 none S(NP, VP) X# return ["S", arg1, arg2] X# end X# X# The 1 denotes the priority (here very low), while "none" specifies X# the associativity (can be right, left, or none). S is the X# left-hand side of the rule, and NP and VP are the (nonterminal) X# symbols that make up its right-hand side. Normally, the priority X# is not needed (the default is 1). In fact, it is best to try to X# write grammars without any priorities or associativity rules. The X# default associativity is none. X# X# Please note the body of the rule itself. The code there is X# triggered whenever an S is found (i.e. when a reduction via the X# above S-rule occurs during the parse). For those who know YACC, X# arg1 is equivalent to $1 and the return expression is equivalent to X# $$ =. Essentially, the above rule definition says that an S is X# composed of an NP and a VP, and that if an S is encountered, the X# parser is to create a list having three members, the first being X# the string "S", the second being the result that was returned when X# the NP was found, and the third being the result returned when the X# VP was encountered. Note that the above rule implies the existence X# of at least two other rules having NP and VP, respectively, as X# their left-hand sides. For example: X# X# rule NP("det", "noun") X# return ["NP", arg1, arg2] X# end X# X# rule VP("v", NP) X# return ["VP", arg1, arg2] X# end X# X# If two or more right-hand sides differ in just a single symbol, X# it is acceptable to combine them into one declaration using a X# vertical slash or bar. Although this bar looks like the usual Icon X# alternation operator, in this context IBPAG uses it as a macro X# device. In the following case, two rules are generated, each with X# one of the alternatives, "that" or "which," in its RHS. The same X# code is triggered by a reduction via either rule: X# X# rule RELCL("that"|"which", S) X# return ["RELCL", arg1, arg2] X# end X# X# X# IV. The tokenizer X# X# Note that in the above examples, "v," "det," "noun," "that", and X# "which" are considered terminal symbols. The user must, in fact, X# create a lexical analyzer called iparse_tokens that returns these X# symbols. The precise form in which iparse_tokens must function is X# as follows: X# X# iparse_tokens: file -> TOK records X# (stream) -> Ts X# Where stream is an open file, and Ts are TOK records. X# As a side-effect, iparse_tokens should increment the global X# variable line_number (once right away, then once for each X# newline encountered, or anything equivalent thereto) X# X# The -> notation above implies that iparse_tokens is a pure X# function. I just can't think of a good notation for generators. X# Iparse_tokens in fact *must be* a generator. TOK records contain X# the terminal symbol names in their first field. If the literal X# string value of the symbols is to be used by any of the rule code, X# it should be stored in the second field of the TOK record. A X# typical value returned might be: X# X# TOK("v", "eat") X# X# YACC/LEX's heterogenous yylval/return (TOKEN) strategy is really X# quite inelegant, and although my system isn't perfect, it avoids X# the global variable, and hence makes running simultaneous parsers a X# bit simpler undertaking (the only globals to worry about in IBPAG X# are line_number, errors, and fail_on_error, all of which can, if X# desired, be ignored). X# X# If you want line numbers to be output with any error messages X# that the parser might report, then make sure that the tokenizer X# keeps track of how many lines it has read by incrementing X# line_number. The parser itself automatically initializes this X# (global) variable to 0, so all you'll normally have to do is X# increment it by one for each newline the tokenizer encounters. If X# you leave line_number alone, the parser simply does not print out X# line numbers for errors it reports (which is somewhat less helpful, X# but workable nonetheless). X# X# X# V. Epsilon X# X# If needed, epsilon (i.e. the empty string) can be specified by X# an empty Icon string (e.g. rule REL(""|"that")). "" is a perfectly X# legal token. It is absolutely vital, however, to note that X# *epsilon is never pushed onto the value stack*. Hence in the above X# instance, if arg1 were to be accessed, an error would result if a X# reduction via REL -> epsilon (rather than by REL -> "that") X# occurred! For this reason it is wise to keep epsilon isolated X# (e.g. rule 10 REL("") and rule 11 REL("that"); note that giving X# both rules an associativity probably isn't necessary here, although X# giving the second rule the higher priority often *will* be). Note X# also that the tokenizer must never return an empty string as a X# token (i.e. TOK("")). Not only will the parser refuse to place it X# on the value stack, but it will not even recognize it as a valid X# lookahead symbol (since, by definition, it doesn't contain X# anything). X# X# X# VI. Reserved tokens ($ and error) X# X# Besides epsilon, the only string (qua symbol) the tokenizer X# cannot return at will is a TOK with either "error" or "$" as its X# first field (e.g. TOK("$")). The $ symbol denotes end-of-input, X# and *must* be returned by the tokenizer when the input stream ends X# (or when, for some other reason, the token stream has stopped). I X# could have cut the code so that failure or &null signalled the same X# thing, but I prefer to use failure of the tokenizer to signal an X# unexpected end of input, and I don't like the inconsistency of X# having &null be a valid token. The bottom line is that the X# tokenizer must return TOK("$") on end-of-input. You'll get used to X# it :-). X# X# The "error" terminal is reserved for error productions. If a X# syntax error occurs, and the token "error" exists in the grammar, X# the parser will attempt to back up as one state to see if any of X# them permits "error" as a valid lookahead symbol. If so, the X# parser jumps to the state that would have resulted if the parser X# had encountered "error" at that point. What this does is allow us X# to write error-recovery rules: X# X# global error_count X# rule EXPR("(", EXPR, ")") X# return arg1 X# end X# rule REGEXP("(", REGEXP, "error") X# write(&errout, "unmatched \"(\"; resynchronizing") X# # Pretend we got a right parenthesis, and continue X# # processing. X# return arg1 X# end X# X# So what happens if we get an expression without an enclosing right X# parenthesis? We get an error message, an increment of the error X# count, and a resynchronized parser that's ready to go (and possibly X# find more errors). This mechanism is very much like the mechanism X# YACC uses. X# X# Note that IBPAG will only pop one state off of the stack in X# efforts to find a state for which "error" is a legitimate lookahead X# token; any more than this, and we could easily back so far out the X# current production that we would end up causing confusion about X# just where the error occurred! If you write error productions, X# make sure that the error terminal is at most one token removed from X# the spot where you expect errors to occur. X# X# X# VII. IBPAG-Icon code compatibility (plus gotchas) X# X# Regular Icon procedures may be freely intermingled with IBPAG X# rules, so you can include iparse_tokens() right in the same file as X# your rule definitions. Note that rules, other than the header, in X# fact, behave somewhat like procedures in the sense that when a rule X# is triggered, the parser executes the code for that rule just the X# way code for a procedure is executed when it is invoked. The main X# difference between Icon procedures and rules is that the rules can X# only return one value or fail. If you want a rule to be able to X# produce more than one value, then have it return a coexpression. X# Failure in a rule signals that the entire RHS of the production X# should be discarded, and the stack should be returned to the state X# it was in before that RHS's first symbol was shifted onto the X# stack. Failure is really just another way of providing the user X# more control over error handling and recovery. If you have nothing X# useful to return, but do *not* want to signal an error, BE SURE TO X# RETURN A NULL DESCRIPTOR ("return &null")! X# X# X# VII. The parser itself X# X# In the output file, the parser that IBPAG constructs is called X# iparse(). You should invoke it somewhere to get the parser X# started. It takes a single argument: A stream (i.e. an open file). X# You could pass it a string, theoretically, instead of a file. X# Iparse() passes its first argument to iparse_tokens(), so be sure X# iparse_tokens() understands that it is working on a string instead X# of a file if you choose to do things this way. IBPAG's output is X# compressed somewhat, but the parser and error handler are human- X# readable. Please look at them and modify them as needed. Note X# especially the debugging facilities that are included with them X# (e.g. dump_lists()). X# X# X# VIII. Miscellaneous X# X# As it encounters errors, the parser, iparse(), increments the X# global variable errors by one. Normally one botched production X# will cause a series of cascading errors. As a result, the error X# handler only increments "errors" for the first in any unbroken X# series of errors. When (and if) the parser manages to X# resynchronize itself, and the cascade terminates, the errors X# variable is once again incremented normally, once for each error X# encountered. X# X# If no error processing is desired at all, you may set the X# global variable fail_on_error to something other than &null. This X# tells iparser's error handler simply to fail if there are any X# syntax errors. Note that "error" productions (described above, in X# the section on reserved tokens) will still work if they have been X# used in the grammar. So in fact, setting fail_on_errors will cause X# failure to occur for all errors that cannot be handled by X# user-defined error productions. What this does is bypass the X# built-in error detection and resynchronization routines. This may X# be useful if an IBPAG file is part of a much larger Icon program X# that needs to have errors registered internally, and not spit out X# separately to stderr by a renegade parser :-). X# X############################################################################ X# X# Below is a sample IBPAG source file. It's kind of a hack, but X# I'm sure it will adequately illustrate the basic principles: X# X# link radcon X# global ID_tbl X# X# procedure main() X# iparse(&input) X# end X# X# rule 0 left S(stream) X# return X# end X# X# rule 1 left stream(calc, stream) X# return X# end X# X# rule 1 left stream(calc) X# return X# end X# X# rule 2 none calc("CR") X# return X# end X# X# rule 3 left calc(expr, "CR") X# # Radcon can't handle reals, so this doesn't really work. X# line_number +:= 1 X# return write(radcon(arg1, \(\ID_tbl)["ibase"] | 10, X# \(\ID_tbl)["obase"] | 10)) X# end X# X# rule 4 none expr("ID") X# if not (return \ID_tbl[arg1]) X# then write(&errout, "uninitialized variable, line ", line_number) X# fail X# end X# X# rule 6 right expr("ID", "=", expr) X# initial ID_tbl := table() X# ID_tbl[arg1] := arg3 X# return arg3 X# end X# X# rule 10 left expr(expr, "+", expr) X# return arg1 + arg3 X# end X# X# rule 10 left expr(expr, "-", expr) X# return arg1 - arg3 X# end X# X# rule 11 left expr(expr, "*", expr) X# return arg1 * arg3 X# end X# X# rule 11 left expr(expr, "/", expr) X# return arg1 / arg3 X# end X# X# rule 11 left expr(expr, "%", expr) X# return arg1 % arg3 X# end X# X# rule 12 left expr(expr, "^", expr) X# return arg1 ^ arg3 X# end X# X# rule 50 none expr("(", expr, ")") X# return arg2 X# end X# X# rule 75 right expr("-", expr) X# return -arg2 X# end X# X# rule 75 right expr("+", expr) X# return +arg2 X# end X# X# rule 100 none expr("NUM") X# if find(".", arg1) X# then return real(arg1) X# else return integer(arg1) X# end X# X# # X# # iparse_tokens: file -> TOK records (a generator) X# # stream -> tokens X# # X# # Where file is an open input stream, and tokens are TOK X# # records holding both the token type and actual token text. X# # X# # TOK records contain two parts, a preterminal symbol (the first X# # "sym" field), and the actual text of the token ("str"). The X# # parser above only pays attention to the sym field, although the X# # user might well want to use the actual text. X# # X# procedure iparse_tokens(stream) X# X# local token, c, whitespace, operators X# #global line_number X# whitespace := '\r\t \n' X# operators := '+-*/^()=' X# X# token := "" X# every c := !(!&input || "\n") do { X# if not any(whitespace ++ operators, c) then { X# token ||:= c X# } else { X# if integer(token) X# then suspend TOK("NUM", "" ~== token) X# else suspend TOK("ID", "" ~== token) X# if any(operators, c) then X# suspend TOK(c) X# else { X# if c == "\n" then { X# line_number +:= 1 X# suspend TOK("CR"|"CR") X# } X# } X# token := "" X# } X# } X# if integer(token) X# then suspend TOK("NUM", "" ~== token) X# else suspend TOK("ID", "" ~== token) X# suspend TOK("CR"|"$") X# X# end X# X############################################################################ X# X# Links: options.icn X# X# See also: maketbls.icn, preproc.icn X# X############################################################################ X Xlink options, structs, ximage X Xglobal DEBUG, VERBOSE X# For other record declarations, see maketbls.icn. Xrecord RE(state, procname, sym, size) Xrecord SH(state) Xrecord AC() X Xprocedure main(a) X X local f, f2, lname, opttbl, usage, tlst, sym, seen, X act, elt, size, r, i, k X # global ptbl, alst, glst X X usage := "usage: ibpag [-d] [-v] [-f input-file]" X X opttbl := options(a, "dvf:") | stop(usage) X if DEBUG := \opttbl["d"] X then VERBOSE := 1 X else VERBOSE := opttbl["v"] X f := \opttbl["f"] | &input X f2 := &output X X ptbl := table() X makeptbl(f, f2) X X # set up (global) alst and glst (the action and goto lists) X CONST_TABLE() X X # X # Set up tlst (a set of all tokens used in the grammar), then X # turn the ACT records into RE, SH, or AC records. X # X tlst := set() X # squeeze a list of rules out of the action list; find the X # terminals in their right-hand sides X every sym := !\(\(!(!alst)).by_rule).RHS do X \sym.terminal & insert(tlst, sym.str) X insert(tlst, "$") X X # X # Clobber all of the ACT records, and turn them into RE, SH, or AC X # records. Get rid of structurally identical, structures by X # making them all point to the same structure. X # X if \VERBOSE then X write(&errout, "Merging duplicate structures in action list...") X seen := set() X every i := 1 to *alst do { X if /alst[i] then next X if *alst[i] = 0 then { X alst[i] := &null X next X } X every k := key(alst[i]) do { X if alst[i][k].str == "reduce" then { X r := alst[i][k].by_rule X size := *r.RHS X # Don't count epsilon moves when calculating sizes! X every elt := !r.RHS do X if elt.str == "" & \elt.terminal then size -:= 1 X act := RE(alst[i][k].state, r.procname, r.LHS, size) X } X # Don't need to store all this info for shifts or accepts. X else if alst[i][k].str == "shift" X then act := SH(alst[i][k].state) X else act := AC() X if alst[i][k] := equiv(act, !seen) X then next X else { X alst[i][k] := act X insert(seen, act) X } X } X # Simple optimization; if alst[i] is structured identically to X # a previously seen table, use the previously seen one! Note X # that equiv is more general than Equiv (it can accept sets X # and tables). See the IPL for equiv(). Equiv() is in X # debug.src. X if alst[i] := equiv(alst[i], !seen) X then next else insert(seen, alst[i]) X } X X write(f2, "") X write(f2, "############################################################################") X write(f2, "#") X write(f2, "# The following code has been inserted by IBPAG (Icon-based") X write(f2, "# Parser Generator). It contains a stack-based LR parser, an") X write(f2, "# error handler, and a debugging tool. The user must supply a") X write(f2, "# tokenizing routine called iparse_tokens().") X write(f2, "#") X write(f2, "# For a description of IBPAG source-file format, see the") X write(f2, "# documentation prepended to ibpag.icn.") X write(f2, "#") X write(f2, "############################################################################") X write(f2, "#") X write(f2, "# See also: ibpag.icn, maketbls.icn, preproc.icn, itokens.icn") X write(f2, "#") X write(f2, "############################################################################") X write(f2, "") X write(f2, "# uncomment for the compiler") X write(f2, "# invocable \"symbol\", \"TOK\", \"RE\", \"SH\", \"AC\"") X write(f2, "") X write(f2, "# I use ximage for debugging; remove it if you don't need it.") X write(f2, "link codeobj#, ximage") X write(f2, "") X write(f2, "record symbol(str, terminal)") X write(f2, "record TOK(sym, str)") X write(f2, "record RE(state, procname, sym, size)") X write(f2, "record SH(state)") X write(f2, "record AC()") X write(f2, "") X write(f2, "global line_number, errors, fail_on_error") X write(f2, "") X write(f2, "#") X write(f2, "# iparse: file -> ?") X write(f2, "# stream -> ?") X write(f2, "#") X write(f2, "# Where stream is an open file, and ? represents the user-defined") X write(f2, "# result of a completed parse of file, from the current location") X write(f2, "# up to the point where the parser executes an \"accept\" action.") X write(f2, "#") X write(f2, "# The second to fifth arguments are used on recursive calls from") X write(f2, "# the error handler, iparse_error. Ignore them, unless you are") X write(f2, "# sure of what you are doing!") X write(f2, "#") X write(f2, "procedure iparse(stream, state_stack, value_stack, next_token, err_state)") X write(f2, "") X write(f2, " local start_symbol, token, act, last_symbol, arglist") X write(f2, " static alst, glst") X write(f2, " #global line_number, errors") X write(f2, " initial {") X every lname := "alst" |"glst" do { X encode(variable(lname)) ? { X writes(f2, "\t", lname, " := decode(\"") X if write(f2, move(47), "_") then { X while write(f2, "\t ",move(60), "_") X write(f2, "\t ", tab(0), "\")") X } X else write(f2, tab(0), "\")") X } X } X write(f2, "\t#") X write(f2, "\t# Uncomment the following if you want a look at the state and goto") X write(f2, "\t# tables. If you aren't planning on looking at them, find the") X write(f2, "\t# procedure definition for dump_lists below, and delete it. Why") X write(f2, "\t# keep it around if it's not being used?") X write(f2, "\t#") X write(f2, "\t# dump_lists(&errout, alst, glst)") X write(f2, " }") X write(f2, " #") X write(f2, " # New, not recursive, invocation; reset stacks, line number and") X write(f2, " # error count.") X write(f2, " #") X write(f2, " start_symbol := ", image(start_symbol)) X write(f2, " /err_state := 0") X write(f2, " /state_stack := [1] & line_number := 0 & errors := 0") X write(f2, " /value_stack := []") X write(f2, " /next_token := create iparse_tokens(stream)") X write(f2, "") X write(f2, " # &trace := -1") X write(f2, "") X write(f2, " while token := @next_token do {") X write(f2, "\trepeat {") X write(f2, "\t act := \\alst[state_stack[1]][token.sym] | {") X write(f2, "\t\t#") X write(f2, "\t\t# You can replace this error handler with whatever you") X write(f2, "\t\t# like, and have it do whatever you like.") X write(f2, "\t\t#") X write(f2, "\t\treturn iparse_error(alst, state_stack, value_stack,") X write(f2, "\t\t\t\t token, next_token, err_state + 1)") X write(f2, "\t }") X write(f2, "") X write(f2, "\t # If we're not working on an error production, assume that") X write(f2, "\t # we have a fully (re)synchronized parser, & clear err_state. ") X write(f2, "\t #") X write(f2, "\t (\\last_symbol | token.sym) == \"error\" | { err_state := 0 }") X write(f2, "\t last_symbol := token.sym") X write(f2, "") X write(f2, "\t case type(act) of {") X write(f2, "\t \"SH\" : {") X write(f2, "\t\t # push the next state onto the state stack") X write(f2, "\t \t push(state_stack, act.state)") X write(f2, "\t\t # push the current token's literal value onto the") X write(f2, "\t\t # value stack") X write(f2, "\t\t push(value_stack, token.str)") X write(f2, "\t\t # break out of enclosing repeat loop") X write(f2, "\t\t break") X write(f2, "\t }") X write(f2, "\t \"RE\" : {") X write(f2, "\t \t arglist := []") X write(f2, "\t\t #") X write(f2, "\t\t # Pop as many elements off of the token stack as") X write(f2, "\t\t # there are symbols in the right-hand side of the") X write(f2, "\t\t # rule. Push these elements onto an argument list.") X write(f2, "\t\t #") X write(f2, "\t\t every 1 to act.size do {") X write(f2, "\t\t pop(state_stack)") X write(f2, "\t\t push(arglist, pop(value_stack))") X write(f2, "\t\t }") X write(f2, "\t\t #") X write(f2, "\t\t # Check to goto list to see what state we should") SHAR_EOF true || echo 'restore of ibpag.icn failed' fi echo 'End of part 1' echo 'File ibpag.icn is continued in part 2' echo 2 > _shar_seq_.tmp exit 0 -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Jan 5 09:20:09 1993 Received: by cheltenham.cs.arizona.edu; Tue, 5 Jan 1993 11:48:20 MST Date: Tue, 5 Jan 1993 09:20:09 MST From: "Gregg Townsend" Message-Id: <199301051620.AA19233@owl.cs.arizona.edu> To: icon-group Subject: Icon v8.7 for Solaris 2.0 Status: R Errors-To: icon-group-errors@cs.arizona.edu Version 8.7 of Icon is now available for Sun's Solaris 2.0 operating system. This implementation uses the OpenWindows X library and does not depend on any compatibility packages. Because Solaris does not come with a C compiler, Icon was built using the Cygnus gcc compiler. This compiler can be obtained by anonymous FTP from the vendor/cygnus directory on ftp.uu.net. Prebuilt binaries can be FTP'd from the /icon/binaries/unix/sun4_solaris directory on cs.arizona.edu. Nothing else is needed to use the interpreter; you will need gcc in your search path to use the compiler. Source code is available in the directory /icon/packages/unix. unix_tar.Z is the standard 8.7 source release; sun4_solar_g.Z is a configuration directory for gcc under Solaris. Both of these are compressed tar files. The "status" file inside the configuration directory notes some minor source code changes that are required to build Icon under Solaris. 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 Jan 6 05:37:05 1993 Received: by cheltenham.cs.arizona.edu; Wed, 6 Jan 1993 06:06:47 MST Date: 6 Jan 93 05:37:05 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Icon for Linux? Message-Id: <1993Jan6.053705.21698@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 Anyone hear of Icon running under Linux yet (with X extensions)? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Jan 6 10:36:11 1993 Received: by cheltenham.cs.arizona.edu; Wed, 6 Jan 1993 11:03:00 MST Date: Wed, 6 Jan 1993 10:36:11 MST From: "Clint Jeffery" Message-Id: <199301061736.AA17247@chuckwalla.cs.arizona.edu> To: uchinews!ellis!goer@speedy.wisc.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (Richard L. Goerwitz's message of 6 Jan 93 05:37:05 GMT <1993Jan6.053705.21698@midway.uchicago.edu> Subject: Icon for Linux? Status: R Errors-To: icon-group-errors@cs.arizona.edu Richard Goerwitz writes: Anyone hear of Icon running under Linux yet (with X extensions)? I built Icon under Linux with X extensions over Christmas break using configuration information supplied some time ago by Charles Hedrick. [Linux is a free POSIX-compliant UNIX for 386/486 PC's.] So the basic answer is: it works, with a little effort, and appears to be very fast. I wasn't with the Linux machine long enough to run the test suite or benchmarks. I'd be happy to discuss details and/or provide assistance by e-mail to folks trying to build Icon under Linux. Clint From icon-group-sender Thu Jan 7 17:29:31 1993 Received: by cheltenham.cs.arizona.edu; Thu, 7 Jan 1993 19:39:45 MST Date: 7 Jan 93 17:29:31 GMT From: agate!spool.mu.edu!uwm.edu!rpi!utcsri!newsflash.concordia.ca!mizar.cc.umanitoba.ca!rahardj@ucbvax.Berkeley.EDU (Budi Rahardjo) Organization: University of Manitoba, Winnipeg, Canada Subject: Re: Icon for Linux? Message-Id: References: <199301061736.AA17247@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In <199301061736.AA17247@chuckwalla.cs.arizona.edu> "Clint Jeffery" writes: ... >I'd be happy to discuss details and/or provide assistance by e-mail to >folks trying to build Icon under Linux. Could you upload the binaries/diff somewhere for anonymous ftp ? Thanks -- budi -- Budi Rahardjo Unix Support - Computer Services - University of Manitoba From icon-group-sender Mon Jan 11 11:07:00 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 05:59:11 MST Date: Mon, 11 Jan 93 11:07 EST From: MYankowski@DOCKMASTER.NCSC.MIL Subject: MS Windows Version of ICon To: icon-group@cs.arizona.edu Message-Id: <930111160736.500430@DOCKMASTER.NCSC.MIL> Status: R Errors-To: icon-group-errors@cs.arizona.edu I remember reading about a Microsoft Windows version of Icon. Is this work still going on? Mike From icon-group-sender Tue Jan 12 05:59:55 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 06:00:11 MST Date: Tue, 12 Jan 1993 05:59:55 MST From: "Ralph Griswold" Message-Id: <199301121259.AA26913@cheltenham.cs.arizona.edu> To: MYankowski@DOCKMASTER.NCSC.MIL, icon-group@cs.arizona.edu Subject: Re: MS Windows Version of ICon Status: R Errors-To: icon-group-errors@cs.arizona.edu As far as I know, nothing substantive has been done toward a Microsfot Windows version of Icon. 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 Tue Jan 12 14:06:54 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 11:43:34 MST Date: Tue, 12 Jan 1993 14:06:54 +0100 From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Message-Id: <9301121306.AA10349@soir.informatik.uni-tuebingen.de> To: icon-group@cs.arizona.edu Subject: Pattern matching in Icon? Status: R Errors-To: icon-group-errors@cs.arizona.edu Would it be feasible to have {SML, Miranda, Hope blabla}-style pattern matching in Icon. (More specifically, a case state that has patterns instead of literals in the cases.) I think it would fit in neatly with the data constructors Icon has, and greatly increase its useability for writing things like compilers in Icon, where you want to branch on the structure of some data object rather than on a specific object. What possible extensions/further developments for Icon are under way, anyway? Cheers :-> Chipsy From icon-group-sender Tue Jan 12 18:23:22 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 11:44:59 MST Date: 12 Jan 93 18:23:22 GMT From: ucivax!omalley@ucbvax.Berkeley.EDU (Owen O'Malley) Organization: UC Irvine Department of ICS Subject: Putting strings into executables Message-Id: <2B530C9A.21878@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 When we release software, we are supposed to include the copyright both in the source code comments and in the executable. Well, I released some software written in Icon and I tried including the string, but when I ran "strings" over the executable it did not find it. I'm guessing that icont compresses the string literals. Is this true? Is there a way to avoid it? 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 Jan 12 12:27:03 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 12:50:06 MST Message-Id: <9301121927.AA15836@turing.cse.nau.edu> From: sbw@turing.cse.nau.edu (Steve Wampler) Date: Tue, 12 Jan 1993 12:27:03 MST In-Reply-To: Michael Sperber's mail message of Jan 12, 2:06pm. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Subject: Re: Pattern matching in Icon? Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu This isn't obvious, but the case clauses in Icon are full Icon expressions: case x of { f(x) : blah.... is completely reasonable. -- Steve Wampler {....!arizona!naucse!sbw} {sbw@turing.cse.nau.edu} From icon-group-sender Tue Jan 12 12:28:34 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 12:50:23 MST Message-Id: <9301121928.AA15845@turing.cse.nau.edu> From: sbw@turing.cse.nau.edu (Steve Wampler) Date: Tue, 12 Jan 1993 12:28:34 MST In-Reply-To: Owen O'Malley's mail message of Jan 12, 6:23pm. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: ucivax!omalley@ucbvax.Berkeley.EDU (Owen O'Malley) Subject: Re: Putting strings into executables Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu No, string literals are not compressed, but they don't look like C-style strings. -- Steve Wampler {....!arizona!naucse!sbw} {sbw@turing.cse.nau.edu} From icon-group-sender Tue Jan 12 12:46:33 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 12:50:30 MST Date: Tue, 12 Jan 1993 12:46:33 MST From: "Ralph Griswold" Message-Id: <199301121946.AA07878@cheltenham.cs.arizona.edu> To: ucivax!omalley@ucbvax.Berkeley.EDU Subject: Re: Putting strings into executables Cc: icon-group Status: R Errors-To: icon-group-errors@cs.arizona.edu Literal strings in Icon programs are placed, uncompressed, in the icode ("exectuable") file produced by icont. They will be at the end of the file, so you need (at least on our system) strings - foo where foo is produced by icont foo.icn It might be wise to surround the literal with nulls or newlines to be sure strings(1) finds it -- I'm not sure that such strings are automatically null-terminated by icont. 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 Tue Jan 12 14:01:08 1993 Received: by cheltenham.cs.arizona.edu; Tue, 12 Jan 1993 19:25:33 MST Date: Tue, 12 Jan 93 14:01:08 CST From: "Richard L. Goerwitz" Message-Id: <9301122001.AA21292@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: Pattern matching Status: R Errors-To: icon-group-errors@cs.arizona.edu >Would it be feasible to have {SML, Miranda, Hope blabla}-style pattern >matching in Icon. (More specifically, a case state that has patterns >instead of literals in the cases.) I think it would fit in neatly >with the data constructors Icon has, and greatly increase its >useability for writing things like compilers in Icon, where you want >to branch on the structure of some data object rather than on a >specific object. There are just so many bits of syntactic sugar one can add to a language before it becomes bloated. Maybe I'm not understanding correctly what you mean, but I don't see anything wrong with: while line := read() do { line ? { if match("this") then X else if match("that") then Y else if match("something else") then Z } } Anyone who knows Icon will immediately recognize this code fragment as implementing a case-like structure for patterns rather than values. Writing a compiler, though, really requires more than a simple set of scanning routines, so I'm not sure that this is what you want either. In most cases, deterministic lexical analyzers have to work on a charac- ter-by-character basis, with little or no backtracking. The lexical analyzers then feed tokens to parsers that operate on stack structures, and don't read the input stream as such. I keep hoping somebody with more theoretical background than I will post a good compiler compiler for Icon some day. -Richard Goerwitz goer@midway.uchicago.edu From icon-group-sender Wed Jan 13 17:26:28 1993 Received: by cheltenham.cs.arizona.edu; Thu, 14 Jan 1993 05:22:48 MST Date: 13 Jan 93 17:26:28 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Steve Wampler) Subject: Re: Pattern matching in Icon? Message-Id: <9301131726.AA18608@turing.cse.nau.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu On Jan 13 at 5:01pm, Michael Sperber writes: } I'll try to make myself even clearer than last time. Let's take } the example again: } } case s of { } syntax_tree("let", args) : ... # args is assigned to the arguments } # field of s } syntax_tree("apply", args) : ... } } } } Here, I probably glitched a bit, and things would have to look a bit } different syntactically. What I meant though, was that the case is } not supposed to evaluate the syntax_trees. Instead it's supposed to } look if a is a record of type syntax_tree, and, if so, execute the } first case, if the first component is "let", binding args to the } second component for the following statements. Admittedly, I didn't } think as much about syntax as I should have, and more work would have } to be done on it. However, I hope it's clear what I mean. } } Cheers :-> Chipsy } Ah, I think I fully understand. I think this would take quite a bit of changes to Icon to work - consider that in Icon, 'syntax_tree' is just a function call, the user could (in a perverse moment), do syntax_tree := f and the case statement suddenly changes. I think the problem could be resolved in specific instances, but it would greatly complicate the case statement: (if this function is a record constructor, then don't evaluate it, it's a pattern...) but I don't see how to do it in general. I think you would have to restrict case clauses to *only* literals and patterns, which is more restrictive than now (not that it would likely impact many people). In the present form, you can still do it by building your own set of pattern-matching operations (since the runtime system has to have something to do it anyway): case s of { match_syntax_tree("let",s) : ... match_syntax_tree("apply",s) :... which would require you (as the programmer) to establish the pattern-matching rules - though to me that's a net win, since I might want to do some form of pattern matching that the language implementor didn't anticipate (such as some form of 'symantic' pattern matching). -- Steve Wampler {....!arizona!naucse!sbw} {sbw@turing.cse.nau.edu} From icon-group-sender Fri Jan 15 04:23:00 1993 Received: by cheltenham.cs.arizona.edu; Fri, 15 Jan 1993 06:25:49 MST Date: 15 Jan 93 04:23:00 GMT From: agate!spool.mu.edu!uwm.edu!linac!newsaintmail@ucbvax.Berkeley.EDU (Michael Glass) Organization: Fermi National Accelerator Laboratory, AD/Controls Subject: Re: Pattern matching in Icon? Message-Id: <14JAN199323230672@adcalc.fnal.gov> References: <9301121306.AA10349@soir.informatik.uni-tuebingen.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu On the principle of always pick an easy target, let me jump in. What Mr. Sperber is missing is the "prolog" control structure. His example looks like this: prolog d of { syntax_tree("let", Args) :- ... syntax_tree("apply", Args) :- ... ... } Where d is a set of records called the "data base", the prolog control structure attempts to unify records with various case clauses, and I need not belabor the point any further. One of Icon's main charms to an old procedural programmer like me is its ability to be mildly declarative. Within fundamentally procedural code I can create bounded contexts for well-behaved declarative statements. Pattern matching and goal directed evaluation are examples of the bounded contexts, and the declarative statements contain generators of some sort. The "prolog" joke has some plausibility. You could fit it into Icon rather naturally. To do so would be a mistake, it seems to me, but since programming in Icon has _some_ declarative feel we should not be surprised that the declarative programmers of the world clamor for more. -- Michael Glass | glass@adcalc.fnal.gov | Parkinson's Coffee Pot From icon-group-sender Fri Jan 15 11:09:13 1993 Received: by cheltenham.cs.arizona.edu; Fri, 15 Jan 1993 06:26:01 MST Date: Fri, 15 Jan 1993 11:09:13 +0100 From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Message-Id: <9301151009.AA10873@soir.informatik.uni-tuebingen.de> To: icon-group@cs.arizona.edu In-Reply-To: (Steve Wampler)'s message of Wed, 13 Jan 93 18:26:28 +0100 <9301131726.AA18608@turing.cse.nau.edu*MAILER@cdc2-gw.rrzn.uni-hannover.de> Subject: Pattern matching in Icon? Status: R Errors-To: icon-group-errors@cs.arizona.edu Steve Wampler writes: >Ah, I think I fully understand. I think this would take quite a >bit of changes to Icon to work - consider that in Icon, 'syntax_tree' >is just a function call, the user could (in a perverse moment), do > > syntax_tree := f > >and the case statement suddenly changes. I think the problem could >be resolved in specific instances, but it would greatly complicate the >case statement: > > (if this function is a record constructor, then don't evaluate it, > it's a pattern...) > >but I don't see how to do it in general. I think you would have >to restrict case clauses to *only* literals and patterns, which is >more restrictive than now (not that it would likely impact many people). > >In the present form, you can still do it by >building your own set of pattern-matching operations (since the >runtime system has to have something to do it anyway): > > case s of { > match_syntax_tree("let",s) : ... > match_syntax_tree("apply",s) :... > >which would require you (as the programmer) to establish the pattern-matching >rules - though to me that's a net win, since I might want to do some form >of pattern matching that the language implementor didn't anticipate (such >as some form of 'symantic' pattern matching). The syntactic issue I glitched on was to use the standard case statement for pattern matching. How about having a "pattern_case" (or a "match ... of") or some separate thing, where only patterns are allowed (meaning: only direct data structure constructors). But I think I still haven't been able to get through fully with my ideas. The above construct would not do what I meant. Also, Bob Alexander writes: >Is this an Icon-esque paraphrase of the structure you want, or something >close? Or do I completely fail to understand the concept? > > case type(s) || "::" || s[1] of { > "syntax_tree::let": { > s[2] := args > ... > } > "syntax_tree::apply": { > s[2] := args > ... > } > >(The "::" is an arbitrary separator). This permanently alters the second >field of "s" -- if that's not okay it could be cured by working on a >copy of s. So I'll try yet again: record syntax_tree(operator, arguments) match of { syntax_tree("let", a) : { # Now, we get here if evaluates to a # syntax_tree record with the operator component "let". # In this branch, a is bound to the arguments componen # of (NOT the other way around!). } ... } In functional languages, this greatly simplifies operating on any kind of recursive data structures, which syntax trees, say, happen to be. That is exactly why many people consider {SML, Hope, Miranda} ideally suited for compiler writing. Icon does not have this feature, but it was designed with compiler design in mind. It is better suited for the early stages of a compiler, but worse for actual program transformation and code generation. Cheers :-> Chipsy From icon-group-sender Fri Jan 15 13:22:44 1993 Received: by cheltenham.cs.arizona.edu; Fri, 15 Jan 1993 20:15:40 MST Date: Fri, 15 Jan 93 13:22:44 PST From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9301152122.AA04938@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: Pattern matching in Icon? Status: R Errors-To: icon-group-errors@cs.arizona.edu Wow, this seems to be a difficult concept to communicate! However, considering your last communication, I think my code fragment does what you want, in current Icon, without muddying things up very much. Let me re-state it with some clarifying additions: record syntax_tree(operator, arguments) ... case type(s) || "::" || s[1] of { # create a key with s's data type # ("syntax_tree") and the operator "syntax_tree::let": { # execute this code if the "type" # is "syntax_tree" and the operator # is "let" s.arguments := a # assign "a" to the "arguments" field ... # etc. } "syntax_tree::apply": { # etc. s.arguments := a ... } (The "::" is an arbitrary separator). This permanently assigns to the arguments field of "s" -- if that's not okay it could be made "temporary" by working on a copy of s. Am I still missing the point? -- Bob Alexander Metaphor Computer Systems (415) 966-0751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex From icon-group-sender Fri Jan 15 22:31:02 1993 Received: by cheltenham.cs.arizona.edu; Sat, 16 Jan 1993 05:56:49 MST Date: 15 Jan 93 22:31:02 GMT From: agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!, @ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: detab/entab - anyone use them? Message-Id: <1993Jan15.223102.11726@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I keep hearing suggestions about what Icon oughta add, which is great. I have a suggestion about what might be removed. In the six years or so that I've known about Icon, I've used detab/entab fewer than five times. My feeling is that they'd be perfectly good implemented as library routines, and not as part of the Icon lib- rary. Does anyone out there use detab/entab a lot?? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat Jan 16 05:59:45 1993 Received: by cheltenham.cs.arizona.edu; Sat, 16 Jan 1993 06:00:16 MST Date: Sat, 16 Jan 1993 05:59:45 MST From: "Ralph Griswold" Message-Id: <199301161259.AA02671@cheltenham.cs.arizona.edu> To: goer@midway.uchicago.EDU, icon-group Subject: endtab/detab Status: R Errors-To: icon-group-errors@cs.arizona.edu I'll be interested in seeing what response there is to your suggestion for removing entab() and detab() from Icon. However, once you have a large user community and widely distributed documentation, it's not feasible to remove something, even if it's little used. Worse, it's not feasible to redesign something that was done badly. That's one of the reasons language design is so hard; once you've done it, implemented it, documented it, and released it, you're stuck with 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 Sat Jan 16 07:09:38 1993 Received: by cheltenham.cs.arizona.edu; Sat, 16 Jan 1993 06:11:25 MST Date: 16 Jan 1993 07:09:38 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Icon on smaller unixes To: icon-group@cs.arizona.edu Message-Id: <01GTKT615ZHU8WWSBK@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'm interested in maybe getting a 386 or 486 PC and loading a small unix on it. But I'd like to have icon work on it as well. I think I've heard of these variants: o Coherent o Linux o Interactive And I'm interested in knowing if any of these can run icon and if it is easy to set up or if it really doesn't matter all that much. I have set up icon on other mysterious 'unix' systems (i.e. Astronautics ZS1). Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia From icon-group-sender Sat Jan 16 07:20:43 1993 Received: by cheltenham.cs.arizona.edu; Sat, 16 Jan 1993 11:48:55 MST Date: 16 Jan 1993 07:20:43 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: entab/detab To: icon-group@cs.arizona.edu Message-Id: <01GTKTGGRTRG8WWSBK@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 use detab() a lot. I have yet to use entab(). Funny things like the vi editor take liberties and insert tabs where it feels like, and I don't want them 99% of the time. In VMS source code, people randomly insert tabs, and I like to get rid of them. The need the entab() is dubious I think. A poormans' compression algorhythm? I think entab() is retained for completeness rather utility IMHO. Ideally, I think ASCII ought to get rid the TAB character, and then the entab()/detab() would become meaningless. 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 Jan 16 16:32:36 1993 Received: by cheltenham.cs.arizona.edu; Sat, 16 Jan 1993 20:44:22 MST Date: Sat, 16 Jan 93 16:32:36 PST From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9301170032.AA05630@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: entab/detab Status: R Errors-To: icon-group-errors@cs.arizona.edu I use entab and detab quite a bit -- often the text I want to process is entabbed, and often I want to entab my output. Interestingly, those routines once *were* library routines (in a slightly different form), and made it into the language somewhere around version 6. Certainly they *could* be library routines, but this sort of operations is way faster as a primitive than if it were written in Icon. I personally don't feel that it clutters up the language. It would be interesting to create a questionaire to determine which features are rarely used. E.g. how often do you use string invocation, or PDCOs, or run-time error conversion to failure? I think an interesting (significant) project would be to create a smaller but more extensible Icon. The "real" Icon would just be a nucleus, and much of the functionality could be added using new yet-to-be-conceived extensibility features. The extensibility cabilities would include (a) "easy" addition of new primitives written in C (whatever that means -- maybe without relinking the interpreter, or at least with changes limited to one module. Maybe dynamic linking -- that seems to be a trend and is implemented in popular platforms now.) (b) addition of new facilities written in Icon without creating name conflicts. (c) overloading of existing functions (like copy()) and operators to handle new data types. Has anyone else out there had a similar fantasy? Then things like entab, X-stuff, and maybe even string scanning could be "extensions". -- Bob Alexander Metaphor Computer Systems (415) 966-0751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex From icon-group-sender Sun Jan 17 08:01:24 1993 Received: by cheltenham.cs.arizona.edu; Sun, 17 Jan 1993 09:11:43 MST Date: 17 Jan 1993 08:01:24 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: RE:entab/detab To: icon-group@cs.arizona.edu Message-Id: <01GTM84WCM828WWTTE@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: IN%"alex@laguna.Metaphor.COM" 16-JAN-1993 21:57:19.34 > To: IN%"icon-group@cs.arizona.edu" > Subj: RE: entab/detab > I use entab and detab quite a bit -- often the text I want to process > is entabbed, and often I want to entab my output. Kind of like my reason but in reverse. I guess some people have a use for tabs. > Interestingly, those routines once *were* library routines (in a > slightly different form), and made it into the language somewhere > around version 6. Certainly they *could* be library routines, but this > sort of operations is way faster as a primitive than if it were written > in Icon. I personally don't feel that it clutters up the language. > It would be interesting to create a questionaire to determine which > features are rarely used. E.g. how often do you use string invocation, > or PDCOs, or run-time error conversion to failure? I think you'd find a pretty even mixture of all kinds overall. I never use entab() or coexpressions. Someone else might understand coexpressions and think they're the greatest thing since the byte. > I think an interesting (significant) project would be to create a > smaller but more extensible Icon. The "real" Icon would just be a > nucleus, and much of the functionality could be added using new > yet-to-be-conceived extensibility features. The extensibility > cabilities would include > (a) "easy" addition of new primitives written in C (whatever > that means -- maybe without relinking the interpreter, or > at least with changes limited to one module. Maybe dynamic > linking -- that seems to be a trend and is implemented in > popular platforms now.) Many icon programmers are not computer science majors. Those of us whose skill in C is little to none, need/use those added features the most, and have the least chance of rolling our own. Variant translators and personal interpreters sound cool in conversation, but many of us don't have a clue as to what they can do for us. > (b) addition of new facilities written in Icon without creating > name conflicts. > (c) overloading of existing functions (like copy()) and > operators to handle new data types. More vendors these days are segmenting their product lines. They tell you this is to make the product more 'modular'. They tell you that you should not have to pay for features you don't use, and this modularity will save you all kinds of money because of that. (Where would unix be if we had to buy C and tcp/ip and each utility as a separate line item?) What happens is the stripped down core gets sold at the regular price, every little value added feature becomes a line item. Now ICON is not a profit driven item like C++ or WordPerfect or Netware. The part that is unpleasant here is that code won't be as portable unless you ship all your icon language enhancements with them, and maybe your enhancements may not like my enhancements. By keeping what some consider a lot of language bloating in a central version, icon can maintain maximum code portability. And I'll let hardware improvements make up for the added memory or speed requirements. > Has anyone else out there had a similar fantasy? Then things like > entab, X-stuff, and maybe even string scanning could be "extensions". I'd like to see a few things added to icon. Here's my wishlist: 1) every to by First for these to work with reals, and maybe someday with any type. &next &prior &first &last to be used also for referencing when numbers may not be meaningful. This may also contribute toward true scanning features for lists, sets, tables, and files. 2) User defined operator $ ? Maybe just the $ character or maybe $+. Maybe this is superfluous because procedures can do it all to. But, I think it's no more pathological than string invocation which already exists. 3) Two way pipes I know this one is probably tricky. I'd like to open a process for read and write, then I'd only need one file handle for a piping dialog. I can also then completely control the process IO. If I open a process for write I can't directly read its output unless I redirect it to a file and read that in separately. This may not always be possible. 4) OS independent files Since icon is now on VMS, Unix, MAC, DOS, IBM and each has a file system syntax for files, directories, and disks, it would sure be easier to write totally portable code if the icon language had a universal file system syntax. Then the backend interpreter/compiler would handle mapping this syntax to the file system of the target OS. > -- Bob Alexander > Metaphor Computer Systems (415) 966-0751 alex@metaphor.com > ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex 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 Jan 17 20:16:44 1993 Received: by cheltenham.cs.arizona.edu; Sun, 17 Jan 1993 20:01:35 MST Message-Id: <9301180116.AA05090@vtopus.cs.vt.edu> Subject: Re: endtab/detab To: ralph@cs.arizona.edu (Ralph Griswold) Date: Sun, 17 Jan 1993 20:16:44 -0500 (EST) From: Thomas F. Reid Cc: reid@vtopus.cs.vt.edu (Thomas F. Reid), icon-group@cs.arizona.edu In-Reply-To: <199301161259.AA02671@cheltenham.cs.arizona.edu> from "Ralph Griswold" at Jan 16, 93 05:59:45 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1504 Status: R Errors-To: icon-group-errors@cs.arizona.edu > However, once you have a large user community and widely distributed > documentation, it's not feasible to remove something, even if it's > little used. Worse, it's not feasible to redesign something that > was done badly. That's one of the reasons language design is so > hard; once you've done it, implemented it, documented it, and > released it, you're stuck with 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) > I think that a change of paradigm is needed for language design. I believe that the language designer should be encouraged to release a new language design and implementation every (say) 5-8 years along with a translator to/from the new/old versions. This way, the language designer can correct old mistakes and extend the language "right" into new concepts without paying too much homage to the cursed god of upward compatibility. There have been too many elegant languages ruined by trying to extend them into areas that the original design cannot comfortably permit. Modula-2 comes to mind. If the two versions are fundamentally the same, then the delta between implementations and the to/from translators should be straightforward. It is extra work for the language designer, but it has the reward of allowing the language to evolve gracefully rather than stagnate or accept awkward extensions. Whatcha think? Tom From icon-group-sender Mon Jan 18 13:52:51 1993 Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 07:55:00 MST Date: Mon, 18 Jan 1993 13:52:51 +0100 From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Message-Id: <9301181252.AA17972@soir.informatik.uni-tuebingen.de> To: icon-group@cs.arizona.edu In-Reply-To: (Michael Glass)'s message of Fri, 15 Jan 93 05:23:00 +0100 <14JAN199323230672@adcalc.fnal.gov*MAILER@cdc2-gw.rrzn.uni-hannover.de> Subject: Pattern matching in Icon? Status: R Errors-To: icon-group-errors@cs.arizona.edu Well, at least one person got it (partially) right. I had't thought of Prolog as the inspiration for the control structure I had proposes, but in fact, a unification is what would happen in pattern matching, albeit in a much more limited sense, that is also easier and more straightforward to implement. As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda, ML or the like?!), the proposed scheme could be used to implement structural recursion VERY elegantly - with the added power of generators. Steve Wampler proposed ... >I guess the only real debate is whether to add it into the language >or not: > > case s := of { > match_syntax_tree(s,"let") : {a := s.arguments > ... > } > > ... > > procedure match_syntax_tree(s, op) ># match a pattern, in this case, the pattern is simple... > if type(s) == "syntax_tree" & s.operator == "let" then > return s > end > >or, though I find this less readable: > > case s := of { > 1(match_syntax_tree(s,"let"), a := s.arguments) : {... > ... > >not as visually pleasing as a new syntax would be, but I contend >this would be more flexible and generalizes better than fixed >patterns would... This stuff looks extremely awkward to me, in fact even more awkward than doing the pattern matching explicitly. It would mean having separate procedures (with different names, too!) for each constructor AND combination of constants/unknowns. My proposal was exactly aimed at removing that syntactic clumsiness. As I said (again, and again), that's exactly why compilers are so much easier to write and read in functional languages. The way to go would probably be using the variant translator feature of Icon to do the job. Anyone interested? (If I'm not all alone with this, I might actually get around to doing it, some day ...) Cheers :-> Chipsy From icon-group-sender Mon Jan 18 14:33:16 1993 Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 11:22:58 MST Date: 18 Jan 93 14:33:16 GMT From: timbuk.cray.com!hemlock.cray.com!cargo@uunet.uu.net (David S. Cargo) Organization: Cray Research, Inc. Subject: Re: detab/entab - anyone use them? Message-Id: <1993Jan18.083316.23978@hemlock.cray.com> References: <1993Jan15.223102.11726@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I use some utilities that I wrote that use entab and detab. You are right that I use it for "poor man's text compression." In particular, by trimming trailing blanks and entabing the result, some large listing files are reduced to half their size without affecting their appearance. I like having entab/detab as functions in the language. o o cargo@escargot.cray.com \_____/ (612) 683-5591 /=O=O=\ _______ DDDD SSSS CCCC / ^ \ /\\\\\\\\ D D S C \ \___/ / /\ ___ \ D D SSS C \_ V _/ /\ /\\\\ \ D D S C \ \__/\ /\ @_/ / DDDDavid SSSS. CCCCargo \____\____\______/ From icon-group-sender Mon Jan 18 08:43:05 1993 Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 11:23:36 MST Message-Id: <9301181543.AA01233@turing.cse.nau.edu> From: sbw@turing.cse.nau.edu (Steve Wampler) Date: Mon, 18 Jan 1993 08:43:05 MST In-Reply-To: Michael Sperber's mail message of Jan 18, 1:52pm. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Subject: Re: Pattern matching in Icon? Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu On Jan 18 at 1:52pm, Michael Sperber writes: } } Well, at least one person got it (partially) right. I had't } thought of Prolog as the inspiration for the control structure } I had proposes, but in fact, a unification is what would happen } in pattern matching, albeit in a much more limited sense, that } is also easier and more straightforward to implement. } As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda, } ML or the like?!), the proposed scheme could be used to } implement structural recursion VERY elegantly - with the } added power of generators. But - you seem to be saying that the language designer is going to implement *exactly* the pattern matching facility you want in *exactly* the right way - once you add something like that to a language, it's *very* hard to change! What I'm saying is that Icon already has a facility that can not only do everything you want, with really very little effort (you write your pattern-matching functions once) but it also has *the ability to be extended* as you, the programmer, sees fit. Furthermore, your proposed pattern matching construct violates syntactic consistency - it looks like something else (witness the confusion those of us who have used Icon extensively have with 'seeing' what it is you want) - normal Icon exprssions. It also changes the structure of the language so that there are places where arbitrary expressions are allowed and not patterns, and places where patterns are allowed and not arbitrary expressions (with very little syntactic clues as to what is needed where!). Finally, you're introducing a 'sublanguage' into Icon (just as the pattern matching of SNOBOL was a sublanguage to SNOBOL). Icon is already a fairly complex language, I'm not convinced that adding syntax to support a fairly limited operation is worth it, *especially* given that Icon already has a more powerful capability with its case expression. } Steve Wampler proposed ... } } >I guess the only real debate is whether to add it into the language } >or not: } > } > case s := of { } > match_syntax_tree(s,"let") : {a := s.arguments } > ... } > } } > } > ... } > } > procedure match_syntax_tree(s, op) } ># match a pattern, in this case, the pattern is simple... } > if type(s) == "syntax_tree" & s.operator == "let" then } > return s } > end } > } >not as visually pleasing as a new syntax would be, but I contend } >this would be more flexible and generalizes better than fixed } >patterns would... } } This stuff looks extremely awkward to me, in fact even more awkward You find adding two assignment operators to your original syntax 'extremely' awkward? Why? More awkward, yes. But I don't see that as 'extremely'! Or is that you're writing your own pattern matching function(s) that you see as awkward? Again, you write them once, hide them away in a library, and presto, no difference there with having them built into the language -- except that you can *change* them! } than doing the pattern matching explicitly. It would mean having } separate procedures (with different names, too!) for each constructor } AND combination of constants/unknowns. My proposal was exactly Nonsense. I named it 'match_syntax_tree'. You could just as easily call it 'pat_match', or whatever, and implement an entire pattern matcher in the one procedure. Yes, you have to *write* the procedure to do what you want, but as I said, I consider that flexibility a net win (in fact, personally, I find it a *huge* win - I *like* being able to describe *exactly* what I want!) And you only have to write it *once*, anyway... Plus you can have different pattern-matchers for different contexts! } aimed at removing that syntactic clumsiness. As I said (again, } and again), that's exactly why compilers are so much easier to } write and read in functional languages. The way to go would } probably be using the variant translator feature of Icon to do } the job. Anyone interested? (If I'm not all alone with this, I } might actually get around to doing it, some day ...) Now that I can see, particularly as an experiment - you could get the syntax you want that way, and Icon already has the capability semantically. The current syntax just doesn't bother me enough to justify my time on it though. You'll still have to write the 'awkward' procedures for actually doing the pattern matching, of course. } Cheers :-> Chipsy -- Steve Wampler {....!arizona!naucse!sbw} {sbw@turing.cse.nau.edu} From icon-group-sender Mon Jan 18 16:35:57 1993 Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 11:23:55 MST Date: 18 Jan 93 16:35:57 GMT From: agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: detab/entab - anyone use them? Message-Id: <1993Jan18.163557.6566@midway.uchicago.edu> References: <1993Jan15.223102.11726@midway.uchicago.edu>, <1993Jan18.083316.23978@hemlock.cray.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 like having entab/detab as functions in the language. Yes, but couldn't they just as well be library functions, and not part of the core language implementation? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Jan 15 10:09:13 1993 Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 05:47:35 MST Date: 15 Jan 93 10:09:13 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Michael Sperber) Subject: Pattern matching in Icon? Message-Id: <9301151009.AA10873@soir.informatik.uni-tuebingen.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Steve Wampler writes: >Ah, I think I fully understand. I think this would take quite a >bit of changes to Icon to work - consider that in Icon, 'syntax_tree' >is just a function call, the user could (in a perverse moment), do > > syntax_tree := f > >and the case statement suddenly changes. I think the problem could >be resolved in specific instances, but it would greatly complicate the >case statement: > > (if this function is a record constructor, then don't evaluate it, > it's a pattern...) > >but I don't see how to do it in general. I think you would have >to restrict case clauses to *only* literals and patterns, which is >more restrictive than now (not that it would likely impact many people). > >In the present form, you can still do it by >building your own set of pattern-matching operations (since the >runtime system has to have something to do it anyway): > > case s of { > match_syntax_tree("let",s) : ... > match_syntax_tree("apply",s) :... > >which would require you (as the programmer) to establish the pattern-matching >rules - though to me that's a net win, since I might want to do some form >of pattern matching that the language implementor didn't anticipate (such >as some form of 'symantic' pattern matching). The syntactic issue I glitched on was to use the standard case statement for pattern matching. How about having a "pattern_case" (or a "match ... of") or some separate thing, where only patterns are allowed (meaning: only direct data structure constructors). But I think I still haven't been able to get through fully with my ideas. The above construct would not do what I meant. Also, Bob Alexander writes: >Is this an Icon-esque paraphrase of the structure you want, or something >close? Or do I completely fail to understand the concept? > > case type(s) || "::" || s[1] of { > "syntax_tree::let": { > s[2] := args > ... > } > "syntax_tree::apply": { > s[2] := args > ... > } > >(The "::" is an arbitrary separator). This permanently alters the second >field of "s" -- if that's not okay it could be cured by working on a >copy of s. So I'll try yet again: record syntax_tree(operator, arguments) match of { syntax_tree("let", a) : { # Now, we get here if evaluates to a # syntax_tree record with the operator component "let". # In this branch, a is bound to the arguments componen # of (NOT the other way around!). } ... } In functional languages, this greatly simplifies operating on any kind of recursive data structures, which syntax trees, say, happen to be. That is exactly why many people consider {SML, Hope, Miranda} ideally suited for compiler writing. Icon does not have this feature, but it was designed with compiler design in mind. It is better suited for the early stages of a compiler, but worse for actual program transformation and code generation. Cheers :-> Chipsy From icon-group-sender Tue Jan 19 01:36:47 1993 Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 05:48:11 MST Date: Tue, 19 Jan 1993 01:36:47 MST From: "Clint Jeffery" Message-Id: <199301190836.AA02412@chuckwalla.cs.arizona.edu> To: icon-group@cs.arizona.edu In-Reply-To: (Richard L. Goerwitz's message of 18 Jan 93 16:35:57 GMT <1993Jan18.163557.6566@midway.uchicago.edu> Subject: detab/entab - anyone use them? Status: R Errors-To: icon-group-errors@cs.arizona.edu >I like having entab/detab as functions in the language. Yes, but couldn't they just as well be library functions, and not part of the core language implementation? The conversation about a minimal, extensible Icon is getting interesting. A smaller Icon would have several compelling benefits for both users and language implementors, but I don't think we can "rob Peter to pay Paul"-- so my question is: When is something in the language, but not in the language? I think if Icon's linker knew about a standard archive of IPL procedures, and pulled out those procedures whose names appear as (undeclared) identifiers in the source program, we could make a library implementation of entab/detab so easy to use that most folks would consider them built-in. And I know a hundred people are going to jump on me for saying it, but personally I think performance is not a very good rationale for entab/detab to be built-ins -- convenience and backward compatibility are better arguments. From icon-group-sender Tue Jan 19 05:48:51 1993 Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 05:48:57 MST Date: Tue, 19 Jan 1993 05:48:51 MST From: "Ralph Griswold" Message-Id: <199301191248.AA16197@cheltenham.cs.arizona.edu> To: icon-group Subject: compiler writing Status: R Errors-To: icon-group-errors@cs.arizona.edu Just for the record, Icon was not designed with compiler writing in mind. 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 Tue Jan 19 13:52:49 1993 Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 06:26:55 MST Date: Tue, 19 Jan 1993 13:52:49 +0100 From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber) Message-Id: <9301191252.AA09689@soir.informatik.uni-tuebingen.de> To: sbw@turing.cse.nau.edu Cc: icon-group@cs.arizona.edu In-Reply-To: Steve Wampler's message of Mon, 18 Jan 1993 08:43:05 MST <9301181543.AA01233@turing.cse.nau.edu> Subject: Pattern matching in Icon? Status: R Errors-To: icon-group-errors@cs.arizona.edu Finally, it seems I've been able to get through with the essence of my proposal. Sorry for all the confusion; it's probably that I'm working on a compiler project right now that is written in SML. Pattern matching is just humungously convenient for syntax transformation. I'm sorry if the impression was that I wanted pattern matching in the core language of Icon - as I said, a variant translator would probably be closest to what I want. However, since it's stated so often that Icon is aimed at compiler writing, I thought that others might have already done some thinking on the matter: I guess it's the generators that make Icon convenient for compiler writing, but actually, that's EXACTLY what the functional-language people say of pattern matching in their languages. Now, Steve Wampler writes: >You find adding two assignment operators to your original syntax >'extremely' awkward? Why? More awkward, yes. But I don't see >that as 'extremely'! Or is that you're writing your own pattern >matching function(s) that you see as awkward? Again, you write them >once, hide them away in a library, and presto, no difference there >with having them built into the language -- except that you can >*change* them! The code itself is not that complicated. However, the advantage of pattern matching is that you usually specifiy lots of differently-structured (and recursive invokations) patterns in a single case. Since for EVERY record constructor and for EVERY structural variant of patterns that you use, you'd need to write a different matching function, indeed things would typically get very bothersome: You cannot just intuitively add patterns to a case without thinking about how the matching procedure for the specific structural variant is called and how it's invoked. So I contend: Yes, VERY awkward. Cheers :-> Chipsy From icon-group-sender Sat Jan 16 13:20:43 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Jan 1993 05:24:41 MST Date: 16 Jan 93 13:20:43 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Chris Tenaglia - 257-8765) Organization: Medical College of Wisconsin (Milwaukee, WI) Subject: Re: entab/detab Message-Id: <01GTKTGGRTRG8WWSBK@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 I use detab() a lot. I have yet to use entab(). Funny things like the vi editor take liberties and insert tabs where it feels like, and I don't want them 99% of the time. In VMS source code, people randomly insert tabs, and I like to get rid of them. The need the entab() is dubious I think. A poormans' compression algorhythm? I think entab() is retained for completeness rather utility IMHO. Ideally, I think ASCII ought to get rid the TAB character, and then the entab()/detab() would become meaningless. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Wed Jan 20 03:21:37 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Jan 1993 05:25:26 MST Date: 20 Jan 93 03:21:37 GMT From: cs.utexas.edu!qt.cs.utexas.edu!yale.edu!newsserver.jvnc.net!newsserver.technet.sg!dbsbanka@uunet.uu.net (Teo Pit Koon) Subject: need intro to 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 Hi! I'm new to this group. I would like to obtain some introductory material on ICON. Can anyone provide some information. Thanks a lot. From icon-group-sender Wed Jan 20 09:46:39 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Jan 1993 11:03:52 MST Date: Wed, 20 Jan 1993 09:46:39 MST From: "Cliff Hathaway" Message-Id: <199301201646.AA18746@javelina.cs.arizona.edu> To: icon-group Subject: Re: need intro to icon Status: R Errors-To: icon-group-errors@cs.arizona.edu > Date: 20 Jan 93 03:21:37 GMT > From: cs.utexas.edu!qt.cs.utexas.edu!yale.edu!newsserver.jvnc.net!newsserver.technet.sg!dbsbanka@uunet.uu.net (Teo Pit Koon) > Subject: need intro to icon > To: icon-group@cs.arizona.edu > Hi! > I'm new to this group. I would like to obtain some introductory material > on ICON. Can anyone provide some information. Thanks a lot. > > Get tr90-6.doc ("An Overview of the Icon Programming Language") in the /icon/doc directory in the anonymous ftp area at cs.arizona.edu. If you don't have direct ftp access, you can use our ftpmail server to obtain a copy of this file. Send e-mail to ftpmail@cs.arizona.edu, with the following lines in the message (the Subject: line is ignored): open cd /icon/doc ascii get tr90-6.doc quit The file should be mailed to you within 20 minutes of the receipt of the request. To receive further instructions on the use of the ftpmail server, send an e-mail message containing only the word help in the message body to ftpmail@cs.arizona .edu. cliff From icon-group-sender Wed Jan 20 15:27:55 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Jan 1993 11:04:21 MST Date: 20 Jan 93 15:27:55 GMT From: timbuk.cray.com!hemlock.cray.com!cargo@uunet.uu.net (David S. Cargo) Organization: Cray Research, Inc. Subject: Re: detab/entab - anyone use them? Message-Id: <1993Jan20.092756.18965@hemlock.cray.com> References: <199301190836.AA02412@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 The existance of a standard archive of IPL procedures that could be linked would be good, but I think you would want to consider the effects of string invocation. If the linker for an Icon interpreter was a dynamic linker, then the combination would be wonderfully flexible. Dynamic linking of Icon procedures would be easier in some respects than dynamic linking for native compiled C procedures. I expect considerably more context would need to be carried around in order to make it possible. David S. Cargo From icon-group-sender Wed Jan 20 12:44:36 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Jan 1993 12:44:55 MST Date: Wed, 20 Jan 1993 12:44:36 MST From: "Ralph Griswold" Message-Id: <199301201944.AA15799@cheltenham.cs.arizona.edu> To: icon-group Subject: New Implementations of Icon Status: R Errors-To: icon-group-errors@cs.arizona.edu The latest version of Icon, 8.7/8, is now available for the following platforms: MS-DOS MS-DOS/386 Macintosh MPW OS/2 UNIX VMS The OS/2, UNIX, and VMS versions support the X-Icon graphic facilities. This is the same version of Icon that has been available until now for only Unix and VMS. Compared to previous versions, this version adds some new functions, keywords, bug fixes, and other improvements. Document IPD188 (also available by FTP) describes the features of Version 8.7; Version 8.8 is essentially identical from an external standpoint and differs only in internal details. To pick up program material electronically, do an anonymous FTP to cs.arizona.edu, cd /icon, and get READ.ME for navigation instructions. Persons who have Internet mail access but not FTP access can get files via ftpmail. For instructions, send an e-mail message with the word help in the message body (not the subject line) to ftpmail@cs.arizona.edu Please address any questions to icon-project@cs.arizona.edu, not to icon-group. 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 Sat Jan 23 00:10:44 1993 Received: by cheltenham.cs.arizona.edu; Sat, 23 Jan 1993 05:57:44 MST Date: Sat, 23 Jan 93 00:10:44 MST From: whm@shepard.sunquest.com (Bill Mitchell) Message-Id: <9301230710.AA27565@shepard.sunquest.com> To: icon-group@cs.arizona.edu Subject: Re: entab/detab Status: R Errors-To: icon-group-errors@cs.arizona.edu I suspect that usage of entab/detab (mostly the latter) is related to one's dialects of implementation techniques and input designs. Personally, in ten years of Icon programming, I've never had a strong urge for either entabbing or detabbing and if I've ever used entab/detab, I can't remember it. detab users: Why do you typically use it? To make intra-line whitespace always be blanks? To make sure that what would print in column N on the screen is the Nth character in a string? What else? My opinion is that entab/detab should have been left as IPL procedures. I don't think that the idiom they provide is used frequently enough to justify inclusion in the language. From icon-group-sender Sat Jan 23 11:54:17 1993 Received: by cheltenham.cs.arizona.edu; Sat, 23 Jan 1993 16:26:43 MST Date: Sat, 23 Jan 1993 11:54:17 MST From: "Gregg Townsend" Message-Id: <199301231854.AA14607@owl.cs.arizona.edu> To: icon-group Subject: builtin Icon functions Status: R Errors-To: icon-group-errors@cs.arizona.edu I am amused by postings that state "I never use X, so I suggest that X should be removed from the library". That's an awfully self-centered view. While I never use acos() or bal(), that doesn't mean that I think they should be deleted. A more defensible criterion is the one states "If it can be programmed in Icon, it belongs in the IPL instead of being a builtin function". At least that one is unbiased. Of course, that would mean we'd lose useful functions like tab(), right(), and trim() -- and just think about the performance of a map() function written in Icon! My own opinion is that a large repertoire of preprogrammed operations greatly increases the utility of a language, whether these are supplied as operators or builtin functions. Certainly FORTRAN would not have succeeded without its math library. Accordingly, I support the inclusion of tab(), bal(), sin(), detab(), and other functions, and would like to see more. The IPL just isn't the same although it is indeed very useful and underappreciated. Usage is more difficult because one must set up the programming environment to find the files, add link directives to the Icon programs, and perhaps deal with version conflicts. The argument is made that all these functions make Icon harder to learn. There is some truth to that, especially when they're all thrown together in one large bag with no indication of where a new student should start; but that's a presentation problem, not a language problem. 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 Sun Jan 24 02:09:19 1993 Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 05:57:30 MST Date: Sun, 24 Jan 93 02:09:19 MST From: whm@shepard.sunquest.com (Bill Mitchell) Message-Id: <9301240909.AA02066@shepard.sunquest.com> To: icon-group@cs.arizona.edu Subject: Re: builtin Icon functions Status: R Errors-To: icon-group-errors@cs.arizona.edu From: gmt@cs.arizona.edu("Gregg Townsend") Date: Sat, 23 Jan 93 11:54:17 MST Subject: builtin Icon functions I am amused by postings that state "I never use X, so I suggest that X should be removed from the library". That's an awfully self-centered view. While I never use acos() or bal(), that doesn't mean that I think they should be deleted. Well, I think you need to read between the lines on such statements. I think that what's usually meant is that "I never use it and I think most persons don't use it." A defensible criterion is the one states "If it can be programmed in Icon, it belongs in the IPL instead of being a builtin function". ... But (as you know) if follow that far enough, you're left with only enough of a language to simulate a Turing machine! My own opinion is that a large repertoire of preprogrammed operations greatly increases the utility of a language, whether these are supplied as operators or builtin functions. Certainly FORTRAN would not have succeeded without its math library. Accordingly, I support the inclusion of tab(), bal(), sin(), detab(), and other functions, and would like to see more. I think a too large repertoire *decreases* the utility of the language. My canonical example: The set of functions that come with GNU Emacs Lisp. It's too much to remember and too much to read! Every additional feature adds a little weight. A little more work to implement, a little more work to document, a little more documentation to read, a little more to remember. I that the challenge in designing programming facilities is to provide a concise set of facilities that provides good coverage of the problems in the perceived domain of the language. If the set's too small, all the users end up reinventing the wheel. If too big, well, see above. Ralph once told me (c. 1982) that if I wanted to add a feature to Icon, I'd have find a feature to throw out. A few features have been added since then and mostly to the good of the language, but as a rule to put on the wall, I think it's a pretty good one. From icon-group-sender Sun Jan 24 12:19:12 1993 Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 10:48:39 MST Date: Sun, 24 Jan 93 12:19:12 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <556329@MTS.cc.Wayne.edu> Subject: Rremoving entab/detab from Icon Status: R Errors-To: icon-group-errors@cs.arizona.edu I may have used entab/detab occasionally, but I don't remember using them. Moving them to the library would make sense, however, only if semantic equivalence could be guaranteed, i.e., one could always repair a program using entab/detab by adding appropriate library loads. Lacking such equivalence, it would be a mistake to remove them from the language. Incompatible change is dangerous--you never know who will get stung, or with what effect. That principle, of course, can be carried to extremes. While deleting merely useless facilities isn't worth the hazard, deleting facilities that interfere with sensible programming often is justified. Some of the changes from K&R C to ANSI C probably fall into that category. The best example I can think of of a terrible language facility that is almost impossible to remove is the COMMON/EQUIVALENCE stuff in Fortran. I haven't followed developments in the Fortran world for a long time, but I know that people have been most hesitant to tinker with COMMON/ EQUIVALENCE because of how the changes might impact programs in use in critical applications such as aeronautical engineering and nuclear power plant control. From icon-group-sender Tue Jan 26 20:56:15 1993 Received: by cheltenham.cs.arizona.edu; Wed, 27 Jan 1993 05:11:41 MST Path: ucbvax!agate!doc.ic.ac.uk!uknet!edcastle!eddie From: eddie@castle.ed.ac.uk (Eddie Corns) Newsgroups: comp.lang.icon Subject: Re: Rremoving entab/detab from Icon Message-Id: <30836@castle.ed.ac.uk> Date: 26 Jan 93 20:56:15 GMT References: <556329@MTS.cc.Wayne.edu> Organization: Edinburgh University Lines: 19 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Surely the best person to decide whether a feature should be in the library or the language itself should be the end user. Can we not think up some scheme whereby those who don't need the overheads or whatever of unwanted features can remove them. Things like entab and friends could be supplied as part of a standard library and also in the language. If some way of removing them from the language (or conversely building extra functions into the language) could be found then we have the best of all possible worlds. Just a thought. This is similar to debates like whether langauages should support variable numbers of arguments. Those of us who find them useful say yes but others complain that the overheads are too high. But of course those who don't want them don't use them and hence occur no overheads and the rest of us put up with the extra overheads when we feel they are useful. Should we have strong or weak typing? -- let the user decide, add more information into a language to give the user the control _they_ need. "The customer is always right." Just my opinion, feel free to disregard it. Eddie From icon-group-sender Tue Jan 26 21:22:01 1993 Received: by cheltenham.cs.arizona.edu; Wed, 27 Jan 1993 05:12:05 MST Path: ucbvax!agate!spool.mu.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!pacbell.com!att-out!walter!flash!norman From: norman@flash.bellcore.com (Norman Ramsey) Newsgroups: comp.lang.icon Subject: separate compilation with iconc? Message-Id: <1993Jan26.212201.24247@walter.bellcore.com> Date: 26 Jan 93 21:22:01 GMT Sender: news@walter.bellcore.com Organization: Bell Communications Research Lines: 7 Nntp-Posting-Host: flash.bellcore.com Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu With icont, I can compile separate Icon files into ucode, then link them in a separate step. Is there a way to do the analogous thing with iconc? If I try `iconc -c grammar.nw', it complains that there's no main procedure. Norman From icon-group-sender Tue Jan 26 22:47:47 1993 Received: by cheltenham.cs.arizona.edu; Wed, 27 Jan 1993 05:13:59 MST Path: ucbvax!agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!swrinde!emory!gatech!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall From: nall@ibm12.scri.fsu.edu (John Nall) Newsgroups: comp.lang.icon Subject: Re: Rremoving entab/detab from Icon Message-Id: <11826@sun13.scri.fsu.edu> Date: 26 Jan 93 22:47:47 GMT References: <556329@MTS.cc.Wayne.edu> <30836@castle.ed.ac.uk> Sender: news@sun13.scri.fsu.edu Reply-To: nall@ibm12.scri.fsu.edu (John Nall) Organization: SCRI, Florida State University Lines: 25 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <30836@castle.ed.ac.uk> eddie@castle.ed.ac.uk (Eddie Corns) writes: > >Surely the best person to decide whether a feature should be in the library or >the language itself should be the end user. ... >"The customer is always right." Just >my opinion, feel free to disregard it. Excuse me? My newsfeed must have malfunctioned - apparently the smiley faces didn't make it. Free software? That suits most of us very well? And the "customer" is going to say "change this" or "change that"? Come on, now, guys..:-) You've got the source - if you don't like something about it, change the sucker! John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Why yes, as a matter of fact, I DID vote for Hillary!!" - me From icon-group-sender Wed Jan 27 05:16:44 1993 Received: by cheltenham.cs.arizona.edu; Wed, 27 Jan 1993 05:16:57 MST Date: Wed, 27 Jan 1993 05:16:44 MST From: "Ralph Griswold" Message-Id: <199301271216.AA14033@cheltenham.cs.arizona.edu> To: icon-group@cs.arizona.edu Subject: separate compilation Status: R Errors-To: icon-group-errors@cs.arizona.edu The Icon compiler requires the entire program so that it can perform type inference. It does not support separate compilation. 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 Jan 27 14:48:18 1993 Received: by cheltenham.cs.arizona.edu; Thu, 28 Jan 1993 06:11:05 MST Path: ucbvax!enterpoop.mit.edu!ira.uka.de!Germany.EU.net!gmd.de!newsserver.jvnc.net!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer From: goer@ellis.uchicago.edu (Richard L. Goerwitz) Newsgroups: comp.lang.icon Subject: Re: Rremoving entab/detab from Icon Message-Id: <1993Jan27.144818.7516@midway.uchicago.edu> Date: 27 Jan 93 14:48:18 GMT References: <556329@MTS.cc.Wayne.edu> <30836@castle.ed.ac.uk> <11826@sun13.scri.fsu.edu> Sender: news@wakinyan.uchicago.edu (News System) Reply-To: goer@midway.uchicago.edu Organization: University of Chicago Lines: 26 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu John Nall writes (concerning the idea that the "customer is always right"): >Excuse me? My newsfeed must have malfunctioned - apparently the >smiley faces didn't make it. > >Free software? That suits most of us very well? And the "customer" is >going to say "change this" or "change that"? Come on, now, guys..:-) >You've got the source - if you don't like something about it, change >the sucker! Just for the record, you can't just go into the Icon source tree and change things. Gotta know the language and the implementation. For many, especially those who don't spend their lives grubbing around in systems programming languages like C, altering things would not be practical. By "customer" I think the poster simply meant "user." The Icon Project is distinguished from most academically based research efforts in having one eye on the user at all times. At least that's been my experience with them. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Jan 28 22:31:57 1993 Received: by cheltenham.cs.arizona.edu; Thu, 28 Jan 1993 19:27:33 MST Via: uk.ac.manchester.computer-science; Fri, 29 Jan 1993 00:09:04 +0000 From: Steve Holden Date: Thu, 28 Jan 93 22:31:57 GMT Message-Id: <6854.9301282231@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: Removing entab/detab from Icon Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm not very keen on all this talk along the lines of "you can remove what you want" or "I don't use this feature so it shouldn't be in". Anybody remember Cobol? (Of course, none of _us_ use it... ;-) This was sickeningly full of "elective" language features which the implementor could choose to include or not at their discretion. And of course this didn't stop IBM and a few others building in vendor- specific features to try and lock their users in. Result? Total non-portability of code. This is definitely _not_ why I'm interested in Icon. Those who want to cut it down or build it up may by all means do so, as long as they don't then put programs built with the resulting compilers/translators out as "Icon". Me, I want to grab other people's code and use it! regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Thu Jan 28 19:31:20 1993 Received: by cheltenham.cs.arizona.edu; Thu, 28 Jan 1993 19:31:48 MST Date: Thu, 28 Jan 1993 19:31:20 MST From: "Ralph Griswold" Message-Id: <199301290231.AA17295@cheltenham.cs.arizona.edu> To: icon-group@cs.arizona.edu Subject: entab/detab Status: R Errors-To: icon-group-errors@cs.arizona.edu There's been a lot of discussion about possibly removing features from Icon. Whether or not an existing feature is considered important or unimportant -- or whether we've made a mistake by including something we shouldn't have -- nothing is going to be removed. That's simply impractical. So don't worry that something you're using may go away. It won't. 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 Jan 29 11:06:24 1993 Received: by cheltenham.cs.arizona.edu; Fri, 29 Jan 1993 05:54:19 MST Date: Fri, 29 Jan 1993 11:06:24 +0300 (EET) From: LARSSON@ntcclu.ntc.nokia.com Message-Id: <930129110624.25824888@ntcclu.ntc.nokia.com> Subject: Removing various features To: icon-group@cs.arizona.edu X-Vmsmail-To: INET::"icon-group@cs.arizona.edu" Status: R Errors-To: icon-group-errors@cs.arizona.edu In a recent posting Steve Holden said: Result? Total non-portability of code. This is definitely _not_ why I'm interested in Icon. Those who want to cut it down or build it up may by all means do so, as long as they don't then put programs built with the resulting compilers/translators out as "Icon". Me, I want to grab other people's code and use it! Agreed to 100 %. Furthermore, we don't have to go as 'far back' as to Cobol: just think of what different implementations of the name/2 predicate does to a Prolog programmer. By the way, what is the overhead of having a few unused builtins in a programming language - except losing the 'elegant, mathematical minimalist' approach. And a thicker manual, of course. (This is an UNINFORMED question from non-computer-science person, NOT intended to cause flames; if it does, I'll try and get my flame-proof suit out of the closet.) Arne *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Arne Larsson Nokia Telecommunications Translator Transmission Systems, Customer Services larsson@ntc02.tele.nokia.fi P.O. Box 12, SF-02611 Espoo, Finland Phone +358 0 5117476, Fax +358 0 51044287 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From icon-group-sender Fri Jan 29 19:09:07 1993 Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 05:51:05 MST Date: Fri, 29 Jan 1993 19:09:07 MST From: "Clint Jeffery" Message-Id: <199301300209.AA13005@chuckwalla.cs.arizona.edu> To: LARSSON@ntcclu.ntc.nokia.com Cc: icon-group@cs.arizona.edu In-Reply-To: LARSSON@ntcclu.ntc.nokia.com's message of Fri, 29 Jan 1993 11:06:24 +0300 (EET) <930129110624.25824888@ntcclu.ntc.nokia.com> Subject: Removing various features Status: R Errors-To: icon-group-errors@cs.arizona.edu > Arne Larsson writes: ...By the way, what is the overhead of having a few unused builtins in a programming language... [I'll say, Icon, for example] For users, the overhead is not bad, except on systems with tiny memories, such as MS-DOS. For language implementors, some little-used built-ins are no trouble and others impose increased difficulty of implementation and increased cost of changing the implementation. For example, when we developed the Icon compiler, we had to make Large changes to all of these built-ins. For a math function like sin() it was no sweat. But for entab()/detab() it was a headache. The "mathematical minimalist" notion is not so bad whenever code plays tricks with the garbage collector. I hope entab() and detab() will get used more, considering the effort that has gone into them and all the free advertising they have been getting lately... :-) From icon-group-sender Fri Jan 29 16:29:04 1993 Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 05:51:32 MST Path: ucbvax!enterpoop.mit.edu!ira.uka.de!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!news.netmbx.de!Germany.EU.net!mcsun!sunic!news.lth.se!paster From: paster@dna.lth.se (Christian S. Collberg) Newsgroups: comp.lang.icon Subject: WIT & XIB -- Where? Message-Id: <1993Jan29.162904.12804@lth.se> Date: 29 Jan 93 16:29:04 GMT Sender: news@lth.se Organization: Department of Computer Science, Lund University Lines: 10 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Sorry if this question has been asked before (I'm new to this group): Where can I pick up WIT & XIB which are mentioned in Jon Lipp and Mary Cameron's reports? And, are there other repositories of Icon programs than cs.arizona.edu/icon? Thanks! Christian -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden From icon-group-sender Sat Jan 30 05:55:25 1993 Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 06:01:59 MST Date: Sat, 30 Jan 1993 05:55:25 MST From: "Ralph Griswold" Message-Id: <199301301255.AA17246@cheltenham.cs.arizona.edu> To: icon-group Subject: WIT and XIB Status: R Errors-To: icon-group-errors@cs.arizona.edu The X-Icon toolkit and interface builder will be included in the next release of the Icon program library. It should be available via FTP and RBBS in a week or two. I'll send an announcement when the time comes. 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 Mon Jan 18 01:16:44 1993 Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 20:39:53 MST Path: ucbvax!dog.ee.lbl.gov!overload.lbl.gov!agate!ames!haven.umd.edu!uunet!mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group From: reid@vtopus.cs.vt.edu (Thomas F. Reid) Newsgroups: comp.lang.icon Subject: Re: endtab/detab Message-Id: <9301180116.AA05090@vtopus.cs.vt.edu> Date: 18 Jan 93 01:16:44 GMT Lines: 32 In-Reply-To: <199301161259.AA02671@cheltenham.cs.arizona.edu> from "Ralph Griswold" at Jan 16, 93 05:59:45 am Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > However, once you have a large user community and widely distributed > documentation, it's not feasible to remove something, even if it's > little used. Worse, it's not feasible to redesign something that > was done badly. That's one of the reasons language design is so > hard; once you've done it, implemented it, documented it, and > released it, you're stuck with 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) > I think that a change of paradigm is needed for language design. I believe that the language designer should be encouraged to release a new language design and implementation every (say) 5-8 years along with a translator to/from the new/old versions. This way, the language designer can correct old mistakes and extend the language "right" into new concepts without paying too much homage to the cursed god of upward compatibility. There have been too many elegant languages ruined by trying to extend them into areas that the original design cannot comfortably permit. Modula-2 comes to mind. If the two versions are fundamentally the same, then the delta between implementations and the to/from translators should be straightforward. It is extra work for the language designer, but it has the reward of allowing the language to evolve gracefully rather than stagnate or accept awkward extensions. Whatcha think? Tom From icon-group-sender Sun Jan 17 14:01:24 1993 Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 20:41:40 MST Path: ucbvax!dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!caen!uunet!mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group From: TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) Newsgroups: comp.lang.icon Subject: RE:entab/detab Message-Id: <01GTM84WCM828WWTTE@mis.mcw.edu> Date: 17 Jan 93 14:01:24 GMT Organization: Medical College of Wisconsin (Milwaukee, WI) Lines: 104 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: IN%"alex@laguna.Metaphor.COM" 16-JAN-1993 21:57:19.34 > To: IN%"icon-group@cs.arizona.edu" > Subj: RE: entab/detab > I use entab and detab quite a bit -- often the text I want to process > is entabbed, and often I want to entab my output. Kind of like my reason but in reverse. I guess some people have a use for tabs. > Interestingly, those routines once *were* library routines (in a > slightly different form), and made it into the language somewhere > around version 6. Certainly they *could* be library routines, but this > sort of operations is way faster as a primitive than if it were written > in Icon. I personally don't feel that it clutters up the language. > It would be interesting to create a questionaire to determine which > features are rarely used. E.g. how often do you use string invocation, > or PDCOs, or run-time error conversion to failure? I think you'd find a pretty even mixture of all kinds overall. I never use entab() or coexpressions. Someone else might understand coexpressions and think they're the greatest thing since the byte. > I think an interesting (significant) project would be to create a > smaller but more extensible Icon. The "real" Icon would just be a > nucleus, and much of the functionality could be added using new > yet-to-be-conceived extensibility features. The extensibility > cabilities would include > (a) "easy" addition of new primitives written in C (whatever > that means -- maybe without relinking the interpreter, or > at least with changes limited to one module. Maybe dynamic > linking -- that seems to be a trend and is implemented in > popular platforms now.) Many icon programmers are not computer science majors. Those of us whose skill in C is little to none, need/use those added features the most, and have the least chance of rolling our own. Variant translators and personal interpreters sound cool in conversation, but many of us don't have a clue as to what they can do for us. > (b) addition of new facilities written in Icon without creating > name conflicts. > (c) overloading of existing functions (like copy()) and > operators to handle new data types. More vendors these days are segmenting their product lines. They tell you this is to make the product more 'modular'. They tell you that you should not have to pay for features you don't use, and this modularity will save you all kinds of money because of that. (Where would unix be if we had to buy C and tcp/ip and each utility as a separate line item?) What happens is the stripped down core gets sold at the regular price, every little value added feature becomes a line item. Now ICON is not a profit driven item like C++ or WordPerfect or Netware. The part that is unpleasant here is that code won't be as portable unless you ship all your icon language enhancements with them, and maybe your enhancements may not like my enhancements. By keeping what some consider a lot of language bloating in a central version, icon can maintain maximum code portability. And I'll let hardware improvements make up for the added memory or speed requirements. > Has anyone else out there had a similar fantasy? Then things like > entab, X-stuff, and maybe even string scanning could be "extensions". I'd like to see a few things added to icon. Here's my wishlist: 1) every to by First for these to work with reals, and maybe someday with any type. &next &prior &first &last to be used also for referencing when numbers may not be meaningful. This may also contribute toward true scanning features for lists, sets, tables, and files. 2) User defined operator $ ? Maybe just the $ character or maybe $+. Maybe this is superfluous because procedures can do it all to. But, I think it's no more pathological than string invocation which already exists. 3) Two way pipes I know this one is probably tricky. I'd like to open a process for read and write, then I'd only need one file handle for a piping dialog. I can also then completely control the process IO. If I open a process for write I can't directly read its output unless I redirect it to a file and read that in separately. This may not always be possible. 4) OS independent files Since icon is now on VMS, Unix, MAC, DOS, IBM and each has a file system syntax for files, directories, and disks, it would sure be easier to write totally portable code if the icon language had a universal file system syntax. Then the backend interpreter/compiler would handle mapping this syntax to the file system of the target OS. > -- Bob Alexander > Metaphor Computer Systems (415) 966-0751 alex@metaphor.com > ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex 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 Jan 29 19:44:26 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Feb 1993 05:29:36 MST Path: ucbvax!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!news.ccs.queensu.ca!qucis.queensu.ca!abraham From: abraham@qucis.queensu.ca (Edna Abraham) Newsgroups: comp.lang.icon Subject: ftp site for info about Icon Message-Id: <1993Jan29.194426.11300@qucis.queensu.ca> Date: 29 Jan 93 19:44:26 GMT Organization: Computing & Information Science, Queen's University at Kingston Lines: 12 Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Can anyone out there tell me the address of the ftp site for information about the icon compiler and its implemetation. Please respond directly to me abraham@qucis.queensu.ca Thanks a lot!!! From icon-group-sender Tue Feb 2 15:26:58 1993 Received: by cheltenham.cs.arizona.edu; Wed, 3 Feb 1993 05:41:23 MST Path: ucbvax!agate!spool.mu.edu!darwin.sura.net!haven.umd.edu!wam.umd.edu!macole From: macole@wam.umd.edu (The Dude) Newsgroups: comp.lang.icon Subject: self-executable code Message-Id: <1993Feb2.152658.29084@wam.umd.edu> Date: 2 Feb 93 15:26:58 GMT Sender: usenet@wam.umd.edu (USENET News system) Organization: University of Maryland, College Park Lines: 13 Nntp-Posting-Host: rac2.wam.umd.edu Apparently-To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Please excuse my ignorance...but is (or will) there be any complier/linker for icon that will create an .EXE file for MS-DOS? Also, what is the ftp address for getting the latest versions of icon? Thanks in advance, Mario -- Mario A. Cole | HJ Ford Associates Incorporated macole@wam.umd.edu | 1111 Jeff Davis Hwy Suite 808 University of Maryland College Park | Crystal City, Arlington, VA 22202 (301) 868-9249 | (703) 553-5580 From icon-group-sender Wed Feb 3 05:47:16 1993 Received: by cheltenham.cs.arizona.edu; Wed, 3 Feb 1993 05:47:44 MST Date: Wed, 3 Feb 1993 05:47:16 MST From: "Ralph Griswold" Message-Id: <199302031247.AA19193@cheltenham.cs.arizona.edu> To: macole@wam.umd.edu Subject: Re: self-executable code Cc: icon-group Status: R Errors-To: icon-group-errors@cs.arizona.edu The present version of Icon does not produce .exe files. The new optimizing compiler for Icon produces .exe files, but it requires a 32-bit platform with extended memory and a 32-bit C compiler (the Icon compiler produces C code). The source code for Icon, which includes both the compiler and the more commonly used interpreter, is available by FTP from cs.arizona.edu. cd /icon and get READ.ME for navigation instructions. Be forewarned that building the Icon compiler requires substantial resources. We recommend a fast 486 and at least 4MB of extended memory (it depends on the 32-bit C compiler you use). 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 Mon Feb 8 12:09:03 1993 Received: by cheltenham.cs.arizona.edu; Mon, 8 Feb 1993 12:09:37 MST Date: Mon, 8 Feb 1993 12:09:03 MST From: "Ralph Griswold" Message-Id: <199302081909.AA00858@cheltenham.cs.arizona.edu> To: icon-group Subject: New Icon program library Status: R Errors-To: icon-group-errors@cs.arizona.edu Version 8.8 of the Icon program library is now available via FTP from our site. This new version contains considerably more material than the previous version, including a section for X-Icon that includes the WIT toolkit and the XIB interface builder. To get this material, do an anonymous FTP to cs.arizona.edu, cd /icon/library, and get READ.ME for a list of what's available. The new version of the library also should be available from our RBBS in a few days. Please direct any questions to me, not to icon-group or icon-project. 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 Mon Feb 8 17:41:33 1993 Received: by cheltenham.cs.arizona.edu; Mon, 8 Feb 1993 17:42:03 MST Date: Mon, 8 Feb 1993 17:41:33 MST From: "Ralph Griswold" Message-Id: <199302090041.AA09090@cheltenham.cs.arizona.edu> To: icon-group Subject: XIB Status: R Errors-To: icon-group-errors@cs.arizona.edu XIB as distributed in the new release of the Icon program library has a call system("mticont -s -u " || s) in xibedit.icn. That's a hold-over from a trial version and should be "icont" in place of "mticont". This only affects prototyping, but the change is easily made. 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 Tue Feb 9 12:22:08 1993 Received: by cheltenham.cs.arizona.edu; Tue, 9 Feb 1993 12:22:31 MST Date: Tue, 9 Feb 1993 12:22:08 MST From: "Ralph Griswold" Message-Id: <199302091922.AA02136@cheltenham.cs.arizona.edu> To: icon-group Subject: XIB correction Status: R Errors-To: icon-group-errors@cs.arizona.edu XIB in the new Version 8.8 Icon program library has a couple of errors related to prototyping. If you plan to use this, pick up the corrected file, xibedit.icn, in /icon/library in our FTP area. 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 Sat Feb 13 02:21:38 1993 Received: by cheltenham.cs.arizona.edu; Sun, 14 Feb 1993 06:55:29 MST Date: 13 Feb 93 02:21:38 GMT From: mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: SCRI, Florida State University Subject: What is text processing?? Message-Id: <12010@sun13.scri.fsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Not absolutely sure as to the best place to post this, but this newsgroup would seem to be a good place to start :-) I teach Computer Science, along with other duties. I'm making up a course for the coming Summer Semester. What I *really* want to do is to teach the students a couple of new programming languages - Perl and ICON. But I'd like to disguise it under a new name. The new name is "Text Processing," and the intent is to say something along the following lines: "You are enrolled in this course to learn about text processing. Text processing consists of X, Y, and Z. You could probably do this with any language, including Fortran, but some languages are better than others for this purpose. Perl and ICON are two which I think are particularly suited, so we will use these as examples. Each problem dealing with X, Y and Z will be done in both languages, so that you may compare them." Sounds interesting, no? Problem is, I'm having a wee bit of difficulty in my own mind deciding what X, Y and Z (above) should be. I have some ideas, of course, or I never would have proposed the damn course in the first place. But I sure would appreciate any thoughts other people might have, so far as what should be taught in such a course. Thanks for any assistance. John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Come on, Hillary! There are a lot of us pulling for you!" From icon-group-sender Sun Feb 14 06:47:25 1993 Received: by cheltenham.cs.arizona.edu; Sun, 14 Feb 1993 14:08:28 MST Date: 14 Feb 93 06:47:25 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: UDSI Subject: Re: ftp site for info about Icon Message-Id: <1lkpttINNc94@access.digex.com> References: <1993Jan29.194426.11300@qucis.queensu.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Try cs.arizona.edu anonymous ftp, and look in the directory icon. From icon-group-sender Sun Feb 14 07:05:44 1993 Received: by cheltenham.cs.arizona.edu; Sun, 14 Feb 1993 14:09:12 MST Date: 14 Feb 93 07:05:44 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: UDSI Subject: novicey beginner question Message-Id: <1lkr08INNcn7@access.digex.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 am just starting out learning ICON and am having a tough time trying to make something work. I realize this is a real undergraddy type question, but I am taking a night course, and the professor is not available. I am trying to write a procedure that given a string looks to see if there are any curly braces and cuts out whatever is between them. this is what i am up to, and i am having a hard time trying to hang it all together. procedure foo (line) line_ptr := 0 # initialize a line ptr com_set := '{}' # establish a cset of the things of interest line ? { if not find(com_set) then return line # if there is no curly return it else { temp := inline(tab(upto(comset))) #scissor out return temp # the stuff between curlies } } end # foo this is not really right, and i thought I'd ask you all what conceptual leap i am missing. the problem is in the temp assignment. If i can get this darn utility routine to work, the rest of the program should come along quite nicely. Thank you for your time, and pardon me if this is an inappropriate posting. pat Newsgroups: comp.lang.icon Subject: novicey, beginner type question Summary: Followup-To: Distribution: world Organization: UDSI Keywords: Newsgroups: um.dining Subject: test. Summary: Followup-To: Distribution: um Organization: UDSI Keywords: Newsgroups: alt.lang.icon Subject: Novice beginner type question. Summary: Followup-To: Distribution: world Keywords: I am just starting out learning ICON and am having a tough time trying to make something work. I realize this is a real undergraddy type question, but I am taking a night course, and the professor is not available. I am trying to write a procedure that given a string looks to see if there are any curly braces and cuts out whatever is between them. this is what i am up to, and i am having a hard time trying to hang it all together. procedure foo (line) line_ptr := 0 # initialize a line ptr com_set := '{}' # establish a cset of the things of interest line ? { if not find(com_set) then return line else { temp := inline(tab(upto(comset))) return temp } } end # foo this is not really right, and i thought I'd ask you all what conceptual leap i am missing. the problem is in the temp assignment. If i can get this darn utility routine to work, the rest of the program should come along quite nicely. Thank you for your time, and pardon me if this is an inappropriate posting. pat From icon-group-sender Sun Feb 14 17:28:21 1993 Received: by cheltenham.cs.arizona.edu; Sun, 14 Feb 1993 16:48:37 MST Date: Sun, 14 Feb 93 17:28:21 CST From: "Richard L. Goerwitz" Message-Id: <9302142328.AA06789@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: novicy question Status: R Errors-To: icon-group-errors@cs.arizona.edu > I am trying to write a procedure that given a string looks to see > if there are any curly braces and cuts out whatever is between them. > > procedure foo (line) > > line_ptr := 0 # initialize a line ptr > com_set := '{}' # establish a cset of the things of interest > line ? { > if not find(com_set) > then return line # if there is no curly return it > else { > temp := inline(tab(upto(comset))) #scissor out > return temp # the stuff between curlies > } > } >end # foo The short answer is that you should just try local s2 s2 := "" s ? { while s2 ||:= tab(find("{")) do { move(1) tab(find("}")+1) } s2 ||:= tab(0) } return s2 But this assumes that braces are never nested (as in "hello { the { re } }"). If the braces can be nested, then read up on how to use bal(). If this func- tion is difficult for you to learn to use, then join the club :-), and post again with with other questions. There's no rule against asking beginners' questions here! Actually, they tend to spawn some interesting discussions. If you're taking an introductory CS course, watch out. Your profs may be ex- pecting you to handle (in addition to nesting) cases where the input is er- roneous, i.e. "hello { there " (i.e. with no right brace). You might as well be warned now, and not have to submit to this rite of passage :-). After all, you get browny points for finding out about and using this mailing list. -Richard Goerwitz From icon-group-sender Mon Feb 15 20:34:50 1993 Received: by cheltenham.cs.arizona.edu; Tue, 16 Feb 1993 05:24:37 MST Date: 15 Feb 93 20:34:50 GMT From: devries@arizona.edu (K'vin D'Vries) Organization: U of Arizona CS Dept, Tucson Subject: A neat ICON trick Message-Id: <32341@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 I was working w/ a case stmt: case x of { <0 : foo() >1 : bar() 1 : foobar() 0 : barfoo() } but, this won't compile because '<0' and '>1' aren't full expr's. But you can fix it by: case x of { 0>x : foo() 1x or 1 To: icon-group@cs.arizona.edu Subject: Text Computing Status: R Errors-To: icon-group-errors@cs.arizona.edu Re: John Nall's question, What is text processing? What are the X, Y, and Z's of text processing? Other than saying text processing is non-numeric computing, which is both most accurate and very negative, my text processing work has 3 components: X. Format and edit: these deserve a category of their own because they take the most time even for numeric computing. Include here the use of editors as well as use of macros and the programming of editors. Y. Launder: this is more general than X. Replace, filter, encrypt, code, and convert data. Coding for part of speech, changing end of line markers from UNIX to DOS conventions, compressing data, setting data up for use in a database, verifying (spell checkers included) legal character sequences are examples. Z. Retrieve information: locate passages with specific strings or patterns of strings, find discontinuous information, find information when strings are incorrectly spelled (fuzzy, soundex searches), build special purpose databases, find material according to its linguistic syntax, computational linguistics (ratio of hypotactic versus paratactic constructions).... Most computing can be rephrased as text processing if we include logical operations, e.g., we can do mathematics by directly using lookup tables: if a pattern of numeric characters is found, replace with values found in the Add table. Have fun, Phillip Lee Thomas (ptho@seq1.loc.gov) - (202) 707-3881 Library of Congress From icon-group-sender Thu Feb 18 17:06:43 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Feb 1993 17:14:01 MST Date: 18 Feb 1993 17:06:43 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: Text Computing To: ptho@seq1.loc.gov Cc: icon-group@cs.arizona.edu Message-Id: <01GUVHIKY5SY8WW2JA@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"ptho@seq1.loc.gov" X-Vms-Cc: 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 See original at bottom: These comments are true. I do tons of the stuff myself. Icon lends itself very well to this sort of thing. However, icon is a line/string oriented system, where editors are a file/buffer oriented systems. I've worked in DEC TPU (text processing utility) and ICON. TPU has an editor environment and many icon-like features. But because it's tied to an editor, it hasn't advanced as far and fast as Icon. Over the past several years I've noticed that ICON is getting to be more general purpose. Recently the math has been improved, there is an object oriented dialect (IDOL), there is X-windows and graphics and many novel computer science ideas. Perhaps the only thing it's not well suited for is systems programming for operating and embedded systems. Although these may come in time. 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: IN%"ptho@seq1.loc.gov" 18-FEB-1993 16:30:26.06 > To: IN%"icon-group@cs.arizona.edu" > Subj: Text Computing > Re: John Nall's question, What is text processing? > What are the X, Y, and Z's of text processing? Other than saying text > processing is non-numeric computing, which is both most accurate and > very negative, my text processing work has 3 components: > X. Format and edit: these deserve a category of their own because they > take the most time even for numeric computing. Include here the use > of editors as well as use of macros and the programming of editors. > Y. Launder: this is more general than X. Replace, filter, encrypt, code, > and convert data. Coding for part of speech, changing end of line markers > from UNIX to DOS conventions, compressing data, setting data up for > use in a database, verifying (spell checkers included) legal character > sequences are examples. > Z. Retrieve information: locate passages with specific strings or > patterns of strings, find discontinuous information, find information > when strings are incorrectly spelled (fuzzy, soundex searches), build > special purpose databases, find material according to its linguistic > syntax, computational linguistics (ratio of hypotactic versus paratactic > constructions).... > Most computing can be rephrased as text processing if we include logical > operations, e.g., we can do mathematics by directly using lookup tables: > if a pattern of numeric characters is found, replace with values found > in the Add table. > Have fun, > Phillip Lee Thomas (ptho@seq1.loc.gov) - (202) 707-3881 > Library of Congress From icon-group-sender Thu Feb 18 16:50:06 1993 Received: by cheltenham.cs.arizona.edu; Sat, 20 Feb 1993 16:21:23 MST Date: 18 Feb 93 16:50:06 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!spool.mu.edu!sol.ctr.columbia.edu!ira.uka.de!rz.uni-karlsruhe.de!news.uni-stuttgart.de!zrzq0111@ucbvax.Berkeley.EDU (Frank Kirschner) Organization: User Help Desk, Comp.Center (RUS), U of Stuttgart, FRG Subject: Re: Removing entab/detab from Icon Message-Id: <1m0enu$g4s@info2.rus.uni-stuttgart.de> References: <6854.9301282231@desktop.desktop.co.uk>, <31821@castle.ed.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 <31821@castle.ed.ac.uk> eddie@castle.ed.ac.uk (Eddie Corns) writes: >steve@dtc.co.uk (Steve Holden) writes: >Well, I was thinking more in terms of the end-user removing unwanted features. >For instance if I want to run a few icon programs on my little Amiga at home, >I would much prefer that uncommon features not reside in memory when not >actually in use. Try to port iconc to your amiga. Then the linker should throw away unused code of the libraries ... From icon-group-sender Tue Feb 23 13:59:56 1993 Received: by cheltenham.cs.arizona.edu; Fri, 26 Feb 1993 08:28:18 MST Date: 23 Feb 93 13:59:56 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!rpi!usc!wupost!spool.mu.edu!yale.edu!ira.uka.de!gmd.de!Germany.EU.net!mcsun!uknet!edcastle!eddie@ucbvax.Berkeley.EDU (Eddie Corns) Organization: Edinburgh University Subject: Re: Removing entab/detab from Icon Message-Id: <32221@castle.ed.ac.uk> References: <6854.9301282231@desktop.desktop.co.uk>, <31821@castle.ed.ac.uk>, <1m0enu$g4s@info2.rus.uni-stuttgart.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu zrzq0111@helpdesk.rus.uni-stuttgart.de (Frank Kirschner) writes: >In article <31821@castle.ed.ac.uk> eddie@castle.ed.ac.uk (Eddie Corns) writes: >>steve@dtc.co.uk (Steve Holden) writes: >>Well, I was thinking more in terms of the end-user removing unwanted features. >>For instance if I want to run a few icon programs on my little Amiga at home, >>I would much prefer that uncommon features not reside in memory when not >>actually in use. >Try to port iconc to your amiga. Then the linker should throw away unused >code of the libraries ... Er yes, that's the whole point innit. Features inside the language aren't in the libraries. Also, apart from the fact that it seems like quite a good language (much better than C, that's for sure), I don't want a C compiler on my Amiga anyway, almost as bad as having a virus on your disks :( (and considerably more expensive), hence no porting for the foreseeable (*) future. Don't know why I keep mentioning it really but don't you often feel that people who create software (in general, I'm not actually referring to icon here which is quite flexible) often limit what users can do just because they don't approve (or can't be bothered etc.) But I don't suppose I'd get far if I phoned the ANSI C committee and said "Look here, I want variable number of arguments in my procedures, if you don't like 'em don't use 'em, no problem, just fix it in the next release OK" (Yes, I know about varargs but that has its limitations). Anyway, I've had my little rant, I promise I won't mention it again (except under extreme provocation (or if you ask me to nicely)). As an aside, perhaps the language would catch on more if there were some more moderate sized tutorials explaining briefly _all_ the language features for those who can already program. I certainly couldn't find any. If this has already been thrashed to death I'm sure you'll all be civilised enough to ignore it. Anyway, I suppose I'll just have to go order the book. Eddie (*) Yes, that's the way it's spelt even though it looks odd, had to look it up. From icon-group-sender Sun Feb 28 11:20:06 1993 Received: by cheltenham.cs.arizona.edu; Sun, 28 Feb 1993 05:20:01 MST Via: uk.ac.edinburgh.festival; Sun, 28 Feb 1993 11:20:10 +0000 Date: 28 Feb 93 11:20:06 GMT From: R J Hare Subject: environment variables To: icon-group@cs.arizona.edu Message-Id: <9302281120.aa12319@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu How do I change the value of an environment variable from within Icon? I an using bash shell and am trying to do something like: system("export DISPLAY=bandit.ucs:0") ie: change the display for X use. The above doesn't work, as system fires up a shell which does what it's told and then re-establishes the old shell - with all it's old environment variables. Surely there's a way of doing this in Icon - have I missed it? I haven't found anything else it can't do for me so far... Thanks. Roger Hare. _____________________________________________________________________________ ______ ________ __ __ | Roger Hare, Computing Service, / __ /\ /__ ___/\ / /\ / /\ | Main Library, University of Edinburgh, / /_/ / / \_/ /\___// /_/_/ / / | Edinburgh, EH8 9LJ, Scotland / __/ / / / / / ____ / / | r.j.hare@edinburgh.ac.uk / /\ \__/__ / / / / /\__/ / / | +44 (0)31 650 3320/642 4809 phone/fax / / /\_\ /___ / / /_/ / /_/ / | \_\/ \_\\_____/ \__/ \__/ | `Don't do it! (First Law of Program | Optimisation)' From icon-group-sender Sun Feb 28 22:53:28 1993 Received: by cheltenham.cs.arizona.edu; Sun, 28 Feb 1993 17:14:05 MST Via: uk.ac.manchester.computer-science; Sun, 28 Feb 1993 23:10:55 +0000 From: Steve Holden Date: Sun, 28 Feb 93 22:53:28 GMT Message-Id: <2560.9302282253@desktop.desktop.co.uk> To: rjhare@festival.ed.ac.uk Subject: Re: environment variables Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Roger: The example you quote of system("export DISPLAY=bandit.ucs:0") doesn't work because system creates a subshell to run its commands in. Changing the environment in that shell doesn't affect the shell under whose control your program is running, and therefore a getenv("DISPLAY") won't see the change you have made. There should really be a setenv() primitive (oh, no, I'm going to get thirteen hundred piece of mail about feeping creaturism now ;-) -- but there isn't, as far as I can tell. regards Steve +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Mon Mar 1 11:59:13 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Mar 1993 11:55:31 MST Date: Mon, 1 Mar 93 11:59:13 -0500 From: ptho@seq1.loc.gov (Phillip Lee Thomas) Message-Id: <9303011659.AA05053@seq1.loc.gov> To: icon-group@cs.arizona.edu Subject: R.J. Hare - environment variables Status: R Errors-To: icon-group-errors@cs.arizona.edu If the system is an MS-DOS system, the environment variable may be set from within Icon by running a batch file. This does not call up a new version of the command processor, unlike .exe and .com files. --Phillip Lee Thomas Library of Congress - ptho@seq1.loc.gov From icon-group-sender Mon Mar 1 10:01:08 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Mar 1993 11:56:07 MST Date: Mon, 1 Mar 93 10:01:08 PST From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9303011801.AA10630@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu, rjhare@festival.ed.ac.uk Subject: Re: environment variables Status: R Errors-To: icon-group-errors@cs.arizona.edu >How do I change the value of an environment variable from within Icon? As you probably know, processes (like Icon) can't influence the environment variables in their parent shell. But there might be hope, depending on exactly what it is you are really trying to accomplish. If you are changing the environment to pass to a command invoked from within Icon, the environment variable can be set in the same system() call: system("MY_VAR=abc command") This construct in the Bourne shell will temporarily add "MY_VAR" to the environment passed to "command", but that change will be forgotton when the Icon program terminates; it will even be forgotten in subsequent system() calls in the same program, since the subshell containing your new definition terminates before the system() call returns to you. Here's a trick I've used when I want my Icon program to change my base shell environment. Pass a value back as standard output, then actually set the variable in the shell itself. For example, if you want to modify the value of $PATH , make a program "my_prog" that prints the new value to standard output and issue the following shell command: PATH=`my_prog` This line can be encapsulated in a file, but that file must be invoked by the "." command ("source" command in C shell). Normal command file (shell script) invocation causes the file's commands to execute in a subshell and, therefore, they won't influence your base shell. In C shell, the above line can more conveniently be encapsulated in an alias, since aliases don't (necessarily) create subshells. -- Bob Alexander Metaphor Computer Systems (415) 966-0751 alex@metaphor.com Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex From icon-group-sender Mon Mar 1 13:52:20 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Mar 1993 16:35:14 MST Date: 01 Mar 1993 13:52:20 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Env Vars To: icon-group@cs.arizona.edu Message-Id: <01GVANRLPDTI8WWIGG@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 unix, changing and passing environmental variables can be done by having a shell script set the vaiable and run the icon program. I'm assuming the child process get the env of the parent. I think I'd better try this first, but this would be my approach. I suppose one could write a program that would write another program or script and run it. But I haven't tried this in the X- environment yet. In DOS I do it a bit differently : system("SET >_SET.TMP") envar := open("_SET.TMP") titlevar := "" every line := !envar do if match("TITLE=",line) then titlevar := line[7:0] close(envar) Because as of my DOS Icon version, there is no getenv(). Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Mon Mar 1 20:32:40 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Mar 1993 19:10:50 MST Date: Mon, 1 Mar 93 20:32:40 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <581039@MTS.cc.Wayne.edu> Subject: Error redirection for icont Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there any special reason why the Icon translator icont doesn't accept the same -e argument for redirection that the Icon interpreter iconx does? This seems like a strange asymmetry. Although it's possible under most operating systems to redirect STDERR as well as STDOUT, it's usually not as easy or obvious. Paul Abrahams From icon-group-sender Mon Mar 1 20:40:17 1993 Received: by cheltenham.cs.arizona.edu; Wed, 3 Mar 1993 05:04:19 MST Date: 1 Mar 93 20:40:17 GMT From: agate!howland.reston.ans.net!spool.mu.edu!olivea!pagesat!spssig.spss.com!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: environment variables Message-Id: <1993Mar1.204017.13953@midway.uchicago.edu> References: <2560.9302282253@desktop.desktop.co.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Steve Holden writes: > >The example you quote of > > system("export DISPLAY=bandit.ucs:0") > >doesn't work because system creates a subshell to run its commands in. The results would be operating system independent, actually. Getenv itself is, in fact, quite OS dependent. Your best bet is not to use it at all. Using environment variables read-only is okay, as long as you test for their presence in the implementation (a la &features). Trying to set environment variables is pretty scary, though :-). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Mar 4 16:11:53 1993 Received: by cheltenham.cs.arizona.edu; Thu, 4 Mar 1993 17:19:19 MST Date: 04 Mar 1993 16:11:53 -0500 (EST) From: KETTUNEN@delphi.com Subject: Poetry analysis To: icon-group@cs.arizona.edu Message-Id: <01GVF013OMCY90NPB6@delphi.com> X-Vms-To: INTERNET"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 Hi, is anybody out there doing any poetry analysis with Icon. I would be interested in hearing of any approaches concerning any language (I am mostly interested in Finnish, but do not let that disturb). Kimmo Kettunen Kettunen@delphi.com From icon-group-sender Fri Mar 5 05:35:47 1993 Received: by cheltenham.cs.arizona.edu; Fri, 5 Mar 1993 05:23:34 MST Date: Fri, 5 Mar 1993 05:35:47 -0500 Message-Id: <9303051035.AA18380@medinah.atc.ucarb.com> To: icon-group@cs.arizona.edu From: far@medinah.atc.ucarb.com Subject: Re: Poetry analysis Status: R Errors-To: icon-group-errors@cs.arizona.edu Thought I'd re-post this for anyone interested, Forrest Richey >To: KETTUNEN@delphi.com >From: far@medinah.atc.ucarb.com >Subject: Re: Poetry analysis >Cc: >Bcc: >X-Attachments: > >>Hi, >> >> is anybody out there doing any poetry analysis with >> Icon. I would be interested in hearing of any approaches >> concerning any language (I am mostly interested in >> Finnish, but do not let that disturb). >> >> >>Kimmo Kettunen >>Kettunen@delphi.com > >I'm not using ICON but rather existing products on MS DOS for recreational >analysis/synthesis of text. Specific tools at present are: > >BABBLE, TRAVESTY and DADAPOEM. > >I'll be glad to describe and (when I finally get FTP capability) share >electronically since I have each as a shareware or freeware version. >Likewise, I am looking for text analysis/synthesis tools in ICON and other >languages. Still probing for ideas on what aspects of language, meaning, text >can be detected/manipulated by computation. > >Another product for generating poetry is Michael Newman's Poetry Generator. >It is more like a workbench for a poet as opposed to analyzing existing poetry >and generating new 'poetry'. > >I also have a ca. 1971 poetry booklet by a professor at an Ohio (USA) college >in which he publishes computer generated poetry based on a simple algorithm >and first lines of several 'real' poems. > >Best, > >Forrest Richey > >far@medinah.atc.ucarb.com From icon-group-sender Tue Mar 9 05:50:47 1993 Received: by cheltenham.cs.arizona.edu; Wed, 10 Mar 1993 05:14:31 MST Date: 9 Mar 93 05:50:47 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications, Greenbelt MD USA Subject: Icon :-> C | ADA translator wanted. Message-Id: <1nhb7nINNsg7@access.digex.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Are there any tools that will convert ICON to C? thanks pat From icon-group-sender Thu Mar 11 11:24:29 1993 Received: by cheltenham.cs.arizona.edu; Thu, 11 Mar 1993 05:55:53 MST Via: uk.ac.manchester.computer-science; Thu, 11 Mar 1993 12:11:44 +0000 From: Steve Holden Date: Thu, 11 Mar 93 11:24:29 GMT Message-Id: <4719.9303111124@desktop.desktop.co.uk> To: not-for-mail@digex.com Subject: Re: Icon :-> C | ADA translator wanted. Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > Are there any tools that will convert ICON to C? Well, you might try "iconc -c", the Icon compiler with the final C-to-object step omitted. The C it produces can only be described as somewhat obfuscated, though. I've asked myself a time or two whether I dared produce this code for contracts which specify C, but so far the answer's always been "no", so I continue to use it for prototyping only on them. regards Steve From icon-group-sender Thu Mar 11 08:06:50 1993 Received: by cheltenham.cs.arizona.edu; Thu, 11 Mar 1993 09:49:57 MST Message-Id: <9303111604.AA33376@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Icon :-> C | ADA translator wanted. To: icon-group@cs.arizona.edu Date: Thu, 11 Mar 93 8:06:50 PST In-Reply-To: <4719.9303111124@desktop.desktop.co.uk>; from "Steve Holden" at Mar 11, 93 11:24 am Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: Steve Holden > > Well, you might try "iconc -c", the Icon compiler with the > final C-to-object step omitted. The C it produces can only > be described as somewhat obfuscated, though. Yes, the code is really not meant for human consumption. The biggest problem is automatic storage management. When an Icon varaible is represented in C it must be accessable to the garbage collector. This means that Icon variables are not represented as simple C variables. In addition, Icon variables are untyped, so their C representation must, in general, include run-time type information. There are probably schemes for representing variables that would result in better looking code than the compiler now produces and making better use of information from type inferencing could also help, but I think that producing human maintainable C code from an Icon compiler would be quite difficult. It is worth noting that automatic storage management causes problems for maintaining the Icon run-time system and it is written with the goal of being maintainable. The other obvious problem is goal-directed evaluation. The compiler goes through some contortions to translate the control flow mechanisms of Icon into the more mundane mechanisms of C. Much of the time it manages to produce fairly reasonable C code, but other times the result looks rather odd. Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Thu Mar 11 09:06:35 1993 Received: by cheltenham.cs.arizona.edu; Thu, 11 Mar 1993 13:40:37 MST Date: Thu, 11 Mar 93 09:06:35 PST From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9303111706.AA08783@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: Icon :-> C | ADA translator wanted. Status: R Errors-To: icon-group-errors@cs.arizona.edu The ultimate Icon to C translation is performed by the Icon optimizing compiler. However, as amazing as it is, the C it produces is not something you would likely ever want to attempt to maintain as C code. I've written several programs in Icon that I have later converted to C for one reason or another (usually not speed, though), and found that often it is often reasonable to just hand-change the various Icon algorithms into C. But there are certain parts of that job that are very annoying and have to be done over and over, like changing ":=" to "=". So I wrote a little filter (in Icon, of course) that performs some of the mundane tasks of hand-converting Icon to C. It's pretty small, so I'm attaching it to this message. Maybe this will prove useful to someone. I have a similar little filter that converts in the other direction -- if anyone is interested let me know. -- Bob Alexander Metaphor Inc. (415) 966-0751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex -------------------------- icn2c.icn ----------------------------------- # # Program to do some mundane aspects of conversion of Icon to C. # # - Reformats comments # - Reformats line-continued strings # - Changes := to = # - Reformats procedure declarations # - Changes end to "}" # procedure main(arg) parenLevel := 0 while line := trim(read(),' \t') do line ? { line := comment := suffix := "" ="procedure" & tab(many(' \t')) & suffix := " {" ="end" & tab(many(' \t')) | pos(0) & line ||:= "}" while line ||:= tab(upto('\'":#')) do { case c := move(1) of { "\"" | "'": { # # Handle character strings. # line ||:= c repeat { until line ||:= tab(find(c) + 1) do { line ||:= tab(0) if line[-1] == "_" then line[-1] := "\"" else stop("unbalanced quotes") Out(line) line := "" &subject := read() line := (tab(many(' \t')) | "") || "\"" } if not (line[-2] == "\\" & not (line[-3] == "\\")) then break } } "#": { # # Handle comments. # comment := trim(tab(0),' \t') } ":": { # # Change := to = # if ="=" then line ||:= "=" else line ||:= c } "(": { parenLevel +:= 1 line ||:= c } ")": { parenLevel -:= 1 line ||:= c } default: line ||:= c } } line ||:= tab(0) || suffix tline := trim(line,' \t') if not (parenLevel > 0 | *tline = 0 | any('{}(!%&*+,-./:<=>?@\\^',tline,-1) | (tline[-4:0] == ("else" | "then") & not tline[-5] | any(' \t',tline[-5]))) then { line := tline || ";" || line[*tline + 1:0] } Out(line,comment) } end procedure Out(line,comment) line ||:= "/*" || ("" ~== \comment) || " */" line := trim(line,' \t') write(line) return end From icon-group-sender Wed Mar 10 15:05:20 1993 Received: by cheltenham.cs.arizona.edu; Sun, 14 Mar 1993 16:05:42 MST Date: 10 Mar 93 15:05:20 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon :-> C | ADA translator wanted. Message-Id: <1993Mar10.150520.1370@midway.uchicago.edu> References: <1nhb7nINNsg7@access.digex.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1nhb7nINNsg7@access.digex.com> prb@access.digex.com (Pat) writes: > >Are there any tools that will convert ICON to C? > The answer is yes, but because the two languages are quite different, the conversion is non-trivial, and the resulting C code is quite large. If you are planning on mixing C and Icon code, you are better off using the built-in C interface from within Icon (see the docs on callout() or what- ever it's called), or just using pipes to and from compiled C code. It's not a pure way of creating an executable, but it works very well, and lets you use each language for those things it's best suited for. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Mar 11 19:07:55 1993 Received: by cheltenham.cs.arizona.edu; Tue, 16 Mar 1993 17:00:50 MST Date: 11 Mar 93 19:07:55 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!caen!umeecs!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!cymorg@ucbvax.Berkeley.EDU (Tanis Half-Elven) Organization: Alternative Collegiate Computing Association Subject: Writing to a file... Message-Id: <1no2mbINN2oq@dns1.NMSU.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 am having a problem with an icon program I am starting to attempt to write. I have the main procedure taking input from the user, and I want a dofile() procedure to write that input to a file. My problem is how do i pas everything that was setup in main to the dofile routine so that it knows what is in the variables i am looking to call. This is a small sample of what I am trying to do... any hints, suggestions, advice, or just code in general that would do what I'm looking for would be appreciated....one thing I can't reasonably do is pass each variable to the function like this: dofile(a,b,c,d,e etc...) cuz there are probably 300+ variables... procedure main() write("Input filename.") file:=read() f:=open(file,"c") write("Input your name") name:=read() dofile(f) end procedure dofile(f) write("Your name is ",name) end please offer help! im stuck! and I don't have a book of any sort to help me out currently... Thanks, Chris Fagyal -- > Chris Fagyal < > Cymorg@acca.nmsu.edu < > cymorg@mrcnext.cso.uiuc.edu < > cef@phantom.cse.nau.edu < From icon-group-sender Mon Mar 15 20:28:35 1993 Received: by cheltenham.cs.arizona.edu; Wed, 17 Mar 1993 04:53:28 MST Date: 15 Mar 93 20:28:35 GMT From: nevada.edu!jimi!snooks.isri.unlv.edu!grover@uunet.uu.net (Kevin Grover) Organization: Information Science Research Institute (UNLV-ISRI) Subject: Re: Language translators Message-Id: <1993Mar15.202835.22484@unlv.edu> References: <1nugjuINNmf3@dns1.NMSU.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 <1nugjuINNmf3@dns1.NMSU.Edu>, cymorg@acca.nmsu.edu (Tanis Half-Elven) writes: ) From: cymorg@acca.nmsu.edu (Tanis Half-Elven) ) Subject: Language translators ) Date: Sat, 13 Mar 93 21:42:22 PST ) Organization: Alternative Collegiate Computing Association ) ) Hi, I was wondering if anyone out there had done any work ) with writing a program that would take input of a string and translate ) it to another language, such as englsh to spanish, or vice versa, ) or any language for that matter. If so, how did you go about ) doing it....suggestions are welcome. It is an idea i've had for ) a long time, but never had the ambition to work on :) ) This is a non-trivial thing. Human languages have many exception. To truley do an adequate job, the translater needs to have a "common sense" database. I remember reading about a project to do this. It involved a very large knowledge base. The semantic analyser translated sentences of the source language into a language independant representation (i.e. meaning based) which could then be translated into another language based on meaning. This has the advantage over straight word translators of not getting erroneous translations of slang, etc. There are several commercial programs the go between English, and German, Spanish, or Italian, but, they're not perfect. (i.e. mostly based on "word for word" or "phrase for phrase" translation. -- - kev, grover@isri.unlv.edu From icon-group-sender Wed Mar 17 07:52:15 1993 Received: by cheltenham.cs.arizona.edu; Wed, 17 Mar 1993 08:12:16 MST Date: 17 Mar 1993 07:52:15 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Language Translators To: icon-group@cs.arizona.edu Message-Id: <01GVWO39GQTK8WVZ3E@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 Some are harder than others. I tried this in German. Real simple sentences are no problem. But you'd want to put in an idiom recognizer first to reduce the "Ich bin ein Berliner" faux pas. Below is my attempt. It's not real sophisticated, but it was a fun experiment. There is translate.icn (the program), and table.txt (the data). It was probably the 3rd icon program I ever wrote. # # TRANSLATE.ICN 4/14/87 BY TENAGLIA # # THIS PROGRAM TRANSLATES WORDS FROM ONE LANGUAGE INTO ANOTHER # procedure main(param) upper := string(&ucase) lower := string(&lcase) if not (file := param[1]) then { write("\f\f << Universal Translator >> \n") writes("Dictionary >") file := read() if file == "" then file := "TABLE.TXT" (fname := open(file)) | stop("Can't open ",file) } xlate := table("??") while line := read(fname) do line ? xlate[tab(upto('|'))] := (move(1),tab(0)) write() chars := &cset -- ' ' input := "hello" while input ~== "quit" do { writes("\n>") input := read() if input == "cls" then { write("\f\f << Universal Translator >> \n") next } sentence := list() input ? while tab(upto(chars)) do put(sentence,tab(many(chars))) write() every i := 1 to *sentence do if xlate[sentence[i]] ~== "??" then writes(xlate[sentence[i]]," ") else writes(map(sentence[i],lower,upper)," ") } end ----table.txt aber|but acht|eight also|thus alt|old am|towards the an|towards appetit|apetite arbeitet|works arbeite|work arbeit|work artzt|doctor auch|also auf|on ausser|out of aus|out auto|car baeume|trees baum|tree bei|by benzin|gasoline berliner|doughnut besser|better bier|beer bin|am bist|are bleifrei|unleaded bleistift|pencil brief|letter buch|book buecher|books dass|that das|the den|the der|the deutsch|german deutsche|german deutscher|german deutsches|german deutschen|german dicker|fat dickes|fat dicke|fat dick|fat die|the dienstag|tuesday dies|this diese|these diesen|these dieser|this dieses|this ding|thing dir|to you donnerstag|thursday drei|three dummer|stupid dummes|stupid dumme|stupid dummkopf|dope dumm|stupid durch|through du|you einen|a einer|a eines|a eine|a eins|one ein|a elf|eleven er|he es gelinkt mir nicht|i'm not pleased esel|donkey essen|eat esse|eat es|it fauler|lazy faules|lazy faule|lazy faul|lazy feder|pen feind|enemy fische|fish fisch|fish frau|woman frei|free freitag|friday freund|friend frohen|happy froher|happy frohes|happy frohe|happy froh|happy fuenf|five fuer|for futter|food gehen|go gehe|go gehts|goes it geht|goes geld|money gesellschaft|company gestern|yesterday ginge|went ging|went grossen|big grosser|big grosses|big grosse|big gross|big gruenen|green gruener|green gruenes|green gruene|green gruen|green guten|good guter|good gutes|good gute|good gut|good haben|have habe|have haeuser|houses hahn|chicken hahnchen|chicken hallo|hello hanswurst|fool hast|have hattet|had hatte|had hat|has haus|house heissen|are named heisse|am named heisst|is named helfen|help helfe|help hempt|shirt herr|mr. heute|today hilft|helps huende|dogs hund|dog hut|hat ich|i ich habe hunger|i'm hungry ihm|to him ihnen|to them ihr|to her im|in the in|in isst|eats ist|is jugend|boy kaetze|cats kammen|came kamm|came katz|cat keinen|no keiner|no keines|no keine|no kein|no kenne|know kennt|knows kinder|children kind|child kleinen|small kleiner|small kleines|small kleine|small klein|small kommen|come komme|come kommt|comes kuehe|cows kugelschrieber|pen kuh|cow leichter|easy leichtes|easy leichte|easy leicht|easy mache|make macht|makes machen|make machst|make maedchen|girl mann|man meinen|my meiner|my meines|my meine|my mein|my mir|to me mit|with mitwoch|wednesday mond|moon montag|monday morgen|morning mund|mouth nach|after nachmittag|afternoon name|name neun|nine nicht|not nul|zero numern|numbers numer|number ober|over oder|or papier|paper pfenig|penny pferde|horses pferd|horse rechner|computer rennen|run renne|run rennt|runs roten|red roter|red rotes|red rote|red rot|red sahe|saw sah|saw samstag|saturday schlechten|bad schlechter|bad schlechtes|bad schlechte|bad schlecht|bad schmecken|taste schmecke|taste schmeckt|tastes schoenen|pretty schoener|pretty schoenes|pretty schoene|pretty schoen|pretty schreiben|write schreibt|writes schriebe|write schwarzen|black schwarzer|black schwarzes|black schwarze|black schwarz|black schweine|pigs schwein|pig schwerer|hard schweres|hard schwere|hard schwer|hard sechs|six sehen|see sehe|see sehr|very seit|since sieben|seven sieht|sees sie|she sind|are sontag|sunday sprechen|speak spreche|speak spricht|speaks stuck|piece stueckchen|little piece trinken|drink trinkt|drinks trinke|drink tuer|door tut|does tue|do tun|do ueber|over um|around und|and unter|under vielen|much vieler|much vieles|much viele|much viel|much vier|four voegeln|birds vogel|bird von|from wann|when wasser|water was|what weissen|white weisser|white weisses|white weisse|white weiss|white welchen|which welcher|which welches|which welche|which welch|which wem|whome wenigen|little weniger|little weniges|little wenige|little wenig|little wenn|if wer|who wessen|whose wie|how will|want wohnen|live wohne|live wohnt|lives wurst|sausage zehn|ten zum|to the zur|to the zu|to zwei|two zwoelf|twelve > From: IN%"nevada.edu!jimi!snooks.isri.unlv.edu!grover@uunet.uu.net" 17-MAR-1993 05:59:34.82 > To: IN%"icon-group@cs.arizona.edu" > Subj: RE: Language translators > In article <1nugjuINNmf3@dns1.NMSU.Edu>, cymorg@acca.nmsu.edu (Tanis Half-Elven) writes: > ) > ) Hi, I was wondering if anyone out there had done any work > ) with writing a program that would take input of a string and translate > ) it to another language, such as englsh to spanish, or vice versa, > ) or any language for that matter. If so, how did you go about > ) doing it....suggestions are welcome. It is an idea i've had for > ) a long time, but never had the ambition to work on :) > ) > This is a non-trivial thing. Human languages have many exception. To > truley do an adequate job, the translater needs to have a "common > sense" database. I remember reading about a project to do this. It > involved a very large knowledge base. The semantic analyser translated > sentences of the source language into a language independant > representation (i.e. meaning based) which could then be translated > into another language based on meaning. This has the advantage over > straight word translators of not getting erroneous translations of > slang, etc. > There are several commercial programs the go between English, and > German, Spanish, or Italian, but, they're not perfect. (i.e. mostly > based on "word for word" or "phrase for phrase" translation. > -- > - kev, grover@isri.unlv.edu From icon-group-sender Fri Mar 12 18:03:22 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Mar 1993 14:17:14 MST Date: 12 Mar 93 18:03:22 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!eng.ufl.edu!usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@ucbvax.Berkeley.EDU (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: Icon :-> C | ADA translator wanted. Message-Id: <12296@sun13.scri.fsu.edu> References: <9303111706.AA08783@laguna.Metaphor.COM> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9303111706.AA08783@laguna.Metaphor.COM> alex@laguna.Metaphor.COM (Bob Alexander) writes: ... >I have a similar little filter that converts in the other direction -- [that is, converting from C to Icon] >if anyone is interested let me know. I'm interested. I would e-mail this, except that I suspect that more people than I am interested, so you might just want to post to the net. >-- Bob Alexander Thanks, John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Older women/make beautiful lovers/yes, older women/they understand..." (song heard one morning about 2 AM, driving through Georgia) From icon-group-sender Thu Mar 18 12:24:03 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Mar 1993 14:17:52 MST Date: Thu, 18 Mar 1993 12:24:03 -0500 Message-Id: <9303181724.AA25412@medinah.atc.ucarb.com> To: icon-group@cs.arizona.edu From: far@medinah.atc.ucarb.com Subject: ICON application to chemical process modelling? Status: R Errors-To: icon-group-errors@cs.arizona.edu I'd like to have a 'topological' copmuter model of a specific group of chemical reactions which give a very complex product mixture. The reaction is nucleophilic displacement by ammonia (and by the resulting intermediate amines) on the C-Cl bonds of 1,2-dichloroethane (EDC). The products are commonly known to chemists as ethyleneamines (i.e.- they are formed of the -NCH2CH2- repeat unit) I want to supply to the model: * an integer value for the number of molecules of ammonia and/or already formed ethyleneamines * an integer value for the number of molecules of EDC * rules for what new bonds can be formed [this will determine the possible structures of the final products] * adjustable relative rate parameters (or liklihoods of) each type of displacement reaction. There are only about 6 [ammonia, primary NH2, secondary NH, secondary cyclic NH, intramolecular primay NH2 and intramolecular secondary NH]. What I want from the model is a product distribution. (#s of each different kind of molecular structure) The kicker here is that I want to rely on the program to generate the structures. Existing approaches to computational reaction modelling mostly involve energetics to decide relative liklihood of following different reaction pathways. The computational resources required for such models are large because of this energetic approach. I wish to shortcut that by using RELATIVE rates. Also, existing approaches require the model-user to supply the reaction pathways and product structures. I hope this 'exhausting enumeration' can be avoided by a program that keeps track of which new bonds are formed, to determine the product structure and (ideally) represent it graphically (e.g.- CH2-CH2 / \ HN NH \ / CH2-CH2 ) [structure drawn in monospaced font] for piperazine, a common product of the reaction of ammonia with EDC I am not much of a programmer but have decided to learn ICON because of my recreational interest in Text analysis/synthesis, machine translation, poetry generation, etc. and use of generated text in creative endeavours both artistic and problem solving. (JOOTSing) I wonder if it is reasonable to try to use ICON for programming the model I sketch above? Suggestions and criticism are welcome. Forrest Richey From icon-group-sender Thu Mar 18 22:13:53 1993 Received: by cheltenham.cs.arizona.edu; Wed, 24 Mar 1993 05:38:27 MST Date: 18 Mar 93 22:13:53 GMT From: mcsun!Germany.EU.net!ira.uka.de!rz.uni-karlsruhe.de!uni-heidelberg!embl-heidelberg.de!scharf@uunet.uu.net Organization: EMBL, European Molecular Biology Laboratory Subject: Icon as embeded language? Message-Id: <1993Mar18.231353.77724@embl-heidelberg.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I'm loocking for an embedded language for my C++ program. I've loocked at Tcl and I currently use Perl but I'm open for something better. I just had a quick look at some of the Icon docu and my questions are: -- Does Icon provide an easy to use interface (like Tcl) to use it as embedded language? In Perl I have constructs like $DIALOG=&Dialog_New(); #$DIALOG is a variable &Dialog_New() calls my function DialogAddButton($DIALOG,"ButtonName","CallbackFunction"); ... but if someone says $DIALOG="Foo"; between the creation and the use of a variable I have a problem. There is also a problem that there is nothing like garbage collection. -- How does Icon then handle my objects? I've seen that there exist someting like an Object Oriented extension/dialect OO-Icon. -- Is it possible to use the OO-Icon as basis for an embedded language? -- Does it support external (in my case C++) Objects? Thanks Michael Michael Scharf ----------------------------------------------------------------------------- ***** ##### # # ##### # European Molecular Biology Lab. ******* # ## ## # # # Protein Design Group ********* # # # # # # # # Meyerhofstr.1 ********* ##### # # # ##### # 6900 Heidelberg, Germany ** ****** # # # # # # Tel: +49 6221 387 305 ******* # # # # # # Fax: +49 6221 387 517 ***** ##### # # ##### ###### Mail: scharf@EMBL-Heidelberg.de ----------------------------------------------------------------------------- From icon-group-sender Wed Mar 24 11:27:13 1993 Received: by cheltenham.cs.arizona.edu; Wed, 24 Mar 1993 15:37:47 MST Date: Wed, 24 Mar 93 11:27:13 -0800 From: Walter Underwood Message-Id: <9303241927.AA16798@hpwunder.hpl.hp.com> To: mcsun!Germany.EU.net!ira.uka.de!rz.uni-karlsruhe.de!uni-heidelberg!embl-heidelberg.de!scharf@uunet.uu.net Cc: icon-group@cs.arizona.edu In-Reply-To: mcsun!Germany.EU.net!ira.uka.de!rz.uni-karlsruhe.de!uni-heidelberg!embl-heidelberg.de!scharf@uunet.uu.net's message of 18 Mar 93 22:13:53 GMT <1993Mar18.231353.77724@embl-heidelberg.de> Subject: Icon as embeded language? Status: R Errors-To: icon-group-errors@cs.arizona.edu Look at ELK (Extension Language Kit). It is an embedded Scheme language. Scheme is a Lisp without the chrome and tailfins. wunder ======= elk-2.0/ANNOUNCE ======== Release 2.0 of Elk, the Extension Language Kit, is now available. Elk is a Scheme interpreter intended to be used as a general, reusable extension language subsystem for integration into existing and future applications. Elk can also be used as a stand-alone implementation of the Scheme programming language. Elk supports several additional language features to increase its usability as an extension language, among them dynamic, incremental loading of object files and `freezing' of a fully customized application into a new executable file (`dump'). The current release of Elk includes several dynamically-loadable extensions, among them interfaces to the X11 Xlib and to the application programmer interface of the Xt intrinsics, and interfaces to the Athena and OSF/Motif widget sets. These extensions are especially useful for application writers whose applications have graphical user-interfaces based on X; they also can be used to interactively explore X and its libraries and as a platform for rapid prototyping of X-based applications. Release 2.0 is a major new release, as some of the interfaces between the interpreter kernel and extensions have been simplified and made more general, i.e. minor massaging of existing extensions will be required (see file MIGRATE). The distribution has been tested on several new systems (such as IBM RS/6000, HP9000/700, SGI, Sony NEWS; see the file MACHINES). The build and install process has been simplified significantly; system-specific configuration files are supplied for the systems on which Elk has been tested. Dynamic loading of object files is supported on all systems that have a functional "ld -A" interface, as well as the NeXT and the HP9000/700. Major internal reorganization has simplified porting Elk to further new systems (assembly language support and a stack-extending version of "alloca" are no longer required). Nearly all artificial limitations have been removed (such as number of before-GC and after-GC functions and of statically GC-linked objects). Elk is now easily usable with ANSI C and C++ (as well as with pre-ANSI C). A number of hooks are provided that will allow the seamless insertion of a new generational/incremental garbage collector that is planned for release 2.1. Elk release 2.0 can be obtained via anonymous FTP from tub.cs.tu-berlin.de (pub/elk/elk-2.0.tar.Z), and from export.lcs.mit.edu (contrib/elk-2.0.tar.Z). -- Oliver Laumann net@cs.tu-berlin.de net@tub.BITNET Carsten Bormann cabo@cs.tu-berlin.de cabo@tub.BITNET From icon-group-sender Mon Mar 22 20:23:02 1993 Received: by cheltenham.cs.arizona.edu; Sat, 27 Mar 1993 10:25:51 MST Date: 22 Mar 93 20:23:02 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: Language Translators Message-Id: <1ol776$hma@access.digex.com> References: <01GVWO39GQTK8WVZ3E@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 I bet one could do a Decent ICON Esperanto- ENglish Translator or something Like THat. pat From icon-group-sender Mon Mar 29 14:42:59 1993 Received: by cheltenham.cs.arizona.edu; Mon, 29 Mar 1993 06:36:33 MST Message-Id: <9303291343.AA20259@ruls41.LeidenUniv.nl> To: IN%"digex.com!digex.com!not-for-mail@uunet.uu.net"%rulfsw.dnet@ruls41 Cc: icon-group@cs.arizona.edu, ruiter@ruls41.LeidenUniv.nl Subject: Re: Language Translators In-Reply-To: Your message of "Sat, 27 Mar 93 18:32:27 GMT." Subject: RE: Language Translators Date: Mon, 29 Mar 93 14:42:59 +0100 From: ruiter@ruls41.LeidenUniv.nl X-Mts: smtp Status: R Errors-To: icon-group-errors@cs.arizona.edu > > I bet one could do a Decent ICON Esperanto- ENglish Translator or > something Like THat. > > pat > Sure, piece of cake! Just devise a semantic theory of both languages, build a parser/translator, and you're done! Could you send me a copy if you're finished? Jan P.A. de Ruiter Leiden University ruiter@ruls41.leidenuniv.nl From icon-group-sender Mon Mar 29 09:26:56 1993 Received: by cheltenham.cs.arizona.edu; Mon, 29 Mar 1993 12:19:28 MST Date: Mon, 29 Mar 93 9:26:56 PST From: John Paolillo To: icon-group@cs.arizona.edu Subject: Language Translators and Artificial Languages Message-Id: Status: R Errors-To: icon-group-errors@cs.arizona.edu With respect to Jan P.A. de Ruiter's criticism of the suggestion that an Esperanto-English translator could easily be written in ICON, the larger problem is probably not the "semantic theory" that one needs for the two languages. Artificial languages such as Esperanto actually shed a different light on the problem of translation; David Crystal says the following about problems in using artificial languages: "Speakers of different languages may translate their mother tongue into an artificial language, but this does not mean that they understand each other any better. The figurative, idiomatic, and connotative uses of words will differ..." (The Cambridge Encyclopedia of Language, 1987 Cambridge University Press, p355) It sounds to me like the tendency is for users of artificial languages to translate directly (word-for-word) from their native language(s) into the artificial language. I suspect that writing an ICON program to do *that* would not be so hard. You just need a semantic theory for English, and not a very good one, either. Such an exercise would do little in the way of teaching one about what is involved in translating from one *natural* language into another. By the way, there are many serious machine translation projects currently being undertaken. In fact there is a journal, _Machine_Translation_, published by Kluwer academic publishers (probably expensive but someone's library may have it), which is probably a useful resource for anyone interested in what people are doing in MT. I would also recommend _Computational_Linguistics_, the journal of the Association for Computational Linguistics, since they also devote space to MT issues. John C. Paolillo Program in Linguistics University of Texas at Arlington From icon-group-sender Tue Mar 30 08:54:08 1993 Received: by cheltenham.cs.arizona.edu; Wed, 31 Mar 1993 04:51:20 MST Date: 30 Mar 93 08:54:08 GMT From: munnari.oz.au!cs.mu.OZ.AU!mundoe!foda@uunet.uu.net (Omar Foda RBA5) Organization: Computer Science, University of Melbourne, Australia Subject: icon for UNIX? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hello, where can I get icon for a UNIX machine from please? Thanks, Omar Foda. From icon-group-sender Tue Mar 30 08:54:08 1993 Received: by cheltenham.cs.arizona.edu; Wed, 31 Mar 1993 08:59:29 MST Date: 30 Mar 93 08:54:08 GMT From: munnari.oz.au!cs.mu.OZ.AU!mundoe!foda@uunet.uu.net (Omar Foda RBA5) Organization: Computer Science, University of Melbourne, Australia Subject: icon for UNIX? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Hello, where can I get icon for a UNIX machine from please? Thanks, Omar Foda. From icon-group-sender Wed Mar 31 09:59:49 1993 Received: by cheltenham.cs.arizona.edu; Wed, 31 Mar 1993 12:52:12 MST Date: Wed, 31 Mar 1993 09:59:49 MST From: "Cliff Hathaway" Message-Id: <199303311659.AA05054@javelina.cs.arizona.edu> To: icon-group Subject: Re: icon for UNIX? Status: R Errors-To: icon-group-errors@cs.arizona.edu (I tried to reply directly to Omar, but the message was returned "Service unavailable - no known UUCP route to mundoe".) > From icon-group-sender Wed Mar 31 04:52:09 1993 > From: munnari.oz.au!cs.mu.OZ.AU!mundoe!foda@uunet.uu.net (Omar Foda RBA5) > Organization: Computer Science, University of Melbourne, Australia > Subject: icon for UNIX? > To: icon-group@cs.arizona.edu > > Hello, where can I get icon for a UNIX machine from please? > Thanks, Omar Foda. Icon can be obtained via anonymous ftp from cs.arizona.edu, or on diskettes by mail, or via ftpmail server (files will be split into manangeable chunks, uuencoded, and mailed to you). Which means is most feasible for you? Cliff Hathaway Icon Project 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 Wed Mar 31 23:27:16 1993 Received: by cheltenham.cs.arizona.edu; Wed, 31 Mar 1993 17:59:37 MST Date: Wed, 31 Mar 93 23:27:16 +0200 From: job@rna.indiv.nluug.nl (Job van Zuijlen) Message-Id: <9303312127.AA12480@mr_ed> To: icon-group@cs.arizona.edu Subject: Language Translators and Artificial Languages Status: R Errors-To: icon-group-errors@cs.arizona.edu Someone pointed out to me that an interesting discussion is going on in this newsgroup. I'm not aquainted with ICON, but I do know someting about machine translation. In reaction to John C. Paolillo's comments on the use of artificial languages I have to admit that I have been involved in a machine translation (MT) project that used Esperanto as an Interlingua (we all have to live, haven't we?). Without defending that choice, I fail to see the point David Christal makes about artificial languages. It is not necessarily simpler to translate from or into Esperanto. In all cases it involves more than word-for-word translation, although the regularity of Esperanto has certain advantages. What our research group learned during the project was that linguistic theories as such are not sufficient to build an MT system, simply because those theories have usually very little to say about translation. There is no current semantic theory that is particularly helpful. So, back to ICON or BASIC or COBOL or whatever? Not necessarily. In our group we started a direction that has also been taken up by other R&D groups and is based on the use of examples, statistics and analogy. The idea is that an MT system does not have to explain how a human translator translates, it only has to translate, i.e. has to give the same results a human translator would give. Examples of those results can be found in bilingual or multilingual text corpora; texts with translations in one or more languages. There are various ways to go from here: an overview of various approaches can be found in "An Introduction to Machine Translation" by Hutchins & Somers, Academic Press 1992. Job van Zuijlen, Utrecht, Netherlands job@rna.indiv.nluug.nl From icon-group-sender Thu Apr 1 05:31:01 1993 Received: by cheltenham.cs.arizona.edu; Thu, 1 Apr 1993 06:58:13 MST Date: Thu, 1 Apr 1993 05:31:01 -0500 Message-Id: <9304011031.AA19688@medinah.atc.ucarb.com> To: icon-group@cs.arizona.edu From: far@medinah.atc.ucarb.com Subject: Language Translators and Artificial Languages Status: R Errors-To: icon-group-errors@cs.arizona.edu >Date: Wed, 31 Mar 93 23:27:16 +0200 >From: job@rna.indiv.nluug.nl (Job van Zuijlen) use of examples, statistics and analogy. The idea is that an MT system does >not have to explain how a human translator translates, it only has to >translate, i.e. has to give the same results a human translator would give. >Examples of those results can be found in bilingual or multilingual text >corpora; texts with translations in one or more languages. There are various >ways to go from here: an overview of various approaches can be found in >"An Introduction to Machine Translation" by Hutchins & Somers, Academic Press >1992. > >Job van Zuijlen, >Utrecht, Netherlands >job@rna.indiv.nluug.nl Yes. I'd heard several years ago of a project or product based on the Canadian Parliamentary records. My impression was that it was the most successful MT work of its time. As Jv Zuijlen above points out, having a good corpus is an advantage. Forrest Richey From icon-group-sender Thu Apr 1 12:13:34 1993 Received: by cheltenham.cs.arizona.edu; Thu, 1 Apr 1993 11:39:45 MST Date: Thu, 1 Apr 93 12:13:34 EST From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <616446@MTS.cc.Wayne.edu> Subject: Error level from MSDOS Icon Status: R Errors-To: icon-group-errors@cs.arizona.edu Here's a minor but annoying problem that shouldn't be too hard to fix at the next update of MSDOS Icon. If there isn't enough extended memory for icont to operate, it quits (as I would expect it to). However, if stderr has been redirected to a file, the generated error messages never make it to that file, probably because stderr hasn't been closed properly. In addition, the error level isn't set nonzero. I came across this behavior because I was setting up an automatic call to Icon from an editor. There wasn't enough extended memory but all the indications of the problem were lost (since the editor didn't display the execution screen). The editor thought that icont had ended normally and had produced no error file. I'd be quite happy if icont merely set the error level nonzero if it aborts because of insufficient memory or a similar condition. I wouldn't want it to set the error level nonzero just because the source program has errors. Paul Abrahams From icon-group-sender Thu Apr 1 15:44:29 1993 Received: by cheltenham.cs.arizona.edu; Thu, 1 Apr 1993 16:00:15 MST Date: 01 Apr 1993 15:44:29 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: April Fools Wish List or is it? To: icon-group@cs.arizona.edu Message-Id: <01GWI2QEMTHU8WWJNC@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 from Milwaukee. Our April fool joke is a near blizzard (2 days ago is was sunny in the 60s). While I was shoveling those 8 inches icon ideas began to happen. If we already have : Object Oriented Icon (IDOL) X-Windows Graphics ICON (XICON, XIB) Parallel processing (Well sort of) ICON in VMS, IBM, DOS, MAC, UNIX and .... Where is the next great frontier ?????? \\\\\\\\\\\\\\\\\\\\\//////////////////////// = NETWORKED-CLIENT/SERVER ICON (drumroll!) = /////////////////////\\\\\\\\\\\\\\\\\\\\\\\\ Wouldn't it be great to weave a web of worldwide interconnected megastring scanning SQL squeezing RPCs to rightsize everything! Oh well, time to go in, take off my boots. I've been stomping in it too much already. Ciao! Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Mon Apr 5 08:37:24 1993 Received: by cheltenham.cs.arizona.edu; Mon, 5 Apr 1993 08:38:20 MST Date: Mon, 5 Apr 1993 08:37:24 MST From: "Ralph Griswold" Message-Id: <199304051537.AA09471@cheltenham.cs.arizona.edu> To: icon-group Subject: Request from new user Status: R Errors-To: icon-group-errors@cs.arizona.edu ... In the past 18 months, I've been a fellow at IBM European Center for Scientific and Engineering Computing, in Roma, where I studied convective turbulence in Rayleigh-Benard cells, in collaboration with the Department of Physics of the University of Roma II 'Tor Vergata', where I graduated. I ran the simulations on many machines, from vector mainframes to SIMD and MIMD machines, to workstation clusters, building up a valuable theoretical and working knowledge in the field. At present, I'm a fellow at CASPUR, a consortium of italian universities aiming to offer supercomputing facilities, with special attention to parallel architectures (from array processors to workstations clusters). In this framework, I'm now working on the porting to a massively parallel SIMD machine and to a workstation cluster, of some fluid dynamics sequential codes, used for research in the Department of Mechanical and Aerospace Engineering of the University of Roma I 'La Sapienza'. While I'm firmly persuaded that the majority of existing codes does not fully exploit even the vectorization facilities available on many computers and that porting to a parallel enviroment requires at least a substantial reorganization (if not a rewriting) of the application, that no automatic translator could deliver, I'm writing some tools to help in the task. At this moment this is a personal project, aimed to ease my work, but is a main candidate for a CASPUR project, as more and more people will use the parallel supercomputing facilities, and full-time support to every group for application porting will be no more feasible. What I'm working on is a system which, after semantic analysis of FORTRAN source code, will spot the main obstacles to effective parallelization, shuch as code ordering, data dependencies, bad data structuring, unbalanced operations distribution, and so on. I've obtained very good results with simple implementations, each one aimed to a single problem. The Icon language, wich I used, as been an invaluable help both for the quickness of development and for the clarity with wich the ideas can be made in code, in a natural way. However, I'm not fully satisfied with this approach, and I'm planning to realize a system that integrates all the tools and is completely modular, with regard both to the starting language and to the target architecture. The tool I'm working on, after parsing of the source code and semantic analysis into an intermediate form, independent of the source language, reports problem both general to every parallel architecture that peculiar to the real target architecture, suitably described in a configuration file. This modularity could allow for using the tool to analyze, besides sequential programs to port, also parallel programs, signaling bottlenecks and inefficiencies. Now, my effort could be reduced if I could find tools such as LEX and YACC, but generating Icon code. Did You developed something similar? If yes, can You made it available to me? At what conditions? Are You eventually interested in some form of collaboration? I thank You for Your patience in reading all this and hope for positive answers from Your part. Best regards Federico Massaioli massaioli@vaxtov.roma2.infn.it From icon-group-sender Fri Apr 2 07:56:52 1993 Received: by cheltenham.cs.arizona.edu; Wed, 7 Apr 1993 12:47:40 MST Date: 2 Apr 93 07:56:52 GMT From: ftpbox!mothost!binford!mcdchg!tellab5!ruth.wheaton.edu!gmribeir@uunet.uu.net (Glauber) Organization: The Bossa Nova University Subject: Is this passable code? Message-Id: <1993Apr2.075652.11967@wheaton.wheaton.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu My apologies if this is repeated, but this is the 3rd time that i'm trying to post this. News sometimes behaves weird here. I started using Icon recently, and am impressed with the power of the language. But, since i'm learning on my own and don't have experience with Icon, i don't know if i'm doing things right. Recently i wrote a short program to find anagrams (yeah...) using the unix dictionary. I'd appreciate any comments/suggestions/flames, etc about my programming style and the Icon way. Thank you very much Glauber. ---------------------------------------------------------------------- # Find all the anagrams of a given word # In the Unix dictionary # Tue Mar 30 07:15:53 CST 1993 procedure main(argv) word := argv[1] if not ( in := open("/usr/dict/words") ) then stop("Can't open system dictionary! :-( ") #initialize l := map( read(in), &ucase, &lcase ) #main loop every ( w := lexperm( word ) ) do { while ( l << w ) do if not ( l := map( read(in), &ucase, &lcase ) ) then return # at this point, either (l == w) or (l >> w) if (l == w) then write(l) } end #I think this is it! # Lexicographical permutation, # Reingold, Combinatorial Algorithms, page 162 # (this is a generator) procedure lexperm( w ) # initialize w := sortword ( map(w, &ucase, &lcase) ) repeat { suspend (w) # now permute every i := (*w - 1) to 1 by (-1) do { if w[i] << w[i+1] then break } every j := *w to 1 by (-1) do { if w[i] << w[j] then break } w[i] :=: w[j] r := *w s := i + 1 while r >= s do { w[r] :=: w[s] r -:= 1 s +:= 1 } # end of permutation if (j = 1) & (i = 1) then fail } end # insertion sort for now... procedure sortword( w ) size := *w # external loop, traverses the word every j := 2 to size do { hold := w[j] # internal loop, "sinks" each letter in place i := j - 1 while i >= 1 do { if hold >>= w[i] then break w[i+1] := w[i] i -:= 1 } w[i+1] := hold } return w end ---------------------------------------------------------------------- -- Glauber Ribeiro glauber@david.wheaton.edu glauber%david.wheaton.edu@tellab5.tellabs.com constantly risking absurdity From icon-group-sender Thu Apr 1 12:23:04 1993 Received: by cheltenham.cs.arizona.edu; Thu, 8 Apr 1993 13:39:30 MST Date: 1 Apr 93 12:23:04 GMT From: mcsun!news.funet.fi!uta!jere@uunet.uu.net (Jere K{pyaho) Organization: University of Tampere, Finland Subject: Earn guru status - help an Icon rookie Message-Id: <9346@kielo.uta.fi> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Can I ask stupid questions in this newsgroup? Thanks. Yesterday I started to learn Icon. Today I ran into a brick wall trying to solve Exercise 3.1 in "The Icon Programming Language" (2nd Ed.). Now, I understand that this procedure genchar( s, c ) every i := ( s ? upto( c ) ) do write ( i ) end outputs the positions of every character of 'c' in 's'. But how do I output the corresponding _characters_ in 's'? I tried 'write(tab(i))', but nothing comes out. Am I missing something fundamental perhaps? This is Icon v8.8 (interpreter), MS-DOS 5.0. I built it from the source using Borland C++ 3.1. Oh, incidentally, I'd like to build the compiler too, but the _TEXT segment is too large. Any solutions? -- // Jere K{pyaho (jere@kielo.uta.fi) | Work is the curse of the // University of Tampere, Finland | drinking classes. -Oscar Wilde From icon-group-sender Fri Apr 9 05:14:18 1993 Received: by cheltenham.cs.arizona.edu; Fri, 9 Apr 1993 05:53:46 MST Via: uk.ac.manchester.computer-science; Fri, 9 Apr 1993 13:10:31 +0100 From: Steve Holden Date: Fri, 9 Apr 93 13:05:20 BST Message-Id: <5718.9304091205@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Re: Earn guru status - help an Icon rookie Status: R Errors-To: icon-group-errors@cs.arizona.edu Well, I wouldn't put myself down as a guru, but it seems to me that a way to recast the given procedure, which was: > > procedure genchar( s, c ) > every i := ( s ? upto( c ) ) do > write ( i ) > end > is as follows. Note that the right-hand operand of the matching operation is now a control structure, so the &pos keyword moves forward through the subject string. The cset() call is not strictly necessary, as an implicit conversion would take place if a string argument were used. procedure main(arg) genchar(arg[1],cset(arg[2])) end procedure genchar(s,c) s ? { every i := tab(upto(c)) do write(move(1)) } end This seems to work fine, as evinced by: scotia% ./t "scotia electronic publishing" "aeiou" o i a e e o i u i i Does anyone have a neater solution - this was just a quick hack. regards Steve PS I hope the group would agree it exists to answer questions like this and help converts to the Icon language? +---------------------------------+-------------------------------------+ | Steve Holden, Technical Director| Desktop Connection Limited | | steve@desktop.co.uk | Manchester Science Park | |---------------------------------+ Lloyd Street North | | Publish and be damned. Publish | Manchester England M15 4EN | | electronically and be heard. | Tel: +44 61 227 9055 Fax: 226 4922 | +---------------------------------+-------------------------------------+ From icon-group-sender Thu Apr 1 17:27:10 1993 Received: by cheltenham.cs.arizona.edu; Fri, 9 Apr 1993 16:52:55 MST Date: 1 Apr 93 17:27:10 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: help an Icon rookie Message-Id: <1993Apr1.172710.5099@midway.uchicago.edu> References: <9346@kielo.uta.fi> 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 <9346@kielo.uta.fi> jere@uta.fi (Jere K{pyaho) writes: >Can I ask stupid questions in this newsgroup? Thanks. A beginner's question yours was. Not a *stupid* one. Beginners' queries are the lifeblood of any newsgroup about any language that isn't overwhelmed with traffic. >Now, I understand that this > > procedure genchar( s, c ) > every i := ( s ? upto( c ) ) do > write ( i ) > end > >outputs the positions of every character of 'c' in 's'. >But how do I output the corresponding _characters_ in 's'? To do this, you have to subscript. There are many ways to do it. You can also use the scanning mechanism itself. One thing to nail down beforehand is how to group scanning expressions for clarity. Normally, it's best to make the scanning expression the outer con- trol structure. This makes modification simpler. In the above pro- cedure, though, there actually wasn't any reason to scan: procedure genchar(s,c) local i every i := upto(c, s) do write(i) end or better yet procedure genchar(s,c) local i every write(upto(c, s)) end If you want to output the actual character matched, then you just add a subscripting mechanism: procedure genchar(s,c) local i every i := upto(c, s) do write(s[i]) end or more compactly (but maybe less clearly): procedure genchar(s,c) local i every write( s[upto(c, s)] ) end I probably would have solved the problem myself in an entirely different way, though, using scanning: procedure genchar(s, c) s ? { while tab(upto(c)) do write(move(1)) } end Or more compactly: procedure genchar(s, c) s ? while write( (tab(upto(c)), move(1)) ) end Please don't hesitate to ask beginner questions here. This newsgroup is not at all hostile to them. Please check my code before using it, as I've had to write a lot of C lately, and I don't shift languages very well. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Apr 1 19:05:59 1993 Received: by cheltenham.cs.arizona.edu; Fri, 9 Apr 1993 16:53:16 MST Date: 1 Apr 93 19:05:59 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!CSM560.smsu.edu!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!cymorg@ucbvax.Berkeley.EDU (Tanis Half-Elven) Organization: Alternative Collegiate Computing Association Subject: Re: Language Translators Message-Id: <1pfeenINNev1@dns1.NMSU.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 week or two back I had asked the question about language translators, and Chris Tenaglia posted something he had done in 1987, and someone else mentioned something about doing a language translator from esperanto-english or vice-versa... I was wonderinf if that person ever started on that or did it??? Please respond through email or here on the group... Thanks, Chris -- > Chris Fagyal < > Cymorg@acca.nmsu.edu < From icon-group-sender Thu Apr 1 10:31:01 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 05:35:21 MST Date: 1 Apr 93 10:31:01 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net Subject: Language Translators and Artificial Languages Message-Id: <9304011031.AA19688@medinah.atc.ucarb.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >Date: Wed, 31 Mar 93 23:27:16 +0200 >From: job@rna.indiv.nluug.nl (Job van Zuijlen) use of examples, statistics and analogy. The idea is that an MT system does >not have to explain how a human translator translates, it only has to >translate, i.e. has to give the same results a human translator would give. >Examples of those results can be found in bilingual or multilingual text >corpora; texts with translations in one or more languages. There are various >ways to go from here: an overview of various approaches can be found in >"An Introduction to Machine Translation" by Hutchins & Somers, Academic Press >1992. > >Job van Zuijlen, >Utrecht, Netherlands >job@rna.indiv.nluug.nl Yes. I'd heard several years ago of a project or product based on the Canadian Parliamentary records. My impression was that it was the most successful MT work of its time. As Jv Zuijlen above points out, having a good corpus is an advantage. Forrest Richey From icon-group-sender Fri Apr 2 10:02:24 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 05:36:01 MST Date: 2 Apr 93 10:02:24 GMT From: mcsun!news.funet.fi!uta!jere@uunet.uu.net (Jere K{pyaho) Organization: University of Tampere, Finland Subject: Icon rookie problems solved Message-Id: <9364@kielo.uta.fi> 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 those people who took the time to help me with my (admittedly trivial) problem concerning Exercise 3.1 of "The Icon Programming Language" (2nd Ed.). I am just learning Icon, and I was very happy to get prompt and friendly answers. The problem was to write a procedure which generates all the characters of a string that are found in a given cset, from left to right. That is, given the string "input and output" and the cset 'ut', the procedure should generate "u", "t", "u", "t", "u", and "t". For the record, here is my solution: #-------cut here------------------ procedure main( L ) genchar( L[1], L[2] ) # don't know how to validate these yet :-) end procedure genchar( s, c ) s ? { every i := upto( c ) do { tab( i ) write( move( i ) ) } } end #--------cut here----------------- Although I'm fascinated by Icon, I don't find this example too intuitive. Maybe it could be further reduced? As to my second problem, it turned out to be an RTFM error. The document IPD205.DOC clearly states that you can't build the Icon version 8.8 compiler under MS-DOS without a 32-bit compiler and a DOS extender, neither of which I own. Oh well. -- // Jere K{pyaho (jere@kielo.uta.fi) | Work is the curse of the // University of Tampere, Finland | drinking classes. -Oscar Wilde From icon-group-sender Fri Apr 2 15:06:23 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 10:27:38 MST Date: 2 Apr 93 15:06:23 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon rookie problems solved Message-Id: <1993Apr2.150623.19869@midway.uchicago.edu> References: <9364@kielo.uta.fi> 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 <9364@kielo.uta.fi> jere@uta.fi (Jere K{pyaho) writes: >For the record, here is my solution: > >procedure genchar( s, c ) > s ? { > every i := upto( c ) do { > tab( i ) > write( move( i ) ) > } > } >end > > >Although I'm fascinated by Icon, I don't find this example >too intuitive. You made the scanning expression the outside enclosing control structure, which is great. Here's another general rule: If you are using "every" within a scanning expression, you're doing some- thing wrong. This rule isn't hard and fast, and you certainly shouldn't feel bad about using it above. If we remove it and the intermediate variable, though, we get something a bit more elegant and (to most Icon programmers) more intuitive: (1) s ? { while tab( upto(c) ) do write( move(1) ) } You may remember that the do-clause can be omitted, so you can do this more compactly: (2) s ? while write( (tab(upto(c)), move(1)) ) Note that (2) uses the (a,b) construct. a & b might just as well have been used. In either case, a must succeed and produce a re- sult before b will be tried. What this does is make it so that, for every time tab(upto(c)) succeeds, move(1) will be executed, and the expression as a whole (either (a,b) or a & b) will produce the result of b, i.e. the result of move(1): (2) s ? while write( tab(upto(c)) & move(1) ) Both of these seem to me to be idiomatic Icon code, although it is true that opinions differ. Some prefer (1). Some prefer (3) to (2). I don't like (2) because it looks messy :-). The key to scanning is that scanning handles all of your place- keeping for you, so you don't have to use "every" or the like. When I tab( upto(c) ), then the first result produced by upto(c) is where I tab to, and that becomes my position (my &pos, in Icon's terms). If I want the next c, I can just move(1) past the current c, and then do another tab( upto(c) ). Icon knows where I am in the string, and I don't have to keep track of it myself. The next time I tab( upto(c) ) I'll end up at the next match! As a result of this, your every i := upto(c) is a neat idea (i.e. produce all the positions at which c chars occur). But it's almost too clever. By simply doing a while tab( upto(c) ) do write( move(1) ) you are moving up to successive positions at which c occurs, then move()ing past them and printing the character matched - and this without using an i variable or any every structures (which tend to be counterintuitive within scanning expressions). Hope this helps. Regarding 32-bit Icon: Icon is really meant for CPUs and OSs that operate in a larger address space than DOS machines tradi- tionally offer. Not that the DOS implementation is a bad one. It's amazingly clever, in fact. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Apr 2 16:05:17 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 17:14:28 MST Date: 2 Apr 93 16:05:17 GMT From: bweiss@arizona.edu (Beth Weiss) Organization: U of Arizona, CS Dept, Tucson Subject: Re: Icon rookie problems solved Message-Id: <35932@optima.cs.arizona.edu> References: <9364@kielo.uta.fi>, <1993Apr2.150623.19869@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@ellis.uchicago.edu (Richard L. Goerwitz) writes: |> In article <9364@kielo.uta.fi> jere@uta.fi (Jere K{pyaho) writes: |> |> >For the record, here is my solution: |> > |> >procedure genchar( s, c ) |> > s ? { |> > every i := upto( c ) do { |> > tab( i ) |> > write( move( i ) ) |> > } |> > } |> >end |> (1) |> s ? { |> while tab( upto(c) ) do |> write( move(1) ) |> >The problem was to write a procedure which generates all |> >the characters of a string that are found in a given cset, |> >from left to right. That is, given the string "input and |> >output" and the cset 'ut', the procedure should generate |> >"u", "t", "u", "t", "u", and "t". Neither of these code segments actually _generates_ the characters in the string--they just print them. In order to generate, you need to use suspend. Try this: procedure genchar(s,c) # this version doesn't use string scanning # and uses subscripting to get the character every ch := upto(c,s) do suspend s[ch] # this method uses string scanning s ? { while tab(upto(c)) do { ch := move(1) suspend ch } } end procedure main() s := read() c := read() # output (or whatever else) is done with the results # of the generator genchar, not within that procedure every write(genchar(s,c)) end --Beth Weiss bweiss@cs.arizona.edu From icon-group-sender Fri Apr 2 19:21:31 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 17:14:58 MST Date: 2 Apr 93 19:21:31 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon rookie problems solved Message-Id: <1993Apr2.192131.2748@midway.uchicago.edu> References: <9364@kielo.uta.fi>, <1993Apr2.150623.19869@midway.uchicago.edu>, <35932@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 bweiss@cs.arizona.edu (Beth Weiss) writes: >|> s ? { >|> while tab( upto(c) ) do >|> write( move(1) ) etc. >Neither of these code segments actually _generates_ the >characters in the string--they just print them. In order to >generate, you need to use suspend. A very valid point. (Can points be *very* valid?) procedure genchar(s,c) suspend s[upto(c,s)] end If it's this easy, why encapsulate it in a separate procedure?? procedure main() stuff... every write(s[upto(c, s)]) -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Sat Apr 10 18:23:43 1993 Received: by cheltenham.cs.arizona.edu; Sat, 10 Apr 1993 18:26:58 MST Date: Sat, 10 Apr 93 18:23:43 -0700 From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9304110123.AA29740@gremlin> To: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!quads!goer@ucbvax.Berkeley.EDU, icon-group@cs.arizona.edu Subject: Re: Icon rookie problems solved Status: R Errors-To: icon-group-errors@cs.arizona.edu >From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) >Subject: Re: Icon rookie problems solved > >bweiss@cs.arizona.edu (Beth Weiss) writes: >... > procedure genchar(s,c) > suspend s[upto(c,s)] > end > >If it's this easy, why encapsulate it in a separate procedure?? > > procedure main() > stuff... > every write(s[upto(c, s)]) >-- > -Richard L. Goerwitz goer%midway@uchicago.bitnet > goer@midway.uchicago.edu rutgers!oddjob!ellis!goer There are at least four reasons: 1) genchar is a suggestive, easy-to-remember name compared to the alternative; 2) reducing 6 elements (s, upto, [], (), c, s) down to 4 (genchar, (), c, s) reduces the chance of making a mistake in the use and placement of the elements; 3) `s', which appears twice in the solution, could be a complicated, even side-effecting, expression, destroying the simplicity (and perhaps the correctness) of your at-first-glance simple solution; 4) if you were ever to come up with a better implementation of genchar (such as reimplementing it as a built-in function or caching the cset-value of c [if it's actually a string, say] to avoid having to repeatedly coerce it), you could perform one change to the implementation of genchar and all calls of genchar would benefit from that change upon recompilation. Otherwise you could be faced with recognizing and changing all instances of s[upto(c,s)] for all s and c, general expressions (in all of your programs). The basic principle at work here is ``information hiding'', which assists the programmer in localizing the effects of antipicated changes to the design or implementation of a program. By hiding a design decision in a module (in this case a single function), it is possible to change that decision with local, rather than global, changes. See: D. L. Parnas, "On the Criteria to be Used in Decomposing Systems into Modules", Communications of the ACM, December 1972. Bill Griswold wgg@cs.ucsd.edu From icon-group-sender Sat Apr 3 08:18:55 1993 Received: by cheltenham.cs.arizona.edu; Sun, 11 Apr 1993 17:27:32 MST Date: 3 Apr 93 08:18:55 GMT From: mcsun!sunic!news.lth.se!collberg@uunet.uu.net (Christian S. Collberg) Organization: Department of Computer Science, Lund University Subject: Re: April Fools Wish List or is it? Message-Id: <1993Apr3.081855.22733@lth.se> References: <01GWI2QEMTHU8WWJNC@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 article <01GWI2QEMTHU8WWJNC@mis.mcw.edu> Chris Tenaglia - 257-8765 writes: > > \\\\\\\\\\\\\\\\\\\\\//////////////////////// > = NETWORKED-CLIENT/SERVER ICON (drumroll!) = > /////////////////////\\\\\\\\\\\\\\\\\\\\\\\\ > >Chris Tenaglia (System Manager) | "The past explained, Actually, I have extended ICON with RPC primitives, including multicasting and broadcasting. Unfortunately it only runs on SUNs. Furthermore, since ICON does not have lightweight processes builtin, a server can only service one call at a time. I'll put this stuff up for ftp eventually, if anyone is interested. Christian -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden From icon-group-sender Sun Apr 11 17:41:48 1993 Received: by cheltenham.cs.arizona.edu; Sun, 11 Apr 1993 20:41:36 MST Date: Sun, 11 Apr 93 17:41:48 -0700 From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9304120041.AA03835@gremlin> To: icon-group@cs.arizona.edu, mcsun!sunic!news.lth.se!collberg@uunet.uu.net Subject: Re: April Fools Wish List or is it? Status: R Errors-To: icon-group-errors@cs.arizona.edu >In article <01GWI2QEMTHU8WWJNC@mis.mcw.edu> Chris Tenaglia - 257-8765 writes: >> >> \\\\\\\\\\\\\\\\\\\\\//////////////////////// >> = NETWORKED-CLIENT/SERVER ICON (drumroll!) = >> /////////////////////\\\\\\\\\\\\\\\\\\\\\\\\ >> >>Chris Tenaglia (System Manager) | "The past explained, > >Actually, I have extended ICON with RPC primitives, including >multicasting and broadcasting. Unfortunately it only runs on >SUNs. Furthermore, since ICON does not have lightweight processes >builtin, a server can only service one call at a time. I'll put >this stuff up for ftp eventually, if anyone is interested. > >Christian > >-- >Christian.Collberg@dna.lth.se >Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden However, Icon *does* have coroutines, which supports lightweight processing if you add a layer of routines that support preemption, etc. A very simple approach is to reimplement (certain) Icon built-in routines to preempt the coroutine that calls them. A more sophisticated approach would have to support a timed preemption mechanism by extending Icon. Bill Griswold wgg@cs.ucsd.edu From icon-group-sender Sun Apr 4 21:20:33 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Apr 1993 11:01:54 MST Date: 4 Apr 93 21:20:33 GMT From: pipex!marble.uknet.ac.uk!mcsun!news.funet.fi!uta!jere@uunet.uu.net (Jere K{pyaho) Organization: University of Tampere, Finland Subject: Re: Icon rookie problems solved Message-Id: <9394@kielo.uta.fi> References: <9364@kielo.uta.fi>, <1993Apr2.150623.19869@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 <1993Apr2.150623.19869@midway.uchicago.edu> goer@midway.uchicago.edu writes: >The key to scanning is that scanning handles all of your place- >keeping for you, so you don't have to use "every" or the like. >When I tab( upto(c) ), then the first result produced by upto(c) >is where I tab to, and that becomes my position (my &pos, in Icon's >terms). If I want the next c, I can just move(1) past the current >c, and then do another tab( upto(c) ). Icon knows where I am in >the string, and I don't have to keep track of it myself. The next >time I tab( upto(c) ) I'll end up at the next match! This is a very lucid explanation of scanning. I wasn't quite sure about what was going on, but now I think I'm a little more educated in this respect. Thanks. > every i := upto(c) I wanted to use an intermediate variable so as to make things clearer (i.e., not to write a thoroughly compact -- and possibly obscure -- expression.) As Beth Weiss pointed out, we are not really *generating* here. I congratulate myself for coming up with another solution that uses suspend not long after I posted my initial solution. It seems that there are quite many ways of achieving things in Icon. The language caters for a wide spectrum of programming styles, which is good. Many idioms of Icon initially seem very obscure to the uninitiated. Of course, they start to make sense fairly quickly. Then again, you can write incomprehensible code in any programming language, including Icon. But I'll happily choose Icon over C for any task concerned with string processing and even primitive database work (Icon is probably suitable for much more sophisticated database programming, but I'm only familiar with the primitive variant :-) -- // Jere K{pyaho (jere@kielo.uta.fi) | Work is the curse of the // University of Tampere, Finland | drinking classes. -Oscar Wilde From icon-group-sender Mon Apr 5 14:52:08 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Apr 1993 15:02:19 MST Date: 5 Apr 93 14:52:08 GMT From: mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: Supercomputer Computations Research Institute Subject: Looking for "instant guide" for Icon Message-Id: <12437@sun13.scri.fsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Has anyone by chance already produced an "instant guide" for Icon? If so, I'd much appreciate getting a copy of it. I'm going to be teaching a course during the summer semester using this language, and would like for the students to have one to use for programming assignments. If no one already has one, then of course I can knock one out. But I hate to replicate work that someone else already has done. (Not lazy - just try to distribute my time wisely :-) Thanks much, John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Older women/make beautiful lovers/yes, older women/they understand..." (song heard one morning about 2 AM, driving through Georgia) From icon-group-sender Mon Apr 12 15:40:46 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Apr 1993 19:58:24 MST Date: Mon, 12 Apr 93 15:40:46 PDT From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9304122240.AA00662@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: Looking for "instant guide" for Icon Status: R Errors-To: icon-group-errors@cs.arizona.edu >Has anyone by chance already produced an "instant guide" for >Icon? If so, I'd much appreciate getting a copy of it. Well, it just so happens... This is in the Icon Program Library last time I looked, but I'll attach it to this message as well. I created a help file that could be used as an "instant guide". It also provides an on-line help facility -- the program and data file are attached. There also once was a nicely formatted Reference Sheet (the 8 1/2 x 11 equivalent of a Reference *Card* :-), but I don't know if it's still maintained and destributed. The number on the copy I have tacked to my wall is IPD107, updated for version 8 but not for *.xx. It doesn't seem to be in the version 8.7 UNIX distribution (too bad). Maybe the Icon Project has an up-to-date copy if you need one, or I could mail you a copy of my slightly-out-of-date one (hard copy). Hope this helps... ------------------- ihelp.icn --------------------- ############################################################################ # # Name: ihelp.icn # # Title: On-line "help" facility. # # Author: Robert J. Alexander # # Date: December 5, 1989 # ############################################################################ # # ihelp -- Program to display "help" information # # ihelp [-f helpfile] [item] [keyword ...] # # The optional item name specifies the section of the help file which # is to be displayed. If no item name is specified a default section # will be displayed, which usually lists the help items that are # available. An initial substring of the item name that differentiates # it from other items is sufficient. # # If keyword(s) are specified, then only lines that contain all of the # keywords, in any order, are displayed. The keywords do not have to # correspond to whole words in the help text; only to text fragments. # # All item name and keyword matches are case independent. # # The help file name is taken from environment variable "HELPFILE". If # HELPFILE is not in the environment, file "help" in the current # directory is used. A help file name specified in the -f option # overrides. # # The help files are formatted as follows: # # default text lines # - # one # item "one" text lines # - # two # item "two" text lines # ... # # Sections are separated by lines containing a single "-". Item names # are the first line following a separator line. # link options procedure main(arg) # # Initialize. # defaultHelpFile := "help" opts := options(arg,"f:") fn := \opts["f"] | "" ~== getenv("HELPFILE") | defaultHelpFile f := open(fn) | stop("Can't open help file \"",fn,"\"") # # Look for the specified section, if one was. # if item := map(arg[1]) then { line := "" until item == map(line[1:*item + 1]) do { while read(f) ~== "-" line := read(f) | stop("No help for ",item) } } # # Output the section lines that contain the keywords. # write(line) keywords := arg[2:0] | [] every i := 1 to *keywords do keywords[i] := map(keywords[i]) while "-" ~== (line := read(f)) do { lline := map(line) if not (every k := !keywords do if not find(k,lline) then break) then write(line) } end ----------- help ------------------------------------------------ Icon Programming Language Version 8.7 Help Summaries Help summaries are available for each of the Icon executable programs (icont, iconx), and for many aspects of the Icon language itself. To see the help summaries, enter one of the following commands: ihelp icont # Icon translator & linker ihelp iconx # Icon interpreter ihelp expressions # summary of expressions & precedence ihelp functions # summary of functions ihelp operations # summary of operations ihelp keywords # list of keywords ihelp datatypes # list of Icon datatypes ihelp reserved # list of reserved words ihelp escapes # list of string escape sequences ihelp abbreviations # abbreviations used in help files ihelp # information on specific function ihelp about # bibliography and credits for help file - abs(N) : N # compute absolute value Produces the absolute value of N. - acos(r1) : r2 # compute arc cosine Produces the arc cosine of r1 in the range of 0 to pi for r1 in the range of -1 to 1. - any(c,s,i1,i2) : i3 # locate initial character Succeeds and produces i1 + 1 if s[i1] is in c and i2 > i1, but fails otherwise. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - args(p) : i # get number of procedure arguments Produces the number of arguments for procedure p. For built-in procedures with a variable number of arguments, the value produced is -1. For declared procedures with a variable number of arguments, the value returned is the negative of the number of formal prameters. - bal(c1,c2,c3,s,i1,i2) : i3,i4,...,in # locate balanced characters Generates the sequence of integer positions in s preceding a character of c1 in s[i1:i2] that is balanced with respect to the characters of c2 and c3, but fails if there is no such position. Defaults: c1 &cset c2 '(' c3 ')' s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - callout(x,x1,x2,...,xn) : xm # call external function Calls the external function specified by x with arguments x1, x2, ..., xn. The mechanism for locating the function specified by x is system dependent. - center(s1,i,s2) : s3 # position string at center Produces a string of size i in which s1 is centered, with s2 used for padding at left and right as necessary. Defaults: i 1 s2 " " (blank) - char(i) : s # produce character Produces a string of length 1 consisting of the character whose internal representation is i. - chdir(s) : n # change directory Changes the directory to s but fails if there is no such directory or if the change cannot be made. - close(f) : f # close file Produces f after closing it unless f was opened with the pipe ("p") option, in which case the integer exit status of the command is returned. - collect(i1,i2) : n # perform garbage collection Causes a garbage collectionin region i1, requesting i2 bytes of space in that region. It fails if the requested space is not available. The regions are identified as follows: 1 Static region 2 String region 3 Block region If i1 is 0, a collection is done, but no region is identified and i2 has no effect. The value of i2 is ignored for the static region. Defaults: i1 0 i2 0 - copy(x1) : x2 # copy value Produces a copy of x1 if x1 is a structure; otherwise it produces x1. - cos(r1) : r2 # compute cosine Produces the cosine of r1 in radians. - cset(x) # convert to cset Produces a cset resulting from converting x, but fails if the conversion is not possible. - delay(i) : n # delay execution Delays execution i milliseconds. - delete(X,x) : X # delete element If X is a set, deletes x from X. If X is a table, deletes the element for key x from X. Produces X. - detab(s1,i1,i2,...,in) : s2 # remove tabs Produces a string based on s1 in which each tab character is replaced by one or more blanks. Tab stops are at i1, i2, ..., in, with additional stops obtained by repeating the last interval. Default: i1 9 - display(i,f) : n # display variables Writes the image of the current co-expression and the values of the local variables in the current procedure call. If i > 0, the local variables in the i preceding procedure calls are displayed as well. After all local variables are displayed, the values of global variables are displayed. Output is written to f. Defaults: i &level f &errout - dtor(r1) : r2 # convert degrees to radians Produces the radian equivalent of r1 given in degrees. - entab(s1,i1,i2,...,in) : s2 # insert tabs Produces a string based on s1 in which runs of blanks are replaced by tabs. Tab stops are at i1, i2, ..., in, with additional stops obtained by repeating the last interval. Default: i1 9 - errorclear() : n # clear error indication Clears the indications of the last error. - exit(i) # exit program Terminates the program with exit status i. Default: i normal exit (system dependent) - exp(r1) : r2 # compute exponential Produces e raised to the power r1. - find(s1,s2,i1,i2) : i3,i4,...,in # find string Generates the sequence of integer positions in s2 at which s1 occurs as a substring in s2[i1:i2], but fails if there is no such position. Defaults: s2 &subject i1 &pos if s2 defaulted, otherwise 1 i2 0 - flush(f) : n # flush I/O buffer Flushes the input/output buffers for f. - function() : s1,s2,...,sn # generate function names Generates the names of the Icon (built-in) functions. - get(L) : x # get value from list Produces the leftmost element of L and removes it from L, but fails if L is empty; synonym for pop(L). - getenv(s1) : s2 # get value of environment variable Produces the value of environment variable s1, but fails if the variable is not set or environment variables are not supported. - iand(i1,i2) : i3 # compute bit-wise "and" Produces the bitwise "and" of i1 and i2. - icom(i1) : i2 # compute bit-wise complement Produces the bitwise complement (1's complement) of i1. - image(x) : s # produce string image Produces a string image of x. - insert(X,x1,x2) : X # insert element If X is a table, inserts the key x1 with value x2 into X. If X is a set, inserts x1 into X. Produces X. Default: x2 &null - integer(x) : i # convert to integer Produces the integer resulting from converting x, but fails if the conversion is not possible. - ior(i1,i2) : i3 # compute bit-wise inclusive "or" Produces the bitwise inclusive "or" of i1 and i2 - ishift(i1,i2) : i3 # shift bits Produces the result of shifting the bits in i1 by i2 positions. Positive values of i2 shift to the left, negative to the right. Vacated bit positions are zero-filled. - ixor(i1,i2) : i3 # compute bit-wise exclusive "or" Produces the bitwise exclusive "or" of i1 and i2. - key(T) : x1,x2,...,xn # generate keys from table Generates the keys in table T. - left(s1,i,s2) : s3 # position string at left Produces a string of size i in which s1 is positioned at the left, with s2 used for padding on the right as necessary. Defaults: i 1 s2 " " (blank) - list(i,x) : L # create list Produces a list of size i in which each value is x. Defaults: i 0 x &null - log(r1,r2) : r3 # compute logarithm Produces the logarithm of r1 to the base r2. Default: r2 e - many(c,s,i1,i2) : i3 # locate many characters Succeeds and produces the position in s after the longest initial sequence of characters in c in s[i1:i2]. It fails if s[i1] is not in c. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - map(s1,s2,s3) : s4 # map characters Produces a string of size *s1 obtained by mapping characters of s1 that occur in s2 into corresponding characters in s3. Defaults: s2 string(&ucase) s3 string(&lcase) - match(s1,s2,i1,i2) : i3 # match initial string Produces i1 + *s1 if s1 == s2[i1+:*s1], but fails otherwise. Defaults: s2 &subject i1 &pos if s2 defaulted, otherwise 1 i2 0 - member(X,x) : x # test for membership If X is a set, succeeds if x is a member of X, but fails otherwise. If X is a table, succeeds if x is a key of an element in X, but fails otherwise. Produces x if it succeeds. - mmout(x) : n # write text to allocation history Writes s to the allocation history file. s is given no interpretation. - mmpause(s) : n # write pause to allocation history Writes s to the allocation history file as a pause point with identification s. Default: s "programmed pause" - mmshow(x,s) : n # redraw in allocation history Specifies redrawing of x in the allocation history file. The color is defined by s as follows: "b" black "g" gray "w" white "h" highlight; blinking black and white if possible "r" normal color If x is not in an allocated region, has no effect. Default: s "r" - move(i) : s # move scanning position Produces &subject[&pos:&pos + i] and assigns i + &pos to &pos, but fails if i is out of range; reverses assignment to &pos if resumed. - name(x) : s # produce name Produces the name of the variable x. If x is an identifier or a keyword that is a variable, the name of the identifier or keyword is produced. If x is a record field reference, the record name and field name are produced with a separating period. If x is a string, the name of the string and the subscript range are shown. If x is a subscripted list or table, the type name followed by the subscripting expression is produced. - numeric(x) : N # convert to numeric Produces an integer or real number resulting from converting x, but fails if the conversion is not possible. - open(s1,s2) : f # open file Produces a file resulting from opening s1 according to options in s2, but fails if the file cannot be opened. The options are: "r" open for reading "w" open for writing "a" open for writing in append mode "b" open for reading and writing "c" create "t" translate line termination sequences to linefeeds "u" do not translate line termination sequences to linefeeds "p" pipe to/from a command -- UNIX The default mode is to translate line termination sequences to linefeeds on input and conversely on output. The untranslated mode should be used when reading and writing binary files. Default: s2 "rt" - ord(s) : i # produce ordinal Produces an integer (ordinal) between 0 and 255 that is the internal representation of the single character in s. - pop(L) : x # pop from list Produces the leftmost element of L and removes it from L, but fails if L is empty; synonym for get(L). - pos(i1) : i2 # test scanning position Produces &pos if &pos = i1, but fails otherwise. - proc(x,i) : p # convert to procedure Produces a procedure corresponding to the value of x, but fails if x does not correspond to a procedure. If x is the string name of an operator, i specifies the number of arguments: 1 for unary (prefix), 2 for binary (infix), and 3 for ternary. Default: i 1 - pull(L) : x # pull from list Produces the rightmost element of L and removes it from L, but fails if L is empty. - push(L,x) : L # push onto list Adds x to the left end of L and produces L. - put(L,x) : L # put onto list Adds x to the right end of L and produces L. - read(f) : s # read line Produces the next line from f, but fails on end of file. Default: f &input - reads(f,i) : s # read string Produces a string consisting of the next i characters from f, or the remaining characters of f if fewer remain, but fails on an end of file. In reads(), unlike read(), line termination sequences have no special significance. reads() should be used for reading binary data. Defaults: f &input i 1 - real(x) : r # convert to real Produces a real number resulting from type conversion of x, but fails if the conversion is not possible. - remove(s) : n # remove file Removes (deletes) the file named s, but fails if s cannot be removed. - rename(s1,s2) : n # rename file Renames the file named s1 to be s2, but fails if the renaming cannot be done. - repl(s1,i) : s2 # replicate string Produces a string consisting of i concatenations of s1. - reverse(s1) : s2 # reverse string Produces a string consisting of the reversal of s. - right(s1,i,s2) : s3 # position string at right Produces a string of size i in which s1 is positioned at the right, with s2 used for padding on the left as necessary. Defaults: i 1 s2 " " (blank) - rtod(r1) : r2 # convert radians to degrees Produces the degree equivalent of r1 given in radians. - runerr(i,x) # terminate with run-time error Terminates program execution with error i and offending value x. Default: x no offending value - save(s) : i # save executable image Saves an executable image of the current running program in the file named s and produces the size of the file, but fails if the file cannot be created. - seek(f,i) : f # seek to position in file Seeks to position i in f, but fails if the seek cannot be performed. The first byte in the file is at position 1. seek(f,0) seeks to the end of file f. - seq(i1,i2) : i3,i4,... # generate sequence of integers Generates an endless sequence of integers starting at i1 with increments of i2. Defaults: i1 1 i2 1 - set(L) : S # create set Produces a set whose members are the distinct values in the list L. Default: L [] - sin(r1) : r2 # compute sine Produces the sine of r1 given in radians. - sort(X,i) : L # sort structure Produces a list containing values from X. If X is a list or a set, sort(X,i) produces the values of X in sorted order. If X is a table, sort(X,i)produces a list obtained by sorting the elements of X, depending on the value of i. For Produces a list according to i: i = (1 | 2) Produces a list of two-element lists of key/value pairs from X; ordered by keys for i = 1, by values for i = 2. i = (3 | 4) Produces a list of size 2 * *X with each consecutive pair of elements consisting of a key and a value from X; ordered by keys for i = 3, by values for i = 4. Default: i 1 - sortf(X,i) : L # sort list or set by field Produces a sorted list of the values in X. Sorting is primarily by type and in most respects is the same as with sort(X,i). However, among lists and among records, two structures are ordered by comparing their ith fields. i can be negative but not zero. Two structures having the equal ith fields are ordered as they would be in regular sorting, but structures lacking an ith field appear before structures having them. Default: i 1 - sqrt(r1) : r2 # compute square root Produces the square root of r1. - stop(x1,x2,...,xn) # stop execution Terminates program execution with an error status after writing strings x1,x2,...,xn. If xi is a file, subsequent output is to xi. Initial output is to standard error output. Default: xi "" (empty string) - string(x) : s # convert to string Produces a string resulting from converting x, but fails if the conversion is not possible. - system(s) : i # call system function Calls the C library function "system" to execute s and produces the resulting integer exit status. - tab(i) : s # set scanning position Produces &subject[&pos:i] and assigns i to &pos, but fails if i is out of range. It reverses assignment to &pos if resumed. - table(x) : T # create table Produces a table with a default value x. Default: x &null - tan(r1) : r2 # compute tangent Produces the tangent of r1 given in radians. - trim(s1,c) : s2 # trim string Produces a string consisting of the characters of s1 up to the trailing characters contained in c. Default: c ' ' (blank) - type(x) : s # produce type name Produces a string corresponding to the type of x. - upto(c,s,i1,i2) : i3,i4,...,in # locate characters Generates the sequence of integer positions in s preceding a character of c in s[i1:i2]. It fails if there is no such position. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - variable(s) : x # produce variable Produces the variable for the identifier or keyword named s, but fails if there is no such variable. Local identifiers override global identifiers. - where(f) : i # produce position in file Produces the current byte position in f. The first byte in the file is at position 1. - write(x1,x2,...,xn) : xn # write line Writes strings x1,x2,...,xn with a line termination sequence added at the end. If xi is a file, subsequent output is to xi. Initial output is to standard output. Default: xi "" (empty string) - writes(x1,x2,...,xn) # write string Writes strings x1,x2,...,xn without a line termination sequence added at the end. If xi is a file, subsequent output is to xi. Initial output is to standard output. Default: xi "" (empty string) - icont -- Icon translator and linker icont [option...] file... -c # translate only (no link) -o file # name icode file "file" -s # suppress progress messages -t # give &trace initial value of -1 -u # issue warnings for undeclared identifiers See also: ihelp iconx - iconx -- Icon interpreter The Icon interpreter is normally invoked automatically when the name of an Icon program is entered as a command, but it can be invoked explicitly, too. iconx icode_file_name [arguments for Icon program.] Shell environment variables recognized by iconx =============================================== Name Default Description -------- ------- ----------------------- TRACE 0 Initial value for &trace. NOERRBUF undefined If set, &errout is not buffered. STRSIZE 65000 Initial size (bytes) of string region (strings). BLOCKSIZE 65000 Initial size (bytes) of block region (most objects). COEXPSIZE 2000 Size (long words) of co-expression blocks. MSTKSIZE 10000 Size (long words) of main interpreter stack. STATSIZE 20480 Initial size (bytes) of static region (co-expression blocks). STATINCR 1/4 of Increment used to expand static region. STATSIZE See also: ihelp icont - Expressions shown in order of decreasing precedence. Items in groups (as separated by empty lines) have equal precedence. High Precedence Expressions (expr) # grouping {expr1;expr2;...} # compound x(expr1,expr2,...) # invocation x{expr1,expr2,...} # " [expr1,expr2,...] # list expr.F # field reference expr1[expr2] # subscript expr1[expr2:expr3] # section expr1[expr2+:expr3] # " expr1[expr2-:expr3] # " Prefix Expressions not expr # success/failure reversal | expr # repeated alternation ! expr # element generation * expr # size + expr # numeric value - expr # negative . expr # value (dereference) / expr # null \ expr # non-null = expr # match and tab ? expr # random value ~ expr # cset complement @ expr # activation ^ expr # refresh Infix Expressions expr1 \ expr2 # limitation expr1 @ expr2 # transmission expr1 ! expr2 # invocation expr1 ^ expr2 # power expr1 * expr2 # product expr1 / expr2 # quotient expr1 % expr2 # remainder expr1 ** expr2 # intersection expr1 + expr2 # sum expr1 - expr2 # numeric difference expr1 ++ expr2 # union expr1 -- expr2 # cset or set difference expr1 || expr2 # string concatenation expr1 ||| expr2 # list concatenation expr1 < expr2 # numeric comparison expr1 <= expr2 # " expr1 = expr2 # " expr1 >= expr2 # " expr1 > expr2 # " expr1 ~= expr2 # " expr1 << expr2 # string comparison expr1 <<= expr2 # " expr1 == expr2 # " expr1 >>= expr2 # " expr1 >> expr2 # " expr1 ~== expr2 # " expr1 === expr2 # value comparison expr1 ~=== expr2 # " expr1 | expr2 # alternation expr1 to expr2 by expr3 # integer generation expr1 := expr2 # assignment expr1 <- expr2 # reversible assignment expr1 :=: expr2 # exchange expr1 <-> expr2 # reversible exchange expr1 op:= expr2 # (augmented assignments) expr1 ? expr2 # string scanning expr1 & expr2 # conjunction Low Precedence Expressions break [expr] # break from loop case expr0 of { # case selection expr1:expr2 ... [default:exprn] } create expr # co-expression creation every expr1 [do expr2] # iterate over generated values fail # failure of procedure if expr1 then exp2 [else exp3] # if-then-else next # go to top of loop repeat expr # loop return expr # return from procedure suspend expr1 [do expr2] # suspension of procedure until expr1 [do expr2] # until-loop while expr1 [do expr2] # while-loop - Functions and datatypes of arguments and produced values: abs(N) : N # compute absolute value acos(r1) : r2 # compute arc cosine any(c,s,i1,i2) : i3 # locate initial character args(p) : i # get number of procedure arguments bal(c1,c2,c3,s,i1,i2) : i3,i4,...,in # locate balanced characters callout(x,x1,x2,...,xn) : xm # call external function center(s1,i,s2) : s3 # position string at center char(i) : s # produce character chdir(s) : n # change directory close(f) : f # close file collect(i1,i2) : n # perform garbage collection copy(x1) : x2 # copy value cos(r1) : r2 # compute cosine cset(x) # convert to cset delay(i) : n # delay execution delete(X,x) : X # delete element detab(s1,i1,i2,...,in) : s2 # remove tabs display(i,f) : n # display variables dtor(r1) : r2 # convert degrees to radians entab(s1,i1,i2,...,in) : s2 # insert tabs errorclear() : n # clear error indication exit(i) # exit program exp(r1) : r2 # compute exponential find(s1,s2,i1,i2) : i3,i4,...,in # find string flush(f) : n # flush I/O buffer function() : s1,s2,...,sn # generate function names get(L) : x # get value from list getenv(s1) : s2 # get value of environment variable iand(i1,i2) : i3 # compute bit-wise "and" icom(i1) : i2 # compute bit-wise complement image(x) : s # produce string image insert(X,x1,x2) : X # insert element integer(x) : i # convert to integer ior(i1,i2) : i3 # compute bit-wise inclusive "or" ishift(i1,i2) : i3 # shift bits ixor(i1,i2) : i3 # compute bit-wise exclusive "or" key(T) : x1,x2,...,xn # generate keys from table left(s1,i,s2) : s3 # position string at left list(i,x) : L # create list log(r1,r2) : r3 # compute logarithm many(c,s,i1,i2) : i3 # locate many characters map(s1,s2,s3) : s4 # map characters match(s1,s2,i1,i2) : i3 # match initial string member(X,x) : x # test for membership mmout(x) : n # write text to allocation history mmpause(s) : n # write pause to allocation history mmshow(x,s) : n # redraw in allocation history move(i) : s # move scanning position name(x) : s # produce name numeric(x) : N # convert to numeric open(s1,s2) : f # open file ord(s) : i # produce ordinal pop(L) : x # pop from list pos(i1) : i2 # test scanning position proc(x,i) : p # convert to procedure pull(L) : x # pull from list push(L,x) : L # push onto list put(L,x) : L # put onto list read(f) : s # read line reads(f,i) : s # read string real(x) : r # convert to real remove(s) : n # remove file rename(s1,s2) : n # rename file repl(s1,i) : s2 # replicate string reverse(s1) : s2 # reverse string right(s1,i,s2) : s3 # position string at right rtod(r1) : r2 # convert radians to degrees runerr(i,x) # terminate with run-time error save(s) : i # save executable image seek(f,i) : f # seek to position in file seq(i1,i2) : i3,i4,... # generate sequence of integers set(L) : S # create set sin(r1) : r2 # compute sine sort(X,i) : L # sort structure sortf(X,i) : L # sort list or set by field sqrt(r1) : r2 # compute square root stop(x1,x2,...,xn) # stop execution string(x) : s # convert to string system(s) : i # call system function tab(i) : s # set scanning position table(x) : T # create table tan(r1) : r2 # compute tangent trim(s1,c) : s2 # trim string type(x) : s # produce type name upto(c,s,i1,i2) : i3,i4,...,in # locate characters variable(s) : x # produce variable where(f) : i # produce position in file write(x1,x2,...,xn) : xn # write line writes(x1,x2,...,xn) # write string - Operations and required datatypes prefix operations +N : N # compute positive -N : N # compute negative ~c1 : c2 # compute cset complement =s1 : s2 # match string in scanning @C : x # activate co-expression ^C1 : C2 # create refreshed co-expression *x : i # compute size ?x1 : x2 # generate random value !x : x1,x2,...,xn # generate values /x : x # check for null value \x : x # check for non-null value .x : x # dereference variable infix operations N1 + N2 : N3 # compute sum N1 - N2 : N3 # compute difference N1 * N2 : N3 # compute product N1 / N2 : N3 # compute quotient N1 % N2 : N3 # compute remainder N1 ^ N2 : N3 # compute exponential x1 ++ x2 : x3 # compute cset or set union x1 -- x2 : x3 # compute cset or set difference x1 ** x2 : x3 # compute cset or set intersection s1 || s2 : s3 # concatenate strings L1 ||| L2 : L3 # concatenate lists R.F : x # get field of record x1 @ C : x2 # transmission value to co-expression x1 & x2 : x2 # evaluate in conjunction N1 < N2 : N2 # compare numerically N1 <= N2 : N2 # " N1 = N2 : N2 # " N1 >= N2 : N2 # " N1 > N2 : N2 # " N1 ~= N2 : N2 # " s1 << s2 : s2 # compare lexically s1 <<= s2 : s2 # " s1 == s2 : s2 # " s1 >>= s2 : s2 # " s1 >> s2 : s2 # " s1 ~== s2 : s2 # " x1 === x2 : x2 # compare values x1 ~=== x2 : x2 # " x1 := x2 : x1 # assign value x1 op:= x2 : x1 # augmented assignment x1 :=: x2 : x1 # exchange values x1 <- x2 : x1 # assign value reversibly x1 <-> x2 : x1 # exchange values reversibly - Keywords &allocated : i1,i2,i3,i4 # accumulated bytes allocated # (total,static,string,block) &ascii : c # cset of ascii characters &clock : s # current time of day &collections : i1,i2,i3,i4 # collection count # (total,static,string,block) &cset : c # cset of all characters ¤t : C # current co-expression &date : s # current date &dateline : s # current date and time &digits : c # cset of digits 0-9 &e : r # base of natural logarithms, 2.71828... &error : i # run-time error conversion control &errornumber : i # run-time error number &errortext : s # run-time error message text &errorvalue : x # run-time error offending value &errout : f # standard error output file &fail # fails &features : s1,s2,...,sn # implementation features &file : s # current source code file name &host : s # string identifying host computer &input : f # standard input file &lcase : c # cset of lower case letters a-z &letters : c # cset of all letters A-Za-z &level : i # level of current procedure call &line : i # current source code line number &main : C # main co-expression &null : n # the null value &output : f # standard output file &phi : r # the golden ratio, 1.61803... &pi : r # the value of pi, 3.14159... &pos : i # string scanning position &progname : s # file name of the executing program &random : i # random number seed ®ions : i1,i2,i3 # current region size # (static,string,block) &source : C # activator of current co-expression &storage : i1,i2,i3 # current bytes allocated # (static,string,block) &subject : s # string scanning subject &time : i # current run time in milliseconds &trace : i # procedure tracing control &ucase : c # cset of upper case letters A-Z &version : s # version of Icon - Datatypes null (n) string (s) co-expression (C) table (T) integer (i) cset (c) procedure (p) set (S) real (r) file (f) list (L) (R) (see also "Abbreviations") - Reserved words break do global next repeat to by else if not return until case end initial of static while create every link procedure suspend default fail local record then - Escapes in string and cset constants \b backspace \v vertical tab \d delete(rubout) \' single quote \e escape (altmode) \" double quote \f formfeed \\ backslash \l linefeed (newline) \ddd octal code \n newline (linefeed) \xdd hexadecimal code \r carriage return \^c control code \t horizontal tab - Abbreviations used in Icon help files (and other Icon literature) c cset C co-expression f file L list i integer N numeric (i or r) n null R record (any record type) p procedure S set r real T table s string X any structure type (L, R, S, or T) x any type F field of record - About the Icon Programming Language Help File Information used in this help file was obtained from the following sources: Griswold, Ralph E. and Madge T. Griswold. "The Icon Programming Language, Second Edition", Prentice-Hall, Inc., Englewood Cliffs, New Jersey. 1990. Griswold, Ralph E. ICONT(1), manual page for "UNIX Programmer's Manual", Department of Computer Science, The University of Arizona. 1988. Griswold, Ralph E., Clinton L. Jeffery, Gregg M. Townsend, and Kenneth Walker. "Version 8.6 of the Icon Programming Language", IPD188, Department of Computer Science, The University of Arizona. 1992. Further information on the Icon Programming Language can be obtained from: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, Arizona 85721 U.S.A. (602) 621-2018 icon-project@cs.arizona.edu (Internet) ...{uunet,allegra,noao}!arizona!icon-project (uucpnet) April 2, 1992. From icon-group-sender Mon Apr 5 16:32:13 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Apr 1993 19:59:00 MST Date: 5 Apr 93 16:32:13 GMT From: digex.com!digex.com!not-for-mail@uunet.uu.net (Pat) Organization: Express Access Online Communications USA Subject: Re: Language Translators Message-Id: <1ppmud$1ai@access.digex.net> References: <1pfeenINNev1@dns1.NMSU.Edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Chris was asking about an Esperanto-English translator in ICON. No. Sorry, Haven't made much progress on it. Pressing business elsewhere. Actually, the only esperanto language program I ever did, was part of a senior project. We were making automatic letter writers for Esperanto. To make the project a little more interesting, we decided the topics should be letters to Penthouse. I think it'd be real interesting to try that out again in ICON. Maybe someone at arizona could make it a subject for a senior thesis. pat From icon-group-sender Tue Apr 13 04:59:05 1993 Received: by cheltenham.cs.arizona.edu; Wed, 14 Apr 1993 05:39:14 MST Date: 13 Apr 93 04:59:05 GMT From: howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!msuinfo!uchinews!ellis!goer@gatech.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: constructing objects at run-time Message-Id: <1993Apr13.045905.394@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I've asked this before, but I'd like to try once more. What do people consider to be the "best" (i.e. easiest, fastest, smal- lest, etc.) way to store and reconstruct objects? I.e. say I have a table one program has created, and this program wants to store the table so that another program can later re-create it. What is the most sensible way of doing this? I lean towards "most sensible" as meaning "fastest on the reconstructing end." -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Apr 14 10:06:11 1993 Received: by cheltenham.cs.arizona.edu; Thu, 15 Apr 1993 05:37:09 MST Date: 14 Apr 93 10:06:11 GMT From: news.univie.ac.@!alijku11!aci.cvut.cs!cis.vutbr.cs!jbowyer@uunet.uu.net (Bowyer Jeff) Organization: Technical University of Brno, Czech Republic Subject: We Want Your Work Message-Id: <1993Apr14.100611.6827@cis.vutbr.cs> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu We want you to announce your work on our mailing list! Do you use a program that has a non-English interface? Have you converted any software to support more than one language for its interface? Will you sponsor a conference that might concern software with a non-English interface? Please tell us! INSOFT-L on LISTSERV@CIS.VUTBR.CS Internationalization of Software Discussion List Internationalization of software relates to two subjects: 1. Software that is written so a user can easily change the language of the interface; 2. Versions of software, such as Czech WordPerfect, whose interface language differs from the original product. Topics discussed on this list will include: -- Techniques for developing new software -- Techniques for converting existing software -- Internationalization tools -- Announcements of internationalized public domain software -- Announcements of foreign-language versions of commercial software -- Calls for papers -- Conference announcements -- References to documentation related to the internationalization of software This list is moderated. To subscribe to this list, send an electronic mail message to LISTSERV@CIS.VUTBR.CS with the body containing the command: SUB INSOFT-L Yourfirstname Yourlastname Owner: Center for Computing and Information Services Technical University of Brno Udolni 19, 602 00 BRNO Czech Republic INSOFT-L-REQUEST@CIS.VUTBR.CS From icon-group-sender Wed Apr 14 14:13:19 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 05:41:52 MST Date: 14 Apr 93 14:13:19 GMT From: usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: Looking for "instant guide" for Icon Message-Id: <12526@sun13.scri.fsu.edu> References: <9304122240.AA00662@laguna.Metaphor.COM> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <9304122240.AA00662@laguna.Metaphor.COM> alex@laguna.Metaphor.COM (Bob Alexander) writes: >>Has anyone by chance already produced an "instant guide" for >>Icon? If so, I'd much appreciate getting a copy of it. > >Well, it just so happens... > >This is in the Icon Program Library last time I looked, but I'll attach >it to this message as well. I created a help file that could be used >as an "instant guide". It also provides an on-line help facility -- >the program and data file are attached. ... Thanks - that is pretty much what I was looking for. I may have to make a few tweaks (to make it fit the format of the class) but by and large it seems to be great. And by the way, it IS in /ipl/progs under the name of ihelp.icn but the help file is not in there. Or at least I could not find it. So thanks for posting it along with your message. (The reason for posting this to the net rather than just an e-mail note is so that the Icon group realizes that the help file is not included with ihelp.icn) John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Older women/make beautiful lovers/yes, older women/they understand..." (song heard one morning about 2 AM, driving through Georgia) From icon-group-sender Mon Apr 12 13:45:14 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 05:42:16 MST Date: 12 Apr 93 13:45:14 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon rookie problems solved Message-Id: <1993Apr12.134514.27757@midway.uchicago.edu> References: <9304110123.AA29740@gremlin> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >> s[upto(c,s)] > >The basic principle at work here is ``information hiding'', which assists >the programmer in localizing the effects of antipicated changes to the >design or implementation of a program. I don't doubt your general principles. Are you sure, though, that you would want to reduce expressions of the above size to procedure calls? Especially when they are so easily and lucidly constructed? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Apr 12 13:45:14 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 05:42:40 MST Date: 12 Apr 93 13:45:14 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon rookie problems solved Message-Id: <1993Apr12.134514.27757@midway.uchicago.edu> References: <9304110123.AA29740@gremlin> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >> s[upto(c,s)] > >The basic principle at work here is ``information hiding'', which assists >the programmer in localizing the effects of antipicated changes to the >design or implementation of a program. I don't doubt your general principles. Are you sure, though, that you would want to reduce expressions of the above size to procedure calls? Especially when they are so easily and lucidly constructed? -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Apr 15 11:20:07 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 05:42:59 MST Date: 15 Apr 93 11:20:07 GMT From: usenet.ufl.edu!mailer.cc.fsu.edu!sun13!ibm12.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: Supercomputer Computations Research Institute Subject: Re: Looking for "instant guide" for Icon Message-Id: <12535@sun13.scri.fsu.edu> References: <9304122240.AA00662@laguna.Metaphor.COM>, <12526@sun13.scri.fsu.edu>, <1993Apr14.155202.14193@hemlock.cray.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993Apr14.155202.14193@hemlock.cray.com> cargo@cray.com (David S. Cargo) writes: > >There is an ihelp.dat file included with the standard distributions. >It is located in the "data" directory, which is at the same level as >the procs and progs directory of the IPL. Yes, I received about a zillion replies (via e-mail) telling me the same thing. I am properly humbled and chastised and apologise to all and sundry (especially the people who maintain the Icon files at Arizona). It is interesting that I received so many replies, since that implies that a lot more people are "lurkers" on this group than on most. I've noticed that only about 4 or 5 people ever post anything. Perhaps we need to raise more controversial issues, such as the use of Icon for political purposes, or something like that :-) John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, Florida "Older women/make beautiful lovers/yes, older women/they understand..." (song heard one morning about 2 AM, driving through Georgia) From icon-group-sender Fri Apr 16 15:46:38 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 17:52:26 MST From: nwharton@uahcs2.cs.uah.edu (Nathan Wharton) (Computer Science Dept., Univ. of Alabama-Huntsville) Message-Id: <9304162046.AA20451@uahcs2.cs.uah.edu> Subject: Unix Pipes and Amiga Icon To: icon-group@cs.arizona.edu Date: Fri, 16 Apr 93 15:46:38 CDT X-Mailer: ELM [version 2.4dev PL73] Content-Type: text Content-Length: 977 Status: R Errors-To: icon-group-errors@cs.arizona.edu I have a question about reading from pipes within icon on unix, and a question about how to set up the IPATH variable on an Amiga 3000 running 2.1. First, the pipe question. I made a named pipe using the unix 'mknod' command with the p option. Is there a way in icon that you can call some procedure to see if there is a data ready on the pipe? What would be nice is a procedure that would return the line read in from the pipe, or else fail if no info is in the pipe. The read function just waits until a line is there. Second, on the Amiga, I can not get icont to link in ucode from other directories. Here is an example of the problem: 9> echo $IPATH ICON:ucode 9> cd $IPATH 9> ls options* options.u1 options.u2 9> cd icon:progs 9> icont zipsort.icn Translating: zipsort.icn: main (1174/15000) No errors Linking: icont: cannot resolve reference to file 'options.u1' Thanks in advance. -- Nathan Wharton nwharton@cs.uah.edu Work: (205)922-6000 From icon-group-sender Wed Apr 14 20:52:02 1993 Received: by cheltenham.cs.arizona.edu; Fri, 16 Apr 1993 17:52:43 MST Date: 14 Apr 93 20:52:02 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!uchinews!raistlin!timbuk.cray.com!hemlock.cray.com!cargo@gatech.edu (David S. Cargo) Organization: Cray Research, Inc. Subject: Re: Looking for "instant guide" for Icon Message-Id: <1993Apr14.155202.14193@hemlock.cray.com> References: <9304122240.AA00662@laguna.Metaphor.COM>, <12526@sun13.scri.fsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu There is an ihelp.dat file included with the standard distributions. It is located in the "data" directory, which is at the same level as the procs and progs directory of the IPL. David S. Cargo cargo@escargot.cray.com (612) 683-5591 From icon-group-sender Mon Apr 12 00:41:48 1993 Received: by cheltenham.cs.arizona.edu; Sat, 17 Apr 1993 08:52:40 MST Date: 12 Apr 93 00:41:48 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (William Griswold) Subject: Re: April Fools Wish List or is it? Message-Id: <9304120041.AA03835@gremlin> 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 <01GWI2QEMTHU8WWJNC@mis.mcw.edu> Chris Tenaglia - 257-8765 writes: >> >> \\\\\\\\\\\\\\\\\\\\\//////////////////////// >> = NETWORKED-CLIENT/SERVER ICON (drumroll!) = >> /////////////////////\\\\\\\\\\\\\\\\\\\\\\\\ >> >>Chris Tenaglia (System Manager) | "The past explained, > >Actually, I have extended ICON with RPC primitives, including >multicasting and broadcasting. Unfortunately it only runs on >SUNs. Furthermore, since ICON does not have lightweight processes >builtin, a server can only service one call at a time. I'll put >this stuff up for ftp eventually, if anyone is interested. > >Christian > >-- >Christian.Collberg@dna.lth.se >Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden However, Icon *does* have coroutines, which supports lightweight processing if you add a layer of routines that support preemption, etc. A very simple approach is to reimplement (certain) Icon built-in routines to preempt the coroutine that calls them. A more sophisticated approach would have to support a timed preemption mechanism by extending Icon. Bill Griswold wgg@cs.ucsd.edu From icon-group-sender Fri Apr 16 19:30:24 1993 Received: by cheltenham.cs.arizona.edu; Sun, 18 Apr 1993 05:11:11 MST Date: 16 Apr 93 19:30:24 GMT From: news.intercon.com!digex.com!digex.com!not-for-mail@louie.udel.edu (Pat) Organization: Express Access Online Communications, Greenbelt MD USA Subject: Is there a run time Debugger in developement? Message-Id: <1qn1gg$hng@access.digex.net> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I hope this isn't arookie question, But is anyone plowing along at writing a run-time debugger? The trace function is nice, but I guess i've gotten spoiled. It would be nice to be able to single step the code and examine values or see them changing as teh code runs. pat From icon-group-sender Mon Apr 12 22:40:46 1993 Received: by cheltenham.cs.arizona.edu; Sun, 18 Apr 1993 05:11:22 MST Date: 12 Apr 93 22:40:46 GMT From: mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group@uunet.uu.net (Bob Alexander) Subject: Re: Looking for "instant guide" for Icon Message-Id: <9304122240.AA00662@laguna.Metaphor.COM> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >Has anyone by chance already produced an "instant guide" for >Icon? If so, I'd much appreciate getting a copy of it. Well, it just so happens... This is in the Icon Program Library last time I looked, but I'll attach it to this message as well. I created a help file that could be used as an "instant guide". It also provides an on-line help facility -- the program and data file are attached. There also once was a nicely formatted Reference Sheet (the 8 1/2 x 11 equivalent of a Reference *Card* :-), but I don't know if it's still maintained and destributed. The number on the copy I have tacked to my wall is IPD107, updated for version 8 but not for *.xx. It doesn't seem to be in the version 8.7 UNIX distribution (too bad). Maybe the Icon Project has an up-to-date copy if you need one, or I could mail you a copy of my slightly-out-of-date one (hard copy). Hope this helps... ------------------- ihelp.icn --------------------- ############################################################################ # # Name: ihelp.icn # # Title: On-line "help" facility. # # Author: Robert J. Alexander # # Date: December 5, 1989 # ############################################################################ # # ihelp -- Program to display "help" information # # ihelp [-f helpfile] [item] [keyword ...] # # The optional item name specifies the section of the help file which # is to be displayed. If no item name is specified a default section # will be displayed, which usually lists the help items that are # available. An initial substring of the item name that differentiates # it from other items is sufficient. # # If keyword(s) are specified, then only lines that contain all of the # keywords, in any order, are displayed. The keywords do not have to # correspond to whole words in the help text; only to text fragments. # # All item name and keyword matches are case independent. # # The help file name is taken from environment variable "HELPFILE". If # HELPFILE is not in the environment, file "help" in the current # directory is used. A help file name specified in the -f option # overrides. # # The help files are formatted as follows: # # default text lines # - # one # item "one" text lines # - # two # item "two" text lines # ... # # Sections are separated by lines containing a single "-". Item names # are the first line following a separator line. # link options procedure main(arg) # # Initialize. # defaultHelpFile := "help" opts := options(arg,"f:") fn := \opts["f"] | "" ~== getenv("HELPFILE") | defaultHelpFile f := open(fn) | stop("Can't open help file \"",fn,"\"") # # Look for the specified section, if one was. # if item := map(arg[1]) then { line := "" until item == map(line[1:*item + 1]) do { while read(f) ~== "-" line := read(f) | stop("No help for ",item) } } # # Output the section lines that contain the keywords. # write(line) keywords := arg[2:0] | [] every i := 1 to *keywords do keywords[i] := map(keywords[i]) while "-" ~== (line := read(f)) do { lline := map(line) if not (every k := !keywords do if not find(k,lline) then break) then write(line) } end ----------- help ------------------------------------------------ Icon Programming Language Version 8.7 Help Summaries Help summaries are available for each of the Icon executable programs (icont, iconx), and for many aspects of the Icon language itself. To see the help summaries, enter one of the following commands: ihelp icont # Icon translator & linker ihelp iconx # Icon interpreter ihelp expressions # summary of expressions & precedence ihelp functions # summary of functions ihelp operations # summary of operations ihelp keywords # list of keywords ihelp datatypes # list of Icon datatypes ihelp reserved # list of reserved words ihelp escapes # list of string escape sequences ihelp abbreviations # abbreviations used in help files ihelp # information on specific function ihelp about # bibliography and credits for help file - abs(N) : N # compute absolute value Produces the absolute value of N. - acos(r1) : r2 # compute arc cosine Produces the arc cosine of r1 in the range of 0 to pi for r1 in the range of -1 to 1. - any(c,s,i1,i2) : i3 # locate initial character Succeeds and produces i1 + 1 if s[i1] is in c and i2 > i1, but fails otherwise. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - args(p) : i # get number of procedure arguments Produces the number of arguments for procedure p. For built-in procedures with a variable number of arguments, the value produced is -1. For declared procedures with a variable number of arguments, the value returned is the negative of the number of formal prameters. - bal(c1,c2,c3,s,i1,i2) : i3,i4,...,in # locate balanced characters Generates the sequence of integer positions in s preceding a character of c1 in s[i1:i2] that is balanced with respect to the characters of c2 and c3, but fails if there is no such position. Defaults: c1 &cset c2 '(' c3 ')' s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - callout(x,x1,x2,...,xn) : xm # call external function Calls the external function specified by x with arguments x1, x2, ..., xn. The mechanism for locating the function specified by x is system dependent. - center(s1,i,s2) : s3 # position string at center Produces a string of size i in which s1 is centered, with s2 used for padding at left and right as necessary. Defaults: i 1 s2 " " (blank) - char(i) : s # produce character Produces a string of length 1 consisting of the character whose internal representation is i. - chdir(s) : n # change directory Changes the directory to s but fails if there is no such directory or if the change cannot be made. - close(f) : f # close file Produces f after closing it unless f was opened with the pipe ("p") option, in which case the integer exit status of the command is returned. - collect(i1,i2) : n # perform garbage collection Causes a garbage collectionin region i1, requesting i2 bytes of space in that region. It fails if the requested space is not available. The regions are identified as follows: 1 Static region 2 String region 3 Block region If i1 is 0, a collection is done, but no region is identified and i2 has no effect. The value of i2 is ignored for the static region. Defaults: i1 0 i2 0 - copy(x1) : x2 # copy value Produces a copy of x1 if x1 is a structure; otherwise it produces x1. - cos(r1) : r2 # compute cosine Produces the cosine of r1 in radians. - cset(x) # convert to cset Produces a cset resulting from converting x, but fails if the conversion is not possible. - delay(i) : n # delay execution Delays execution i milliseconds. - delete(X,x) : X # delete element If X is a set, deletes x from X. If X is a table, deletes the element for key x from X. Produces X. - detab(s1,i1,i2,...,in) : s2 # remove tabs Produces a string based on s1 in which each tab character is replaced by one or more blanks. Tab stops are at i1, i2, ..., in, with additional stops obtained by repeating the last interval. Default: i1 9 - display(i,f) : n # display variables Writes the image of the current co-expression and the values of the local variables in the current procedure call. If i > 0, the local variables in the i preceding procedure calls are displayed as well. After all local variables are displayed, the values of global variables are displayed. Output is written to f. Defaults: i &level f &errout - dtor(r1) : r2 # convert degrees to radians Produces the radian equivalent of r1 given in degrees. - entab(s1,i1,i2,...,in) : s2 # insert tabs Produces a string based on s1 in which runs of blanks are replaced by tabs. Tab stops are at i1, i2, ..., in, with additional stops obtained by repeating the last interval. Default: i1 9 - errorclear() : n # clear error indication Clears the indications of the last error. - exit(i) # exit program Terminates the program with exit status i. Default: i normal exit (system dependent) - exp(r1) : r2 # compute exponential Produces e raised to the power r1. - find(s1,s2,i1,i2) : i3,i4,...,in # find string Generates the sequence of integer positions in s2 at which s1 occurs as a substring in s2[i1:i2], but fails if there is no such position. Defaults: s2 &subject i1 &pos if s2 defaulted, otherwise 1 i2 0 - flush(f) : n # flush I/O buffer Flushes the input/output buffers for f. - function() : s1,s2,...,sn # generate function names Generates the names of the Icon (built-in) functions. - get(L) : x # get value from list Produces the leftmost element of L and removes it from L, but fails if L is empty; synonym for pop(L). - getenv(s1) : s2 # get value of environment variable Produces the value of environment variable s1, but fails if the variable is not set or environment variables are not supported. - iand(i1,i2) : i3 # compute bit-wise "and" Produces the bitwise "and" of i1 and i2. - icom(i1) : i2 # compute bit-wise complement Produces the bitwise complement (1's complement) of i1. - image(x) : s # produce string image Produces a string image of x. - insert(X,x1,x2) : X # insert element If X is a table, inserts the key x1 with value x2 into X. If X is a set, inserts x1 into X. Produces X. Default: x2 &null - integer(x) : i # convert to integer Produces the integer resulting from converting x, but fails if the conversion is not possible. - ior(i1,i2) : i3 # compute bit-wise inclusive "or" Produces the bitwise inclusive "or" of i1 and i2 - ishift(i1,i2) : i3 # shift bits Produces the result of shifting the bits in i1 by i2 positions. Positive values of i2 shift to the left, negative to the right. Vacated bit positions are zero-filled. - ixor(i1,i2) : i3 # compute bit-wise exclusive "or" Produces the bitwise exclusive "or" of i1 and i2. - key(T) : x1,x2,...,xn # generate keys from table Generates the keys in table T. - left(s1,i,s2) : s3 # position string at left Produces a string of size i in which s1 is positioned at the left, with s2 used for padding on the right as necessary. Defaults: i 1 s2 " " (blank) - list(i,x) : L # create list Produces a list of size i in which each value is x. Defaults: i 0 x &null - log(r1,r2) : r3 # compute logarithm Produces the logarithm of r1 to the base r2. Default: r2 e - many(c,s,i1,i2) : i3 # locate many characters Succeeds and produces the position in s after the longest initial sequence of characters in c in s[i1:i2]. It fails if s[i1] is not in c. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - map(s1,s2,s3) : s4 # map characters Produces a string of size *s1 obtained by mapping characters of s1 that occur in s2 into corresponding characters in s3. Defaults: s2 string(&ucase) s3 string(&lcase) - match(s1,s2,i1,i2) : i3 # match initial string Produces i1 + *s1 if s1 == s2[i1+:*s1], but fails otherwise. Defaults: s2 &subject i1 &pos if s2 defaulted, otherwise 1 i2 0 - member(X,x) : x # test for membership If X is a set, succeeds if x is a member of X, but fails otherwise. If X is a table, succeeds if x is a key of an element in X, but fails otherwise. Produces x if it succeeds. - mmout(x) : n # write text to allocation history Writes s to the allocation history file. s is given no interpretation. - mmpause(s) : n # write pause to allocation history Writes s to the allocation history file as a pause point with identification s. Default: s "programmed pause" - mmshow(x,s) : n # redraw in allocation history Specifies redrawing of x in the allocation history file. The color is defined by s as follows: "b" black "g" gray "w" white "h" highlight; blinking black and white if possible "r" normal color If x is not in an allocated region, has no effect. Default: s "r" - move(i) : s # move scanning position Produces &subject[&pos:&pos + i] and assigns i + &pos to &pos, but fails if i is out of range; reverses assignment to &pos if resumed. - name(x) : s # produce name Produces the name of the variable x. If x is an identifier or a keyword that is a variable, the name of the identifier or keyword is produced. If x is a record field reference, the record name and field name are produced with a separating period. If x is a string, the name of the string and the subscript range are shown. If x is a subscripted list or table, the type name followed by the subscripting expression is produced. - numeric(x) : N # convert to numeric Produces an integer or real number resulting from converting x, but fails if the conversion is not possible. - open(s1,s2) : f # open file Produces a file resulting from opening s1 according to options in s2, but fails if the file cannot be opened. The options are: "r" open for reading "w" open for writing "a" open for writing in append mode "b" open for reading and writing "c" create "t" translate line termination sequences to linefeeds "u" do not translate line termination sequences to linefeeds "p" pipe to/from a command -- UNIX The default mode is to translate line termination sequences to linefeeds on input and conversely on output. The untranslated mode should be used when reading and writing binary files. Default: s2 "rt" - ord(s) : i # produce ordinal Produces an integer (ordinal) between 0 and 255 that is the internal representation of the single character in s. - pop(L) : x # pop from list Produces the leftmost element of L and removes it from L, but fails if L is empty; synonym for get(L). - pos(i1) : i2 # test scanning position Produces &pos if &pos = i1, but fails otherwise. - proc(x,i) : p # convert to procedure Produces a procedure corresponding to the value of x, but fails if x does not correspond to a procedure. If x is the string name of an operator, i specifies the number of arguments: 1 for unary (prefix), 2 for binary (infix), and 3 for ternary. Default: i 1 - pull(L) : x # pull from list Produces the rightmost element of L and removes it from L, but fails if L is empty. - push(L,x) : L # push onto list Adds x to the left end of L and produces L. - put(L,x) : L # put onto list Adds x to the right end of L and produces L. - read(f) : s # read line Produces the next line from f, but fails on end of file. Default: f &input - reads(f,i) : s # read string Produces a string consisting of the next i characters from f, or the remaining characters of f if fewer remain, but fails on an end of file. In reads(), unlike read(), line termination sequences have no special significance. reads() should be used for reading binary data. Defaults: f &input i 1 - real(x) : r # convert to real Produces a real number resulting from type conversion of x, but fails if the conversion is not possible. - remove(s) : n # remove file Removes (deletes) the file named s, but fails if s cannot be removed. - rename(s1,s2) : n # rename file Renames the file named s1 to be s2, but fails if the renaming cannot be done. - repl(s1,i) : s2 # replicate string Produces a string consisting of i concatenations of s1. - reverse(s1) : s2 # reverse string Produces a string consisting of the reversal of s. - right(s1,i,s2) : s3 # position string at right Produces a string of size i in which s1 is positioned at the right, with s2 used for padding on the left as necessary. Defaults: i 1 s2 " " (blank) - rtod(r1) : r2 # convert radians to degrees Produces the degree equivalent of r1 given in radians. - runerr(i,x) # terminate with run-time error Terminates program execution with error i and offending value x. Default: x no offending value - save(s) : i # save executable image Saves an executable image of the current running program in the file named s and produces the size of the file, but fails if the file cannot be created. - seek(f,i) : f # seek to position in file Seeks to position i in f, but fails if the seek cannot be performed. The first byte in the file is at position 1. seek(f,0) seeks to the end of file f. - seq(i1,i2) : i3,i4,... # generate sequence of integers Generates an endless sequence of integers starting at i1 with increments of i2. Defaults: i1 1 i2 1 - set(L) : S # create set Produces a set whose members are the distinct values in the list L. Default: L [] - sin(r1) : r2 # compute sine Produces the sine of r1 given in radians. - sort(X,i) : L # sort structure Produces a list containing values from X. If X is a list or a set, sort(X,i) produces the values of X in sorted order. If X is a table, sort(X,i)produces a list obtained by sorting the elements of X, depending on the value of i. For Produces a list according to i: i = (1 | 2) Produces a list of two-element lists of key/value pairs from X; ordered by keys for i = 1, by values for i = 2. i = (3 | 4) Produces a list of size 2 * *X with each consecutive pair of elements consisting of a key and a value from X; ordered by keys for i = 3, by values for i = 4. Default: i 1 - sortf(X,i) : L # sort list or set by field Produces a sorted list of the values in X. Sorting is primarily by type and in most respects is the same as with sort(X,i). However, among lists and among records, two structures are ordered by comparing their ith fields. i can be negative but not zero. Two structures having the equal ith fields are ordered as they would be in regular sorting, but structures lacking an ith field appear before structures having them. Default: i 1 - sqrt(r1) : r2 # compute square root Produces the square root of r1. - stop(x1,x2,...,xn) # stop execution Terminates program execution with an error status after writing strings x1,x2,...,xn. If xi is a file, subsequent output is to xi. Initial output is to standard error output. Default: xi "" (empty string) - string(x) : s # convert to string Produces a string resulting from converting x, but fails if the conversion is not possible. - system(s) : i # call system function Calls the C library function "system" to execute s and produces the resulting integer exit status. - tab(i) : s # set scanning position Produces &subject[&pos:i] and assigns i to &pos, but fails if i is out of range. It reverses assignment to &pos if resumed. - table(x) : T # create table Produces a table with a default value x. Default: x &null - tan(r1) : r2 # compute tangent Produces the tangent of r1 given in radians. - trim(s1,c) : s2 # trim string Produces a string consisting of the characters of s1 up to the trailing characters contained in c. Default: c ' ' (blank) - type(x) : s # produce type name Produces a string corresponding to the type of x. - upto(c,s,i1,i2) : i3,i4,...,in # locate characters Generates the sequence of integer positions in s preceding a character of c in s[i1:i2]. It fails if there is no such position. Defaults: s &subject i1 &pos if s defaulted, otherwise 1 i2 0 - variable(s) : x # produce variable Produces the variable for the identifier or keyword named s, but fails if there is no such variable. Local identifiers override global identifiers. - where(f) : i # produce position in file Produces the current byte position in f. The first byte in the file is at position 1. - write(x1,x2,...,xn) : xn # write line Writes strings x1,x2,...,xn with a line termination sequence added at the end. If xi is a file, subsequent output is to xi. Initial output is to standard output. Default: xi "" (empty string) - writes(x1,x2,...,xn) # write string Writes strings x1,x2,...,xn without a line termination sequence added at the end. If xi is a file, subsequent output is to xi. Initial output is to standard output. Default: xi "" (empty string) - icont -- Icon translator and linker icont [option...] file... -c # translate only (no link) -o file # name icode file "file" -s # suppress progress messages -t # give &trace initial value of -1 -u # issue warnings for undeclared identifiers See also: ihelp iconx - iconx -- Icon interpreter The Icon interpreter is normally invoked automatically when the name of an Icon program is entered as a command, but it can be invoked explicitly, too. iconx icode_file_name [arguments for Icon program.] Shell environment variables recognized by iconx =============================================== Name Default Description -------- ------- ----------------------- TRACE 0 Initial value for &trace. NOERRBUF undefined If set, &errout is not buffered. STRSIZE 65000 Initial size (bytes) of string region (strings). BLOCKSIZE 65000 Initial size (bytes) of block region (most objects). COEXPSIZE 2000 Size (long words) of co-expression blocks. MSTKSIZE 10000 Size (long words) of main interpreter stack. STATSIZE 20480 Initial size (bytes) of static region (co-expression blocks). STATINCR 1/4 of Increment used to expand static region. STATSIZE See also: ihelp icont - Expressions shown in order of decreasing precedence. Items in groups (as separated by empty lines) have equal precedence. High Precedence Expressions (expr) # grouping {expr1;expr2;...} # compound x(expr1,expr2,...) # invocation x{expr1,expr2,...} # " [expr1,expr2,...] # list expr.F # field reference expr1[expr2] # subscript expr1[expr2:expr3] # section expr1[expr2+:expr3] # " expr1[expr2-:expr3] # " Prefix Expressions not expr # success/failure reversal | expr # repeated alternation ! expr # element generation * expr # size + expr # numeric value - expr # negative . expr # value (dereference) / expr # null \ expr # non-null = expr # match and tab ? expr # random value ~ expr # cset complement @ expr # activation ^ expr # refresh Infix Expressions expr1 \ expr2 # limitation expr1 @ expr2 # transmission expr1 ! expr2 # invocation expr1 ^ expr2 # power expr1 * expr2 # product expr1 / expr2 # quotient expr1 % expr2 # remainder expr1 ** expr2 # intersection expr1 + expr2 # sum expr1 - expr2 # numeric difference expr1 ++ expr2 # union expr1 -- expr2 # cset or set difference expr1 || expr2 # string concatenation expr1 ||| expr2 # list concatenation expr1 < expr2 # numeric comparison expr1 <= expr2 # " expr1 = expr2 # " expr1 >= expr2 # " expr1 > expr2 # " expr1 ~= expr2 # " expr1 << expr2 # string comparison expr1 <<= expr2 # " expr1 == expr2 # " expr1 >>= expr2 # " expr1 >> expr2 # " expr1 ~== expr2 # " expr1 === expr2 # value comparison expr1 ~=== expr2 # " expr1 | expr2 # alternation expr1 to expr2 by expr3 # integer generation expr1 := expr2 # assignment expr1 <- expr2 # reversible assignment expr1 :=: expr2 # exchange expr1 <-> expr2 # reversible exchange expr1 op:= expr2 # (augmented assignments) expr1 ? expr2 # string scanning expr1 & expr2 # conjunction Low Precedence Expressions break [expr] # break from loop case expr0 of { # case selection expr1:expr2 ... [default:exprn] } create expr # co-expression creation every expr1 [do expr2] # iterate over generated values fail # failure of procedure if expr1 then exp2 [else exp3] # if-then-else next # go to top of loop repeat expr # loop return expr # return from procedure suspend expr1 [do expr2] # suspension of procedure until expr1 [do expr2] # until-loop while expr1 [do expr2] # while-loop - Functions and datatypes of arguments and produced values: abs(N) : N # compute absolute value acos(r1) : r2 # compute arc cosine any(c,s,i1,i2) : i3 # locate initial character args(p) : i # get number of procedure arguments bal(c1,c2,c3,s,i1,i2) : i3,i4,...,in # locate balanced characters callout(x,x1,x2,...,xn) : xm # call external function center(s1,i,s2) : s3 # position string at center char(i) : s # produce character chdir(s) : n # change directory close(f) : f # close file collect(i1,i2) : n # perform garbage collection copy(x1) : x2 # copy value cos(r1) : r2 # compute cosine cset(x) # convert to cset delay(i) : n # delay execution delete(X,x) : X # delete element detab(s1,i1,i2,...,in) : s2 # remove tabs display(i,f) : n # display variables dtor(r1) : r2 # convert degrees to radians entab(s1,i1,i2,...,in) : s2 # insert tabs errorclear() : n # clear error indication exit(i) # exit program exp(r1) : r2 # compute exponential find(s1,s2,i1,i2) : i3,i4,...,in # find string flush(f) : n # flush I/O buffer function() : s1,s2,...,sn # generate function names get(L) : x # get value from list getenv(s1) : s2 # get value of environment variable iand(i1,i2) : i3 # compute bit-wise "and" icom(i1) : i2 # compute bit-wise complement image(x) : s # produce string image insert(X,x1,x2) : X # insert element integer(x) : i # convert to integer ior(i1,i2) : i3 # compute bit-wise inclusive "or" ishift(i1,i2) : i3 # shift bits ixor(i1,i2) : i3 # compute bit-wise exclusive "or" key(T) : x1,x2,...,xn # generate keys from table left(s1,i,s2) : s3 # position string at left list(i,x) : L # create list log(r1,r2) : r3 # compute logarithm many(c,s,i1,i2) : i3 # locate many characters map(s1,s2,s3) : s4 # map characters match(s1,s2,i1,i2) : i3 # match initial string member(X,x) : x # test for membership mmout(x) : n # write text to allocation history mmpause(s) : n # write pause to allocation history mmshow(x,s) : n # redraw in allocation history move(i) : s # move scanning position name(x) : s # produce name numeric(x) : N # convert to numeric open(s1,s2) : f # open file ord(s) : i # produce ordinal pop(L) : x # pop from list pos(i1) : i2 # test scanning position proc(x,i) : p # convert to procedure pull(L) : x # pull from list push(L,x) : L # push onto list put(L,x) : L # put onto list read(f) : s # read line reads(f,i) : s # read string real(x) : r # convert to real remove(s) : n # remove file rename(s1,s2) : n # rename file repl(s1,i) : s2 # replicate string reverse(s1) : s2 # reverse string right(s1,i,s2) : s3 # position string at right rtod(r1) : r2 # convert radians to degrees runerr(i,x) # terminate with run-time error save(s) : i # save executable image seek(f,i) : f # seek to position in file seq(i1,i2) : i3,i4,... # generate sequence of integers set(L) : S # create set sin(r1) : r2 # compute sine sort(X,i) : L # sort structure sortf(X,i) : L # sort list or set by field sqrt(r1) : r2 # compute square root stop(x1,x2,...,xn) # stop execution string(x) : s # convert to string system(s) : i # call system function tab(i) : s # set scanning position table(x) : T # create table tan(r1) : r2 # compute tangent trim(s1,c) : s2 # trim string type(x) : s # produce type name upto(c,s,i1,i2) : i3,i4,...,in # locate characters variable(s) : x # produce variable where(f) : i # produce position in file write(x1,x2,...,xn) : xn # write line writes(x1,x2,...,xn) # write string - Operations and required datatypes prefix operations +N : N # compute positive -N : N # compute negative ~c1 : c2 # compute cset complement =s1 : s2 # match string in scanning @C : x # activate co-expression ^C1 : C2 # create refreshed co-expression *x : i # compute size ?x1 : x2 # generate random value !x : x1,x2,...,xn # generate values /x : x # check for null value \x : x # check for non-null value .x : x # dereference variable infix operations N1 + N2 : N3 # compute sum N1 - N2 : N3 # compute difference N1 * N2 : N3 # compute product N1 / N2 : N3 # compute quotient N1 % N2 : N3 # compute remainder N1 ^ N2 : N3 # compute exponential x1 ++ x2 : x3 # compute cset or set union x1 -- x2 : x3 # compute cset or set difference x1 ** x2 : x3 # compute cset or set intersection s1 || s2 : s3 # concatenate strings L1 ||| L2 : L3 # concatenate lists R.F : x # get field of record x1 @ C : x2 # transmission value to co-expression x1 & x2 : x2 # evaluate in conjunction N1 < N2 : N2 # compare numerically N1 <= N2 : N2 # " N1 = N2 : N2 # " N1 >= N2 : N2 # " N1 > N2 : N2 # " N1 ~= N2 : N2 # " s1 << s2 : s2 # compare lexically s1 <<= s2 : s2 # " s1 == s2 : s2 # " s1 >>= s2 : s2 # " s1 >> s2 : s2 # " s1 ~== s2 : s2 # " x1 === x2 : x2 # compare values x1 ~=== x2 : x2 # " x1 := x2 : x1 # assign value x1 op:= x2 : x1 # augmented assignment x1 :=: x2 : x1 # exchange values x1 <- x2 : x1 # assign value reversibly x1 <-> x2 : x1 # exchange values reversibly - Keywords &allocated : i1,i2,i3,i4 # accumulated bytes allocated # (total,static,string,block) &ascii : c # cset of ascii characters &clock : s # current time of day &collections : i1,i2,i3,i4 # collection count # (total,static,string,block) &cset : c # cset of all characters ¤t : C # current co-expression &date : s # current date &dateline : s # current date and time &digits : c # cset of digits 0-9 &e : r # base of natural logarithms, 2.71828... &error : i # run-time error conversion control &errornumber : i # run-time error number &errortext : s # run-time error message text &errorvalue : x # run-time error offending value &errout : f # standard error output file &fail # fails &features : s1,s2,...,sn # implementation features &file : s # current source code file name &host : s # string identifying host computer &input : f # standard input file &lcase : c # cset of lower case letters a-z &letters : c # cset of all letters A-Za-z &level : i # level of current procedure call &line : i # current source code line number &main : C # main co-expression &null : n # the null value &output : f # standard output file &phi : r # the golden ratio, 1.61803... &pi : r # the value of pi, 3.14159... &pos : i # string scanning position &progname : s # file name of the executing program &random : i # random number seed ®ions : i1,i2,i3 # current region size # (static,string,block) &source : C # activator of current co-expression &storage : i1,i2,i3 # current bytes allocated # (static,string,block) &subject : s # string scanning subject &time : i # current run time in milliseconds &trace : i # procedure tracing control &ucase : c # cset of upper case letters A-Z &version : s # version of Icon - Datatypes null (n) string (s) co-expression (C) table (T) integer (i) cset (c) procedure (p) set (S) real (r) file (f) list (L) (R) (see also "Abbreviations") - Reserved words break do global next repeat to by else if not return until case end initial of static while create every link procedure suspend default fail local record then - Escapes in string and cset constants \b backspace \v vertical tab \d delete(rubout) \' single quote \e escape (altmode) \" double quote \f formfeed \\ backslash \l linefeed (newline) \ddd octal code \n newline (linefeed) \xdd hexadecimal code \r carriage return \^c control code \t horizontal tab - Abbreviations used in Icon help files (and other Icon literature) c cset C co-expression f file L list i integer N numeric (i or r) n null R record (any record type) p procedure S set r real T table s string X any structure type (L, R, S, or T) x any type F field of record - About the Icon Programming Language Help File Information used in this help file was obtained from the following sources: Griswold, Ralph E. and Madge T. Griswold. "The Icon Programming Language, Second Edition", Prentice-Hall, Inc., Englewood Cliffs, New Jersey. 1990. Griswold, Ralph E. ICONT(1), manual page for "UNIX Programmer's Manual", Department of Computer Science, The University of Arizona. 1988. Griswold, Ralph E., Clinton L. Jeffery, Gregg M. Townsend, and Kenneth Walker. "Version 8.6 of the Icon Programming Language", IPD188, Department of Computer Science, The University of Arizona. 1992. Further information on the Icon Programming Language can be obtained from: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, Arizona 85721 U.S.A. (602) 621-2018 icon-project@cs.arizona.edu (Internet) ...{uunet,allegra,noao}!arizona!icon-project (uucpnet) April 2, 1992.