From icon-group-sender Thu Aug 15 08:48:37 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7FFmYI26852 for icon-group-addresses; Thu, 15 Aug 2002 08:48:34 -0700 (MST) Message-Id: <200208151548.g7FFmYI26852@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: What about "Expressions?" (was Re: Icon Wish List) Date: 15 Aug 2002 00:16:33 GMT X-Draft-From: ("nnvirtual:Languages" 1022) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Elsewhere Maybe All Commands are Simple Microsoft: Where even the version numbers aren't Y2K-compliant X-Shopping-List: (1) Myopic annoyers (2) Incoherent griddle compasses (3) Poisonous gracious malnutrition (4) Diligent paradoxes X-Uboat-Death-Message: ATTACKED BY ATOMIC BOMB 87E 19S. SINKING. U-207. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The world rejoiced as Hrvoje Blazevic wrote: > On Fri, 02 Aug 2002 18:46:43 +0200, ernobe wrote: >> I wish you luck in your endeavour. Icon is superior, and I realize that >> showing how superior it already is in practice will not necessarily >> allow it to "take off". It will need to advertize itself, so to speak. >> The only other computer language that I know of which uses >> expressions is >> Terse (www.terse.com) an expression-based assembly language. It is >> easier to program in than C or Assembly. I wonder why Icon can't >> become or is not considered a more low-level language. That would >> certainly raise brows. It would not take-off. It would launch. > I must be missing something here. Icon (and terse) the only > languages using expressions? How about Scheme -- or for that matter > the whole functional camp? This is indeed an interesting question. It _may_ be that the notion of "expression-based" being referenced is that control structures work on the expression in a bit of a different way than in Algol-descended languages. But it's not clear. Terse is definitely a "hype-heavy, theory-light" language; in the absence of more documentation, it's not obvious what it's doing that is similar to Icon that _isn't_ similar to C or Modula-3. And I think the likelihood of Icon "launching" because of being regarded as a "more low level language" as being, um, rather remote. Terse hasn't been taking the world by storm any more than FORTH has. But I'd be curious as to what the definition of "Expressions" is supposed to be, in this context. -- (concatenate 'string "chris" "@cbbrowne.com") http://cbbrowne.com/info/sgml.html "I don't know what OS we will be running in 40 years, but it will probably be called Unix...." -- Chris Mikkelson From icon-group-sender Thu Aug 15 08:50:29 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7FFoLc26976 for icon-group-addresses; Thu, 15 Aug 2002 08:50:21 -0700 (MST) Message-Id: <200208151550.g7FFoLc26976@baskerville.CS.Arizona.EDU> Date: Wed, 14 Aug 2002 23:27:12 -0600 From: Clint Jeffery To: trutkin@physics.clarku.edu CC: icon-group@cs.arizona.edu Subject: Re: Icon Wish List (binary I/O subthread) Errors-To: icon-group-errors@cs.arizona.edu Status: RO Another answer to Taybin's question about reading binary data, which I am surprised no one has already brought up unless I missed it, is: "look in the Icon Program Library, there are library routines to do this stuff". Hmm, I wonder what else in the IPL might be immediately useful? Maybe lots of stuff? Among other places, the Icon Program Library is documented in a dense 90+ pages (Appendix B) of "Programming with Unicon", which some might view as a companion/supplement handbook for Icon programmers. :-) Clint jeffery@cs.nmsu.edu From icon-group-sender Thu Aug 15 08:53:15 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7FFrBA27056 for icon-group-addresses; Thu, 15 Aug 2002 08:53:11 -0700 (MST) Message-Id: <200208151553.g7FFrBA27056@baskerville.CS.Arizona.EDU> From: Hrvoje Blazevic X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: Thu, 15 Aug 2002 14:25:53 +0200 X-Complaints-To: abuse@hinet.hr User-Agent: Pan/0.11.2 (Unix) X-Comment-To: "Christopher Browne" To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Thu, 15 Aug 2002 02:16:33 +0200, Christopher Browne wrote: > This is indeed an interesting question. > > It _may_ be that the notion of "expression-based" being referenced is > that control structures work on the expression in a bit of a different > way than in Algol-descended languages. > > But it's not clear. > > Terse is definitely a "hype-heavy, theory-light" language; in the > absence of more documentation, it's not obvious what it's doing that is > similar to Icon that _isn't_ similar to C or Modula-3. > > And I think the likelihood of Icon "launching" because of being regarded > as a "more low level language" as being, um, rather remote. Terse hasn't > been taking the world by storm any more than FORTH has. > > But I'd be curious as to what the definition of "Expressions" is > supposed to be, in this context. I must be careful here, lest someone from this group answers; " If you can't speak English", how can you understand what an expression is". Anyway, I'm not very interested in theoretical definition of what an expression means. The reaction was just to the statement that: The only other computer language that I know of which uses expressions is Terse (www.terse.com) an expression-based assembly language. Now, I don't know terse (never heard of it), but I do know that Scheme is an expression based language. Everything (except definition) is an expression - even assignment is. I guess that the important difference here is that most imperative languages (except Icon) work with statements. Scheme and the rest of FP languages work with expressions. To quote an example from Graphics Programming in Icon; p9 In Pascal, the following line is a statement: if switch = on then write("on") else write("off"); Icon is different in this regard. Icon has no statements, only expressions. ... write(if switch = on then "on" else "off") end quote. Well, the same is true for Scheme (or Lisp, and other FP languages in general) From icon-group-sender Thu Aug 15 13:14:54 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7FKEc607370 for icon-group-addresses; Thu, 15 Aug 2002 13:14:38 -0700 (MST) Message-Id: <200208152014.g7FKEc607370@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 15 Aug 2002 16:53:13 GMT X-Draft-From: ("nnvirtual:Languages" 978) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Elsewhere Maybe All Commands are Simple Microsoft: Where the service packs are larger than the original releases. X-Shopping-List: (1) Domestic temptations (2) Philanthropic load nougat (3) Political seduction circumcisions (4) Titanic directions X-Uboat-Death-Message: BOMBED BY AIRCRAFT. SINKING. U-541. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO A long time ago, in a galaxy far, far away, Hrvoje Blazevic wrote: > On Thu, 15 Aug 2002 02:16:33 +0200, Christopher Browne wrote: > >> This is indeed an interesting question. >> >> It _may_ be that the notion of "expression-based" being referenced is >> that control structures work on the expression in a bit of a different >> way than in Algol-descended languages. >> >> But it's not clear. >> >> Terse is definitely a "hype-heavy, theory-light" language; in the >> absence of more documentation, it's not obvious what it's doing that is >> similar to Icon that _isn't_ similar to C or Modula-3. >> >> And I think the likelihood of Icon "launching" because of being regarded >> as a "more low level language" as being, um, rather remote. Terse hasn't >> been taking the world by storm any more than FORTH has. >> >> But I'd be curious as to what the definition of "Expressions" is >> supposed to be, in this context. > I must be careful here, lest someone from this group answers; " If > you can't speak English", how can you understand what an expression > is". You're exactly right, and I'd certainly not "mark you down" for not being a native speaker of English. (I don't think I know how to pronounce _your_ first name, so I have my own "issues of illiteracy" :-).) > Anyway, I'm not very interested in theoretical definition of what an > expression means. The reaction was just to the statement that: The > only other computer language that I know of which uses expressions > is Terse (www.terse.com) an expression-based assembly language. I think theory _is_ important here; it's from theory that we can get some common concepts that allow us to agree on just what it is that the word "expressions" means. > Now, I don't know terse (never heard of it), but I do know that > Scheme is an expression based language. Everything (except > definition) is an expression - even assignment is. OK... > I guess that the important difference here is that most imperative > languages (except Icon) work with statements. Scheme and the rest of > FP languages work with expressions. > > To quote an example from Graphics Programming in Icon; p9 > > In Pascal, the following line is a statement: > > if switch = on then write("on") else write("off"); > > Icon is different in this regard. Icon has no statements, only expressions. > ... > write(if switch = on then "on" else "off") > > end quote. > > Well, the same is true for Scheme (or Lisp, and other FP languages > in general) I'm just not sure I'm seeing what is the essential difference between "statements" and "expressions" here. I'm not a dumb reader; your English seems fine (better than far too many natives!); I'm _quite_ familiar with Lisp and Scheme; I'm just not sure what the difference you're getting at is. And perhaps what you have in mind isn't the same as what the guy that brought up Terse had in mind... -- (concatenate 'string "chris" "@cbbrowne.com") http://www.ntlug.org/~cbbrowne/languages.html Why isn't phonetic spelled the way it sounds? From icon-group-sender Fri Aug 16 16:11:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNATQ22865 for icon-group-addresses; Fri, 16 Aug 2002 16:10:29 -0700 (MST) Message-Id: <200208162310.g7GNATQ22865@baskerville.CS.Arizona.EDU> From: Hrvoje Blazevic X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: Thu, 15 Aug 2002 23:16:43 +0200 X-Complaints-To: abuse@hinet.hr User-Agent: Pan/0.11.2 (Unix) X-Comment-To: "Christopher Browne" To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Thu, 15 Aug 2002 18:53:13 +0200, Christopher Browne wrote: > I'm just not sure I'm seeing what is the essential difference between > "statements" and "expressions" here. > > I'm not a dumb reader; your English seems fine (better than far too many > natives!); I'm _quite_ familiar with Lisp and Scheme; I'm just not sure > what the difference you're getting at is. And perhaps what you have in > mind isn't the same as what the guy that brought up Terse had in mind... The difference is essential! Imperative languages use statements -- which results in flow of information between different parts of program being passed in the form of a variable assignment. Statements do not return values, they have side-effects, most notably assignment to variables that describe the state of the computation at any given moment. Although Icon *is* imperative language it can get away with less state variables than most, simply because it uses expressions which return values. Therefore smaller chunks of code in Icon do not have to describe state as the set of variables. I may be getting over my head here, because I'm *not* an Icon programmer. I did get briefly involved with Icon about 10 years ago, just after several years of down and dirty imperative programming using Pascal and C/C++. At that time I read "The Icon Programming Language" (2nd edition), and was instantly drawn to Icon. Unfortunately at about the same time my son reached fourth grade, and I wanted to start him on a road to CS, so I started looking at Logo. After that, the road was clear; Logo, Lisp (emacs lisp), Scheme and Haskell. I do not think that I'll ever go back to Icon, but I still sometimes check the web site, nostalgia ... probably :-) From icon-group-sender Fri Aug 16 16:12:45 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNCh222928 for icon-group-addresses; Fri, 16 Aug 2002 16:12:43 -0700 (MST) Message-Id: <200208162312.g7GNCh222928@baskerville.CS.Arizona.EDU> Date: Fri, 16 Aug 2002 11:42:26 +1200 (NZST) From: "Richard A. O'Keefe" To: hrvoje@despammed.com, icon-group@cs.arizona.edu Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Errors-To: icon-group-errors@cs.arizona.edu Status: RO Concerning expression languages: Algol 68. There was a lovely book "Mes Premiers Pas en Programmation" that taught programming using Algol 68. It got about halfway through before introducing the imperative features of the language. I don't know about Bliss-16 or Bliss-32, but Bliss-10 was arguably an expression language, so I imagine the other Blisses were too. Bliss-32 was the system implementation language used in VAX/VMS. The CWI language ALEPH was arguably an expression language (for some value of "expression") *and* it used Prolog-style backtracking. Whatever happened to ALEPH, anyway? What it didn't have was *generators*, or Icon's data structures. Of course Interlisp was (or is, can you still buy it?) an expression language *with* generators but not backtracking, although you could program backtracking if you tried hard enough. From icon-group-sender Fri Aug 16 16:13:23 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNDLU22966 for icon-group-addresses; Fri, 16 Aug 2002 16:13:21 -0700 (MST) Message-Id: <200208162313.g7GNDLU22966@baskerville.CS.Arizona.EDU> From: Bob Ardler To: icon-group@cs.arizona.edu Date: Fri, 16 Aug 2002 10:44:22 +0100 Subject: Re: What about "Expressions?" User-Agent: Pluto/2.04e (RISC-OS/4.03) Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > I'm just not sure I'm seeing what is the essential difference > between "statements" and "expressions" here. I think he's saying that something in Icon which in normal imperative languages you'd naturally call a statement and never call an expression, eg a:=b, has a value - either success or fail, so that makes it an expression and you can use it like other expressions as a sub-expression. Earlier: >How about Scheme - or for that matter the whole functional camp? Maybe it's the contrasting look and feel of complete programs: assembler a string of assignments and jumps, Algol a string of mostly assignments where you can get by without gotos and the gosubs have evolved into procedures and functions, LISP where it's one monster function and assignments feel uncomfortable. If your mother tongue is one style of language it's harder to learn a different style than a similar. An appeal of Icon is the way it has its expression- evaluation character but it's written down like and looks like an imperative language, which might feel more comfortable for some. From icon-group-sender Fri Aug 16 16:13:56 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNDrE22997 for icon-group-addresses; Fri, 16 Aug 2002 16:13:54 -0700 (MST) Message-Id: <200208162313.g7GNDrE22997@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 16 Aug 2002 08:38:22 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hrvoje Blazevic wrote in message news:... > On Thu, 15 Aug 2002 18:53:13 +0200, Christopher Browne wrote: [snip] > > Imperative languages use statements -- which results in flow of > information between different parts of program being passed in the > form of a variable assignment. > > Statements do not return values, they have side-effects, most notably > assignment to variables that describe the state of the computation at > any given moment. > This is not without its advantage, of course. In particular, in terms of readability, I find that explicit variables allow my mind to 'close' (I'm not using it in the technical sense of "closure") previous statements. On the other hand, in reading s-expression languages like Lisp and Scheme, I find that I have to hold in my mind too many _unstated_ intermediate results before I find what the expression is all about. (One could argue that this may be due more to bad code, i.e., irresponsible use of deep embedding, than to intrinsic properties of s-expressions). Compare the readability of these chunks of code: FORTRAN-like The man kicked the dog. The dog chased the cat. The cat bit the mouse. The mouse died. LISP-like (in infix notation) The mouse the cat the dog the man kicked chased bit died. Of course, variable-less, assignment-less languages have advantages. Speaking of speaking (or writing) grammatical English, which skill has been implied in a recent post as a 'requisite' for programming, what do readers with good English grammar think of this sentence: grammatically correct or not? Be careful with your answer. Your reputation as a programmer is on the line. The horse raced past the barn collapsed. > Although Icon *is* imperative language it can get away with less state > variables than most, simply because it uses expressions which return > values. Therefore smaller chunks of code in Icon do not have to > describe state as the set of variables. > > I may be getting over my head here, because I'm *not* an Icon > programmer. I did get briefly involved with Icon about 10 years ago, > just after several years of down and dirty imperative programming > using Pascal and C/C++. At that time I read "The Icon Programming > Language" (2nd edition), and was instantly drawn to Icon. > Unfortunately at about the same time my son reached fourth > grade, and I wanted to start him on a road to CS, so I started looking > at Logo. > > After that, the road was clear; Logo, Lisp (emacs lisp), Scheme and Haskell. > > I do not think that I'll ever go back to Icon, but I still sometimes > check the web site, nostalgia ... probably :-) From icon-group-sender Fri Aug 16 16:14:31 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNETE23031 for icon-group-addresses; Fri, 16 Aug 2002 16:14:29 -0700 (MST) Message-Id: <200208162314.g7GNETE23031@baskerville.CS.Arizona.EDU> From: Steve Wampler X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: Fri, 16 Aug 2002 09:41:16 -0700 X-Complaints-To: abuse@noao.edu X-Accept-Language: en To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > Speaking of speaking (or writing) grammatical English, which skill has > been implied in a recent post as a 'requisite' for programming, what > do readers with good English grammar think of this sentence: > grammatically correct or not? Be careful with your answer. Your > reputation as a programmer is on the line. > > The horse raced past the barn collapsed. I can't wait to see the answer! Regardless, it's certainly considered correct English for those of us of Pennsylvania Dutch descent... -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud. From icon-group-sender Fri Aug 16 16:14:59 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNEuY23062 for icon-group-addresses; Fri, 16 Aug 2002 16:14:56 -0700 (MST) Message-Id: <200208162314.g7GNEuY23062@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 16 Aug 2002 17:42:52 GMT X-Draft-From: ("nnvirtual:Languages" 602) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Exceptionally Mediocre Autocratic Control System Microsoft: Where the service packs are larger than the original releases. X-Shopping-List: (1) Wine-making gong tensions (2) Gelatinous configuration protrusions (3) Atypical hay ammunition (4) Bumptious carnations (5) Torrential trousers X-Uboat-Death-Message: ATTACKED BY IRC SERVER 12N 12W. SINKING. U-507. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO A long time ago, in a galaxy far, far away, Steve Wampler wrote: > Gene Kahn wrote: >> >> Speaking of speaking (or writing) grammatical English, which skill has >> been implied in a recent post as a 'requisite' for programming, what >> do readers with good English grammar think of this sentence: >> grammatically correct or not? Be careful with your answer. Your >> reputation as a programmer is on the line. >> >> The horse raced past the barn collapsed. > > I can't wait to see the answer! Regardless, it's certainly > considered correct English for those of us of Pennsylvania > Dutch descent... While it's grammatically correct, it doesn't really make _sense_. It's quite unusual for a horse to be deemed "racing" when it's collapsed. As a result of the "grammatical" meaning being semantically pretty insensible, it is much easier for the eye to look for more logical interpretations, such as: "The horse raced past the barn and collapsed." "The horse raced past the collapsed barn." "The horse raced past the barn which collapsed." Grammatically equivalent phrases to the original where the semantics would make sense might include: The horse hobbled past the barn collapsed. The horse raced past the barn exhausted. This is probably one of the places where a comma would be in order: The horse raced past the barn, collapsed. -- (reverse (concatenate 'string "moc.enworbbc@" "sirhc")) http://www3.sympatico.ca/cbbrowne/ MS-Windows: Proof that P.T. Barnum was correct. From icon-group-sender Fri Aug 16 16:15:17 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNFEI23155 for icon-group-addresses; Fri, 16 Aug 2002 16:15:14 -0700 (MST) Message-Id: <200208162315.g7GNFEI23155@baskerville.CS.Arizona.EDU> From: Jesse Tov X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 16 Aug 2002 17:42:06 GMT User-Agent: slrn/0.9.7.4 (Linux) To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn : > previous statements. On the other hand, in reading s-expression > languages like Lisp and Scheme, I find that I have to hold in my mind > too many _unstated_ intermediate results before I find what the > expression is all about. (One could argue that this may be due more to > bad code, i.e., irresponsible use of deep embedding, than to intrinsic > properties of s-expressions). I would argue that it's bad code. That's what "let" ("let" in ML, "let*" in Scheme) is for. (I don't know Lisp well enough, but I bet there's something equivalent.) > Compare the readability of these chunks > of code: > > FORTRAN-like > The man kicked the dog. > The dog chased the cat. > The cat bit the mouse. > The mouse died. > > LISP-like (in infix notation) > The mouse the cat the dog the man kicked chased bit died. ML-like The man kicked the dog which chased the cat which bit the mouse which died. (OK, so "let" to "which" is sort of a stretch, but "which" lets you stop remembering everything and encapsulate it as a temporary variable, a "pronoun," if you will. It makes the sentence right-branching, and thus easier to read.) > Speaking of speaking (or writing) grammatical English, which skill has > been implied in a recent post as a 'requisite' for programming, what > do readers with good English grammar think of this sentence: > grammatically correct or not? Be careful with your answer. Your > reputation as a programmer is on the line. > > The horse raced past the barn collapsed. Well, I can't find any way to parse it that has the barn collapsing rather than the horse. In my dialect, it's is equivalent to The horse which was raced past the barn collapsed. and is perfectly grammatical. However, I know in some people's dialects (my grandfather, from eastern Pennsylvania), it's more like: The horse which raced past the barn collapsed. When I hear it like this, it's ungrammatical to me. Jesse -- "A hungry man is not a free man." --Adlai Stevenson From icon-group-sender Fri Aug 16 16:16:04 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7GNG2A23208 for icon-group-addresses; Fri, 16 Aug 2002 16:16:02 -0700 (MST) Message-Id: <200208162316.g7GNG2A23208@baskerville.CS.Arizona.EDU> From: Steve Wampler X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: Fri, 16 Aug 2002 11:03:54 -0700 X-Complaints-To: abuse@noao.edu X-Accept-Language: en To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > > A long time ago, in a galaxy far, far away, Steve Wampler wrote: > > Gene Kahn wrote: > >> > >> The horse raced past the barn collapsed. > > > > I can't wait to see the answer! Regardless, it's certainly > > considered correct English for those of us of Pennsylvania > > Dutch descent... > > While it's grammatically correct, it doesn't really make _sense_. > It's quite unusual for a horse to be deemed "racing" when it's > collapsed. > Ah, but to me (PD-heritage, remember), it's the same as: The horse raced by the collapsed barn. no ambiguity at all! Why do I have the feeling our stock as programmers is gradually sinking into the ooze? -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud. From icon-group-sender Mon Aug 19 12:43:57 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JJgDU12774 for icon-group-addresses; Mon, 19 Aug 2002 12:42:13 -0700 (MST) Message-Id: <200208191942.g7JJgDU12774@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 17 Aug 2002 01:25:39 GMT X-Draft-From: ("nnvirtual:Languages" 626) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Emacs Made Almost Completely Screwed Microsoft: Where `market lock-in' means throwing away the keys. X-Shopping-List: (1) Obvious anonymous detergents (2) Scientific furniture (3) Fabulous flossbags X-Uboat-Death-Message: TORPEDOED BY IRC SERVER 12N 12W. SINKING. U-709. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In an attempt to throw the authorities off his trail, Steve Wampler transmitted: > Christopher Browne wrote: >> >> A long time ago, in a galaxy far, far away, Steve Wampler wrote: >> > Gene Kahn wrote: >> >> >> >> The horse raced past the barn collapsed. >> > >> > I can't wait to see the answer! Regardless, it's certainly >> > considered correct English for those of us of Pennsylvania >> > Dutch descent... >> >> While it's grammatically correct, it doesn't really make _sense_. >> It's quite unusual for a horse to be deemed "racing" when it's >> collapsed. >> > > Ah, but to me (PD-heritage, remember), it's the same as: > > The horse raced by the collapsed barn. > > no ambiguity at all! > > Why do I have the feeling our stock as programmers is gradually > sinking into the ooze? My vision is of a horse half-embedded in the ground _trying_ to race past the barn, and not quite succeeding. -- (concatenate 'string "cbbrowne" "@ntlug.org") http://cbbrowne.com/info/languages.html "Bureaucracies interpret communication as damage and route around it" -- Jamie Zawinski From icon-group-sender Mon Aug 19 12:51:00 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JJouc13314 for icon-group-addresses; Mon, 19 Aug 2002 12:50:56 -0700 (MST) Message-Id: <200208191950.g7JJouc13314@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 17 Aug 2002 01:25:39 GMT X-Draft-From: ("nnvirtual:Languages" 619) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Experience the Mildest Ad Campaign ever Seen Microsoft: I'm not laughing anymore. X-Shopping-List: (1) Assiduous buds (2) Presidential incongruous capture enemas (3) Scrumptious erosion circumlocutions X-Uboat-Death-Message: TORPEDOED BY SALESMEN. UNABLE TO DIVE. SINKING. U-244. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The world rejoiced as Jesse Tov wrote: > Gene Kahn : >> previous statements. On the other hand, in reading s-expression >> languages like Lisp and Scheme, I find that I have to hold in my mind >> too many _unstated_ intermediate results before I find what the >> expression is all about. (One could argue that this may be due more to >> bad code, i.e., irresponsible use of deep embedding, than to intrinsic >> properties of s-expressions). > > I would argue that it's bad code. That's what "let" ("let" > in ML, "let*" in Scheme) is for. (I don't know Lisp well > enough, but I bet there's something equivalent.) Lisp was there first with LET and LET*. The ML way is a bit more obviously expressive; code might assortedly look like: (LET* ((A 1) (B (* A 2))) (+ A B)) which expands to (let ((a 1)) (let ((b (* a 2))) (+ a b))) which is rather like let a = 1 in let b = a * 2 in a + b;; Contrast with (let ((a 1) (b 2)) (* a b)) which is like let a = 1 and b = 2 in a * b;; >> Compare the readability of these chunks >> of code: >> >> FORTRAN-like >> The man kicked the dog. >> The dog chased the cat. >> The cat bit the mouse. >> The mouse died. >> >> LISP-like (in infix notation) >> The mouse the cat the dog the man kicked chased bit died. > > ML-like > The man kicked the dog > which chased the cat > which bit the mouse > which died. > > (OK, so "let" to "which" is sort of a stretch, but "which" > lets you stop remembering everything and encapsulate it as a > temporary variable, a "pronoun," if you will. It makes the > sentence right-branching, and thus easier to read.) > >> Speaking of speaking (or writing) grammatical English, which skill has >> been implied in a recent post as a 'requisite' for programming, what >> do readers with good English grammar think of this sentence: >> grammatically correct or not? Be careful with your answer. Your >> reputation as a programmer is on the line. >> >> The horse raced past the barn collapsed. > > Well, I can't find any way to parse it that has the barn collapsing > rather than the horse. In my dialect, it's is equivalent to > The horse which was raced past the barn collapsed. > and is perfectly grammatical. However, I know in some people's > dialects (my grandfather, from eastern Pennsylvania), it's more like: > The horse which raced past the barn collapsed. > When I hear it like this, it's ungrammatical to me. The problem here isn't grammar; it's semantics, and semantics that don't make sense. If we changed the last word from "collapsed" to "upright", it would read: The horse raced past the barn upright. The problem isn't with the barn; it's not with racing; its that if the horse is "collapsed," it doesn't make sense for it to be able to have "raced" past the barn. Being in a state of collapse would generally _end_ any racing. The sentence demonstrates why we have punctuation. It makes a bit more sense (or at least the ambiguity of what "collapsed" attaches to gets broken a bit) if we add a comma: The horse raced past the barn, collapsed. The problem with Perl is that it winds up slathering massive amounts of punctuation in everywhere, $whether @YOU %{want} $(it)++ or not. In human language, we want to have a _few_ accents here and there that break things up where they are needed. A comma or two per line, a period in each sentence, and a colon or semicolon once in a while to indicate significant pauses. Perl goes hogwild on punctuation, which gets really annoying after a while. That sample sentence probably needed an extra comma even though it wasn't strictly necessary in much the way that arithmetic operations often read much better with a few extra parentheses that allow the reader to avoid the need to puzzle through the specific order of bindings of arithmetic operations for the given language. -- (concatenate 'string "cbbrowne" "@acm.org") http://www3.sympatico.ca/cbbrowne/spiritual.html This login session: $13.99 From icon-group-sender Mon Aug 19 12:51:49 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JJplQ13392 for icon-group-addresses; Mon, 19 Aug 2002 12:51:47 -0700 (MST) Message-Id: <200208191951.g7JJplQ13392@baskerville.CS.Arizona.EDU> From: Hrvoje Blazevic X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: Sat, 17 Aug 2002 09:16:19 +0200 X-Complaints-To: abuse@hinet.hr User-Agent: Pan/0.11.2 (Unix) X-Comment-To: "Gene Kahn" To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Fri, 16 Aug 2002 17:38:22 +0200, Gene Kahn wrote: >> Statements do not return values, they have side-effects, most notably >> assignment to variables that describe the state of the computation at >> any given moment. >> > This is not without its advantage, of course. In particular, in terms of > readability, I find that explicit variables allow my mind to 'close' > (I'm not using it in the technical sense of "closure") previous > statements. On the other hand, in reading s-expression languages like > Lisp and Scheme, I find that I have to hold in my mind too many > _unstated_ intermediate results before I find what the expression is all > about. (One could argue that this may be due more to bad code, i.e., > irresponsible use of deep embedding, than to intrinsic properties of > s-expressions). Compare the readability of these chunks of code: > > FORTRAN-like > The man kicked the dog. > The dog chased the cat. > The cat bit the mouse. > The mouse died. > > LISP-like (in infix notation) > The mouse the cat the dog the man kicked chased bit died. Well -- this comparison is very unfair, a favorite imperative programmer's trick. I do not mean this in derogatory way. In the meantime I have checked your web-site, and have found a lot of interesting material, quite a lot of common interest. In these two examples you are deliberately confusing programming languages, and human languages. Human languages are not formal systems, while programming languages are. When you force yourself (difficult in this example) to forget about standard meaning of English words, then the second example can make more sense than the first. Phew -- I had to reach for GEB (Goedel Escher Bach) to answer this one. But let's go back to programming paradigms; Unfortunately, most programmers, and students would agree with you -- following the state of variables is easier to understand, than holding a deep recursive structure in the head. I did have problems with this when I started with Logo and Scheme. However, given enough of endurance and several good books (and interestingly enough books from FP camp seem to be an order of magnitude better than those from imperative camp), one can stop trying to reason about processes that recursive procedures carry out in the terms of remembering values, and switch to the higher level of simply following the definitions of data structures that those processes work on. When one is able to do this, imperative style all of the sudden starts looking complicated and mind limiting. I will not bother you with very good arguments of when and where assignment is appropriate, and what are its advantages and drawbacks. (there are more drawbacks -- of course :-) All this is very thoroughly described in HtDP and SICP. From icon-group-sender Mon Aug 19 13:01:38 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JK1Xg13957 for icon-group-addresses; Mon, 19 Aug 2002 13:01:33 -0700 (MST) Message-Id: <200208192001.g7JK1Xg13957@baskerville.CS.Arizona.EDU> From: Jesse Tov X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 17 Aug 2002 07:31:14 GMT User-Agent: slrn/0.9.7.4 (Linux) To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne : > (LET* ((A 1) > (B (* A 2))) > (+ A B)) > > which expands to > (let ((a 1)) > (let ((b (* a 2))) > (+ a b))) So the same as scheme. >> The horse which raced past the barn collapsed. >> When I hear it like this, it's ungrammatical to me. > > The problem here isn't grammar; it's semantics, and semantics that > don't make sense. I disagree---the semantics are fine if "collapsed" is a verb: The horse collapsed. Which horse collapsed? The horse raced past the barn collapsed. It's syntactically ambiguous, and with your parsing, the problem is semantics, but with my parsing the semantics are fine. > If we changed the last word from "collapsed" to "upright", it would > read: > The horse raced past the barn upright. "Upright" just removes the ambiguity because it has to parse as an adjective, and and the syntax tree in which it works (your parsing above, but not mine) makes sense semantically. Jesse From icon-group-sender Mon Aug 19 13:08:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JK8n614346 for icon-group-addresses; Mon, 19 Aug 2002 13:08:49 -0700 (MST) Message-Id: <200208192008.g7JK8n614346@baskerville.CS.Arizona.EDU> Date: Sun, 18 Aug 2002 15:25:42 +1000 From: Rohan McLeod X-Accept-Language: en To: Gene Kahn CC: icon-group@cs.arizona.edu Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Errors-To: icon-group-errors@cs.arizona.edu Status: RO > > > what > do readers with good English grammar think of this sentence: > grammatically correct or not? Be careful with your answer. Your > reputation as a programmer is on the line. > > The horse raced past the barn collapsed. I have little ability and no reputation as a programmer; neither am I particularly fussed by grammar; on the other hand I am quite compulsive obsessive about ambiguity. The above sentence seems ambiguous: 1/The horse raced past, the barn collapsed. -Two things happened not neccessarily connected 2/ The horse raced past the barn, collapsed. - The horse raced past the the barn in a state of collapse (?) well what did I miss? ;Rohan McLeod From icon-group-sender Mon Aug 19 13:09:36 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JK9Xs14419 for icon-group-addresses; Mon, 19 Aug 2002 13:09:33 -0700 (MST) Message-Id: <200208192009.g7JK9Xs14419@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 18 Aug 2002 10:03:32 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Reply to Steve, Jesse, Christopher, and Hrvoje: The sentences The mouse the cat the dog the man kicked chased bit died. The horse raced past the barn collapsed. are standard sentences in introductory linguistics course that illustrate one point or another. Steve and Jesse's interpretation is the "generally accepted" reading: The horse raced past the barn collapsed. = The horse (which was) raced past the barn collapsed. Jesse's grandfather's reading (see below), as he pointed out, is incorrect or very marginal to most speakers. Most speakers don't delete "which" in that context. The horse raced past the barn collapsed ?= The horse (which) raced past the barn collapsed. Setting off the the embedded clause with commas makes the sentence easy to read, but this sentence differs from the original in restrictiveness. The horse, raced past the barn, collapsed. <> The horse raced past the barn collapsed. How did we get into a discussion of English grammar? Well, for one thing, one's ability to write grammatical English is a requisite to writing computer programs (in a revolutionary approach to programming), as someone suggested earlier. So I was testing if those I'm holding a discussion with are good programmers or not ;-). Also, these sentences illustrate that certain structures even in natural languages are harder to read than others. Headleass clause is one (the sentence about the horse), embedding is another (the sentence about the mouse), though, as Jesse pointed out, right-branching is easier to read: ML-like The man kicked the dog which chased the cat which bit the mouse which died. and that's because essentially this has the effect of compounding (concatenation). It is not the plethora of parentheses that makes Lisp less readable to me. It is the fact that it allows left- AND center- AND right-branching (though indentation helps somewhat to clarify visually the branches) PLUS deep nesting. Left-branching (+ (- (...))) Center-branching (+ (* a (...) b) c) Right-branching (+ a (* b (...))) In concatenative languages (ML, Joy, etc.) , this would look like the following, which, at this level would has a simple sequential structure. e1 . e2 . (...) . e3 . e4 Nesting is unavoidable in a language that eschews variables and assignments, and to the programmer/writer the lure of deep nesting is hard to resist. This poses readability problems to the next programmer who has to maintain the code. (In my case, the comfort level is roughly two nestings and three variables, which make for 5 items, which is the lower bound of the magic number 7 plus or minus 2). Though, as has been pointed out, one can choose to go against the functional spirit of Lisp and use "let". Now, you wouldn't want to say to someone "The mouse the cat the dog the man kicked chased bit died" even if you know that it is grammatical. So why would a programmer write in Lisp something like (+ (* a (...) b ) c )? Well, because the language was designed to communicate with the compiler, and there is a heavy penalty if you don't treat this feature as rule number one. So why don't programming language designers think of designing an "artificial human" language for describing objects and their behavior primarily for human communication (but optimized under the hood for the compiler). All this is getting to be out of topic. So back to the topic of the original thread: wish list. Wish list to make Icon more useful. For what tasks? For mainstream programming? Does Icon aspire to become a mainstream language? Genghis Khan's Conclusion: If a language has not reached the mainstream within 9 years of Release 1.0, it never will. I think that there is now nothing that proponents of Icon, Lisp, Scheme, Eiffel, Smalltalk, and a host of other languages can do to make their languages more mainstream (that is to say, as popularly used as C++, Java, and Visual Basic). They will remain 'niche' languages. This does not mean one should stop working on the language. I'd say make Icon the best language at what it does best (goal-directed processing), and make it a callable engine from mainstream languages, and make it ridiculously easy to use libraries and packages from other languages. I'm off to the Scheme camp to check out what they have to offer ... --gk Jesse Tov wrote in message news:... > Christopher Browne : > > (LET* ((A 1) > > (B (* A 2))) > > (+ A B)) > > > > which expands to > > (let ((a 1)) > > (let ((b (* a 2))) > > (+ a b))) > > So the same as scheme. > > >> The horse which raced past the barn collapsed. > >> When I hear it like this, it's ungrammatical to me. > > > > The problem here isn't grammar; it's semantics, and semantics that > > don't make sense. > > I disagree---the semantics are fine if "collapsed" is a verb: > > The horse collapsed. Which horse collapsed? The horse raced past > the barn collapsed. > > It's syntactically ambiguous, and with your parsing, the problem is > semantics, but with my parsing the semantics are fine. > > > If we changed the last word from "collapsed" to "upright", it would > > read: > > The horse raced past the barn upright. > > "Upright" just removes the ambiguity because it has to parse as an > adjective, and and the syntax tree in which it works (your parsing > above, but not mine) makes sense semantically. > > Jesse From icon-group-sender Mon Aug 19 13:10:13 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JKAAU14517 for icon-group-addresses; Mon, 19 Aug 2002 13:10:10 -0700 (MST) Message-Id: <200208192010.g7JKAAU14517@baskerville.CS.Arizona.EDU> Date: Mon, 19 Aug 2002 14:16:57 +1200 (NZST) From: "Richard A. O'Keefe" To: cbbrowne@acm.org, icon-group@cs.arizona.edu Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Errors-To: icon-group-errors@cs.arizona.edu Status: RO There is a category of sentences called "Garden Path" sentences because they lead the hearer down the garden path (you expect one structure, but it has another). Mitch Marcus was particularly interested in them because they also misled his parser, for which he claimed "psychological realism". One idea is that people may have (at least) two strategies for dealing with language: a fast heuristic parser that normally gets it right, and a slow, more-or-less conscious rule-following process that can cope with gubbins like "Buffalo buffalo buffalo Buffalo buffalo." >> The horse raced past the barn collapsed. This sentence has, as far as I am aware, a single grammatical reading. It isn't *any* of "The horse raced past the barn and collapsed." [The collapse need not have been immediate.] "The horse raced past the collapsed barn." [The horse collapsed, not the barn.] "The horse raced past the barn which collapsed." [The horse collapsed, not the barn.] and does *not* involve a collapsed horse racing. Basically, what's going on is THAT-deletion plus a +passive reading of "raced". Read it as "The horse [that was] raced past the barn collapsed [then or later]." The point of this particular example is that when we get to the word "barn" we are expecting the next thing to be a full stop, not another verb and the reading we _+think_ we are dealing with is -passive. To get it right we have to go back, insert THAT, and change raced from -passive to +passive. While it's grammatically correct, it doesn't really make _sense_. It makes perfect sense. Someone raced the horse past the barn and the poor animal then collapsed. The horse hobbled past the barn collapsed. I can't parse this one. English is an anomalous SVO language; only a very few "fossilised" adjectives follow the noun they modify (as in governor(noun)-general(adjective), major-general, court martial, durance vile). So "collapsed" cannot be an adjective here. The sentence does not admit a +passive reading for "hobbled", because "to hobble an animal" does not admit a PATH complement, the point of hobbling is to *prevent* the animal following much of a path. The horse raced past the barn exhausted. This one makes sense. "The horse raced past the barn in an exhausted manner." It's a bit garden-pathish. This is probably one of the places where a comma would be in order: The horse raced past the barn, collapsed. I can't parse this. Has an AND been deleted from it? If it were The horse raced past the barn, collapsed, and had a fit. then I could parse it, but the AND seems to be necessary. From icon-group-sender Mon Aug 19 13:10:34 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JKAVk14542 for icon-group-addresses; Mon, 19 Aug 2002 13:10:31 -0700 (MST) Message-Id: <200208192010.g7JKAVk14542@baskerville.CS.Arizona.EDU> Date: Mon, 19 Aug 2002 15:56:04 +1200 (NZST) From: "Richard A. O'Keefe" To: icon-group@cs.arizona.edu, jenjhiz@yahoo.com Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Errors-To: icon-group-errors@cs.arizona.edu Status: RO jenjhiz@yahoo.com (Gene Kahn) wrote: This is not without its advantage, of course. In particular, in terms of readability, I find that explicit variables allow my mind to 'close' (I'm not using it in the technical sense of "closure") previous statements. On the other hand, in reading s-expression languages like Lisp and Scheme, I find that I have to hold in my mind too many _unstated_ intermediate results before I find what the expression is all about. You may be reading them in the wrong direction. FORTRAN-like The man kicked the dog. The dog chased the cat. The cat bit the mouse. The mouse died. LISP-like (in infix notation) The mouse the cat the dog the man kicked chased bit died. As a Lisp programmer, I must say that doesn't look Lisp-like to me. Remember, Lisp puts the "verb" FIRST. Let's have a form (the (Variable) Condition) which binds Variable inside Condition and returns the thing that satifies Condition. ;; 'the' is reserved in Common Lisp, so this must be Scheme! (let* ((H (the (H) (is-man H))) (D (the (D) (and (is-dog D) (kicked H D)))) (C (the (C) (and (is-cat C) (chased D C)))) (M (the (M) (and (is-mouse M) (bit C M))))) (died M)) This could also be written (died (the (M) (and (is-mouse M) (was bit M (the (C) (and (is-cat C) (was chased C (the (D) (and (is-dog D) (was kicked D (the (H) (is-man H)))))))))))) where (define (was f x y) (f y x)) As a Lisp programmer, I wouldn't be satisifed with either of these. I'd extend "the" to ;; new form (the (Variable Type) Cond1 ... Condk) => ;; old form (the (Variable) (and (is-Type Variable) Cond1 ... Condk)) and write (let* ((H (the (man H) #t)) (D (the (dog D) (kicked H D))) (C (the (cat C) (chased D C))) (M (the (mouse M) (bit C M)))) (died M)) or (died (the (mouse M) (was bit M (the (cat C) (was chased C (the (dog D) (was kicked D (the (man H))))))))) "has died the mouse that was bit by the cat that was chased by the dog that was kicked by the man". Of course, variable-less, assignment-less languages have advantages. Indeed. So of course does Icon. The rule is always to use the language that best fits the easiest way to think correctly about the problem, and then translate into whatever your boss forces you to use. From icon-group-sender Mon Aug 19 13:11:09 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JKB6A14616 for icon-group-addresses; Mon, 19 Aug 2002 13:11:06 -0700 (MST) Message-Id: <200208192011.g7JKB6A14616@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: "'icon-group@CS.Arizona.EDU'" Subject: MT Icon === aspect-oriented-programming framework? Date: Mon, 19 Aug 2002 00:55:03 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Would it be safe to say that MT Icon provides a framework in which one could do Aspect-Oriented Programming? I only have the shallowest understanding of AOP, so please forgive the naive question. From icon-group-sender Fri Aug 23 12:50:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7NJnPM25465 for icon-group-addresses; Fri, 23 Aug 2002 12:49:25 -0700 (MST) Message-Id: <200208231949.g7NJnPM25465@baskerville.CS.Arizona.EDU> From: "Steve Adams" X-Newsgroups: comp.lang.icon Subject: syntax files for editors X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Date: Fri, 23 Aug 2002 14:07:17 GMT X-Complaints-To: abuse@rr.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Does anyone know of syntax coloring files for Icon for use with editors like MED, EditPlus 2, or Crimson? Thanks. From icon-group-sender Mon Sep 9 12:25:38 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g89JNtA02982 for icon-group-addresses; Mon, 9 Sep 2002 12:23:55 -0700 (MST) Message-Id: <200209091923.g89JNtA02982@baskerville.CS.Arizona.EDU> Subject: Using Procedure Names for Debugging From: Steve Graham To: Icon Group Date: 09 Sep 2002 12:35:14 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO While developing an Icon program, I wanted an easy way to debug each procedure. I had read that there is more than 1 way to invoke a command. For example, you can have the statement write(5) or you can have "write"(5). I figured that I would use this idea to develop a test module, to which I would pass a procedure name and arguments. The test module would in turn invoke the specified procedure as in the 2nd example above with the arguments and report back the results, if any. However, I wasn't able to make it work. I'd bet there is a way, though. Any ideas? TIA, Steve From icon-group-sender Tue Sep 10 07:49:26 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8AEn4s10509 for icon-group-addresses; Tue, 10 Sep 2002 07:49:04 -0700 (MST) Message-Id: <200209101449.g8AEn4s10509@baskerville.CS.Arizona.EDU> X-Sender: whm@mail.mse.com Date: Mon, 09 Sep 2002 23:03:24 -0700 To: Steve Graham From: "William H. Mitchell" Subject: Re: Using Procedure Names for Debugging Cc: Icon Group Errors-To: icon-group-errors@cs.arizona.edu Status: RO At 12:35 PM 9/9/02 -0500, Steve Graham wrote: >While developing an Icon program, I wanted an easy way to debug each >procedure. I had read that there is more than 1 way to invoke a >command. For example, you can have the statement write(5) or you can >have "write"(5). I figured that I would use this idea to develop a test >module, to which I would pass a procedure name and arguments. The test >module would in turn invoke the specified procedure as in the 2nd >example above with the arguments and report back the results, if any. >However, I wasn't able to make it work. I'd bet there is a way, >though. Any ideas? That approach sounds fine but there may be some detail tripping you up. One thing to note is that if you want to use string invocation (i.e., "x"(1)), you need an "invocable" declaration if you're going to invoke non-builtins. Here's a sample program that I think may do what you want: invocable all # declares all procedures as invocable procedure main(args) if r := args[1]!args[2:0] then # calls procedure named as first # command line argument with following # command line arguments write("Result: ", image(r)) else write("Call failed...") end Here's a test procedure to use with it: procedure x(y) write("x called with ", y) end Here are some examples of usage, assuming it's named "rp" (run procedure): $ rp center abc 20 . Result: "........abc........." $ rp find d "abcdefg" Result: 4 $ rp find x "abcdefg" Call failed... $ rp x testing x called with testing Call failed... Note that the last invocation, "rp x testing" fails because there's no return or suspend at the end of x. Note also that without the "invocable all" declaration, the last call would produce error 106. Big picture-wise, however, you might find that qei, from the Icon Program Library is a general purpose tool for interactively evaluating Icon expressions: $ qei Icon Expression Evaluator, Version 1.2, type :? for help > center("abc", 20, "."); r1_ := "........abc........." (string) > find("d", "abcdefg"); r2_ := 4 (integer) > find("x", "abcdefg"); Failure > From icon-group-sender Tue Sep 10 07:50:47 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8AEoiU10589 for icon-group-addresses; Tue, 10 Sep 2002 07:50:44 -0700 (MST) Message-Id: <200209101450.g8AEoiU10589@baskerville.CS.Arizona.EDU> Subject: Re: Using Procedure Names for Debugging From: Steve Graham To: Icon Group Date: 10 Sep 2002 08:33:07 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO As a number of you kindly pointed out, the invocable directive needed to be added to my program to enable this technique with non-builtins. Thanks to all who so quickly responded. Steve === On Mon, 2002-09-09 at 12:35, Steve Graham wrote: > While developing an Icon program, I wanted an easy way to debug each > procedure. I had read that there is more than 1 way to invoke a > command. For example, you can have the statement write(5) or you can > have "write"(5). I figured that I would use this idea to develop a test > module, to which I would pass a procedure name and arguments. The test > module would in turn invoke the specified procedure as in the 2nd > example above with the arguments and report back the results, if any. > However, I wasn't able to make it work. I'd bet there is a way, > though. Any ideas? > > TIA, Steve > > -- Steve --------------------------------------------------------------------------------------- Steve Graham Lead Project Analyst/Engineer LabCorp Phone: (972) 643-6124 Fax: (972) 454-1050 Mail: Steve_Graham@labcorp.com --------------------------------------------------------------------------------------- From icon-group-sender Mon Sep 16 08:04:19 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GF3GI09206 for icon-group-addresses; Mon, 16 Sep 2002 08:03:16 -0700 (MST) Message-Id: <200209161503.g8GF3GI09206@baskerville.CS.Arizona.EDU> Date: Sat, 14 Sep 2002 17:19:19 +0200 From: No spam X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > An Icon.NET or a plug-in to the Eclipse development system will give > Icon good exposure. Plus .NET will provide many libraries that Icon > may not have access to at this point. Anybody working on these > projects? What is .NET? :-) From icon-group-sender Mon Sep 16 08:05:10 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GF57E09376 for icon-group-addresses; Mon, 16 Sep 2002 08:05:07 -0700 (MST) Message-Id: <200209161505.g8GF57E09376@baskerville.CS.Arizona.EDU> Date: Sat, 14 Sep 2002 17:17:54 +0200 From: No spam X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Frank J. Lhota" wrote: > 1) Object-Oriented Programming > I have not used Icon a lot, but was fascinated by its expressive power. Why I don't use it much has nothing to do with its lack of OO support - I would never have used it for large programs anyway - it is lack of time to become familiar with a new language, and 'competition' from other languages like Perl. There is one language that I would _never_ use for a small ad-hoc program: Java. Why? Because it is terrobly verbose, and there is no need for OO in an ad-hoc program. So, I would actually vote to keep OO out of Icon! I would find it a lot more attractive if it was kept trimmed-down. > 2) Better Interfacing to External Programs One of the resons I don't use Icon much, is that I haven't figured out how to interface with C. > 3) Unicode Support No view on it - I don't use other than 'normal' character set for small systems utilities. > > 4) Icon as a Scripting Language > Or go the other way, and reenable iconc? Atle - trolletATskynetDOTbe From icon-group-sender Mon Sep 16 08:05:40 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GF5bA09430 for icon-group-addresses; Mon, 16 Sep 2002 08:05:37 -0700 (MST) Message-Id: <200209161505.g8GF5bA09430@baskerville.CS.Arizona.EDU> Date: Sun, 15 Sep 2002 12:25:10 +0200 From: No spam X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > > A long time ago, in a galaxy far, far away, Steve Wampler wrote: > > Gene Kahn wrote: > >> > >> Speaking of speaking (or writing) grammatical English, which skill has > >> been implied in a recent post as a 'requisite' for programming, what > >> do readers with good English grammar think of this sentence: > >> grammatically correct or not? Be careful with your answer. Your > >> reputation as a programmer is on the line. > >> > >> The horse raced past the barn collapsed. > > > > I can't wait to see the answer! Regardless, it's certainly > > considered correct English for those of us of Pennsylvania > > Dutch descent... > > While it's grammatically correct, it doesn't really make _sense_. > It's quite unusual for a horse to be deemed "racing" when it's > collapsed. > > As a result of the "grammatical" meaning being semantically pretty > insensible, it is much easier for the eye to look for more logical > interpretations, such as: > > "The horse raced past the barn and collapsed." > "The horse raced past the collapsed barn." > "The horse raced past the barn which collapsed." > > Grammatically equivalent phrases to the original where the semantics > would make sense might include: > > The horse hobbled past the barn collapsed. > The horse raced past the barn exhausted. > > This is probably one of the places where a comma would be in order: > > The horse raced past the barn, collapsed. If the horse was very fast, you might get: The horse raced past, the barn collapsed. From icon-group-sender Mon Sep 16 12:57:24 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GJv1626567 for icon-group-addresses; Mon, 16 Sep 2002 12:57:01 -0700 (MST) Message-Id: <200209161957.g8GJv1626567@baskerville.CS.Arizona.EDU> Date: Mon, 16 Sep 2002 21:01:34 +0200 From: No spam X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > An "Icon.NET", as in VB.NET, is my informal and short name for an > implementation of Icon running inside the Microsoft .NET environment. > Yes, but if .NET is not adopted outside the Microsoft realm, use of it would be highly non-portable ...? Atle From icon-group-sender Mon Sep 16 12:57:46 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GJvi226617 for icon-group-addresses; Mon, 16 Sep 2002 12:57:44 -0700 (MST) Message-Id: <200209161957.g8GJvi226617@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 16 Sep 2002 12:01:07 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO An "Icon.NET", as in VB.NET, is my informal and short name for an implementation of Icon running inside the Microsoft .NET environment. No spam wrote in message news:<3D835377.8D8FD6BB@nospam.org>... > Gene Kahn wrote: > > > > An Icon.NET or a plug-in to the Eclipse development system will give > > Icon good exposure. Plus .NET will provide many libraries that Icon > > may not have access to at this point. Anybody working on these > > projects? > > What is .NET? :-) From icon-group-sender Mon Sep 16 12:58:37 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GJwYA26683 for icon-group-addresses; Mon, 16 Sep 2002 12:58:34 -0700 (MST) Message-Id: <200209161958.g8GJwYA26683@baskerville.CS.Arizona.EDU> Date: Mon, 16 Sep 2002 21:04:26 +0200 From: No spam X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > Christopher Browne: > > > If the horse was very fast, you might get: > > > > The horse raced past, the barn collapsed. > > I'd say that's a good reading! ... but not easy to parse! Look for predicate: 'raced' Look for subject: 'The horse' Look for object: 'past the barn' I don't think the above, two part meaning could be found with any 'mechanical' parser, and certainly not LL1 :-) Atle From icon-group-sender Mon Sep 16 12:59:15 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GJx8626728 for icon-group-addresses; Mon, 16 Sep 2002 12:59:08 -0700 (MST) Message-Id: <200209161959.g8GJx8626728@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 16 Sep 2002 11:55:48 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne: > If the horse was very fast, you might get: > > The horse raced past, the barn collapsed. I'd say that's a good reading! No spam wrote in message news:<3D846006.6F9ECD44@nospam.org>... > Christopher Browne wrote: > > > > A long time ago, in a galaxy far, far away, Steve Wampler wrote: > > > Gene Kahn wrote: > > >> > > >> Speaking of speaking (or writing) grammatical English, which skill has > > >> been implied in a recent post as a 'requisite' for programming, what > > >> do readers with good English grammar think of this sentence: > > >> grammatically correct or not? Be careful with your answer. Your > > >> reputation as a programmer is on the line. > > >> > > >> The horse raced past the barn collapsed. > > > > > > I can't wait to see the answer! Regardless, it's certainly > > > considered correct English for those of us of Pennsylvania > > > Dutch descent... > > > > While it's grammatically correct, it doesn't really make _sense_. > > It's quite unusual for a horse to be deemed "racing" when it's > > collapsed. > > > > As a result of the "grammatical" meaning being semantically pretty > > insensible, it is much easier for the eye to look for more logical > > interpretations, such as: > > > > "The horse raced past the barn and collapsed." > > "The horse raced past the collapsed barn." > > "The horse raced past the barn which collapsed." > > > > Grammatically equivalent phrases to the original where the semantics > > would make sense might include: > > > > The horse hobbled past the barn collapsed. > > The horse raced past the barn exhausted. > > > > This is probably one of the places where a comma would be in order: > > > > The horse raced past the barn, collapsed. > > If the horse was very fast, you might get: > > The horse raced past, the barn collapsed. From icon-group-sender Mon Sep 16 16:24:02 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8GNNiA09185 for icon-group-addresses; Mon, 16 Sep 2002 16:23:44 -0700 (MST) Message-Id: <200209162323.g8GNNiA09185@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 16 Sep 2002 22:52:42 GMT X-Draft-From: ("nnvirtual:Languages" 928) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Everyday Material Almost Compiled Successfully Microsoft: We've got the solution for the problem we sold you. X-Uboat-Death-Message: BLOWN UP BY EIGHT DESTROYERS. EXPLODING. U-704. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In the last exciting episode, No spam wrote:: > Gene Kahn wrote: >> An "Icon.NET", as in VB.NET, is my informal and short name for an >> implementation of Icon running inside the Microsoft .NET >> environment. > > Yes, but if .NET is not adopted outside the Microsoft realm, use of > it would be highly non-portable ...? There seem to be two other implementations of the ".NET VM," which /could/ be a counterargument. But I doubt they will be /realistic/ alternatives to .NET anymore than the "UNIX port" of DCOM made it realistic to deploy COM-based applications on UNIX. The reason is that Microsoft isn't going to have the environment start and end with the VM. They will actively encourage users to write applications that employ extensive references to components that will only be available on Windows. Anything GUI would represent an /excellent/ example of this, for instance. They'll be more than happy to provide .NET interfaces to Win32, perhaps even having that "linked in" by default, and that will only be available on Windows. It would seem to me to make a /lot/ more sense to try to deploy Icon atop the upcoming Perl "Parrot" bytecode system. Consider that: a) It /is/ intended to be portable; b) There is intent for it to be not /totally/ Perl-oriented, as the Python and Ruby communities have had discussions about cooperation; c) It is not inconceivable that you could submit changes to Parrot to the Perl team, and have /some/ hope of them being accepted. -- (concatenate 'string "cbbrowne" "@ntlug.org") http://cbbrowne.com/info/bytecode.html You know that little indestructible black box that is used on planes---why can't they make the whole plane out of the same substance? From icon-group-sender Tue Sep 17 08:25:54 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HFOTU05746 for icon-group-addresses; Tue, 17 Sep 2002 08:24:29 -0700 (MST) Message-Id: <200209171524.g8HFOTU05746@baskerville.CS.Arizona.EDU> Date: Tue, 17 Sep 2002 10:36:37 +0200 From: TrolletAtskynetDOTbe X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > There seem to be two other implementations of the ".NET VM," which > /could/ be a counterargument. But I doubt they will be /realistic/ > alternatives to .NET anymore than the "UNIX port" of DCOM made it > realistic to deploy COM-based applications on UNIX. I put a :-) after my question 'What is .NET' - but I was serious when I wrote it. Let me think .. when did I first hear of it? Two years back? When did I last hear of it? Two years back. So it has become an integral part of Windows development after all? As long as it doesn't infect non-Windows areas, I guess that is OK. Everybody seemed to agree that a framework like .NET was a Good Thing (tm) but they also suspected that Microsoft would certainly find a way to take a Good Thing and do something bad with it ... so they did, it seems. Two years back, I wanted to find out what it was ... now I am more relaxed about it. > It would seem to me to make a /lot/ more sense to try to deploy Icon > atop the upcoming Perl "Parrot" bytecode system. Consider that: > a) It /is/ intended to be portable; > b) There is intent for it to be not /totally/ Perl-oriented, as the > Python and Ruby communities have had discussions about cooperation; > c) It is not inconceivable that you could submit changes to Parrot to > the Perl team, and have /some/ hope of them being accepted. If Icon can find its way in between Perl and C somewhere ... I guess it might benefit from taking advantage of a Perl source-to-bytecode compiler/bytecode runtime in one end and icont in the other? Of course, if a bytecode-to-binary compiler is made, then icont is not needed ... and Perl becomes a compiled language, too. Good idea? Atle From icon-group-sender Tue Sep 17 08:33:24 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HFXAk06288 for icon-group-addresses; Tue, 17 Sep 2002 08:33:10 -0700 (MST) Message-Id: <200209171533.g8HFXAk06288@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 17 Sep 2002 14:42:23 GMT X-Draft-From: ("nnvirtual:Languages" 943) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Emacs May Alienate Clients and Supporters Microsoft: Making the world a better place... for Microsoft. X-Uboat-Death-Message: ATOMIC BOMB. ATTACKED. LEAVE BOAT. U-811. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The world rejoiced as TrolletAtskynetDOTbe wrote: > Christopher Browne wrote: >> There seem to be two other implementations of the ".NET VM," which >> /could/ be a counterargument. But I doubt they will be /realistic/ >> alternatives to .NET anymore than the "UNIX port" of DCOM made it >> realistic to deploy COM-based applications on UNIX. > > I put a :-) after my question 'What is .NET' - but I was serious when I > wrote it. > Let me think .. when did I first hear of it? Two years back? > When did I last hear of it? Two years back. > So it has become an integral part of Windows development after all? > As long as it doesn't infect non-Windows areas, I guess that is OK. I'm not sure it's "integral" yet. (I suspect it has too many discontinuities to be piece-wise continuous, and thus integrable... :-)) > Everybody seemed to agree that a framework like .NET was a Good Thing > (tm) but they also suspected that Microsoft would certainly find a way > to take a Good Thing and do something bad with it ... so they did, it > seems. > Two years back, I wanted to find out what it was ... now I am more > relaxed about it. There still seems to be a lot of "vaporware" about it. Be sure to realize that it's competition to J2EE, as opposed to other things. >> It would seem to me to make a /lot/ more sense to try to deploy Icon >> atop the upcoming Perl "Parrot" bytecode system. Consider that: >> a) It /is/ intended to be portable; >> b) There is intent for it to be not /totally/ Perl-oriented, as the >> Python and Ruby communities have had discussions about cooperation; >> c) It is not inconceivable that you could submit changes to Parrot to >> the Perl team, and have /some/ hope of them being accepted. > > If Icon can find its way in between Perl and C somewhere ... I guess it > might benefit from taking advantage of a Perl source-to-bytecode > compiler/bytecode runtime in one end and icont in the other? > > Of course, if a bytecode-to-binary compiler is made, then icont is not > needed ... and Perl becomes a compiled language, too. > > Good idea? Actually, I don't think so. Generating native code has at least two demerits here: a) Compiled code is no longer portable across platforms; b) Native-compiled code tends to be a LOT bigger than bytecode (by around a factor of five, for cases I've seen), and this doesn't necessarily lead to greatly improved performance. The code that gets helped by "native compilation" is tight loops involving primitive operations. For Perl, and Icon, for that matter, code that is /interesting/ will make extensive use of string pattern matching (regexes, in Perl), and that sort of code will dig into the "native-compile" libraries, and perform well even with 'byte-compiled' code. Perl code that's doing tight loops foreach $i (0..7500) { $FOO{$i} += $BAR[$i]; } /might/ be helped by native compilation, although the fact that the objects are rather dynamic may mean that this particular code snippet wouldn't be helped at all. Perl code that does extensive regex work generally /isn't/ slower than the equivalent C code, because in both cases, the code that gets run a lot is the heavily-optimized regular expression libraries. -- (reverse (concatenate 'string "gro.mca@" "enworbbc")) http://cbbrowne.com/info/languages.html "The only completely consistent people are the dead." -- Aldous Huxley From icon-group-sender Tue Sep 17 12:46:35 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HJk6Q24613 for icon-group-addresses; Tue, 17 Sep 2002 12:46:06 -0700 (MST) Message-Id: <200209171946.g8HJk6Q24613@baskerville.CS.Arizona.EDU> Date: Tue, 17 Sep 2002 18:34:08 +0200 From: TrolletAtskynetDOTbe X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > I'm not sure it's "integral" yet. (I suspect it has too many > discontinuities to be piece-wise continuous, and thus integrable... > :-)) I think you have a few /points/ there :-) > There still seems to be a lot of "vaporware" about it. Be sure to > realize that it's competition to J2EE, as opposed to other things. ... as I thought, I just wasn't sure. > The code that gets helped by "native compilation" is tight loops > involving primitive operations. For Perl, and Icon, for that matter, > code that is /interesting/ will make extensive use of string pattern > matching (regexes, in Perl), and that sort of code will dig into the > "native-compile" libraries, and perform well even with 'byte-compiled' > code. Of course. I just forgot what Icon (and Perl) are used for! I see a need for better integrations with 'extern's , tho? Atle From icon-group-sender Tue Sep 17 12:49:47 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HJmMw24760 for icon-group-addresses; Tue, 17 Sep 2002 12:48:22 -0700 (MST) Message-Id: <200209171948.g8HJmMw24760@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 17 Sep 2002 17:33:22 GMT X-Draft-From: ("nnvirtual:Languages" 950) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Excavating Mayan Architecture Comes Simpler Microsoft: Where `market lock-in' means throwing away the keys. X-Uboat-Death-Message: ATTACKED BY NETSCAPE. UNABLE TO DIVE. EXPLODING. U-306. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In the last exciting episode, TrolletAtskynetDOTbe wrote:: > Christopher Browne wrote: > >> I'm not sure it's "integral" yet. (I suspect it has too many >> discontinuities to be piece-wise continuous, and thus integrable... >> :-)) > I think you have a few /points/ there :-) > >> There still seems to be a lot of "vaporware" about it. Be sure to >> realize that it's competition to J2EE, as opposed to other things. > ... as I thought, I just wasn't sure. > >> The code that gets helped by "native compilation" is tight loops >> involving primitive operations. For Perl, and Icon, for that matter, >> code that is /interesting/ will make extensive use of string pattern >> matching (regexes, in Perl), and that sort of code will dig into the >> "native-compile" libraries, and perform well even with 'byte-compiled' >> code. > > Of course. I just forgot what Icon (and Perl) are used for! > I see a need for better integrations with 'extern's , tho? That's true; in theory, that ought to be a benefit of glomming onto "Perl Parrot," as the plan is to hook 'externs' to Perl through that level, and if that's the case, that buys "free hooks" for anyone else using Parrot for their own ends. While you can download, compile, and use Parrot today, there is certainly a lot of "vapor" to it... -- (concatenate 'string "cbbrowne" "@acm.org") http://www3.sympatico.ca/cbbrowne/perl.html "If Gladstone fell into the Thames it would be a misfortune but if someone pulled him out it would be a calamity." -- Benjamin Disraeli on William Gladstone From icon-group-sender Tue Sep 17 12:53:20 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HJrDA25065 for icon-group-addresses; Tue, 17 Sep 2002 12:53:13 -0700 (MST) Message-Id: <200209171953.g8HJrDA25065@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 17 Sep 2002 12:01:25 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO No spam wrote in message news:<3D862A8E.FBCB5B6F@nospam.org>... > Gene Kahn wrote: > > > > An "Icon.NET", as in VB.NET, is my informal and short name for an > > implementation of Icon running inside the Microsoft .NET environment. > > > Yes, but if .NET is not adopted outside the Microsoft realm, use of it > would be highly non-portable ...? > > Atle Not trying to be a smart-a**, but does anybody really seriously believe that .NET will NOT be used by a sizeable number of developers, large enough to become a serious alternative development environment if not /the/ development environment? gk From icon-group-sender Tue Sep 17 12:53:37 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HJrYk25102 for icon-group-addresses; Tue, 17 Sep 2002 12:53:34 -0700 (MST) Message-Id: <200209171953.g8HJrYk25102@baskerville.CS.Arizona.EDU> From: jenjhiz@yahoo.com (Gene Kahn) X-Newsgroups: comp.lang.icon Subject: Re: What about "Expressions?" (was Re: Icon Wish List) Date: 17 Sep 2002 11:55:30 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO No spam wrote in message news:<3D862B3A.714A7125@nospam.org>... > Gene Kahn wrote: > > > > Christopher Browne: > > > > > If the horse was very fast, you might get: > > > > > > The horse raced past, the barn collapsed. > > > > I'd say that's a good reading! > > ... but not easy to parse! > > Look for predicate: 'raced' > Look for subject: 'The horse' > Look for object: 'past the barn' > > I don't think the above, two part meaning could be found with any > 'mechanical' parser, and certainly not LL1 :-) > > Atle Given that the reading: "The horse raced past, the barn collapsed" is acceptable, along with the original reading "The horse that raced past the barn collapsed" then of course the sentence is ambiguous. The ambiguity arises because "past" can function as adverb (first reading) or preposition (the original reading). The word "past" should be marked for these readings, and the parser should try both readings. But I don't really know much about parsers. g(ee)k From icon-group-sender Tue Sep 17 16:28:36 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HNSNg10407 for icon-group-addresses; Tue, 17 Sep 2002 16:28:23 -0700 (MST) Message-Id: <200209172328.g8HNSNg10407@baskerville.CS.Arizona.EDU> Date: Tue, 17 Sep 2002 13:41:26 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group@cs.arizona.edu Subject: Re: Icon Wish 2 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > > Not trying to be a smart-a**, but does anybody really seriously > believe that .NET will NOT be used by a sizeable number of developers, > large enough to become a serious alternative development environment > if not /the/ development environment? That's a non-issue. The only issue here is: "Will *I* use .NET?". And the answer is "only if it's available for free on Unix/Linux platforms". (I realize that sounds arrogant - it isn't meant to be, but rather a statement that the world I live in has very little to do with Microsoft Windows and that how big .NET [or J2EE, or XYZ...] becomes in other people's worlds simply isn't a concern.) Right now Icon runs quite nicely on *all* the systems I use. If it stops doing that, I'll stop using Icon - switching platforms to gain access to the language just doesn't make much sense. [Ok, what it really means is I'll stop upgrading to new versions of Icon...] Granted, if my financial well-being depended primarily on my developing software for Windows, then I would look at .NET more seriously - *when* it has become a dominant player. A question - how pervasive is a .NET environment *within* a language implementation? Would it be possible to hook Icon in through a (loadable) library without making the language itself dependent on .NET? Or is .NET pretty much an all or nothing deal? -Steve -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Wed Sep 18 08:41:24 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8IFeQg14746 for icon-group-addresses; Wed, 18 Sep 2002 08:40:26 -0700 (MST) Message-Id: <200209181540.g8IFeQg14746@baskerville.CS.Arizona.EDU> Date: Wed, 18 Sep 2002 12:12:33 +0200 From: TrolletAtskynetDOTbe X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > That's true; in theory, that ought to be a benefit of glomming onto > "Perl Parrot," as the plan is to hook 'externs' to Perl through that > level, and if that's the case, that buys "free hooks" for anyone else > using Parrot for their own ends. > > While you can download, compile, and use Parrot today, there is > certainly a lot of "vapor" to it... Is there a place I can get a peek at it? What is the 'amount of job' neccessary to change the Icon runtime to use it? Atle From icon-group-sender Wed Sep 18 08:45:13 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8IFj5U15021 for icon-group-addresses; Wed, 18 Sep 2002 08:45:05 -0700 (MST) Message-Id: <200209181545.g8IFj5U15021@baskerville.CS.Arizona.EDU> Date: Wed, 18 Sep 2002 12:11:28 +0200 From: TrolletAtskynetDOTbe X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Gene Kahn wrote: > > No spam wrote in message news:<3D862A8E.FBCB5B6F@nospam.org>... > > Gene Kahn wrote: > > > > > > An "Icon.NET", as in VB.NET, is my informal and short name for an > > > implementation of Icon running inside the Microsoft .NET environment. > > > > > Yes, but if .NET is not adopted outside the Microsoft realm, use of it > > would be highly non-portable ...? > > > > Atle > > Not trying to be a smart-a**, but does anybody really seriously > believe that .NET will NOT be used by a sizeable number of developers, > large enough to become a serious alternative development environment > if not /the/ development environment? If I should take a guess with what I think I know, I'd say that the goal to become /the/ development environment will have to be acheived like this: First making .NET /the/ environment for MS devlopment tools, then the other tools (Borland, ...) - all for the Windows OS. I would say so far it is realistic. But further than that? Conquer the *nix world with .NET? I would say the most they can hope for, is maybe take a bite out the part that maintains some kind of Windows compatibility. But both KDE and GNOME have their own frameworks, even Motif has a framework. At the risk of being flamed to computer Hell, I'd say GNOME is 'winning' - Sun has standardized on it, and you can delelop in plain C - yes, developers like to know what is going on 'under the hood' - at least the ones we can call Hackers. The chance of putting .NET on top of CORBA are rather slim if I'm right about the above. Atle From icon-group-sender Wed Sep 18 08:45:29 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8IFjQo15088 for icon-group-addresses; Wed, 18 Sep 2002 08:45:26 -0700 (MST) Message-Id: <200209181545.g8IFjQo15088@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish 2 Date: 18 Sep 2002 14:21:02 GMT X-Draft-From: ("nnvirtual:Languages" 932) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Extensibility and Modifiability Aggravate Confirmed Simpletons Microsoft: Where even the version numbers aren't Y2K-compliant X-Uboat-Death-Message: ANNOYED BY SPACE-TIME VORTEX. SINKING. U-71. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The world rejoiced as TrolletAtskynetDOTbe wrote: > Christopher Browne wrote: > >> That's true; in theory, that ought to be a benefit of glomming onto >> "Perl Parrot," as the plan is to hook 'externs' to Perl through that >> level, and if that's the case, that buys "free hooks" for anyone else >> using Parrot for their own ends. >> >> While you can download, compile, and use Parrot today, there is >> certainly a lot of "vapor" to it... > > Is there a place I can get a peek at it? > What is the 'amount of job' neccessary to change the Icon runtime to use > it? I have /no/ idea. I have not been intimate with Icon bytecode, so can't suggest the scope of the differences. -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://www3.sympatico.ca/cbbrowne/emacs.html Why does sour cream have an expiration date? From icon-group-sender Thu Sep 19 08:22:26 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8JFLso23179 for icon-group-addresses; Thu, 19 Sep 2002 08:21:54 -0700 (MST) Message-Id: <200209191521.g8JFLso23179@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Thu, 19 Sep 2002 12:57:52 +1000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Frank J. Lhota wrote: > Looking over the last several versions of Icon, the last several > versions did little more than adding a few functions and fix a few > bugs. It has been a while since there have been major enhancements to > the Icon language. This type of stagnation harms Icon's long term > prospects. It is time to consider some major upgrades to Icon. > I've been watching this debate with interest (and am heartened by the increase in traffic above zero messages a month...) so here's my $0.04(AU) [current exchange rate is $1.00AU = $0.54US] > 1) Object-Oriented Programming Yes, Idol is very interesting, but I haven't used it in any project, just dabbled. I have used Icon for a few large tools; 3 of them are an essential part of the software development production system in my company. The simplest one is a pre-processor in the style of cpp, which we can use with our 4GL (sql-based) source code. This is a relatively simple process, and objects could have been convenient to store things like the defines and the stack of the pre-processor blocks, however lack of OO did not cause any difficulty. The second major tool is a 4GL code generator. It reads form specification files, accesses the database for table schema, and generates 4GL. Given the large number of source instructions representing screen objects and business rule actions, OO would have been very useful indeed and I did find myself wishing for classes *with methods* to get around my regular confusion as I got deep into nasty expressions which could only exploit . and [ ] operators. Not a few bugs were caused by mistakes with access to deep object members and performing work on them. The 3rd major tool is a source code merger, which reads a bunch of instructions to insert, replace or delete code blocks in the generated 4GL (this allows our programmers to maintain regenerable forms and yet perform powerful modifications to the generated code, to suit the exact business needs). This tool exploits the amazing power of coroutines amongst other things, and I managed to achieve a remarkable O(N) processing time. It's remarkable because I wrote it to replace a 3rd-party tool which slowed quadratically vs code size. This process had middling need for OO but once again exploited the magic of Icon to achieve its task. It's when projects achieve a critical mass that OO becomes a benefit. Any educational sample of OO fails to prove the need for OO IMHO. I still desire OO in Icon and forsee no costs beyond the implementation effort. I really can't see OO degrading Icon; with proper design it should fit in very nicely and elegantly. Apart from the corruption caused by it's pre-processing nature, Idol does show what is possible. With integrated support, the rough edges of Idol could be cleaned up. It's interesting to think about the style of the syntax to use. Given that OO is only really useful for large projects, I would lean towards the "one file, one class" approach, which means that the classes could look like this: # just a suggestion class Foo [ : superclass ... ] define var, var, var ... static classvar, classvar ... constructor Foo( arg ... ) .... end destructor ~Foo( ) # typical destructor stuff end method instanceMethod( arg ... ) ... end static method classMethod( args ) ... end NOTE: use of "constructor", "destructor" and "method" keywords does not denote a preference. Since Icon is completely free with variable types and call arguments, it follows that class members should not be typed, and overloaded methods do not make sense either - one name, one method. A class constructor is obviously needed, and presumably a class destructor too; for the usual application-level cleanups. Due to the nature of Icon garbage collection, the destructor would not be called at any predictable time, but then, people comfortably live with that in Java. There's probably scope for operator overloading. Icon has a decent set of operators, and some tasks benefit from operator overloading - however, people do tend to get very silly trying to squeeze as much as possible into that mould ;) What about member privacy? With the 1 file, 1 class model, it does become possible to add a "private" keyword for class methods, members and statics. If marked as private, the member is not visible outside the file. However, that does not fit at all with the dynamic typing of Icon. How do you know the type of a particular variable at any one time? You don't, so you can't block access to specific fields, unless some sort of runtime check was added to provide the illusion of privacy. Perhaps that's acceptable... If the runtime check was provided, then presumably protected member access could also be fitted. Personally I wouldn't fuss deeply about this. The Perlish idea of the "gentleperson's agreement" works for me. Should member variables be accessible with the usual . notation? Or should objects *only* allow either readonly access to variables, with all assignments applied only in the class source file? Presumably, identifiers would be looked up thru the local declarations (and method args) then class variables, then finally globals. So it could be reasonable to say that Obj.varname is simply not assignable. Very easy. However, that would make even classes suspicious of themself: class Foo; define Bar; method Baz( ) local other other := expression-yielding-Foo-object other.Bar := 1 # ERROR!!!!! dang other.setBar(1) # works, but ugly end Hence, I would keep away from that and invoke the Gentlecodesters agreement again... With the current Icon runtime, the interpretation of obj.member would actually need to resolve to an internal object just like the pending array (or is it string?) assignments (sorry, my implementation book is at home and it's been 5 years since I last read it anyway). Since obj.field (and indeed obj[index]) could be variously interpreted as rec.field, or class.field, or class.static, or class.method depending in the dynamic type of obj, the . operator in the runtime would need extending so that if the left arg is an object, the field is looked up via the class. If the field is found as a member variable, then it probably could yield an assignable item just like rec.field, but if the field is found to be a method, then it should yield a new variant on the proc - a special block which also records the sender. In theory, it's entirely possible to pass this thing around before using it: mc := obj.method foo(mc) .... procedure foo(mc) x := mc(arg1, arg2) Simply because obj.method needs to have ( ) stuffed on the end before the actual call is applied. In normal practice of course, that is what would usually happen: val := obj.method(arg1, arg2) but the internal implentation is simple and interesting because of it. What else? Inheritance? OK... Sure, multiple inheritance. Circular like Idol? Why not! Very interesting idea and I don't see why the compiler needs to drown in a sea of infinite recursion if decent programmers work on it ;-) What about if two supers have the same super, leading to a diamond structure? class A class B : A class C : A class D : B C What did Idol do? Merge? I don't remember. But Idol is probably a good guide. How's this for an alternative: Since OO is best for large projects, the Eiffel concept of "redefine" and "rename" are very appealing. Not only do these two clauses eliminate most of the anti-multiple inheritance arguments, it also solves a less talked-about problem, where a parent class might be extended by adding a new method or member, which subsequently conflicts silently with a subclass member of the same name. There is responsibility in this direction also... The redefine and rename clauses eliminate the need for messy syntax which is needed to access overridden parent members. If they are overridden they can be made available through a different name so there is no need for nonsense like super::method( ... ). With the rename and redefine clauses, you are expected to know and declare redefinitions. In large projects, that's a very powerful safety feature. How could this work in Objective Icon? The compiler will collect a class definition. An optional list of parent classes might be found, with optional redefine or rename clauses, along with member variables and methods. The compiler would collect all these items in good faith, and build the intermediate code as it does now, assuming that the linker and runtime will make more sense of it all. The linker would then take on a greater role. All the class definitions need to be banged together; insert Tab A into Slot B and so on. At this point, the inheritance trees (graphs) will be constructed. I would propose that each class definition will have a private member list built, so that the runtime system does not need to travel the tree each time a member is accessed. A simple lookup of the member in the objects class will be sufficient to find it's offset within the object and it's type etc. Back to the class traversal: For each class, visit all the parents looking for extra members and methods to attach to the class. Any conflicts which are in violation of the rename and redefine clauses can be found at this time. Therefore the class tree could be shown to be correct by the linker. By this time, everything is resolved, the final .icx is written and we're ready for the real fun to begin. Is that enough? I've proposed something very simple, requiring only a few new internal block types to represent the classes, the objects, and the mutated proc blocks (sender.method). I've relied upon a Gentle-programmers agreement for all the usual fuss about protection, encapsulation etc. Runtime traversals to find methods can be avoided. What about abstract classes and abstract methods? What about them? I suppose they are possible; in fact, a redefine clause without a corresponding method definition will implicitly be an abstract method. Is this any use? I would guess that an abstract method would merely be a null member in the class lookup table. Icon currently supports this (and provides a runtime error) if you attempt a call to a non-existent method. This is probably a very appropriate response for OO too. > 2) Better Interfacing to External Programs > >[SNIP] > > Nevertheless, other languages provide ways of calling external > functions and handling external memory. Why can't Icon have these > abilities? > Why not indeed? Perl's XS facility does a very good job. Of course, the C code must comply. Perl does offer a usable malloc and free which means it's quite easy to link in 3rd party libraries which may not assume they'll be linked into Perl. Icon/XS will need the same respect for 3rd-party libraries. The XS framework generator is a very useful tool for Perl, and points to the need for something similar with Icon. > 3) Unicode Support > Don't care ;-) I guess we should all get into the 21st century sooner or later... > 4) Icon as a Scripting Language > Interesting idea. In principle, some simple hack can already be done using hash-bang lines and possibly a bit of disguised shell-code. Isn't there an icont argument which asks for automatic execution of the resulting object? If there isn't it can surely be added. To do this "properly" on UNIX, the compiler could probably write to a tmp file (not linked into a directory) and then hand the open file handles off to a cooperating iconx which can slurp up the icode from the tmp file handles and then close them, resulting in their deallocation. This is a very simple improvement to the compiler and runner, and I wouldn't really class this as an extension to Icon, because it's more mechanical than anything else. From icon-group-sender Thu Sep 19 12:25:39 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8JJOrY08547 for icon-group-addresses; Thu, 19 Sep 2002 12:24:53 -0700 (MST) Message-Id: <200209191924.g8JJOrY08547@baskerville.CS.Arizona.EDU> Date: Thu, 19 Sep 2002 08:57:54 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Icon as a Scripting Language Errors-To: icon-group-errors@cs.arizona.edu Status: RO > From: "Andrew Hamm" > Date: Thu, 19 Sep 2002 12:57:52 +1000 > > > 4) Icon as a Scripting Language > > Interesting idea. In principle, some simple hack can already be done using > hash-bang lines and possibly a bit of disguised shell-code. Isn't there an > icont argument which asks for automatic execution of the resulting object? > If there isn't it can surely be added. > > To do this "properly" on UNIX, the compiler could probably write to a tmp > file (not linked into a directory) and then hand the open file handles off > to a cooperating iconx which can slurp up the icode from the tmp file > handles and then close them, resulting in their deallocation. This is a very > simple improvement to the compiler and runner, and I wouldn't really class > this as an extension to Icon, because it's more mechanical than anything > else. This feature is present in the current version of Icon for Unix. You can enter "icon foo.icn" to execute an Icon program, or you can make the source file executable and head it with the magic string #!/usr/bin/env icon to run it directly. There is also " icon -P 'program' " for embedding a tiny program in a larger shell script, as is commonly done with "sed". I believe it is done "properly": the current directory doesn't need to be writable (you can run from CD or whatever) and the temporary files are cleaned up afterward. For more details see the new "icon" (not "icont") man page. There's a copy on the web at http://www.cs.arizona.edu/icon/v941/icon.txt --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Mon Sep 23 19:48:10 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8O2lAw02390 for icon-group-addresses; Mon, 23 Sep 2002 19:47:10 -0700 (MST) Message-Id: <200209240247.g8O2lAw02390@baskerville.CS.Arizona.EDU> Date: Fri, 20 Sep 2002 09:07:52 -0400 From: "Steve Graham" To: Subject: Moving from Procedural to Object-Oriented (Was Re: Icon Wish List) Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g8KD8Ww18598 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Andrew's post rings close to home, as my division is considering a move from a procedural language to an object-oriented one. Accepting that on the one hand a LARGE system may benefit from the benefits of the object-oriented approach, while not forgetting that fads occur in all walks of life, including programming, I would appreciate if anyone in this group has seen the benefits vs the costs of moving from procedural to OO. Maybe also the "be sure to avoid" things. For my part, I see the advantage of hiding data and reusing code, but this can be done with structured code and well-crafted libraries. TIA, Steve === >>> "Andrew Hamm" 09/18/02 09:57PM >>> Frank J. Lhota wrote: > Looking over the last several versions of Icon, the last several > versions did little more than adding a few functions and fix a few > bugs. It has been a while since there have been major enhancements to > the Icon language. This type of stagnation harms Icon's long term > prospects. It is time to consider some major upgrades to Icon. > I've been watching this debate with interest (and am heartened by the increase in traffic above zero messages a month...) so here's my $0.04(AU) [current exchange rate is $1.00AU = $0.54US] > 1) Object-Oriented Programming Yes, Idol is very interesting, but I haven't used it in any project, just dabbled. I have used Icon for a few large tools; 3 of them are an essential part of the software development production system in my company. The simplest one is a pre-processor in the style of cpp, which we can use with our 4GL (sql-based) source code. This is a relatively simple process, and objects could have been convenient to store things like the defines and the stack of the pre-processor blocks, however lack of OO did not cause any difficulty. The second major tool is a 4GL code generator. It reads form specification files, accesses the database for table schema, and generates 4GL. Given the large number of source instructions representing screen objects and business rule actions, OO would have been very useful indeed and I did find myself wishing for classes *with methods* to get around my regular confusion as I got deep into nasty expressions which could only exploit . and [ ] operators. Not a few bugs were caused by mistakes with access to deep object members and performing work on them. The 3rd major tool is a source code merger, which reads a bunch of instructions to insert, replace or delete code blocks in the generated 4GL (this allows our programmers to maintain regenerable forms and yet perform powerful modifications to the generated code, to suit the exact business needs). This tool exploits the amazing power of coroutines amongst other things, and I managed to achieve a remarkable O(N) processing time. It's remarkable because I wrote it to replace a 3rd-party tool which slowed quadratically vs code size. This process had middling need for OO but once again exploited the magic of Icon to achieve its task. It's when projects achieve a critical mass that OO becomes a benefit. Any educational sample of OO fails to prove the need for OO IMHO. I still desire OO in Icon and forsee no costs beyond the implementation effort. I really can't see OO degrading Icon; with proper design it should fit in very nicely and elegantly. Apart from the corruption caused by it's pre-processing nature, Idol does show what is possible. With integrated support, the rough edges of Idol could be cleaned up. It's interesting to think about the style of the syntax to use. Given that OO is only really useful for large projects, I would lean towards the "one file, one class" approach, which means that the classes could look like this: # just a suggestion class Foo [ : superclass ... ] define var, var, var ... static classvar, classvar ... constructor Foo( arg ... ) .... end destructor ~Foo( ) # typical destructor stuff end method instanceMethod( arg ... ) ... end static method classMethod( args ) ... end NOTE: use of "constructor", "destructor" and "method" keywords does not denote a preference. Since Icon is completely free with variable types and call arguments, it follows that class members should not be typed, and overloaded methods do not make sense either - one name, one method. A class constructor is obviously needed, and presumably a class destructor too; for the usual application-level cleanups. Due to the nature of Icon garbage collection, the destructor would not be called at any predictable time, but then, people comfortably live with that in Java. There's probably scope for operator overloading. Icon has a decent set of operators, and some tasks benefit from operator overloading - however, people do tend to get very silly trying to squeeze as much as possible into that mould ;) What about member privacy? With the 1 file, 1 class model, it does become possible to add a "private" keyword for class methods, members and statics. If marked as private, the member is not visible outside the file. However, that does not fit at all with the dynamic typing of Icon. How do you know the type of a particular variable at any one time? You don't, so you can't block access to specific fields, unless some sort of runtime check was added to provide the illusion of privacy. Perhaps that's acceptable... If the runtime check was provided, then presumably protected member access could also be fitted. Personally I wouldn't fuss deeply about this. The Perlish idea of the "gentleperson's agreement" works for me. Should member variables be accessible with the usual . notation? Or should objects *only* allow either readonly access to variables, with all assignments applied only in the class source file? Presumably, identifiers would be looked up thru the local declarations (and method args) then class variables, then finally globals. So it could be reasonable to say that Obj.varname is simply not assignable. Very easy. However, that would make even classes suspicious of themself: class Foo; define Bar; method Baz( ) local other other := expression-yielding-Foo-object other.Bar := 1 # ERROR!!!!! dang other.setBar(1) # works, but ugly end Hence, I would keep away from that and invoke the Gentlecodesters agreement again... With the current Icon runtime, the interpretation of obj.member would actually need to resolve to an internal object just like the pending array (or is it string?) assignments (sorry, my implementation book is at home and it's been 5 years since I last read it anyway). Since obj.field (and indeed obj[index]) could be variously interpreted as rec.field, or class.field, or class.static, or class.method depending in the dynamic type of obj, the . operator in the runtime would need extending so that if the left arg is an object, the field is looked up via the class. If the field is found as a member variable, then it probably could yield an assignable item just like rec.field, but if the field is found to be a method, then it should yield a new variant on the proc - a special block which also records the sender. In theory, it's entirely possible to pass this thing around before using it: mc := obj.method foo(mc) .... procedure foo(mc) x := mc(arg1, arg2) Simply because obj.method needs to have ( ) stuffed on the end before the actual call is applied. In normal practice of course, that is what would usually happen: val := obj.method(arg1, arg2) but the internal implentation is simple and interesting because of it. What else? Inheritance? OK... Sure, multiple inheritance. Circular like Idol? Why not! Very interesting idea and I don't see why the compiler needs to drown in a sea of infinite recursion if decent programmers work on it ;-) What about if two supers have the same super, leading to a diamond structure? class A class B : A class C : A class D : B C What did Idol do? Merge? I don't remember. But Idol is probably a good guide. How's this for an alternative: Since OO is best for large projects, the Eiffel concept of "redefine" and "rename" are very appealing. Not only do these two clauses eliminate most of the anti-multiple inheritance arguments, it also solves a less talked-about problem, where a parent class might be extended by adding a new method or member, which subsequently conflicts silently with a subclass member of the same name. There is responsibility in this direction also... The redefine and rename clauses eliminate the need for messy syntax which is needed to access overridden parent members. If they are overridden they can be made available through a different name so there is no need for nonsense like super::method( ... ). With the rename and redefine clauses, you are expected to know and declare redefinitions. In large projects, that's a very powerful safety feature. How could this work in Objective Icon? The compiler will collect a class definition. An optional list of parent classes might be found, with optional redefine or rename clauses, along with member variables and methods. The compiler would collect all these items in good faith, and build the intermediate code as it does now, assuming that the linker and runtime will make more sense of it all. The linker would then take on a greater role. All the class definitions need to be banged together; insert Tab A into Slot B and so on. At this point, the inheritance trees (graphs) will be constructed. I would propose that each class definition will have a private member list built, so that the runtime system does not need to travel the tree each time a member is accessed. A simple lookup of the member in the objects class will be sufficient to find it's offset within the object and it's type etc. Back to the class traversal: For each class, visit all the parents looking for extra members and methods to attach to the class. Any conflicts which are in violation of the rename and redefine clauses can be found at this time. Therefore the class tree could be shown to be correct by the linker. By this time, everything is resolved, the final .icx is written and we're ready for the real fun to begin. Is that enough? I've proposed something very simple, requiring only a few new internal block types to represent the classes, the objects, and the mutated proc blocks (sender.method). I've relied upon a Gentle-programmers agreement for all the usual fuss about protection, encapsulation etc. Runtime traversals to find methods can be avoided. What about abstract classes and abstract methods? What about them? I suppose they are possible; in fact, a redefine clause without a corresponding method definition will implicitly be an abstract method. Is this any use? I would guess that an abstract method would merely be a null member in the class lookup table. Icon currently supports this (and provides a runtime error) if you attempt a call to a non-existent method. This is probably a very appropriate response for OO too. > 2) Better Interfacing to External Programs > >[SNIP] > > Nevertheless, other languages provide ways of calling external > functions and handling external memory. Why can't Icon have these > abilities? > Why not indeed? Perl's XS facility does a very good job. Of course, the C code must comply. Perl does offer a usable malloc and free which means it's quite easy to link in 3rd party libraries which may not assume they'll be linked into Perl. Icon/XS will need the same respect for 3rd-party libraries. The XS framework generator is a very useful tool for Perl, and points to the need for something similar with Icon. > 3) Unicode Support > Don't care ;-) I guess we should all get into the 21st century sooner or later... > 4) Icon as a Scripting Language > Interesting idea. In principle, some simple hack can already be done using hash-bang lines and possibly a bit of disguised shell-code. Isn't there an icont argument which asks for automatic execution of the resulting object? If there isn't it can surely be added. To do this "properly" on UNIX, the compiler could probably write to a tmp file (not linked into a directory) and then hand the open file handles off to a cooperating iconx which can slurp up the icode from the tmp file handles and then close them, resulting in their deallocation. This is a very simple improvement to the compiler and runner, and I wouldn't really class this as an extension to Icon, because it's more mechanical than anything else. From icon-group-sender Tue Sep 24 12:57:43 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8OJvRM28525 for icon-group-addresses; Tue, 24 Sep 2002 12:57:27 -0700 (MST) Message-Id: <200209241957.g8OJvRM28525@baskerville.CS.Arizona.EDU> X-Sent: 24 Sep 2002 18:26:32 GMT X-Sender: nevin@mail.hax.com Date: Tue, 24 Sep 2002 13:26:30 -0500 To: icon-group@cs.arizona.edu From: "Nevin :-] Liber" Subject: Re: Moving from Procedural to Object-Oriented (Was Re: Icon Wish List) Errors-To: icon-group-errors@cs.arizona.edu Status: RO >Andrew's post rings close to home, as my division is considering a >move from a procedural language to an object-oriented one. Good luck. :-) >Accepting that on the one hand a LARGE system may benefit from the >benefits of the object-oriented approach, while not forgetting that >fads occur in all walks of life, including programming, I don't think it is a fad. It is just another tool in the toolbox. > I would appreciate if anyone in this group has seen the benefits vs >the costs of moving from procedural to OO. It is a bit too general a question. It matters which language(s) you are moving between. For instance, if you are moving to C++, you get a number of paradigms to use: inheritance, RAII (Resource Acquisition Is Initialisation) classes (the constructor acquires a resource, and the destructor releases that resource; this works because C++ destructors are called at well-defined times), generic programming (templates), etc. Other languages give you other paradigms. Maybe also the "be sure to avoid" things. Don't use a feature just because it is there; use it because it is appropriate. Not everything needs to be an object (unless your language requires it). Not everything needs to be a deep inheritance tree. Not every type of object needs to be designed for reuse. Etc., etc. When designing objects, try and avoid asking the object questions of the form "what kind are you really"; this doesn't tend to scale. Don't write new stuff procedurally just because your organisation tends to be more comfortable doing so. >For my part, I see the advantage of hiding data and reusing code, >but this can be done with structured code and well-crafted libraries. While certainly true (heck, you can do that in assembler too), the more the language manages implicitly for the programmer, the less buggy your software will be. Lots of bugs in languages like C are due to incorrect memory management (dangling pointers, memory leaks, etc.); languages with garbage collection such as Icon never have those kinds of problems; good discipline in C++ (using things like Smart Pointer idioms, which is an RAII type of class) makes this much easier than in C (not as easy as with GC, but more general, since it can be applied to any type of resource, not just memory). Making it harder for programmers to express mistakes is a Good Thing. There are, of course, development, performance and size penalties for this, which your organisation has to use good engineering judgement on whether the benefit is worth the cost. And there will be a large up front cost, as there tends to be lots of implicit undocumented knowledge in old code bases that (hopefully) ends up being rediscovered (and maybe even documented) in the new code base. But that rediscovery takes time. OO isn't a panacea. It is another way of doing things. It is another approach for expressing a design. -- Nevin ":-)" Liber (773) 961-1620 From icon-group-sender Thu Oct 3 12:38:08 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g93JaTQ07219 for icon-group-addresses; Thu, 3 Oct 2002 12:36:29 -0700 (MST) Message-Id: <200210031936.g93JaTQ07219@baskerville.CS.Arizona.EDU> From: "Sean L. Palmer" X-Newsgroups: comp.lang.icon Subject: icon Date: Thu, 3 Oct 2002 10:20:34 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Is this language completely dead? Is anyone using it for anything? Sean From icon-group-sender Thu Oct 3 13:17:38 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g93KHNs18043 for icon-group-addresses; Thu, 3 Oct 2002 13:17:23 -0700 (MST) Message-Id: <200210032017.g93KHNs18043@baskerville.CS.Arizona.EDU> From: icon-project@cs.arizona.edu X-Newsgroups: comp.lang.icon,comp.answers,news.answers Subject: Icon Programming Language FAQ Date: 3 Oct 2002 10:03:54 -0700 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions about the Icon programming language www.cs.arizona.edu/icon/faq.htm Last updated October 1, 2002 Learning about Icon A1. What is Icon? A2. What is Icon good for? A3. What are Icon's distinguishing characteristics? A4. What is the Icon program library? A5. Where can I learn more about Icon? A6. How about comprehensive documentation? Implementations B1. What platforms support Icon? B2. How do I get started with Icon? B3. Is there a Unicode version of Icon? B4. What happened to the compiler? Administration C1. What is the Icon Project? C2. How often is the on-line material updated? C3. Where did Icon come from? C4. Where is Icon going? Support D1. Is there a users' group for Icon? D2. How do I get technical support? Programming E1. Why doesn't read() work with every? E2. Why doesn't string invocation such as "foo"() work? E3. How can I call a C function? E4. Can I open a bidirectional pipe? _________________________________________________________________ Learning about Icon A1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but with semantics at a much higher level. Icon has a novel expression-evaluation mechanism that integrates goal-directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion: For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. A2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's especially strong at building software tools, for processing text, and for experimental and research applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. Consequently, Icon is used both for short, one-shot tasks and for very complex applications. A3. What are Icon's distinguishing characteristics? * A high-level, general-purpose programming language * Friendly line-oriented syntax (no semicolons needed) * Emphasis on programmer productivity * Usually interpreted * Evolved from programming languages (vs. scripting languages) * Procedural control flow plus generators and goal-directed evaluation * Values have types; variables are typeless, accept any value * Static scoping: global or (procedure) local * Automatic garbage collection * All integers have arbitrary precision * Uses strings (not chars) as basic text datatype * Has lists that function as arrays, queues, and stacks * Also has sets, tables, records (structs), reals (doubles), more * No second-class "primitive types" * Not "object-oriented" (no classes, inheritance, or instance methods) * No exception catching * No concurrency (no threads, monitors, semaphores, or synchronization) * Has co-expressions (coroutines) * Basic least-common-denominator system interface (a la ANSI C) * Procedural graphics (event-driven paradigm available but not mandated) * Retained windows (programs are never called to repaint) * Simple GUI builder that can re-edit its generated code * Turtle graphics package * Large library of contributed procedures and programs A4. What is the Icon program library? The library is a collection of programs and procedures written in Icon. User contributions are welcome and form a significant portion of the library. Library procedures effectively augment the built-in functions available to an Icon program. A wide variety of procedures currently exists, and most graphically-based programs are built around library procedures. The programs in the library range from simple demonstrations to handy tools to complex graphical applications. The library is a resource for both new and experienced programmers. In addition to their basic utility, its programs and procedures serve as examples of how things can be written in Icon. A5. Where can I learn more about Icon? Here are some good places to start. * Ralph Griswold's overview: www.cs.arizona.edu/icon/docs/ipd266.htm * Dave Hanson's introduction: www.cs.arizona.edu/icon/intro.htm * John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon A6. How about comprehensive documentation? Two books specify the Icon language. The core language is covered by The Icon Programming Language (third edition), by Griswold and Griswold. Graphics facilities are described in Graphics Programming in Icon by Griswold, Jeffery, and Townsend. These books contain both tutorial and reference material. They are available from RTC Books (www.rtcbooks.com, search for "Icon") or from Jeffery Systems (www.zianet.com/jeffery/books). Additionally, The Icon Programming Language can be downloaded at no charge from the Icon books page, www.cs.arizona.edu/icon/books.htm. Icon's internals are detailed in The Implementation of the Icon Programming Language by Griswold and Griswold (Princeton, 1986, out of print). Although considerable changes have occurred since Version 6, described in the book, the basic structure is the same. Two technical reports, IPD112 and IPD239, describe subsequent changes. The Icon Programming Language Handbook, by Thomas W. Christopher, is available on the web at www.toolsofcomputing.com/IconHandbook. There is a large amount of additional information at the Icon web site, www.cs.arizona.edu/icon. _________________________________________________________________ Implementations B1. What platforms support Icon? Current implementations with graphics support are available for Unix and Windows. On the Macintosh, the Unix implementation runs under MacOS X, with graphics using XFree86. Older versions of Icon are available for some other systems. An alternative Java-based implementation for Unix, Jcon, is also available. B2. How do I get started with Icon? Version 9.4.1 of Icon for Unix can be downloaded from www.cs.arizona.edu/icon/v941. Source and binary packages are available, each with the complete Icon program library. Version 9.3 of Icon for Windows is compatible at the source level with version 9.4.1. It can be downloaded from www.cs.arizona.edu/icon/v93w.htm. The Version 9.4.1 library can be obtained separately from www.cs.arizona.edu/icon/v941. For older implementations, start at www.cs.arizona.edu/icon/implver.htm. Jcon is at www.cs.arizona.edu/icon/jcon. B3. Is there a Unicode version of Icon? No. Icon is defined in terms of 8-bit characters, and changing this presents several design challenges that would likely break existing programs. Also, modifying the C implementation is probably infeasible, but a Unicode version of Jcon might be possible. B4. What happened to the compiler? For a while, Unix distributions included both an interpreter and a compiler; but the interpreter is is usually fast enough even for production work, and most people found that using the compiler wasn't worth the extra compilation time or the hassles involved. We no longer advertise the compiler or produce binaries for it. It is still part of the source code distribution, and we have not deliberately broken it, but we no longer support it and we cannot offer help if problems arise. _________________________________________________________________ Administration C1. What is the Icon Project? The Icon Project is a name used by the group that distributes and supports the Icon programming language. The project maintains the Icon web site at www.cs.arizona.edu/icon. A non-commercial organization, the project is supported by the Department of Computer Science at the University of Arizona. C2. How often is the on-line material updated? New material is added when it's available. Established implementations usually are updated only when there's a new version. This typically is every year or two. The Icon program library is updated on a similar schedule. C3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 1960s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at the University of Arizona with support from the National Science Foundation. Although it has similar objectives and many similar capabilities, Icon bears little superficial resemblance to SNOBOL4. Icon implementations were developed by faculty, staff, and students at the University of Arizona, with significant contributions from volunteers around the world. An Icon history by Ralph and Madge Griswold appears in the preprints of the second History of Programming Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol 28, No 3). The name Icon is not an acronym, nor does it stand for anything in particular, although the word iconoclastic was mentioned when the name was chosen. The name predates the now common use of icon to refer to small images used in graphical user interfaces. This sometimes misleads people into thinking that that Icon is designed to create or manipulate icons, but there's no good solution to that problem. C4. Where is Icon going? We continue to use Icon on a daily basis, but no significant changes are planned. We expect to support the Unix version for the forseeable future, and to distribute ports to other systems as supplied by volunteers. The Unicon project is developing an object-oriented language based on Icon. For more information, see unicon.sourceforge.net. An earlier object-oriented extension to Icon, Idol, can be found in the Icon program library. _________________________________________________________________ Support D1. Is there a users' group for Icon? There is no official Icon users' group, but The Icon Project maintains a moderated "Icon-group" electronic mailing list. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between Icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list and is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends its announcements and other messages to the mailing list. D2. How do I get technical support? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please use the appropriate resource when you need assistance: * For programming assistance, submit a query to the mailing list or newsgroup (see above). * For porting assistance or Unix problems, contact icon-project@cs.arizona.edu. * For problems with the Windows implementation, contact the implementor, jeffery@cs.nmsu.edu. * For general information and additional documentation, visit the Icon web site: www.cs.arizona.edu/icon. _________________________________________________________________ Programming E1. Why doesn't read() work with every? every s := read() do {...} doesn't loop because read() produces a single value and then fails if resumed. Other "consumer" procedures such as get() and pop() work the same way. Use a while loop with these procedures, and save every for use with generators such as !x or key(T). E2. Why doesn't string invocation such as "foo"() work? String invocation works if the procedure is present; the catch is that the linker removes unreferenced procedures. To ensure a procedure's presence, reference it in the main() procedure. A simple reference suffices, as in refs := [foo, bar, baz]; it's not necessary to actually call it. (Why does the linker remove unreferenced procedures? Because this can save huge amounts of memory for programs that use the library.) E3. How can I call a C function? You can't call an arbitrary C function, but if you're willing to write a function to Icon's specifications, there are two approaches. Under Unix, which provides loadfunc(), you can load one or more functions from a shared library, and then treat them as if they had been written in Icon. Some examples can be found in the cfuncs and packs/loadfuncs directories of the Icon program library. The more cumbersome approach is to add code to the Icon interpreter and rebuild it; some hooks are provided for this purpose. Both approaches are discussed in Calling C Functions from Icon, www.cs.arizona.edu/icon/docs/ipd240.htm. The Jcon implementation allows Icon programs to call Java code that is written to Jcon specifications. E4. Can I open a bidirectional pipe? No, this is not possible. Although the concept is simple -- write a line to a program via a pipe, then read that program's output -- it probably wouldn't work. Most I/O libraries don't write anything to a pipe until they've filled a buffer, and the most likely consequence would be a deadlock, with each program waiting for the other to send more data. _________________________________________________________________ This FAQ is edited by Gregg Townsend. It includes contributions from Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd Proebsting. From icon-group-sender Thu Oct 3 13:18:48 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g93KIjo20791 for icon-group-addresses; Thu, 3 Oct 2002 13:18:45 -0700 (MST) Message-Id: <200210032018.g93KIjo20791@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Re: icon X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Thu, 03 Oct 2002 18:30:18 GMT X-Complaints-To: abuse@verizon.net To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO I still use Icon for code analysis / generation. I must admit there are times where it feels like I'm the world's last Icon programmer. From icon-group-sender Thu Oct 3 13:25:38 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g93KPY600748 for icon-group-addresses; Thu, 3 Oct 2002 13:25:34 -0700 (MST) Message-Id: <200210032025.g93KPY600748@baskerville.CS.Arizona.EDU> Date: Thu, 03 Oct 2002 16:02:52 -0400 From: "Steve Graham" To: Subject: Re: icon Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g93K3Sw08039 Errors-To: icon-group-errors@cs.arizona.edu Status: RO No. Yes, personally I use it for utilities and used it in a recent programming competition. >>> "Sean L. Palmer" 10/03/02 12:20PM >>> Is this language completely dead? Is anyone using it for anything? Sean From icon-group-sender Fri Oct 4 07:36:46 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94EaRE12986 for icon-group-addresses; Fri, 4 Oct 2002 07:36:28 -0700 (MST) Message-Id: <200210041436.g94EaRE12986@baskerville.CS.Arizona.EDU> Date: Thu, 3 Oct 2002 22:21:13 -0300 (ADT) From: Larry Bezeau To: icon-group@cs.arizona.edu Subject: Icon use in the common gateway interface Errors-To: icon-group-errors@cs.arizona.edu Status: RO I use Icon to write CGI programs. If you wish to take a multiple choice quiz that is formatted and marked by Icon programs (actually Unicon) go to http://www.unb.ca/education/ed3051/multcho.html and try one of the quizzes listed on that page. Larry Bezeau@UNB.Ca From icon-group-sender Fri Oct 4 07:37:48 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94Ebk213108 for icon-group-addresses; Fri, 4 Oct 2002 07:37:46 -0700 (MST) Message-Id: <200210041437.g94Ebk213108@baskerville.CS.Arizona.EDU> Date: Thu, 03 Oct 2002 23:17:50 -0400 From: Brian Clausing X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: icon X-Complaints-To: abuse@erinet.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Frank J. Lhota" wrote: > > I still use Icon for code analysis / generation. I must admit there are > times where it feels like I'm the world's last Icon programmer. It's a superior tool for many purposes, and it is being used commercially. I'm told that one reason it was selected for commercial work is that Icon programs are 5-10 times smaller than their counterparts in popular programming languages. The Icon system, which one seemed to be large, now looks small in comparison to the huge memories and elephantine applications of the present day. Much programming these days involves handling text, and a great number of programs are interpreted. Griswold and colleagues have created a coherent and powerful system in Icon. And the source doesn't look like line noise. From icon-group-sender Fri Oct 4 07:38:07 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94Ec5E13146 for icon-group-addresses; Fri, 4 Oct 2002 07:38:05 -0700 (MST) Message-Id: <200210041438.g94Ec5E13146@baskerville.CS.Arizona.EDU> From: "Jan A. Staecker" To: "'Frank J. Lhota'" Cc: Subject: AW: icon Date: Fri, 4 Oct 2002 07:11:17 +0200 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 04 Oct 2002 05:09:06.0603 (UTC) FILETIME=[2A0A87B0:01C26B64] X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g9459Jw19902 Errors-To: icon-group-errors@cs.arizona.edu Status: RO I would like to reuse it again, but I am waiting for a .NET version. (Perhaps in 1-2 years?) I used it 10 years ago - but I think it is still a very good language. Bye Dipl. Phys. Jan Staecker PS: If there is a .NET version I' am interested here in Germany to do some articles or talks on it. > -----Ursprüngliche Nachricht----- > Von: Frank J. Lhota [mailto:NOSPAM.lhota.adarose@verizon.net] > Gesendet: Donnerstag, 3. Oktober 2002 20:30 > An: icon-group@CS.Arizona.EDU > Betreff: Re: icon > > > I still use Icon for code analysis / generation. I must admit > there are times where it feels like I'm the world's last Icon > programmer. > > > > From icon-group-sender Fri Oct 4 07:38:19 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94EcGk13187 for icon-group-addresses; Fri, 4 Oct 2002 07:38:16 -0700 (MST) Message-Id: <200210041438.g94EcGk13187@baskerville.CS.Arizona.EDU> From: "Shmuel (Seymour J.) Metz" X-Newsgroups: comp.lang.icon Subject: Re: icon Date: Fri, 04 Oct 2002 01:25:27 -0400 Mail-Copies-To: nobody X-Cise: tanbanso@iinet.net.au X-CompuServe-Customer: Yes X-Coriate: admin@interspeed.co.nz X-Ecrate: tanandtanlawyers.com X-Punge: Micro$oft X-Sanguinate: themvsguy@email.com X-Terminate: SPA(GIS) X-Tinguish: Mark Griffith X-Treme: C&C,DWS X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In <3d9c7b7d$1_2@nopics.sjc>, on 10/03/2002 at 10:20 AM, "Sean L. Palmer" said: >Is this language completely dead? No. >Is anyone using it for anything? Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Fri Oct 4 07:38:42 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94Ecds13221 for icon-group-addresses; Fri, 4 Oct 2002 07:38:39 -0700 (MST) Message-Id: <200210041438.g94Ecds13221@baskerville.CS.Arizona.EDU> From: "Shmuel (Seymour J.) Metz" X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Fri, 04 Oct 2002 01:24:49 -0400 Mail-Copies-To: nobody X-Cise: tanbanso@iinet.net.au X-CompuServe-Customer: Yes X-Coriate: admin@interspeed.co.nz X-Ecrate: tanandtanlawyers.com X-Punge: Micro$oft X-Sanguinate: themvsguy@email.com X-Terminate: SPA(GIS) X-Tinguish: Mark Griffith X-Treme: C&C,DWS X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In , on 09/19/2002 at 12:57 PM, "Andrew Hamm" said: >Since Icon is completely free with variable types and call arguments, >it follows that class members should not be typed, No. The class is the type. >and overloaded methods do >not make sense either They make perfect sense if you allow subclasses and such. >one name, one method Too restrictive, and destroys some of the value of OO programming. >What about member privacy? With the 1 file, 1 class model, it does >become possible to add a "private" keyword for class methods, >members and statics. If marked as private, the member is not visible >outside the file. However, that does not fit at all with the dynamic >typing of Icon. Yes it does. Don't confuse the scope of the name with the lifetime of the object. >However, >that does not fit at all with the dynamic typing of Icon. It fits in perfectly. All that changes is that there are more possible types. >How do you know the type of a particular variable at any one time? The same way as in any other language with dynamic types. >To do this "properly" on UNIX, the compiler could probably write to >a tmp file (not linked into a directory) and then hand the open file >handles off to a cooperating iconx which can slurp up the icode from >the tmp file handles and then close them, resulting in their >deallocation. Bletch! -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Fri Oct 4 07:39:03 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94Ed0E13258 for icon-group-addresses; Fri, 4 Oct 2002 07:39:00 -0700 (MST) Message-Id: <200210041439.g94Ed0E13258@baskerville.CS.Arizona.EDU> X-Newsreader: knews 1.0b.1 From: rtr@blueyonder.co.uk (Robby) Subject: Re: icon X-Newsgroups: comp.lang.icon Date: Fri, 04 Oct 2002 09:48:57 GMT X-Complaints-To: abuse@blueyonder.co.uk To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Yeah, I use it for all kinds of little proglets. I absolutely hate perl, this makes Icon my favorite language for anything script like. I have never used Icon to write anything bigger than 200 LOC though. Robby -- I'd rather write programs that write programs than write programs. R. Sites From icon-group-sender Fri Oct 4 07:39:23 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94EdKM13297 for icon-group-addresses; Fri, 4 Oct 2002 07:39:20 -0700 (MST) Message-Id: <200210041439.g94EdKM13297@baskerville.CS.Arizona.EDU> From: "Boulet, Dan" To: "'Sean L. Palmer'" , icon-group@cs.arizona.edu Subject: RE: icon Date: Fri, 4 Oct 2002 07:21:35 -0400 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Yes, I use it quite a bit. I've written quite a few text tools and a program to audit software installation on our test bed. I originally developed this application using the AWK scripting language but abandoned that in favour of Icon. Regards, Daniel J. Boulet NAV CANADA Systems Test Specialist C113-4 (613) 248-7221 From icon-group-sender Fri Oct 4 07:39:54 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94EdqY13368 for icon-group-addresses; Fri, 4 Oct 2002 07:39:52 -0700 (MST) Message-Id: <200210041439.g94EdqY13368@baskerville.CS.Arizona.EDU> X-Sender: dnaugler@semovm.semo.edu Date: Fri, 04 Oct 2002 07:38:45 -0500 To: icon-group@cs.arizona.edu From: David Naugler Subject: Re: icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO Icon is one of the languages I often teach in a Programming Languages class. My current combination (Smalltalk/Icon/SML) is a nice contrast to the C/C++/Java that is all most my students would otherwise see. Icon is a really nice language and serves well pedagogically. Although I don't believe that Icon needs to be object oriented like "everything" else (I'm a fan of OO, but there are other important valid approaches), I think Unicon might tempt more programmers to discover the joys of Icon. At 10:20 AM 10/3/2002 -0700, Sean L. Palmer wrote: >Is this language completely dead? > >Is anyone using it for anything? > >Sean From icon-group-sender Fri Oct 4 12:29:24 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94JT5E11004 for icon-group-addresses; Fri, 4 Oct 2002 12:29:05 -0700 (MST) Message-Id: <200210041929.g94JT5E11004@baskerville.CS.Arizona.EDU> Subject: Re: icon To: icon-group@cs.arizona.edu From: Chris.D.Tenaglia@jci.com Date: Fri, 4 Oct 2002 10:10:19 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.9a |January 7, 2002) at 10/04/2002 10:10:25 AM Errors-To: icon-group-errors@cs.arizona.edu Status: RO It's my favorite programming language also. I tried pushing it as a universal scripting language. But the perl hacks would contend the same for their tool. So I use posix shell for scripting simple stuff, 90%. Then I use Icon as a specialty tool if the app uses: o X-windows o Sets and boolean operations o CGI parsing Most use is on unix, but some on DOS and VAX/VMS. Wish there was a port for Alpha/VMS. I could not get it to compile "as is" there. ----- Forwarded by Chris D Tenaglia/CORP/Johnson_Controls on 10/04/2002 10:03 AM ----- clausing@voyager .net To: icon-group@CS.Arizona.EDU cc: 10/03/2002 10:17 Subject: Re: icon PM "Frank J. Lhota" wrote: > > I still use Icon for code analysis / generation. I must admit there are > times where it feels like I'm the world's last Icon programmer. It's a superior tool for many purposes, and it is being used commercially. I'm told that one reason it was selected for commercial work is that Icon programs are 5-10 times smaller than their counterparts in popular programming languages. The Icon system, which one seemed to be large, now looks small in comparison to the huge memories and elephantine applications of the present day. Much programming these days involves handling text, and a great number of programs are interpreted. Griswold and colleagues have created a coherent and powerful system in Icon. And the source doesn't look like line noise. From icon-group-sender Fri Oct 4 12:30:10 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94JU7w11408 for icon-group-addresses; Fri, 4 Oct 2002 12:30:07 -0700 (MST) Message-Id: <200210041930.g94JU7w11408@baskerville.CS.Arizona.EDU> From: Andrew Shi-hwa Chen X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Fri, 04 Oct 2002 11:30:47 -0400 X-Accept-Language: en To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO This is a multi-part message in MIME format. --------------BD999B6AED3EAC0F935360F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This sounds like how OO is done in LPC, which isn't really bad at all. I rather like the one-file one-class model myself, but a big problem with it is reloading if the file changes. Also, another big problem with it is if people with Java backgrounds start using Icon, they'll want all sorts of classes for all sorts of things (listeners, adaptors, interfaces, etc...) and the code will bloat to the point where Icon will look like a much more complicated Java. I would recommend subclassing that's single-inheritence and inferred from directory structure. A directory with a class of the same name in it would be the parent class, child classes would have different names (but in the same directory), grand children would be in a subdirectory, etc.... Having both a file with a name (say "foo") and a directory with that name and a file with that name in it (say "foo" with "foo" in it) would be an error. Why this way? 1) The file browser doubles as a class browser. 2) It promotes the use of class clusters a la Objective-C. 3) Similar to Java packages, it makes for a very clean and easy to understand namespace organization. But I would highly recommend against creating any kind of standard class library or anything like that. Don't force OO on people that don't want it - let them continue to use it as a scripting language if they want to (a la Python) - let them code anything (GUI apps, etc...) without needing to subclass this or that or whatever. "Shmuel (Seymour J.) Metz" wrote: > > In , on 09/19/2002 > at 12:57 PM, "Andrew Hamm" said: > > >Since Icon is completely free with variable types and call arguments, > >it follows that class members should not be typed, > > No. The class is the type. > > >and overloaded methods do > >not make sense either > > They make perfect sense if you allow subclasses and such. > > >one name, one method > > Too restrictive, and destroys some of the value of OO programming. > > >What about member privacy? With the 1 file, 1 class model, it does > >become possible to add a "private" keyword for class methods, > >members and statics. If marked as private, the member is not visible > >outside the file. However, that does not fit at all with the dynamic > >typing of Icon. > > Yes it does. Don't confuse the scope of the name with the lifetime of > the object. > > >However, > >that does not fit at all with the dynamic typing of Icon. > > It fits in perfectly. All that changes is that there are more possible > types. > > >How do you know the type of a particular variable at any one time? > > The same way as in any other language with dynamic types. > > >To do this "properly" on UNIX, the compiler could probably write to > >a tmp file (not linked into a directory) and then hand the open file > >handles off to a cooperating iconx which can slurp up the icode from > >the tmp file handles and then close them, resulting in their > >deallocation. > > Bletch! -- Andrew Chen --------------BD999B6AED3EAC0F935360F4 Content-Type: text/x-vcard; charset=us-ascii; name="chenandr.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Andrew Shi-hwa Chen Content-Disposition: attachment; filename="chenandr.vcf" begin:vcard n:Chen;Andrew x-mozilla-html:FALSE url:http://www.cse.msu.edu/~chenandr/ org:Michigan State University;Computer Science and Engineering version:2.1 email;internet:chenandr@cse.msu.edu title:Teaching Assistant adr;quoted-printable:;;3315 Engineering Building=0D=0Ac/o Computer Science Department;East Lansing;Michigan;48825;USA x-mozilla-cpt:;0 fn:Andrew Chen end:vcard --------------BD999B6AED3EAC0F935360F4-- From icon-group-sender Fri Oct 4 12:30:25 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94JUNU11523 for icon-group-addresses; Fri, 4 Oct 2002 12:30:23 -0700 (MST) Message-Id: <200210041930.g94JUNU11523@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: "'Brian Clausing'" , "'icon-group@cs.arizona.edu'" Subject: Commercial use (RE: icon) - where to go FFI? Date: Fri, 4 Oct 2002 10:41:06 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Where can one learn more about where and how Icon is being used commercially? Since Icon programs are 5-10 times shorter, I suppose that they should be cheaper to produce - I'm interested to know if anyone has done analysis to support my supposition. -----Original Message----- From: Brian Clausing [mailto:clausing@voyager.net] Sent: Thursday, October 03, 2002 10:18 PM To: icon-group@CS.Arizona.EDU Subject: Re: icon "Frank J. Lhota" wrote: > > I still use Icon for code analysis / generation. I must admit there are > times where it feels like I'm the world's last Icon programmer. It's a superior tool for many purposes, and it is being used commercially. I'm told that one reason it was selected for commercial work is that Icon programs are 5-10 times smaller than their counterparts in popular programming languages. The Icon system, which one seemed to be large, now looks small in comparison to the huge memories and elephantine applications of the present day. Much programming these days involves handling text, and a great number of programs are interpreted. Griswold and colleagues have created a coherent and powerful system in Icon. And the source doesn't look like line noise. From icon-group-sender Fri Oct 4 12:30:58 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94JUtY11864 for icon-group-addresses; Fri, 4 Oct 2002 12:30:55 -0700 (MST) Message-Id: <200210041930.g94JUtY11864@baskerville.CS.Arizona.EDU> Date: Fri, 4 Oct 2002 11:22:49 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Icon implementation book now available by download Errors-To: icon-group-errors@cs.arizona.edu Status: RO The Implementation of the Icon Programming Language, by Ralph and Madge Griswold, has been out of print and hard to find. Princeton University Press has reverted the rights to the authors; Ralph has scanned the pages and they are now available for free downloading. Both 1-up and 2-up versions can be downloaded from http://www.cs.arizona.edu/icon/ibsale.htm --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Mon Oct 7 07:50:30 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g97EmBs18991 for icon-group-addresses; Mon, 7 Oct 2002 07:48:11 -0700 (MST) Message-Id: <200210071448.g97EmBs18991@baskerville.CS.Arizona.EDU> Date: Sat, 5 Oct 2002 11:40:20 -0700 From: Mark Kot To: icon-group@cs.arizona.edu Subject: Re: icon Mail-Followup-To: icon-group@CS.Arizona.EDU Content-Disposition: inline User-Agent: Mutt/1.4i Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Thu, Oct 03, 2002 at 10:20:34AM -0700, Sean L. Palmer wrote: > Is this language completely dead? > > Is anyone using it for anything? > > Sean > > Icon is my main andy most certainly my favorite programming language. (I used to program in Fortran and then in C.) Some of my most enjoyable Icon pro- grams from the last year or two include: (1) ibird Ibird is a bird information program that provides easy access to photographs, songs, range maps, species accounts, and taxonomic information for the birds of North America. (2) iref Iref is a suite of programs to handle biblio- graphic information. I use these programs as cus- tomized or enhanced replacements for refer, addbib, and other troff/groff programs. (3) tric Tric an icon troff graphics preprocessor that I use as a replacement for grap. This one was fun. tric extracts and runs icon programs that I embed in my troff/groff documents. The programs use a library module to generate the pic graphics com- mands that troff/groff understands. Tric then embeds these pic commands back into the document and pipes the output to groff. (4) iconcise Iconcise is a program to look for verbose or trite phrases in my writing (5) izipf Izipf is a suite of programs that I wrote to ana- lyze the diversity of postings to newsgroups. Some of the programs analyze header information from archived newsgroups. Other programs simulate the growth and evolution of newsgroups using sim- ple stochastic processes. (The resulting analyses can be seen in an article, ``Zipf's law and the diversity of biology newsgroups'', that will be coming out in the journal Scientometrics early in 2003). Mark Kot From icon-group-sender Mon Oct 7 12:24:39 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g97JOB615819 for icon-group-addresses; Mon, 7 Oct 2002 12:24:11 -0700 (MST) Message-Id: <200210071924.g97JOB615819@baskerville.CS.Arizona.EDU> Date: Mon, 7 Oct 2002 10:56:49 -0400 (EDT) From: Taybin Rutkin X-Sender: trutkin@planck.clarku.edu To: Mark Kot cc: icon-group@cs.arizona.edu Subject: Re: icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Sat, 5 Oct 2002, Mark Kot wrote: > (4) iconcise > > Iconcise is a program to look for verbose or trite > phrases in my writing How does this work? It looks for sentences over and under a certain length? > (5) izipf > > Izipf is a suite of programs that I wrote to ana- > lyze the diversity of postings to newsgroups. > Some of the programs analyze header information > from archived newsgroups. Other programs simulate > the growth and evolution of newsgroups using sim- > ple stochastic processes. (The resulting analyses > can be seen in an article, ``Zipf's law and the > diversity of biology newsgroups'', that will be > coming out in the journal Scientometrics early in > 2003). Is this like the above program, but run on USENET and with a history mechanism? Taybin -- http://www.piratesvsninjas.com From icon-group-sender Mon Oct 7 12:25:07 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g97JP3o16054 for icon-group-addresses; Mon, 7 Oct 2002 12:25:03 -0700 (MST) Message-Id: <200210071925.g97JP3o16054@baskerville.CS.Arizona.EDU> From: "Shmuel (Seymour J.) Metz" X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Mon, 07 Oct 2002 12:24:15 -0400 Mail-Copies-To: nobody X-Cise: tanbanso@iinet.net.au X-CompuServe-Customer: Yes X-Coriate: admin@interspeed.co.nz X-Ecrate: tanandtanlawyers.com X-Punge: Micro$oft X-Sanguinate: themvsguy@email.com X-Terminate: SPA(GIS) X-Tinguish: Mark Griffith X-Treme: C&C,DWS X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In <3D9DB427.6CFE2F61@cse.msu.edu>, on 10/04/2002 at 11:30 AM, Andrew Shi-hwa Chen said: >I would recommend subclassing that's single-inheritence and inferred >from directory structure. Too confusing and unwieldy; I'd rather have the relationships included as part of the source text. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Mon Oct 7 16:25:42 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g97NPGQ26268 for icon-group-addresses; Mon, 7 Oct 2002 16:25:16 -0700 (MST) Message-Id: <200210072325.g97NPGQ26268@baskerville.CS.Arizona.EDU> Date: Mon, 7 Oct 2002 12:51:48 -0700 (PDT) From: Mark Kot Subject: Re: icon To: trutkin@physics.clarku.edu Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO >Date: Mon, 7 Oct 2002 10:56:49 -0400 (EDT) >From: Taybin Rutkin >X-Sender: trutkin@planck.clarku.edu >To: Mark Kot >cc: icon-group@CS.Arizona.EDU >Subject: Re: icon > >On Sat, 5 Oct 2002, Mark Kot wrote: > >> (4) iconcise >> >> Iconcise is a program to look for verbose or trite >> phrases in my writing > >How does this work? It looks for sentences over and under a certain >length? iconcise is actually based on a handbook of common verbose phrases that also recommends substitutions. I haven't posted the program for the simple reason that I don't want to cross over from ``fair use'' to copyright infringement (since the program, in effect, implements the book). What makes Icon handy for this program is (a) generators and (b) nice easy-to-use structures. Generators allow one to quickly generate all of the manifestations of verbose phrases. Basicly, the program consists of many lines like every insert(T, "by " || ("itself"|"themselves"), ["alone"]) every insert(T, ("don't"|"didn't") || " pay attention to", ["ignore"]) or even longer lines like every insert(T, ("declining"|"decreasing"|"diminishing"|"dwindling") || " " || ("number"|"quantity"), ["decreasingly", "few", "fewer and fewer"]) that create table elements with the bad phrase as the key and a list of possible substitutions as the corresponding table elements. The program also creates a set of verbose phrases (SVP): SVP := set() every insert(SVP, key(T)) The program generates sentences from the input (see sentence from senten1 in the Icon library), creates all of the multiword substrings in each sentence, and checks whether these substrings are members in the set. If the the phrase is in the set it uses the table to make suggestions. The program proceeds sentence by sentence. It sounds complicated, but it actually exectutes quite quickly. Indeed, it seems instantaneous (but that may say something about the number of verbose phrases in my writing). Mark >> (5) izipf >> >> Izipf is a suite of programs that I wrote to ana- >> lyze the diversity of postings to newsgroups. >> Some of the programs analyze header information >> from archived newsgroups. Other programs simulate >> the growth and evolution of newsgroups using sim- >> ple stochastic processes. (The resulting analyses >> can be seen in an article, ``Zipf's law and the >> diversity of biology newsgroups'', that will be >> coming out in the journal Scientometrics early in >> 2003). > >Is this like the above program, but run on USENET and with a history >mechanism? > >Taybin >-- >http://www.piratesvsninjas.com > > From icon-group-sender Mon Oct 7 16:34:03 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g97NXuk29782 for icon-group-addresses; Mon, 7 Oct 2002 16:33:56 -0700 (MST) Message-Id: <200210072333.g97NXuk29782@baskerville.CS.Arizona.EDU> Date: Mon, 7 Oct 2002 18:10:14 -0400 (EDT) From: Taybin Rutkin X-Sender: trutkin@planck.clarku.edu To: Mark Kot cc: icon-group@cs.arizona.edu Subject: Re: icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Mon, 7 Oct 2002, Mark Kot wrote: > iconcise is actually based on a handbook of common > verbose phrases that also recommends substitutions. > I haven't posted the program for the simple reason > that I don't want to cross over from ``fair use'' > to copyright infringement (since the program, in > effect, implements the book). And what about izipf? Is that this program but with USENET connectivity and a history mechanism of some sort? Taybin -- http://www.piratesvsninjas.com From icon-group-sender Tue Oct 8 07:39:26 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g98EdAA28643 for icon-group-addresses; Tue, 8 Oct 2002 07:39:10 -0700 (MST) Message-Id: <200210081439.g98EdAA28643@baskerville.CS.Arizona.EDU> Date: Mon, 7 Oct 2002 16:41:19 -0700 (PDT) From: Mark Kot Subject: Re: icon To: trutkin@physics.clarku.edu Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO >Date: Mon, 7 Oct 2002 18:10:14 -0400 (EDT) >From: Taybin Rutkin >X-Sender: trutkin@planck.clarku.edu >To: Mark Kot >cc: icon-group@CS.Arizona.EDU >Subject: Re: icon >MIME-Version: 1.0 > >On Mon, 7 Oct 2002, Mark Kot wrote: > >> iconcise is actually based on a handbook of common >> verbose phrases that also recommends substitutions. >> I haven't posted the program for the simple reason >> that I don't want to cross over from ``fair use'' >> to copyright infringement (since the program, in >> effect, implements the book). > >And what about izipf? Is that this program but with USENET connectivity >and a history mechanism of some sort? > >Taybin >-- >http://www.piratesvsninjas.com > No, izipf is rather different. It's actually a whole suite of programs. (My colleagues and I were trying to work out the community ecology of newsgroups.) The original program was irank. The program takes archived newsgroups (it also works on email spools), looks for the ``From:'' line and finds the ID of the sender. It then tallies the number posts from each poster and ranks the posters. We use this program to generate frequency-rank or rank abundance distributions. Here's the code (are we allowed to post code ?): ######################################################### ##### PROGRAM: irank.icn ##### CREATED: 01/05/2001 ##### REVISED: 01/05/2001 ##### PURPOSE: TALLY AND RANK SOURCES ##### TRY TAG FIRST ##### IF TAG FAILS USE FULL FROM ######################################################### link strings procedure main(clargs) infile := open(clargs[1]) | &input sources := table(0) while line := read(infile) do line ? { if="From: " then { address := map(tab(0)) tags := 0 every word := words(address, ' <>\t\r\n\v\f') do word ? { if name := tab(find("@")) then { tags +:= 1 sources[name] +:= 1 break } } if tags = 0 then sources[address] +:= 1 } } ranked := sort(sources, 2) every i := 1 to *ranked do write(i, "\t", ranked[*ranked-i+1][2]) end Amazingly, the rank abundance distribution for most newsgroups follows Zipf's law. As I said, there is a whole suite of programs (most of which may not mean much): aclass aclass (1) - izipf program to generate an abundance class distribution bs_a bs_a (1) - izipf program to fit a broken-stick series bs_ra bs_ra (1) - izipf program to generate broken-stick rank-abundance distribution bs_s bs_s (1) - izipf program to generate broken-stick spectrum cofdet cofdet (1) - izipf program to run regressions on many newsgroups correlate correlate (1) - izipf program for predicted and actual slopes for many newsgroups counts counts (1) - izipf program to determine newsgroup parameters from irank output eslope eslope (1) - izipf program for following slopes in a simulation getdata getdata (1) - izipf program to fetch newsgroup headers from archive ichi ichi (1) - izipf program for goodness 0f fit to Simon's Yule distribution iksimon iksimon (1) - izipf KS test for fit to Simon model iksimons iksimons (1) - izipf KS test for fit to Simon model iksmspectra iksmspectra (1) - izipf KS test of many real and simulated spectra for many newsgroups ikspectra ikspectra (1) - izipf KS test of one real and simulated spectrum for many newsgroups ikspectrum ikspectrum (1) - izipf KS test of real and simulated spectra inamerank inamerank (1) - izipf program to rank, tally, and name posters inew inew (1) - izipf program to determine posters as a function of posts inumber inumber (1) - izipf program to assign a poster number to each post irank irank (1) - izipf program to produce rank-frequency distribution itagless itagless (1) - izipf program to find tagless headers logs_a logs_a (1) - izipf program to fit a logarithmics series logs_ra logs_ra (1) - izipf program to generate a logarithmic series rank-abundance distribution logs_s logs_s (1) - izipf program to generate logarithmic spectrum param param (1) - izipf program to determine newsgroup parameters params params (1) - izipf program to determine parameters for many newsgroups simon_says simon_says (1) - izipf program to generate Simon's Yule distribution simulate simulate (1) - izipf program to plot real and simulated rank-abundance distributions for all newsgroups spectrum spectrum (1) - izipf program to generate frequency spectrum sw sw (1) - izipf program to compute Shannon-Weaver diversity index from irank input tagnumbers tagnumbers (1) - izipf program to count and classify tags for many newsgroups theory theory (1) - izipf program to predict slopes of Gunther process That's probably more than you wanted to know. Mark From icon-group-sender Tue Oct 8 13:13:31 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g98KCPY27292 for icon-group-addresses; Tue, 8 Oct 2002 13:12:25 -0700 (MST) Message-Id: <200210082012.g98KCPY27292@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: A Better Reverse / Map Example X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Tue, 08 Oct 2002 18:20:22 GMT X-Complaints-To: abuse@verizon.net To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The book "The Icon Programming Language" has an important chapter called "Mappings and Labelings". The major thrust of the chapter is that the predefined map function can quickly perform a variety of transpositions. To illustrate, an example of how map could be used to implement the reverse function as a procedure. One of the limitations of the map technique is that the number of characters that can be transported is limited by the number of 8-bit characters, namely 256. The procedure version of reverse must therefore break up strings longer than 256 into pieces of at most 256 characters, reverse them, and put them together. In the example in the book, this is done by recursion. This use of recursion strikes me as somewhat awkward. As an alternative approach, I would decompose long strings into 256 character pieces using reverse string scanning, i.e. we scan the string, and start the scanning by moving to the right end of the string. We then use move with a negative argument to chop the string into pieces small enough to map. The technique is illustrated here: ############################################################################ #### procedure reverse(s) local result static trans, labels, max initial { # Set up labels, trans, max for short reverse mappings labels := "ab" trans := "ba" max := *labels # use this to bootstrap to 256 character mappings trans := reverse( result := string(&cset) ) labels := result max := *labels } s ? { tab( 0 ) result := "" while result ||:= map( trans, labels, move( -max ) ) if ( s := tab( 1 ) ) >> "" then result ||:= map( right( trans, *s ), left ( labels, *s ), s ) } return result end From icon-group-sender Mon Oct 14 07:49:46 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9EEm9w06924 for icon-group-addresses; Mon, 14 Oct 2002 07:48:09 -0700 (MST) Message-Id: <200210141448.g9EEm9w06924@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Sun, 13 Oct 2002 00:46:52 +1000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Shmuel (Seymour J.) Metz wrote: > [STUFF] > I don't think you've understood what I've said. Perhaps I'm not using the correct terminology... let me deal with your points one by one. >> Since Icon is completely free with variable types and call arguments, >> it follows that class members should not be typed, > > No. The class is the type. > look at this: procedure thing(arg) local lcl to me, "arg" and "lcl" are variables; the dynamically allocated objects which they may refer to at any point during execution have type (traditional Icon types being string, numerics, tables etc), but "arg" and "lcl" do not have a declared type. Of course the allocated objects will have type; as you say, the class will be the type of the allocated object currently referred to by arg or lcl, but still, "arg" and "lcl" do not have a declared type and it is contrary to the current design of Icon to declare type for these variables - ie the named variables. Clearly the referred objects will have class type. It does violence to Icon to suggest that variables be declared with type, such as: local lcl: someClass and to me, it follows that class members should not be declared with type either. Neither should method arguments.... read on. >> and overloaded methods do >> not make sense either > > They make perfect sense if you allow subclasses and such. > I said "overloaded" not "overridden". An example of an overloaded method is: class ClassA { draw(int x, int y); draw(Coord xy); } Now, objects of type ClassA may have these two calls made: anA.draw(10, 20); or anA.draw(new Coord(10, 20)); // or equivalent Here, the draw method is "overloaded" within the class to support different calls providing that the argument signatures are sufficiently unambiguous within the language rules. In languages supporting overloaded methods, they require the argument type and possibly the return type to be declared for the methods, and the "signatures" of the methods must be sufficiently distinct to allow the compiler to choose the correct method when it knows the count and types of all the values being provided to the method call. Since Icon supports untyped arguments, default null values for unprovided arguments, quiet discarding of excess arguments and finally explicit variable argument lists with the trailing arg[] syntax, it follows that Object Icon would most naturally support one method of one name *per class* with normal Icon-style argument declaration and invocation. However I am not saying that Object Icon should prevent *overriding* of methods in sub-classes. I thought my discussion clearly showed cognisance of sub-classes and *overridden* methods. >> one name, one method > > Too restrictive, and destroys some of the value of OO programming. > No, it doesn't. Icon currently supports variable argument lists in procedure calls, and it's a common technique to detect the differing arguments provided and perform a variant action depending on the arguments passed. Further, any method which cared to handle different args differently can easily examine the type of the arguments and choose to interpret them appropriately. For example, C++ might require you to declare draw(int x, int y) { .... } and draw(xy Coord) { .... } but Object Icon can easily be coded to detect the types of the args and deal with it accordingly. eg procedure draw(x, y) if numeric(\x) & numeric(\y) then .... else if type(x) == "Coord" & /y then .... else OK, so that sample is not perfect, but a few minutes of real thought would make it most usable. Sample given for illustration only. >> What about member privacy? With the 1 file, 1 class model, it does >> become possible to add a "private" keyword for class methods, >> members and statics. If marked as private, the member is not visible >> outside the file. However, that does not fit at all with the dynamic >> typing of Icon. > > Yes it does. Don't confuse the scope of the name with the lifetime of > the object. > Well, no it doesn't. You need to consider how it might be implemented. If ClassA declared a private member M, but ClassB declared a public member M, consider this situation: class ClassC ........ procedure method1(arg) .... if arg.M > 10 then ..... now, how can the compiler determine that arg.M is legal? Depending on what is passed in, arg.M may or may not be legal depending on the current dynamic type of the value that arg refers to. The only way to solve this is with a runtime check which cross-references the current dynamic type with the visibility of M in relation to the context using it. Did you say "Bletch!" ? I say bletch to such horrific runtime tests... I want my scripts to complete today, thank-you very much. >> However, >> that does not fit at all with the dynamic typing of Icon. > > It fits in perfectly. All that changes is that there are more possible > types. > The increased set of possible types is not related to the necessary compiler and/or runtime code required to enforce scoping rules. >> How do you know the type of a particular variable at any one time? > > The same way as in any other language with dynamic types. > I am aiming more for compile-type checking. I spit on runtime checking of OO rules. If you want heavy rules, use a language which can resolve all the nonsense at compile time. Icon has never demanded specific declarations, and an Object Icon should retain that freedom and simplicity. It's about time that programmers learned to respect good programming practices. I am disgusted at the mess we lovingingly call C++ version 3 with STL and standards approval. What a disaster, and all that legalise rubbish just because programmers continue to be lazy and clumsy and enjoy shooting themselves in the foot. >> To do this "properly" on UNIX, the compiler could probably write to >> a tmp file (not linked into a directory) and then hand the open file >> handles off to a cooperating iconx which can slurp up the icode from >> the tmp file handles and then close them, resulting in their >> deallocation. > > Bletch! > I'm only suggesting a method to add #!/usr/bin/icon capabilities easily into Icon. Since the current implementation is neatly split into a compiler/linker and a separate runtime, it's mere mechanics to add #! to Icon, without requiring the merging of icont and iconx just because "it's more elegant" to merge them, or too "bletchy" to use a dirty trick. Why burden the runtime with the baggage of the compiler? My suggestion is merely pragmatic, and nobody needs to see how much steam and oil is spraying around in the engine room. However, there is tantalising merit in allowing Icon programs to support some kind of "eval" statement just like Perl or shells do; this would require access to the compiler from the runtime... Ultimately, you have to remember that Icon is very dynamically typed, very simple in it's scoping, and it doesn't follow convention. Please let's not burden Icon or a hypothetical Object Icon with fashionable or politically correct ideas about how OO must be implemented. C++ has shown the folly of designing a language to the point that only a lawyer can fully understand all the rules. Perl has shown quite clearly that lack of enforced encapsulation rules does not cause a mass outbreak of bugs. I've collected dozens of classes out of CPAN and am happily using them, completely ignorant of the internal mechanics and totally unfazed by the lack of privacy for the class members. If I start fishing around inside the class, messing around with class members beyond that described in the doco, then I've only got myself to blame when my code blows up in my face. Same goes for everyone else. From icon-group-sender Mon Oct 14 07:55:19 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9EEtEY07323 for icon-group-addresses; Mon, 14 Oct 2002 07:55:14 -0700 (MST) Message-Id: <200210141455.g9EEtEY07323@baskerville.CS.Arizona.EDU> From: "Shmuel (Seymour J.) Metz" X-Newsgroups: comp.lang.icon Subject: Re: Icon Wish List Date: Sat, 12 Oct 2002 22:01:24 -0400 Mail-Copies-To: nobody X-Cise: tanbanso@iinet.net.au X-CompuServe-Customer: Yes X-Coriate: admin@interspeed.co.nz X-Ecrate: tanandtanlawyers.com X-Punge: Micro$oft X-Sanguinate: themvsguy@email.com X-Terminate: SPA(GIS) X-Tinguish: Mark Griffith X-Treme: C&C,DWS X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In , on 10/13/2002 at 12:46 AM, "Andrew Hamm" said: >I don't think you've understood what I've said. Au contraire; you have confirmed that I understood what I've said and that you didn't understand what I said. Typing can be static or dynamic. Icon uses dynamic typing. I never said that the association between a variable and a class should be static. I said "The class is the type.". If the type in Icon is dynamic then clearly you would expect the association of a variable to a type in a hypothetical OO Icon to also be dynamic. >and to me, it follows that class members should not be declared with >type either. Why? >I said "overloaded" not "overridden". So did I. >Since Icon supports untyped arguments, It doesn't. It supports arguments whose type is only known at execution time. >it follows No. >Further, any method which cared to handle different args differently Irrelevant; I'm talking about two different methods, with the choice being determined at run-time based on the classes of the parameters. That sort of thing is a basic part of the OO paradigm. >Well, no it doesn't. You need to consider how it might be >implemented Yes it does. I would expect some sort of hash table, which is not exactly rocket science. >now, how can the compiler determine that arg.M is legal? It probably can't. The run-time environment will determine it. >The only way to solve this is with a >runtime check which cross-references the current dynamic type with >the visibility of M in relation to the context using it. So what else is new? >Did you say "Bletch!" ? No, you did. I don't agree. There are all sorts of things that can only be checked at run time. >I want my scripts to complete today, thank-you very much. And I want my scripts to complete correctly, even if they take a microsecond longer. >I am aiming more for compile-type checking. Which is a more major change than making Icon OO. >I spit on runtime checking >Icon has never demanded specific declarations, Now you've got me really confused. Which is the real Andrew; the one that wants to do the checking at compile time or the one that notices that Icon does a lot of things at run time? >Ultimately, you have to remember that Icon is very dynamically >typed, I remember that, but you seem to be unhappy with it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Mon Oct 14 12:48:25 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9EJm2k26263 for icon-group-addresses; Mon, 14 Oct 2002 12:48:02 -0700 (MST) Message-Id: <200210141948.g9EJm2k26263@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: icon-group@cs.arizona.edu Cc: "'ahamm@mail.com'" , "'Shmuel (Seymour J.) Metz'" Subject: Heat, light, Idol, and Unicon (RE: Icon Wish List) Date: Mon, 14 Oct 2002 10:32:29 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO I am not quite sure why there is so much talk devoted in this thread to adding object orientation to Icon. Idol has been around for a long time, and Unicon (which is in beta) extends Idol by integrating many of its features into a gently extended dialect of Icon. What is your reason for wanting to do a different, competing OO extension of Icon? What would it do for you that Unicon does not do already? -----Original Message----- From: Shmuel (Seymour J.) Metz [mailto:spamtrap@library.lspace.org.invalid] Sent: Saturday, October 12, 2002 9:01 PM To: icon-group@CS.Arizona.EDU Subject: Re: Icon Wish List In , on 10/13/2002 at 12:46 AM, "Andrew Hamm" said: >I don't think you've understood what I've said. Au contraire; you have confirmed that I understood what I've said and that you didn't understand what I said. Typing can be static or dynamic. Icon uses dynamic typing. I never said that the association between a variable and a class should be static. I said "The class is the type.". If the type in Icon is dynamic then clearly you would expect the association of a variable to a type in a hypothetical OO Icon to also be dynamic. >and to me, it follows that class members should not be declared with >type either. Why? >I said "overloaded" not "overridden". So did I. >Since Icon supports untyped arguments, It doesn't. It supports arguments whose type is only known at execution time. >it follows No. >Further, any method which cared to handle different args differently Irrelevant; I'm talking about two different methods, with the choice being determined at run-time based on the classes of the parameters. That sort of thing is a basic part of the OO paradigm. >Well, no it doesn't. You need to consider how it might be >implemented Yes it does. I would expect some sort of hash table, which is not exactly rocket science. >now, how can the compiler determine that arg.M is legal? It probably can't. The run-time environment will determine it. >The only way to solve this is with a >runtime check which cross-references the current dynamic type with >the visibility of M in relation to the context using it. So what else is new? >Did you say "Bletch!" ? No, you did. I don't agree. There are all sorts of things that can only be checked at run time. >I want my scripts to complete today, thank-you very much. And I want my scripts to complete correctly, even if they take a microsecond longer. >I am aiming more for compile-type checking. Which is a more major change than making Icon OO. >I spit on runtime checking >Icon has never demanded specific declarations, Now you've got me really confused. Which is the real Andrew; the one that wants to do the checking at compile time or the one that notices that Icon does a lot of things at run time? >Ultimately, you have to remember that Icon is very dynamically >typed, I remember that, but you seem to be unhappy with it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Mon Oct 14 16:24:04 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9ENNlE09043 for icon-group-addresses; Mon, 14 Oct 2002 16:23:47 -0700 (MST) Message-Id: <200210142323.g9ENNlE09043@baskerville.CS.Arizona.EDU> From: Robert Parlett Subject: Re: Icon Wish List X-Newsgroups: comp.lang.icon Date: Mon, 14 Oct 2002 23:11:37 +0100 User-Agent: KNode/0.7.1 X-Complaints-To: abuse@zen.co.uk To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Andrew Hamm wrote: > Frank J. Lhota wrote: >> Looking over the last several versions of Icon, the last several >> versions did little more than adding a few functions and fix a few >> bugs. It has been a while since there have been major enhancements to >> the Icon language. This type of stagnation harms Icon's long term >> prospects. It is time to consider some major upgrades to Icon. >> > > I've been watching this debate with interest (and am heartened by the > increase in traffic above zero messages a month...) so here's my $0.04(AU) > [current exchange rate is $1.00AU = $0.54US] > >> 1) Object-Oriented Programming > > Yes, Idol is very interesting, but I haven't used it in any project, just > dabbled. I have used Icon for a few large tools; 3 of them are an > essential part of the software development production system in my > company. > [SNIP] > Apart from the corruption caused by it's pre-processing > nature, Idol does show what is possible. With integrated support, the rough > edges of Idol could be cleaned up. > [SNIP] Have you looked at Unicon recently? Idol was renamed Unicon quite a while ago, and the language has developed quite significantly since then. In particular, it now has a full parser, generated from a yacc-style grammar, a class information database which allows classes to be referenced between files at will, and a namespace facility, which groups classes, procedures, records and globals into packages, which can be imported elsewhere. Apart from being very convenient this helps prevent name clashes between unrelated libraries of code used in the same application. Unicon also has lots of Posix-style function additions, which are invaluable in this day and age. See http://unicon.sourceforge.net for more details. To get a feel for the current language, my own page http://www.parlett.dial.pipex.com has quite a bit of Unicon source code available for download, and an article about the namespace facility. Kind regards, R P Parlett From icon-group-sender Tue Oct 15 12:44:35 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9FJgUg07353 for icon-group-addresses; Tue, 15 Oct 2002 12:42:30 -0700 (MST) Message-Id: <200210151942.g9FJgUg07353@baskerville.CS.Arizona.EDU> From: Patrick Scheible X-Newsgroups: comp.lang.icon Subject: Unicon on FreeBSD? Re: Icon Wish List Date: 15 Oct 2002 17:29:01 GMT X-Newsreader: Gnus v5.3/Emacs 19.34 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Robert Parlett writes: > Have you looked at Unicon recently? [snip] Has anyone gotten Unicon to run on FreeBSD? -- Patrick From icon-group-sender Fri Oct 18 16:26:37 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9INOpY26956 for icon-group-addresses; Fri, 18 Oct 2002 16:24:51 -0700 (MST) Message-Id: <200210182324.g9INOpY26956@baskerville.CS.Arizona.EDU> From: "Boulet, Dan" To: "IconGroup (E-mail)" , "Unicon Group (E-mail)" Subject: recursive generators Date: Fri, 18 Oct 2002 15:30:41 -0400 Errors-To: icon-group-errors@cs.arizona.edu Status: RO This is an appeal to all experts in recursive generation. Given the following string: astring := "[main],a,b,c,d,[a],a1,[b],b1,b2,[c],c1,c2,c3,[d],1,2,3,[a1],a11,a12,a13,[b1 ],b11,b12,b13,b14,[b2],b21,b22,b23,b24,[a11],x,y,z" Does anyone have any ideas on how the following sub-strings can be generated: main,a,a1,a11,x main,a,a1,a11,y main,a,a1,a11,z main,a,a1,a12 main,a,a1,a13 main,b,b1,b11 main,b,b1,b12 main,b,b1,b13 main,b,b1,b14 main,b,b2,b21 main,b,b2,b22 main,b,b2,b23 main,b,b2,b24 main,c,c1 main,c,c2 main,c,c3 main,d,1 main,d,2 main,d,3 note that: main points to a,b,c a points to a1 a1 points to a11,a12,a13 a11 points to x,y,z b points to b1,b2 etc ... Regards, Daniel J. Boulet NAV CANADA Systems Test Specialist C113-4 (613) 248-7221 From icon-group-sender Fri Oct 18 17:05:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9J05ec29243 for icon-group-addresses; Fri, 18 Oct 2002 17:05:40 -0700 (MST) Message-Id: <200210190005.g9J05ec29243@baskerville.CS.Arizona.EDU> Date: Fri, 18 Oct 2002 14:22:33 -0700 From: Steve Wampler X-Accept-Language: en To: "Boulet, Dan" CC: "IconGroup (E-mail)" , "Unicon Group (E-mail)" Subject: Re: [Unicon-group] recursive generators Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Boulet, Dan" wrote: --------------------------------------------------------------------------- This is an appeal to all experts in recursive generation. Given the following string: astring := "[main],a,b,c,d,[a],a1,[b],b1,b2,[c],c1,c2,c3,[d],1,2,3,[a1],a11,a12,a13,[b1 ],b11,b12,b13,b14,[b2],b21,b22,b23,b24,[a11],x,y,z" Does anyone have any ideas on how the following sub-strings can be generated: main,a,a1,a11,x main,a,a1,a11,y main,a,a1,a11,z main,a,a1,a12 main,a,a1,a13 main,b,b1,b11 main,b,b1,b12 main,b,b1,b13 main,b,b1,b14 main,b,b2,b21 main,b,b2,b22 main,b,b2,b23 main,b,b2,b24 main,c,c1 main,c,c2 main,c,c3 main,d,1 main,d,2 main,d,3 ----------------------------------------------------------- Well, first a question - do you intend such strings to represent just acyclic graphs or general graphs? (Affects the answer slightly.) I don't know if this is what you're looking for, but I'd approach the problem as a graph traversal problem. First parse the string to build the graph and then generate all (acyclic) paths in the graph starting at the root node (presumably, that's the first node in the string, right?) -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Fri Oct 18 17:06:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9J06oc29339 for icon-group-addresses; Fri, 18 Oct 2002 17:06:51 -0700 (MST) Message-Id: <200210190006.g9J06oc29339@baskerville.CS.Arizona.EDU> X-Zen-Trace: 62.3.105.86 From: Robert Parlett To: "Boulet, Dan" , "IconGroup (E-mail)" , "Unicon Group (E-mail)" Subject: Re: [Unicon-group] recursive generators Date: Fri, 18 Oct 2002 22:33:13 +0100 User-Agent: KMail/1.4.1 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Friday 18 October 2002 8:30 pm, Boulet, Dan wrote: > This is an appeal to all experts in recursive generation. Given the > following string: > > astring := > "[main],a,b,c,d,[a],a1,[b],b1,b2,[c],c1,c2,c3,[d],1,2,3,[a1],a11,a12,a13,[b >1 ],b11,b12,b13,b14,[b2],b21,b22,b23,b24,[a11],x,y,z" > > Does anyone have any ideas on how the following sub-strings can be > generated: > > main,a,a1,a11,x > main,a,a1,a11,y > main,a,a1,a11,z > main,a,a1,a12 > main,a,a1,a13 > main,b,b1,b11 > main,b,b1,b12 > main,b,b1,b13 > main,b,b1,b14 > main,b,b2,b21 > main,b,b2,b22 > main,b,b2,b23 > main,b,b2,b24 > main,c,c1 > main,c,c2 > main,c,c3 > main,d,1 > main,d,2 > main,d,3 > > note that: > main points to a,b,c > a points to a1 > a1 points to a11,a12,a13 > a11 points to x,y,z > b points to b1,b2 > etc ... > > > Regards, > > Daniel J. Boulet > NAV CANADA > Systems Test Specialist > C113-4 > (613) 248-7221 If you do put your string into a convenient data structure (eg a table of lists), then the generator is very simple Hope this helps. procedure generate_lines(t, s) if member(t, s) then suspend s || "," || generate_lines(t, !t[s]) else return s end procedure get_table() local t t := table() t["main"] := ["a","b","c","d"] t["a"] := ["a1"] t["b"] := ["b1","b2"] t["c"] := ["c1","c2","c3"] t["d"] := ["1","2","3"] t["a1"] := ["a11","a12","a13"] t["b1"] := ["b11","b12","b13","b14"] t["b2"] := ["b21","b22","b23","b24"] t["a11"] := ["x","y","z"] return t end procedure main() every write(generate_lines(get_table(), "main")) end From icon-group-sender Mon Oct 21 07:48:04 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9LEkJg12989 for icon-group-addresses; Mon, 21 Oct 2002 07:46:19 -0700 (MST) Message-Id: <200210211446.g9LEkJg12989@baskerville.CS.Arizona.EDU> X-Originating-IP: [202.9.176.215] From: "Trinity Palakkad" To: icon-group@cs.arizona.edu Date: Sun, 20 Oct 2002 16:17:19 +0530 X-OriginalArrivalTime: 20 Oct 2002 10:47:19.0583 (UTC) FILETIME=[10358AF0:01C27826] Errors-To: icon-group-errors@cs.arizona.edu Status: RO Sir, I found Icon programming very interesting. I want to learn more about. I'm finding it difficult to get material on Events,Event Queues and related topics like polling,blocking etc.I also need information about Subject window and different canvas states.I would be grateful if you could provide me with some information on these. Thanking You, Yours faithfully, Preethy _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp From icon-group-sender Mon Oct 21 07:48:26 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9LEmKk13069 for icon-group-addresses; Mon, 21 Oct 2002 07:48:20 -0700 (MST) Message-Id: <200210211448.g9LEmKk13069@baskerville.CS.Arizona.EDU> X-Originating-IP: [202.9.176.215] From: "Trinity Palakkad" To: icon-group@cs.arizona.edu Subject: Programming doubts Date: Sun, 20 Oct 2002 16:22:04 +0530 X-OriginalArrivalTime: 20 Oct 2002 10:52:05.0066 (UTC) FILETIME=[BA5ECAA0:01C27826] Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hi, Following are 2 programs in which I need help. Could you please give your suggestions regarding this? Program 1 link wopen procedure main() WOpen("size=300,400","pos=100,100") WAttrib("bg=blue","fg=white","canvas=hidden") WDone() end After executing the program,no other programs can be executed due to some linking error.Even the same program cannot be run for a second time.What change is to be made to the program? Program 2 link wopen procedure main() WOpen("size=300,400","pos=100,100","label=W1") WAttrib("bg=blue","fg=white","canvas=normal") WWrite("The window is in the normal state") WOpen("size=300,400","pos=200,200","label=W2") WAttrib("bg=blue","fg=white","canvas=hidden") WDone() end The program does not produce the desired result. W2 has to be closed.Instead,W1 is being closed. What change is to be made to the program? Thanks, Preethy _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp From icon-group-sender Mon Oct 21 07:49:07 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9LEn4o13136 for icon-group-addresses; Mon, 21 Oct 2002 07:49:04 -0700 (MST) Message-Id: <200210211449.g9LEn4o13136@baskerville.CS.Arizona.EDU> From: "WebsiteWill" X-Newsgroups: comp.lang.icon Subject: Length of Icon File Date: Sun, 20 Oct 2002 22:37:21 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello: I a writing an Icon file that is beginning to get some decent length to it. Over 1000 lines. I noticed tonight at some point Icon would no longer accept user input. After checking out the keyboard and rebooting multiple times I noticed that i could Backspace or Delete or even move around the program but not add more stuff. So I moved some functions that weren't necessary at the time over to another file and found that i was able to code some more. is there a way to make icon accept a longer program? or a way to include functions in an outside source and have them linked in at runtime? Thanks, Webby From icon-group-sender Mon Oct 21 07:49:54 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9LEnpI13185 for icon-group-addresses; Mon, 21 Oct 2002 07:49:51 -0700 (MST) Message-Id: <200210211449.g9LEnpI13185@baskerville.CS.Arizona.EDU> Date: Mon, 21 Oct 2002 07:46:37 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Fun with graphs Errors-To: icon-group-errors@cs.arizona.edu Status: RO Recently Dan Boulet posted a query about generating paths through a directed-acyclic graph (dag) and Robert Parlett posted an elegant response showing how to generate those paths once the graph has been converted from string representation into an 'internal' form. A complete program that parses the string form into the internal form and then generates paths in the graph is shown below (the procedure that generates the paths is a slight variant of Robert's). However, if you think about the representations of the dag (both Dan's string representation and Roberts internal form), it becomes apparent that both are powerful enough to represent arbitrary directed graphs and not just acyclic ones. So, a little challenge to those of you who like to play with Icon: Rewrite the following program to find all 'acyclic' paths in a general graph from the 'root' node (first node given) to leaf nodes. (An acyclic path is a path that contains no cycles - all paths in a dag are acyclic; that is not necessarily true in a general graph.) ----- paths.icn ------ # # Generate paths through a directed acyclic graph. # global rootNode procedure main(args) aString := "[main],a,b,c,d,[a],a1,[b],b1,b2," || "[c],c1,c2,c3,[d],1,2,3,[a1],a11,a12,a13," || "[b1],b11,b12,b13,b14,[b2],b21,b22,b23,b24,"|| "[a11],x,y,z" if *args > 0 then aString := args[1] every write(trim(showPaths(parseGraph(aString), rootNode), ',')) end procedure parseGraph(s) nodeTab := table() (s ||",") ? { # force uniform node representation while getNode(nodeTab) } return nodeTab end procedure getNode(nodeTab) value := 2( ="[", tab(upto(']')), ="]," ) | fail /rootNode := value childrenStr := tab(upto('[')|0) if *childrenStr > 0 then { childrenStr ? { /nodeTab[value] := [] # allows repeated nodes! while put(nodeTab[value], tab(upto(','))) do move(1) } } return end procedure showPaths(t, s) # finds paths to leaf nodes if /t[s] then return s suspend s || "," || showPaths(t, !t[s], seen) end ----------------------------------------------------------------- -Steve -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Mon Oct 21 17:02:25 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9M024k25566 for icon-group-addresses; Mon, 21 Oct 2002 17:02:04 -0700 (MST) Message-Id: <200210220002.g9M024k25566@baskerville.CS.Arizona.EDU> Date: Mon, 21 Oct 2002 13:56:40 -0600 From: Clint Jeffery To: websitewill@cox-internet.com CC: icon-group@cs.arizona.edu Subject: Re: Length of Icon File Errors-To: icon-group-errors@cs.arizona.edu Status: RO ["Webby" asks about writing larger Icon programs.] The old IDE included with Windows Icon uses Windows' built-in edit control, which is limited to 32KB even on current Windows OS'es. To write larger source files than this you will need to switch to your favorite programmer's editor, and either compile from the command line, or use a "make" tool. To stick with the old IDE you could split your program into multiple source files each <32KB, and write an "Icon Project FILE" with extension .icp that lists each source .icn filename of the project, one per line. The IDE works as an ultra-simple "make" tool to compile and link such projects together. Clint jeffery@cs.nmsu.edu From icon-group-sender Tue Oct 22 12:33:08 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9MJWAE04817 for icon-group-addresses; Tue, 22 Oct 2002 12:32:10 -0700 (MST) Message-Id: <200210221932.g9MJWAE04817@baskerville.CS.Arizona.EDU> Date: Tue, 22 Oct 2002 09:29:57 -0700 (MST) From: Gregg Townsend To: icon-group@cs.arizona.edu, tipl2@hotmail.com Subject: Re: Icon event documentation Errors-To: icon-group-errors@cs.arizona.edu Status: RO > From: "Trinity Palakkad" > Date: Sun, 20 Oct 2002 16:17:19 +0530 > > I'm finding it difficult to get material > on Events,Event Queues and related topics > like polling,blocking etc.I also need information > about Subject window and different canvas states. The best references are the Icon graphics book (for more info about it, see:) http://www.cs.arizona.edu/icon/books.htm and the technical report IPD281: http://www.cs.arizona.edu/icon/docs/ipd281.htm --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Wed Oct 23 08:03:38 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9NF3IM22344 for icon-group-addresses; Wed, 23 Oct 2002 08:03:19 -0700 (MST) Message-Id: <200210231503.g9NF3IM22344@baskerville.CS.Arizona.EDU> From: "Paul W. Abrahams" To: icon-group@cs.arizona.edu Subject: The "variable" function and records Date: Tue, 22 Oct 2002 19:46:01 -0400 Errors-To: icon-group-errors@cs.arizona.edu Status: RO I've been trying to write an Icon version of the COBOL "move corresponding" facility (also known in PL/I as "by name assignment"). However, I can't figure out how to use the "variable" function to assign something to a record component. Here's a test case: #!/usr/bin/env icon record r1(a,b,c,d) procedure main() local x1 x1:=r1("one","two","three","four") variable(name(x1.a)):="pete" write(name(x1.a),":",image(x1.a),":",x1.a) end What I get is: r1.a:"one":one What I'm striving for is to be able to assign to the "x" field of a record R, where "x" is a string-valued variable. Is there a way to do that? Paul From icon-group-sender Wed Oct 23 13:00:51 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9NJxew14318 for icon-group-addresses; Wed, 23 Oct 2002 12:59:40 -0700 (MST) Message-Id: <200210231959.g9NJxew14318@baskerville.CS.Arizona.EDU> From: "Paul W. Abrahams" To: icon2002@OptOnLine.net Subject: move_corresponding Date: Wed, 23 Oct 2002 14:57:43 -0400 Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Wednesday 23 October 2002 11:43 am, Steve Hunter wrote: > record r1(a,b,c,d) > > procedure main() > local x1 > x1:=r1("one","two","three","four") > fld_nm := "a"; x1[fld_nm]:="pete" > write(name(x1.a),":",image(x1.a),":",x1.a) > > end I hadn't realized that a record can be subscripted by a field name as well as by a position (but of course it can). I found a kludgy workaround for the problem, by building tables that map field names to their positions, but this solution is far better. Paul From icon-group-sender Wed Oct 23 16:27:29 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9NNR0g29135 for icon-group-addresses; Wed, 23 Oct 2002 16:27:01 -0700 (MST) Message-Id: <200210232327.g9NNR0g29135@baskerville.CS.Arizona.EDU> From: "Paul W. Abrahams" To: icon-group@cs.arizona.edu Subject: move_corresponding: the procedure Date: Wed, 23 Oct 2002 16:32:23 -0400 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Here's the code of the move_corresponding procedure I referred to earlier (which, according to Clint, will work only in newer versions of Icon). It might be a useful addition to the Icon library. Paul ----------------------- procedure move_corresponding(s1,s2) # move_corresponding moves correspondingly-named fields from the # record parameter s1 to the record parameter s2. Fields whose # names are not common are not affected. The ordering of the field # names is irrelevant. local names1,names2,n,i # Generate the set of common names names1:=set() every i := 1 to *s1 do insert(names1,name(s1[i]) ? (tab(upto('.')),=".",tab(0))) every write(!names1) names2:=set() every i := 1 to *s2 do insert(names2,name(s2[i]) ? (tab(upto('.')),=".",tab(0))) # Now copy the components with shared names every n := !(names1**names2) do s1[n] := s2[n] end From icon-group-sender Thu Oct 24 07:55:47 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9OEtNU03886 for icon-group-addresses; Thu, 24 Oct 2002 07:55:23 -0700 (MST) Message-Id: <200210241455.g9OEtNU03886@baskerville.CS.Arizona.EDU> X-Originating-IP: [202.9.164.10] From: "Trinity Palakkad" To: icon-group@cs.arizona.edu Subject: Doubts in programming Date: Thu, 24 Oct 2002 09:39:08 +0530 X-OriginalArrivalTime: 24 Oct 2002 04:09:09.0112 (UTC) FILETIME=[1A07F780:01C27B13] Errors-To: icon-group-errors@cs.arizona.edu Status: RO Program 1 link wopen procedure main() WOpen("size=300,400","pos=100,100") WAttrib("bg=blue","fg=white","canvas=hidden") WDone() end After executing the program,no other programs can be executed due to some linking error.Even the same program cannot be run for a second time.What change is to be made to the program? Program 2 link wopen procedure main() WOpen("size=300,400","pos=100,100","label=W1") WAttrib("bg=blue","fg=white","canvas=normal") WWrite("The window is in the normal state") WOpen("size=300,400","pos=200,200","label=W2") WAttrib("bg=blue","fg=white","canvas=hidden") WDone() end The program does not produce the desired result. W2 has to be closed.Instead,W1 is being closed. What change is to be made to the program? _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp From icon-group-sender Thu Oct 24 12:29:15 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9OJSmU00911 for icon-group-addresses; Thu, 24 Oct 2002 12:28:48 -0700 (MST) Message-Id: <200210241928.g9OJSmU00911@baskerville.CS.Arizona.EDU> Date: Thu, 24 Oct 2002 08:46:16 -0700 From: Steve Wampler X-Accept-Language: en To: Trinity Palakkad , icon-group Subject: Re: Doubts in programming Errors-To: icon-group-errors@cs.arizona.edu Status: RO Trinity Palakkad wrote: > > Program 1 > > link wopen > > procedure main() > WOpen("size=300,400","pos=100,100") > WAttrib("bg=blue","fg=white","canvas=hidden") > WDone() > end > > After executing the program,no other programs can be executed > due to some linking error.Even the same program cannot be run > for a second time.What change is to be made to the program? What linking error? I don't think that's what you're seeing. I think you're seeing the fact that WDone says to wait for a 'Q' or 'q' to be typed into the window before processing and you can't do that because you've opened the window as 'hidden', so you can't see it to type the 'Q' or 'q'. Try: procedure main() WOpen("size=300,400","pos=100,100") WAttrib("bg=blue","fg=white","canvas=normal") WDone() end instead and then type Q or q inside the window. Or consider using WClose() instead of WDone, depending on what you want to do... > Program 2 > > link wopen > > procedure main() > WOpen("size=300,400","pos=100,100","label=W1") > WAttrib("bg=blue","fg=white","canvas=normal") > WWrite("The window is in the normal state") > WOpen("size=300,400","pos=200,200","label=W2") > WAttrib("bg=blue","fg=white","canvas=hidden") > WDone() > end > > The program does not produce the desired result. > W2 has to be closed.Instead,W1 is being closed. > What change is to be made to the program? Well, it does do what you told it to do, so I guess that wasn't what you desired... The first WOpen sets &window, which is then used by subsequent Wxxx() functions that don't specify a window. So the 2nd WAttrib() call that sets the canvas to hidden is hiding the first window, not the second. I've found it to be good practice to use explicit window names anytime I'm using more than one window. Doing so, the above program would be (something like): link wopen procedure main() w1 := WOpen("size=300,400","pos=100,100","label=W1") WAttrib(w1,"bg=blue","fg=white","canvas=normal") WWrite(w1,"The window is in the normal state") w2 := WOpen("size=300,400","pos=200,200","label=W2") WAttrib(w2,"bg=blue","fg=white","canvas=hidden") WClose(w2) WDone(w1) end Note that I'm using WClose(w2) and not WDone(w2) - since you've got w2 'hidden', WDone(w2) would be a problem, just as it was with the hidden window in your first example. If you don't have the "Graphics Programming in Icon" book, you should get it as an invaluable reference. > _________________________________________________________________ > Choose an Internet access plan right for you -- try MSN! > http://resourcecenter.msn.com/access/plans/default.asp -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Thu Oct 24 12:49:33 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9OJnNU02327 for icon-group-addresses; Thu, 24 Oct 2002 12:49:23 -0700 (MST) Message-Id: <200210241949.g9OJnNU02327@baskerville.CS.Arizona.EDU> From: "Paul W. Abrahams" To: icon-group@cs.arizona.edu Subject: move_corresponding -- whoops!!! Date: Thu, 24 Oct 2002 12:36:01 -0400 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Seems that I reversed the direction of the critical assignment expression, so that the assignment is from s2 to s1 rather than s1 to s2 as it should be. The correct procedure is: procedure move_corresponding(s1,s2) # move_corresponding moves correspondingly-named fields from the # record parameter s1 to the record parameter s2. Fields whose # names are not common are not affected. The ordering of the field # names is irrelevant. local names1,names2,n,i # Generate the set of common names names1:=set() every i := 1 to *s1 do insert(names1,name(s1[i]) ? (tab(upto('.')),=".",tab(0))) every write(!names1) names2:=set() every i := 1 to *s2 do insert(names2,name(s2[i]) ? (tab(upto('.')),=".",tab(0))) # Now copy the components with shared names every n := !(names1**names2) do s2[n] := s1[n] end From icon-group-sender Thu Oct 24 16:24:22 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9ONNaQ17534 for icon-group-addresses; Thu, 24 Oct 2002 16:23:36 -0700 (MST) Message-Id: <200210242323.g9ONNaQ17534@baskerville.CS.Arizona.EDU> Date: Thu, 24 Oct 2002 13:13:16 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Re: move_corresponding Errors-To: icon-group-errors@cs.arizona.edu Status: RO Here's what I came up with, realizing that Icon will fail gracefully when the names don't match: # movecorr(R1, R2) copies values from the fields of record R1 into # fields of the same names (if any) in record R2, and returns R2. procedure movecorr(R1, R2) local s every s := (name(!R1) ? (tab(upto('.') + 1) & tab(0))) do R2[s] := R1[s] return R2 end --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Sat Oct 26 11:58:31 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9QIuuE26658 for icon-group-addresses; Sat, 26 Oct 2002 11:56:56 -0700 (MST) Message-Id: <200210261856.g9QIuuE26658@baskerville.CS.Arizona.EDU> From: xadeu2002@hotmail.com (adeukcin) X-Newsgroups: comp.lang.icon Subject: Icon broken? Date: 26 Oct 2002 00:09:39 -0700 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO I am trying to write a simple Regular Expression... s := "Ic(cond)best" re := RePat("( \(cond\) )") i := 0 j := 0 i := ReFind(re,s) j := ReMatch(re,s,i) s[i:j] := "on is the" write(s[i:j]) >From what I understand... This should output something like... "Icon is the best" instead it gives me somthing like... "Ic(on is the)best" the \( does not seem to remove the special meaning from ( So if what I am wanting to do is possible...how... If I am doing this wrong...can you explain? Thank you very very much!!! From icon-group-sender Mon Oct 28 07:58:52 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9SEvaQ05275 for icon-group-addresses; Mon, 28 Oct 2002 07:57:36 -0700 (MST) Message-Id: <200210281457.g9SEvaQ05275@baskerville.CS.Arizona.EDU> From: Ed L Cashin X-Newsgroups: comp.lang.icon Subject: icon graphics: fonts in Windoze Date: 26 Oct 2002 18:28:30 -0400 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hi. Icon graphics are so easy that it would be fun to write presentations in Icon itself, or to write an Icon program that would read a "presentation description file" and generate an executable for a presentation. I have no problem finding fonts on UN*X, where I can use xfontsel and where the examples in _Graphics Programming in Icon_ work. (I tried fontpick on UN*X, but I don't understand how to use it.) Is there a good way to find out what fonts are available on my Windows XP system and how to use them in Icon programs? -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Mon Oct 28 07:59:56 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9SExrA05395 for icon-group-addresses; Mon, 28 Oct 2002 07:59:53 -0700 (MST) Message-Id: <200210281459.g9SExrA05395@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Icon broken? Date: Mon, 28 Oct 2002 10:46:50 +1100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO adeukcin wrote: > I am trying to write a simple Regular Expression... > s := "Ic(cond)best" > re := RePat("( \(cond\) )") > > i := 0 > j := 0 > > i := ReFind(re,s) > j := ReMatch(re,s,i) > > s[i:j] := "on is the" > write(s[i:j]) > > From what I understand... > This should output something like... > "Icon is the best" > instead it gives me somthing like... > "Ic(on is the)best" > > the \( does not seem to remove the special meaning from ( > RePat - hmm - I haven't seen them before. However.... your problem is understanding the need to use \ in strings. If you want a \ to be in a string, you need to back-slash it. The compiler reads the source code and interprets it first. re := RePat("( \\(cond\\) )") now, the string stored internally in the object code and executed by the runtime will contain the \ that you desire. Try writing the string to see the difference with and without the correct number of \ From icon-group-sender Tue Oct 29 07:27:23 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9TEQfQ27204 for icon-group-addresses; Tue, 29 Oct 2002 07:26:41 -0700 (MST) Message-Id: <200210291426.g9TEQfQ27204@baskerville.CS.Arizona.EDU> Date: Mon, 28 Oct 2002 19:30:02 -0700 From: Clint Jeffery To: ecashin@uga.edu CC: icon-group@cs.arizona.edu Subject: Re: icon graphics: fonts in Windoze Errors-To: icon-group-errors@cs.arizona.edu Status: RO [Ed Cashin writes] : Icon graphics are so easy that it would be fun to write presentations in : Icon itself, or to write an Icon program that would read a "presentation : description file" and generate an executable for a presentation. A very cool application idea! I've toyed with it, but OpenOffice works well enough that I just haven't needed to do anything serious with it. [He then asks about selection of available MS Windows fonts in Icon] The WinFontDialog() function in Windows Icon and Unicon let's your user view or select from available fonts with the standard Windows font dialog. If you mean for your program to get a list of available fonts, I am not aware of a direct way to do this under the Win32 API, perhaps someone with Windows expertise can suggest a solution or a cheesey workaround. Clint jeffery@cs.nmsu.edu From icon-group-sender Tue Oct 29 12:39:49 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9TJceQ14095 for icon-group-addresses; Tue, 29 Oct 2002 12:38:40 -0700 (MST) Message-Id: <200210291938.g9TJceQ14095@baskerville.CS.Arizona.EDU> Date: Tue, 29 Oct 2002 10:34:38 -0800 (PST) From: Neha Sharma Subject: request/doubt To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hi > > I have a doubt of how to read an input file in icon > till the last character..(like if i have a file that > has many lines in it )..how do i read all the lines in > that file and save it in some string in my icon > program??????. > > if nyone knows answer to this please reply asap. > > regards > neha > From icon-group-sender Tue Oct 29 16:27:02 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9TNQoA26805 for icon-group-addresses; Tue, 29 Oct 2002 16:26:50 -0700 (MST) Message-Id: <200210292326.g9TNQoA26805@baskerville.CS.Arizona.EDU> From: "Boulet, Dan" To: "'Neha Sharma'" , icon-group@cs.arizona.edu Subject: RE: request/doubt Date: Tue, 29 Oct 2002 14:57:14 -0500 Errors-To: icon-group-errors@cs.arizona.edu Status: RO I assume you are wondering how to read a file into a single string as opposed to read the lines of the file individually. This is accomplished by using the "u" option when opening a file. "U" means un-translated. "end of lines" character sequences are not translated. Example: "afile.txt" contains the following lines: this is a test Your program might look something like this: procedure main() f := open("afile.txt","ru") | stop("error opening file") s := "" while s ||:= read(f) write(image(s)) end The result is this: "this\ris\ra\rtest\r" Regards, Daniel J. Boulet From icon-group-sender Tue Oct 29 16:27:39 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9TNRbY26869 for icon-group-addresses; Tue, 29 Oct 2002 16:27:37 -0700 (MST) Message-Id: <200210292327.g9TNRbY26869@baskerville.CS.Arizona.EDU> From: "Richard H. McCullough" To: Subject: Fw: request/doubt Date: Tue, 29 Oct 2002 14:39:41 -0800 Status: RO procedure main() bigline :=3D "" while line :=3D read() do { # each line of standard input bigline ||:=3D line # if you want one big line } end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Dick McCullough=20 knowledge :=3D man do identify od existent done knowledge haspart list of proposition From icon-group-sender Wed Oct 30 09:09:45 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9UG9LY29514 for icon-group-addresses; Wed, 30 Oct 2002 09:09:21 -0700 (MST) Message-Id: <200210301609.g9UG9LY29514@baskerville.CS.Arizona.EDU> From: Bob Ardler To: Date: Wed, 30 Oct 2002 09:14:15 +0000 (GMT) Subject: Re: Fw: request/doubt User-Agent: Pluto/2.04e (RISC-OS/4.03) Errors-To: icon-group-errors@cs.arizona.edu Status: RO Richard H. McCullough wrote, with the help of microsoftian genius: > This is a multi-part message in MIME format. > ------=_NextPart_000_0010_01C27F59.04249B40 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > Dick McCullough=20 > knowledge :=3D man do identify od existent done > knowledge haspart list of proposition > ----- Original Message -----=20 > From: Richard H. McCullough=20 > To: Neha Sharma=20 > Sent: Tuesday, October 29, 2002 2:37 PM > Subject: Re: request/doubt > procedure main() > bigline :=3D "" > while line :=3D read() do { # each line of standard input > bigline ||:=3D line # if you want one big line > } > end > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > Dick McCullough=20 > knowledge :=3D man do identify od existent done > knowledge haspart list of proposition > ----- Original Message -----=20 > From: Neha Sharma=20 > To: icon-group@CS.Arizona.EDU=20 > Sent: Tuesday, October 29, 2002 10:34 AM > Subject: request/doubt > --0-573434436-1035916478=3D:8746 > Content-Type: text/plain; charset=3Dus-ascii > Hi > >=20 > > I have a doubt of how to read an input file in icon > > till the last character..(like if i have a file that > > has many lines in it )..how do i read all the lines in > > that file and save it in some string in my icon > > program??????. > >=20 > > if nyone knows answer to this please reply asap. > >=20 > > regards > > neha > >=20 > --------------------------------- > Do you Yahoo!? > HotJobs - Search new jobs daily now > --0-573434436-1035916478=3D:8746 > Content-Type: text/html; charset=3Dus-ascii > Hi
>
> I have a doubt of how to read an = > input file in icon
> till the last character..(like if i have a = > file that
> has many lines in it )..how do i read all the lines = > in
> that file and save it in some string in my icon
> = > program??????.
>
> if nyone knows answer to this please = > reply asap.
>
> regards
> neha
> = >


Do you Yahoo!?
> ">HotJobs - Search new jobs daily now > --0-573434436-1035916478=3D:8746-- > ------=_NextPart_000_0010_01C27F59.04249B40 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > charset=3Diso-8859-1"> > > > > >
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dick McCullough
href=3D"http://www.volcano.net/~rhm">knowledge :=3D man = > do=20 > identify od existent done
knowledge haspart list = > of proposition
>
----- Original Message -----=20 >
From: title=3Drhm@cdepot.net href=3D"mailto:rhm@cdepot.net">Richard H. = > McCullough=20 >
> >
Sent: Tuesday, October 29, 2002 2:37 PM
>
Subject: Re: request/doubt
>

>
procedure main()
>
bigline :=3D ""
>
while line :=3D read() do = > {    # each=20 > line of standard input
>
    bigline ||:=3D=20 > line    # if you want one big line
>
}
>
size=3D2>end
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dick = > McCullough=20 >
knowledge :=3D = > man do=20 > identify od existent done
knowledge haspart list = > of proposition
> style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = > BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> >
----- Original Message -----
> style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = > black">From:=20 > Neha = > Sharma=20 > > >
Sent: Tuesday, October 29, 2002 = > 10:34=20 > AM
>
Subject: request/doubt
>

--0-573434436-1035916478=3D:8746
Content-Type: = > text/plain;=20 > charset=3Dus-ascii

Hi
>
> I have a doubt of how to = > read an=20 > input file in icon
> till the last character..(like if i have a = > file=20 > that
> has many lines in it )..how do i read all the lines = > in
>=20 > that file and save it in some string in my icon
> = > program??????.
>=20 >
> if nyone knows answer to this please reply asap.
> = >
>=20 > regards
> neha
>=20 >



---------------------------------
Do you = > Yahoo!?
HotJobs=20 > - Search new jobs daily = > now
--0-573434436-1035916478=3D:8746
Content-Type:=20 > text/html; charset=3Dus-ascii

<FONT = > size=3D3>Hi<BR>&gt;=20 > <BR>&gt; I have a doubt of how to read an input file in=20 > icon<BR>&gt; till the last character..(like if i have a file = > that<BR>&gt; has many lines in it )..how do i read all the = > lines=20 > in<BR>&gt; that file and save it in some string in my=20 > icon<BR>&gt; program??????.<BR>&gt; = > <BR>&gt; if=20 > nyone knows answer to this please reply asap.<BR>&gt;=20 > <BR>&gt; regards<BR>&gt; neha<BR>&gt;=20 > <BR></FONT><p><br><hr size=3D1>Do you=20 > Yahoo!?<br>
<a href=3D" = > href=3D"http://rd.yahoo.com/careers/mailsig/*http://www.hotjobs.com">http= > ://rd.yahoo.com/careers/mailsig/*http://www.hotjobs.com=20 > ">HotJobs</a> - Search new jobs daily=20 > = > now
--0-573434436-1035916478=3D:8746--

ML> > ------=_NextPart_000_0010_01C27F59.04249B40-- - a cogent argument on behalf of plain-text messages which obey newsgroup-style conventions. (This reply is also a demonstration of the horrors of excessive quoting down to the last Yahoo plug.) -- Bob Ardler, ardler@argonet.co.uk Of making features there is no end - Ecclesiastes i.2 From icon-group-sender Fri Nov 1 12:58:15 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA1Jv9Y09869 for icon-group-addresses; Fri, 1 Nov 2002 12:57:09 -0700 (MST) Message-Id: <200211011957.gA1Jv9Y09869@baskerville.CS.Arizona.EDU> From: icon-project@cs.arizona.edu X-Newsgroups: comp.lang.icon,comp.answers,news.answers Subject: Icon Programming Language FAQ Date: 1 Nov 2002 08:19:07 -0700 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions about the Icon programming language www.cs.arizona.edu/icon/faq.htm Last updated October 14, 2002 Learning about Icon A1. What is Icon? A2. What is Icon good for? A3. What are Icon's distinguishing characteristics? A4. What is the Icon program library? A5. Where can I learn more about Icon? A6. How about comprehensive documentation? Implementations B1. What platforms support Icon? B2. How do I get started with Icon? B3. Is there a Unicode version of Icon? B4. What happened to the compiler? Administration C1. What is the Icon Project? C2. How often is the on-line material updated? C3. Where did Icon come from? C4. Where is Icon going? Support D1. Is there a users' group for Icon? D2. How do I get technical support? Programming E1. Why doesn't read() work with every? E2. Why doesn't string invocation such as "foo"() work? E3. How can I call a C function? E4. Can I open a bidirectional pipe? _________________________________________________________________ Learning about Icon A1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but with semantics at a much higher level. Icon has a novel expression-evaluation mechanism that integrates goal-directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion: For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. A2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's especially strong at building software tools, for processing text, and for experimental and research applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. Consequently, Icon is used both for short, one-shot tasks and for very complex applications. A3. What are Icon's distinguishing characteristics? * A high-level, general-purpose programming language * Friendly line-oriented syntax (no semicolons needed) * Emphasis on programmer productivity * Usually interpreted * Evolved from programming languages (vs. scripting languages) * Procedural control flow plus generators and goal-directed evaluation * Values have types; variables are typeless, accept any value * Static scoping: global or (procedure) local * Automatic garbage collection * All integers have arbitrary precision * Uses strings (not chars) as basic text datatype * Has lists that function as arrays, queues, and stacks * Also has sets, tables, records (structs), reals (doubles), more * No second-class "primitive types" * Not "object-oriented" (no classes, inheritance, or instance methods) * No exception catching * No concurrency (no threads, monitors, semaphores, or synchronization) * Has co-expressions (coroutines) * Basic least-common-denominator system interface (a la ANSI C) * Procedural graphics (event-driven paradigm available but not mandated) * Retained windows (programs are never called to repaint) * Simple GUI builder that can re-edit its generated code * Turtle graphics package * Large library of contributed procedures and programs A4. What is the Icon program library? The library is a collection of programs and procedures written in Icon. User contributions are welcome and form a significant portion of the library. Library procedures effectively augment the built-in functions available to an Icon program. A wide variety of procedures currently exists, and most graphically-based programs are built around library procedures. The programs in the library range from simple demonstrations to handy tools to complex graphical applications. The library is a resource for both new and experienced programmers. In addition to their basic utility, its programs and procedures serve as examples of how things can be written in Icon. A5. Where can I learn more about Icon? Here are some good places to start. * Ralph Griswold's overview: www.cs.arizona.edu/icon/docs/ipd266.htm * Dave Hanson's introduction: www.cs.arizona.edu/icon/intro.htm * John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon A6. How about comprehensive documentation? Two books define the Icon language. The core language is covered in The Icon Programming Language (third edition), by Griswold and Griswold. Graphics facilities are described in Graphics Programming in Icon by Griswold, Jeffery, and Townsend. These books contain both tutorial and reference material. Icon's internals are detailed in The Implementation of the Icon Programming Language by Griswold and Griswold. Although considerable changes have occurred since Version 6, described in the book, the basic structure of Icon remains the same. Two technical reports, IPD112 and IPD239, describe subsequent changes. The Language and Graphics books are available from RTC Books (www.rtcbooks.com, search for "Icon") or from Jeffery Systems (www.zianet.com/jeffery/books). The Language and Implementation books can be downloaded at no charge from the Icon books page, www.cs.arizona.edu/icon/books.htm. The Icon Programming Language Handbook, by Thomas W. Christopher, is available on the web at www.toolsofcomputing.com/IconHandbook. There is a large amount of additional information at the Icon web site, www.cs.arizona.edu/icon. _________________________________________________________________ Implementations B1. What platforms support Icon? Current implementations with graphics support are available for Unix and Windows. On the Apple Macintosh, Icon runs in the Unix development environment of MacOS X, with graphics using XFree86. Older versions of Icon are available for some other systems. An alternative Java-based implementation for Unix, Jcon, is also available. B2. How do I get started with Icon? Version 9.4.1 of Icon for Unix can be downloaded from www.cs.arizona.edu/icon/v941. Source and binary packages are available, each with the complete Icon program library. Version 9.3 of Icon for Windows is compatible at the source level with version 9.4.1. It can be downloaded from www.cs.arizona.edu/icon/v93w.htm. The Version 9.4.1 library can be obtained separately from www.cs.arizona.edu/icon/v941. For older implementations, start at www.cs.arizona.edu/icon/implver.htm. Jcon is at www.cs.arizona.edu/icon/jcon. B3. Is there a Unicode version of Icon? No. Icon is defined in terms of 8-bit characters, and changing this presents several design challenges that would likely break existing programs. Also, modifying the C implementation is probably infeasible, but a Unicode version of Jcon might be possible. B4. What happened to the compiler? For a while, Unix distributions included both an interpreter and a compiler; but the interpreter is is usually fast enough even for production work, and most people found that using the compiler wasn't worth the extra compilation time or the hassles involved. We no longer advertise the compiler or produce binaries for it. It is still part of the source code distribution, and we have not deliberately broken it, but we no longer support it and we cannot offer help if problems arise. _________________________________________________________________ Administration C1. What is the Icon Project? The Icon Project is a name used by the group that distributes and supports the Icon programming language. The project maintains the Icon web site at www.cs.arizona.edu/icon. A non-commercial organization, the project is supported by the Department of Computer Science at the University of Arizona. C2. How often is the on-line material updated? New material is added when it's available. Established implementations usually are updated only when there's a new version. This typically is every year or two. The Icon program library is updated on a similar schedule. C3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 1960s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at the University of Arizona with support from the National Science Foundation. Although it has similar objectives and many similar capabilities, Icon bears little superficial resemblance to SNOBOL4. Icon implementations were developed by faculty, staff, and students at the University of Arizona, with significant contributions from volunteers around the world. An Icon history by Ralph and Madge Griswold appears in the preprints of the second History of Programming Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol 28, No 3). The name Icon is not an acronym, nor does it stand for anything in particular, although the word iconoclastic was mentioned when the name was chosen. The name predates the now common use of icon to refer to small images used in graphical user interfaces. This sometimes misleads people into thinking that that Icon is designed to create or manipulate icons, but there's no good solution to that problem. C4. Where is Icon going? We continue to use Icon on a daily basis, but no significant changes are planned. We expect to support the Unix version for the forseeable future, and to distribute ports to other systems as supplied by volunteers. The Unicon project is developing an object-oriented language based on Icon. For more information, see unicon.sourceforge.net. An earlier object-oriented extension to Icon, Idol, can be found in the Icon program library. _________________________________________________________________ Support D1. Is there a users' group for Icon? There is no official Icon users' group, but The Icon Project maintains a moderated "Icon-group" electronic mailing list. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between Icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list and is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends its announcements and other messages to the mailing list. D2. How do I get technical support? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please use the appropriate resource when you need assistance: * For programming assistance, submit a query to the mailing list or newsgroup (see above). * For porting assistance or Unix problems, contact icon-project@cs.arizona.edu. * For problems with the Windows implementation, contact the implementor, jeffery@cs.nmsu.edu. * For general information and additional documentation, visit the Icon web site: www.cs.arizona.edu/icon. _________________________________________________________________ Programming E1. Why doesn't read() work with every? every s := read() do {...} doesn't loop because read() produces a single value and then fails if resumed. Other "consumer" procedures such as get() and pop() work the same way. Use a while loop with these procedures, and save every for use with generators such as !x or key(T). E2. Why doesn't string invocation such as "foo"() work? String invocation works if the procedure is present; the catch is that the linker removes unreferenced procedures. To ensure a procedure's presence, reference it in the main() procedure. A simple reference suffices, as in refs := [foo, bar, baz]; it's not necessary to actually call it. (Why does the linker remove unreferenced procedures? Because this can save huge amounts of memory for programs that use the library.) E3. How can I call a C function? You can't call an arbitrary C function, but if you're willing to write a function to Icon's specifications, there are two approaches. Under Unix, which provides loadfunc(), you can load one or more functions from a shared library, and then treat them as if they had been written in Icon. Some examples can be found in the cfuncs and packs/loadfuncs directories of the Icon program library. The more cumbersome approach is to add code to the Icon interpreter and rebuild it; some hooks are provided for this purpose. Both approaches are discussed in Calling C Functions from Icon, www.cs.arizona.edu/icon/docs/ipd240.htm. The Jcon implementation allows Icon programs to call Java code that is written to Jcon specifications. E4. Can I open a bidirectional pipe? No, this is not possible. Although the concept is simple -- write a line to a program via a pipe, then read that program's output -- it probably wouldn't work. Most I/O libraries don't write anything to a pipe until they've filled a buffer, and the most likely consequence would be a deadlock, with each program waiting for the other to send more data. _________________________________________________________________ This FAQ is edited by Gregg Townsend. It includes contributions from Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd Proebsting. From icon-group-sender Mon Nov 4 08:28:33 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA4FPUs24268 for icon-group-addresses; Mon, 4 Nov 2002 08:25:30 -0700 (MST) Message-Id: <200211041525.gA4FPUs24268@baskerville.CS.Arizona.EDU> From: "WebsiteWill" X-Newsgroups: comp.lang.icon Subject: Question about Icon Date: Sun, 3 Nov 2002 11:25:08 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Is there a way to have an Icon Program take as input a Scheme program as a basic string, do some conversions to that string and then output the new string to a Scheme interpreter/compiler and run it then finally take the output from Scheme as a new set of input into the same Icon Program? Thanks, Will From icon-group-sender Wed Nov 6 08:03:29 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA6F2Lo17099 for icon-group-addresses; Wed, 6 Nov 2002 08:02:21 -0700 (MST) Message-Id: <200211061502.gA6F2Lo17099@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Question about Icon Date: Wed, 6 Nov 2002 13:15:06 +1100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO WebsiteWill wrote: > Is there a way to have an Icon Program take as input a Scheme program > as a basic string, do some conversions to that string and then output > the new string to a Scheme interpreter/compiler and run it then > finally take the output from Scheme as a new set of input into the > same Icon Program? > Scheme is a LISPy language, is it not? If so, the syntax is basically recursive (term ....) where term can be a literal identifier, literal number, quoted item or ( ) wrapped around another list of terms. Therefore the Icon bal operator will probably do well for you. However, I fear that if a quoted item may use the traditional LISP method of putting a leading ' only eg 'thingy then you might have trouble dealing with embedded items. Alternatively, you might be better off building a smarter lexical analyser (can't be that difficult since LISP syntax is so simple) and then a recursive descent parser then manipulate the resulting tree. But honestly, I'd guess that the best tool to manipulate a Scheme tree that way is by using Scheme? From icon-group-sender Wed Nov 6 08:09:00 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA6F8oA17834 for icon-group-addresses; Wed, 6 Nov 2002 08:08:51 -0700 (MST) Message-Id: <200211061508.gA6F8oA17834@baskerville.CS.Arizona.EDU> Date: Wed, 06 Nov 2002 21:07:15 +1100 From: Bruce Gordon Rennie X-Accept-Language: en To: WebsiteWill , ICON Mail List Subject: Re: Question about Icon X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Errors-To: icon-group-errors@cs.arizona.edu Status: RO Will, You might want to look at skeem which from my understanding is a scheme interpreter written in Icon. This may give you the necessary information that you are seeking. WebsiteWill wrote: > > Is there a way to have an Icon Program take as input a Scheme program as a > basic string, do some conversions to that string and then output the new > string to a Scheme interpreter/compiler and run it then finally take the > output from Scheme as a new set of input into the same Icon Program? > > Thanks, > > Will regards -- Bruce Rennie ( from God's Own Country Downunder ) Disciple of Jesus Christ in Training The Cross of Jesus Christ - Salvation for all men. Song of Solomon ( Song of Songs ) - The greatest Love Story Ever and a story for our times. Be a GOD Chaser. From icon-group-sender Thu Nov 7 08:10:46 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA7F9Sw04688 for icon-group-addresses; Thu, 7 Nov 2002 08:09:28 -0700 (MST) Message-Id: <200211071509.gA7F9Sw04688@baskerville.CS.Arizona.EDU> To: "WebsiteWill" Cc: icon-group@cs.arizona.edu Subject: Re: Question about Icon From: Ed L Cashin Date: 06 Nov 2002 19:41:10 -0500 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: icon-group-errors@cs.arizona.edu Status: RO "WebsiteWill" writes: > Is there a way to have an Icon Program take as input a Scheme > program as a basic string, do some conversions to that string and > then output the new string to a Scheme interpreter/compiler and run > it then finally take the output from Scheme as a new set of input > into the same Icon Program? I was interested in your question, so I looked up info on pipes in icon, but it looks like there is no easy way to launch another process inside of icon and then do both writing to and reading from the another process. (Perl has to jump through hoops to support this -- see the perlipc manpage.) Please anyone chime in if there is an easy way to launch a process in icon code and then do I/O to and from the process. You could, of course, manipulate the string, write it to a file on disk, run the scheme interpreter from icon with popen or open with the pipe mode (so that the scheme interpreter is reading from the file), and then read the output from the scheme interpreter through the pipe's filehandle. -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Thu Nov 7 16:44:19 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA7Ngh201603 for icon-group-addresses; Thu, 7 Nov 2002 16:42:43 -0700 (MST) Message-Id: <200211072342.gA7Ngh201603@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: "'Ed L Cashin '" , "'icon-group@CS.Arizona.EDU'" Cc: "'websitewill@cox-internet.com'" Subject: RE: Question about Icon Date: Thu, 7 Nov 2002 16:55:16 -0600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO The easy way is to use Unicon because it provides the filepair() builting function. The POSIX extensions for Icon do the same - at least according to: -----Original Message----- From: Ed L Cashin To: WebsiteWill Cc: icon-group@CS.Arizona.EDU Sent: 11/6/02 6:41 PM Subject: Re: Question about Icon "WebsiteWill" writes: > Is there a way to have an Icon Program take as input a Scheme > program as a basic string, do some conversions to that string and > then output the new string to a Scheme interpreter/compiler and run > it then finally take the output from Scheme as a new set of input > into the same Icon Program? I was interested in your question, so I looked up info on pipes in icon, but it looks like there is no easy way to launch another process inside of icon and then do both writing to and reading from the another process. (Perl has to jump through hoops to support this -- see the perlipc manpage.) Please anyone chime in if there is an easy way to launch a process in icon code and then do I/O to and from the process. You could, of course, manipulate the string, write it to a file on disk, run the scheme interpreter from icon with popen or open with the pipe mode (so that the scheme interpreter is reading from the file), and then read the output from the scheme interpreter through the pipe's filehandle. -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Fri Nov 8 08:12:43 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA8FCUw05556 for icon-group-addresses; Fri, 8 Nov 2002 08:12:30 -0700 (MST) Message-Id: <200211081512.gA8FCUw05556@baskerville.CS.Arizona.EDU> To: Art Eschenlauer Cc: "'icon-group@CS.Arizona.EDU'" Subject: Re: Question about Icon From: Ed L Cashin Date: 07 Nov 2002 20:36:57 -0500 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Art Eschenlauer writes: > The easy way is to use Unicon > > because it provides the filepair() builting function. > The POSIX extensions for Icon do the same - at least according to: > Is unicon pretty solid? I noticed that the uni.zip archive for version 10.0 doesn't expand into its own directory (usually a bad sign) and that the Install target fails with a complaint about lib/*.* being absent. Maybe I should give it another look, though. -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Fri Nov 8 08:13:23 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA8FDLg05590 for icon-group-addresses; Fri, 8 Nov 2002 08:13:21 -0700 (MST) Message-Id: <200211081513.gA8FDLg05590@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: Subject: Skeem Date: Fri, 8 Nov 2002 11:00:36 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - As a benighted Windows user I notice that the Skeem package has a file called 'Makefile' containing a script. What does this run on? Is there any documentation on Skeem or other items in the Icon libraries, apart from the comments in the source code? It would be interesting to know the thinking behind some of the items, how they came to be there and what they were for etc. Regards _John Sampson_ From icon-group-sender Fri Nov 8 16:35:33 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gA8NZ3Y23654 for icon-group-addresses; Fri, 8 Nov 2002 16:35:04 -0700 (MST) Message-Id: <200211082335.gA8NZ3Y23654@baskerville.CS.Arizona.EDU> Date: Fri, 8 Nov 2002 16:19:40 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Re: Skeem Errors-To: icon-group-errors@cs.arizona.edu Status: RO > From: "jsampson-indexer" > Date: Fri, 8 Nov 2002 11:00:36 -0000 > > As a benighted Windows user I notice that the Skeem package has a file > called 'Makefile' containing a script. What does this run on? A makefile is not exactly a script, but it gives directions on how to build a program. "Make" is a very powerful tool and is widely used on Unix for software development. The original Feldman paper describing "make" can be downloaded from links on: http://citeseer.nj.nec.com/feldman79make.html > Is there any documentation on Skeem or other items in the Icon libraries, > apart from the comments in the source code? I'm not aware of anything else for Skeem. That's true for most items in the Icon libraries. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Mon Nov 11 10:55:04 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gABHs1I09669 for icon-group-addresses; Mon, 11 Nov 2002 10:54:01 -0700 (MST) Message-Id: <200211111754.gABHs1I09669@baskerville.CS.Arizona.EDU> From: "Richard H. McCullough" To: "Gregg Townsend" , Subject: Re: UNIX tools on Windows Date: Fri, 8 Nov 2002 17:02:05 -0800 Status: RO There are now many packages of UNIX tools which run on Windows. I have personally used the following packages: Microsoft Services for Windows 3.0 only $99 only runs on latest OS -- XP, NT, 2000 MKS Toolkit 8.0 now $500 ballpark, I think will run on earlier OS -- 95, 98, ME mingw32 free -- open source The free one doesn't include as many commands, I think about 100 "standard" UNIX commands. The other two include about 300 "standard" UNIX=20 commands, and conform to POSIX standards. All three packages include make, each with some=20 minor variations in Makefile rules. If you keep your Makefiles simple, the differences won't bite you. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Dick McCullough=20 knowledge :=3D man do identify od existent done knowledge haspart list of proposition From icon-group-sender Mon Nov 11 10:56:17 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gABHuFk09841 for icon-group-addresses; Mon, 11 Nov 2002 10:56:15 -0700 (MST) Message-Id: <200211111756.gABHuFk09841@baskerville.CS.Arizona.EDU> Date: Sat, 9 Nov 2002 10:17:10 -0700 From: Clint Jeffery To: ecashin@uga.edu CC: icon-group@cs.arizona.edu Subject: Re: Question about Icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO [Ed Cashin calls into question the solidity of my darling little language:] > Is unicon pretty solid? I noticed that the uni.zip archive for > version 10.0 doesn't expand into its own directory (usually a bad sign) I am not sure you are being fair in your conclusions here, Ed. :-) > the Install target fails with a complaint about lib/*.* > being absent. Maybe I should give it another look, though. Hmm, I grant that this is a sloppy oversight. I backed Icon 9.4's Install rule into Unicon, but I disagree with their "lib" directory organization, so Unicon uses a different one. I need to modify the Install target to make better sense. Thanks for mentioning it. As to whether Unicon is pretty solid, I had better let Unicon users answer that one. It has enjoyed a long lingering beta period and is being used by a lot of people who are doing interesting things with it. Clint jeffery@cs.nmsu.edu From icon-group-sender Mon Nov 11 10:56:58 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gABHuuw09889 for icon-group-addresses; Mon, 11 Nov 2002 10:56:56 -0700 (MST) Message-Id: <200211111756.gABHuuw09889@baskerville.CS.Arizona.EDU> To: jeffery@cs.nmsu.edu Cc: icon-group@cs.arizona.edu Subject: Re: Question about Icon From: Ed L Cashin Date: 09 Nov 2002 12:47:44 -0500 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Clint Jeffery writes: > [Ed Cashin calls into question the solidity of my darling little language:] > > > Is unicon pretty solid? I noticed that the uni.zip archive for > > version 10.0 doesn't expand into its own directory (usually a bad sign) > > I am not sure you are being fair in your conclusions here, Ed. :-) No, I agree. It wasn't a judgement so much as a casual first impression based on my own expectations and biases. I'd expect that other folks might have a similar reaction, but then I don't know the reasons behind the decision against unicon unpacking into a unicon-10.0 directory. > > the Install target fails with a complaint about lib/*.* > > being absent. Maybe I should give it another look, though. > > Hmm, I grant that this is a sloppy oversight. I backed Icon 9.4's > Install rule into Unicon, but I disagree with their "lib" directory > organization, so Unicon uses a different one. I need to modify > the Install target to make better sense. Thanks for mentioning it. Sure! > As to whether Unicon is pretty solid, I had better let Unicon users > answer that one. It has enjoyed a long lingering beta period and is > being used by a lot of people who are doing interesting things with > it. So unicon's more of an active project and maybe only recently stable enough to consider splitting the release into stable (good for unicon beginners) and development versions. I'm looking forward to checking it out. Thanks for the response. -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Mon Nov 11 10:57:21 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gABHvHk09932 for icon-group-addresses; Mon, 11 Nov 2002 10:57:18 -0700 (MST) Message-Id: <200211111757.gABHvHk09932@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: Subject: RE: Skeem Date: Sat, 9 Nov 2002 20:33:28 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - Many thanks. > > Is there any documentation on Skeem or other items in the Icon > libraries, > > apart from the comments in the source code? > > I'm not aware of anything else for Skeem. > That's true for most items in the Icon libraries. Also for other libraries, I find. It seems a pity, because so much of educational value must be lost. Scientists usually write up their work, don't they? Regards _John Sampson_ From icon-group-sender Mon Nov 11 13:48:29 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gABKm5A17505 for icon-group-addresses; Mon, 11 Nov 2002 13:48:05 -0700 (MST) Message-Id: <200211112048.gABKm5A17505@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: "'Richard H. McCullough'" , Gregg Townsend , icon-group@cs.arizona.edu Subject: Cygwin (RE: UNIX tools on Windows) Date: Mon, 11 Nov 2002 13:06:26 -0600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Cygwin is also free (as in available without charge). In contrast to the mingw32 approach (which is analogous to statically linking on Unix), Cygwin compiles binaries that are dependent upon its own DLL. It comes with a setup program that provides all sorts of packages, including even an X server and several open source database management systems. Check it out - it's windows programming the way that it should be (i.e., sane); you start it up and you are in bash! On good days it's available from http://sources.redhat.com/cygwin/ -----Original Message----- From: Richard H. McCullough [mailto:rhm@cdepot.net] Sent: Friday, November 08, 2002 7:02 PM To: Gregg Townsend; icon-group@CS.Arizona.EDU Subject: Re: UNIX tools on Windows There are now many packages of UNIX tools which run on Windows. I have personally used the following packages: Microsoft Services for Windows 3.0 only $99 only runs on latest OS -- XP, NT, 2000 MKS Toolkit 8.0 now $500 ballpark, I think will run on earlier OS -- 95, 98, ME mingw32 free -- open source The free one doesn't include as many commands, I think about 100 "standard" UNIX commands. The other two include about 300 "standard" UNIX=20 commands, and conform to POSIX standards. All three packages include make, each with some=20 minor variations in Makefile rules. If you keep your Makefiles simple, the differences won't bite you. Dick McCullough=20 knowledge :=3D man do identify od existent done knowledge haspart list of proposition From icon-group-sender Mon Nov 11 19:33:45 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAC2XNo03073 for icon-group-addresses; Mon, 11 Nov 2002 19:33:23 -0700 (MST) Message-Id: <200211120233.gAC2XNo03073@baskerville.CS.Arizona.EDU> Date: Mon, 11 Nov 2002 14:32:26 -0700 From: Clint Jeffery To: art.eschenlauer@sufsys.com CC: rhm@cdepot.net, gmt@cs.arizona.edu, icon-group@cs.arizona.edu Subject: Re: Cygwin (RE: UNIX tools on Windows) Errors-To: icon-group-errors@cs.arizona.edu Status: RO [Art puts in a good plug for Cygwin] I don't believe this interpretation of mingw32 is entirely complete. In contrast with cygwin which uses one or more big UNIX compatibility DLLs, mingw32's goal is to produce "native" Windows applications that link to the DLL's that come with Windows. It is true that any UNIX compatibility layered on top of Win32 in that case is statically linked, but since its goal is for gcc to run well under Windows, rather than to make it into a UNIX, it may produce executables that are more attractive for some applications than does a cygwin-based UNIX-compatible Windows build. For example, you can deliver a .exe that works without having the customer install Cygwin. Having said all that, I am all in favor of UNIX-compatibility tools on Windows, and all in favor of supporting Cygwin in our source code. I only wish Microsoft had had the minimal sense of technical vision it would have taken to make Windows a real UNIX with real X11 in the first place. Apple has pretty much achieved this... Clint From icon-group-sender Mon Nov 11 19:34:46 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAC2Yiw03153 for icon-group-addresses; Mon, 11 Nov 2002 19:34:44 -0700 (MST) Message-Id: <200211120234.gAC2Yiw03153@baskerville.CS.Arizona.EDU> From: Art Eschenlauer To: "'jeffery@cs.nmsu.edu'" , Art Eschenlauer Cc: rhm@cdepot.net, gmt@cs.arizona.edu, icon-group@cs.arizona.edu Subject: RE: Cygwin (RE: UNIX tools on Windows) Date: Mon, 11 Nov 2002 15:38:40 -0600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO [Clint contrasts the Windows compatibility of Cygwin and mingw32] Yes, Apple deserves Kudos for going the unix-like path! The nice thing about the Cygwin environment is that it is so feature rich. Most of what you need is already available as packages, and if not then you can readily compile and run many common software packages on Windows with little more effort than it takes to say ./configure; make; make install Since there are so many packages for it, it is more likely than not that some odd unix utility that someone used in their makefile is already deployed onto your machine. Sadly, I have not succeeded in building Unicon with Cygwin, however. In other words, IMHO, if you want to build stuff to give to others, mingw32 rocks. If you want an environment that makes you immediately productive on windows, Cygwin is a great help. From icon-group-sender Mon Nov 11 19:35:25 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAC2ZNQ03238 for icon-group-addresses; Mon, 11 Nov 2002 19:35:23 -0700 (MST) Message-Id: <200211120235.gAC2ZNQ03238@baskerville.CS.Arizona.EDU> From: "Richard H. McCullough" To: , Cc: , Subject: Re: Cygwin (RE: UNIX tools on Windows) Date: Mon, 11 Nov 2002 15:32:58 -0800 Status: RO The Microsoft SFU 3.0 package does include X Window. I haven't tried to pin down all the details, but I think this is the case: 1. their Korn Shell logs in using X Window 2. their X Window library is several versions behind what is current today. My main disappointment is that the Korn Shell can create and use soft links, but Windows XP Pro itself (including Windows Explorer and cmd.exe) does not recognize them. Only the UNIX package of commands recognize soft links. I find soft links very useful in my development work. The name of the MS UNIX subsystem is "Interix". Interix includes FTP and TELNET servers. Vanilla Windows XP Pro also has a TELNET server and good networking support. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Dick McCullough=20 knowledge :=3D man do identify od existent done knowledge haspart list of proposition From icon-group-sender Wed Nov 13 13:18:02 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gADKGiM03289 for icon-group-addresses; Wed, 13 Nov 2002 13:16:44 -0700 (MST) Message-Id: <200211132016.gADKGiM03289@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Icon and .NET X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Wed, 13 Nov 2002 18:02:01 GMT X-Complaints-To: abuse@verizon.net To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Has anyone looked at implementing Icon or Unicon in C#? Maybe we could introduce Icon to the .NET world. From icon-group-sender Tue Nov 19 08:18:14 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJFFoQ07727 for icon-group-addresses; Tue, 19 Nov 2002 08:15:50 -0700 (MST) Message-Id: <200211191515.gAJFFoQ07727@baskerville.CS.Arizona.EDU> From: James P Scully X-Newsgroups: comp.lang.icon Subject: not dead? Date: Mon, 18 Nov 2002 21:34:45 -0700 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO wow...the last post was over a year ago... I just signed up to this newsgroup, expecting to nuzzle up against a tree's worth or so of paper, filled with awe-inspiring, newly printed newsgroup messages tonight...I was expecting lots of enthusiasm and support for Icon... Icon.NET even - ... but I find nothing? What gives? Is anybody out there? From icon-group-sender Tue Nov 19 08:51:28 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJFpIs09445 for icon-group-addresses; Tue, 19 Nov 2002 08:51:18 -0700 (MST) Message-Id: <200211191551.gAJFpIs09445@baskerville.CS.Arizona.EDU> From: "Edward A. Feustel" X-Newsgroups: comp.lang.icon Subject: Re: not dead? Date: Tue, 19 Nov 2002 07:08:58 -0500 X-Complaints-To: abuse@rcn.com X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MSMail-Priority: Normal To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Yes, we are out here. At a minimum you should have seen the monthly icon FAQ post. You might also want to look in on unicon on sourceforge where Clinton Jeffrey and company are using icon as a base and are adding network and database connections. Ed F. "James P Scully" wrote in message news:Pine.GSO.4.33.0211181951050.3748-100000@lectura.CS.Arizona.EDU... > wow...the last post was over a year ago... > I just signed up to this newsgroup, expecting to nuzzle up against a > tree's worth or so of paper, filled with awe-inspiring, newly printed > newsgroup messages tonight...I was expecting lots of enthusiasm and > support for Icon... Icon.NET even - ... but I find nothing? What gives? > Is anybody out there? > From icon-group-sender Tue Nov 19 12:45:12 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJJidg21713 for icon-group-addresses; Tue, 19 Nov 2002 12:44:39 -0700 (MST) Message-Id: <200211191944.gAJJidg21713@baskerville.CS.Arizona.EDU> Date: Tue, 19 Nov 2002 11:27:44 -0500 (EST) From: Taybin Rutkin X-Sender: trutkin@planck.clarku.edu To: James P Scully cc: icon-group@cs.arizona.edu Subject: Re: not dead? Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Mon, 18 Nov 2002, James P Scully wrote: > wow...the last post was over a year ago... > I just signed up to this newsgroup, expecting to nuzzle up against a > tree's worth or so of paper, filled with awe-inspiring, newly printed > newsgroup messages tonight...I was expecting lots of enthusiasm and > support for Icon... Icon.NET even - ... but I find nothing? What gives? > Is anybody out there? I believe the mailing list is slightly more active than the newsgroup. I know it hasn't been a year since I've received a posting from it. On a side note, I recently used Icon for some text processing, and it is *still* the most enjoyable language I've ever used. Taybin -- http://www.piratesvsninjas.com From icon-group-sender Tue Nov 19 12:48:19 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJJmDg21892 for icon-group-addresses; Tue, 19 Nov 2002 12:48:13 -0700 (MST) Message-Id: <200211191948.gAJJmDg21892@baskerville.CS.Arizona.EDU> From: jleger@afslogistics.com (Jonathan Leger) X-Newsgroups: comp.lang.icon Subject: I know why Icon isn't popular. Date: 19 Nov 2002 10:31:38 -0800 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO To ward off the flames, let me first say that Icon is the most elegant programming language that I've ever used. I love it. It takes the "mundane" issues like storage and typing out of the hands of the developer and lets him focus on what's really important: application functionality. But Icon lacks the tools and technologies needed by real-world applications programmers, at least in the Windows world. It does not have (or at least I am not aware of it having): 1) A strong IDE. 2) A strong visual GUI developer. 3) Built-in real-world database support (though Unicon took care of this with ODBC). To be accepted into the world of Windows application programmers, Icon needs: 4) Support for technologies like COM+. 5) The ability to compile Icon libraries to DLLs for use in other languages. In fact, if Icon could just do #5 I would gladly write the middle-tier for my database applications in Unicon for the ODBC and just use a good front end like Visual Basic for making pretty forms. My $0.02. Jonathan Leger From icon-group-sender Tue Nov 19 16:33:44 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJNXLg19591 for icon-group-addresses; Tue, 19 Nov 2002 16:33:21 -0700 (MST) Message-Id: <200211192333.gAJNXLg19591@baskerville.CS.Arizona.EDU> Date: Tue, 19 Nov 2002 13:32:59 -0700 From: Clint Jeffery To: jleger@afslogistics.com CC: icon-group@cs.arizona.edu Subject: I know why Icon is very popular. Errors-To: icon-group-errors@cs.arizona.edu Status: RO Icon is one of the most popular languages ever created as a result of an academic research project. It is fine to ask what would make it More popular, indeed, I ask that all the time. But one's expectations for any language not invented at Microsoft, Sun, IBM, or AT&T must be modest. Only several small miracles of marketing and timing can popularize such a language, even if it has all the bells and whistles you mention. And whining about it not being popular does not help make it popular or cause the features you ask for to become implemented by some puff of inspiration. [Jonathan wishes Icon had an IDE, a GUI builder, database support, COM+ support, and the ability to create DLL's callable from other languages.] Jonathan, this is public domain software and most improvements are made by volunteers, why don't you add these things to your version of Icon? Actually, Unicon has database support and a strong visual GUI developer. So why don't you add a module to use Icon and Unicon from Visual Studio, write a COM+ interface, and write a DLL generator facility, and then you will be all set! Share your results with the rest of the community, and you will be popular. Seriously, these things will get implemented only when someone volunteers and does them, or someone pays to have them done, possibly for use on a specific project. That's how database facilities came about... Clint jeffery@cs.nmsu.edu From icon-group-sender Tue Nov 19 16:35:06 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJNZ0Y19673 for icon-group-addresses; Tue, 19 Nov 2002 16:35:00 -0700 (MST) Message-Id: <200211192335.gAJNZ0Y19673@baskerville.CS.Arizona.EDU> From: Jon Leger To: "'jeffery@cs.nmsu.edu'" , Jon Leger Cc: icon-group@cs.arizona.edu Subject: RE: I know why Icon is very popular. Date: Tue, 19 Nov 2002 15:09:59 -0600 Status: RO -----Original Message----- But one's expectations for any language not invented at Microsoft, Sun, IBM, or AT&T must be modest. -------------------------- I agree with this. My post was more a response to the many posts regarding wish lists for Icon and the many persons who wondered at why Icon is not more popular than it is. -----Original Message----- Only several small miracles of marketing and timing can popularize such a language, even if it has all the bells and whistles you mention. And whining about it not being popular does not help make it popular or cause the features you ask for to become implemented by some puff of inspiration. -------------------------- You don't have to be so sensitive. I was not insulting the language or defaming Icon in any way by pointing out that it does not have as much use as other languages in real-world applications because of the tools it lacks. I was simply making an observation. -----Original Message----- Jonathan, this is public domain software and most improvements are made by volunteers, why don't you add these things to your version of Icon? Actually, Unicon has database support and a strong visual GUI developer. So why don't you add a module to use Icon and Unicon from Visual Studio, write a COM+ interface, and write a DLL generator facility, and then you will be all set! Share your results with the rest of the community, and you will be popular. -------------------------- Aha! Finally a useful piece of information from this post! I'm glad to know that Unicon has a strong visual GUI developer. I will certainly look into it. I am not a C programmer and so have little to add to the development of Icon as a language, although I am working on an Icon-driven database which my benchmarks are showing to be faster than MS SQL Server 7, so that could be useful when it's done and will certainly be released to the public. -----Original Message----- Seriously, these things will get implemented only when someone volunteers and does them, or someone pays to have them done, possibly for use on a specific project. That's how database facilities came about... --------------------------- And again I say... I was not saying that Icon is not an awesome language, my point is ONLY that Icon (currently) lacks many of the tools for real-world application development. And when that changes I will be one happy programmer. Jonathan Leger From icon-group-sender Tue Nov 19 16:36:20 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJNaFw19778 for icon-group-addresses; Tue, 19 Nov 2002 16:36:15 -0700 (MST) Message-Id: <200211192336.gAJNaFw19778@baskerville.CS.Arizona.EDU> From: Christopher Browne X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: 19 Nov 2002 23:28:53 GMT X-Draft-From: ("nntp+chvatal:comp.lang.icon" 197) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Every Mode Acknowledges Customized Strokes Microsoft: We've got the solution for the problem we sold you. X-Uboat-Death-Message: BOMBED BY IRC SERVER. SINKING. U-14. To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The world rejoiced as jleger@afslogistics.com (Jonathan Leger) wrote: > But Icon lacks the tools and technologies needed by real-world > applications programmers, at least in the Windows world. It does not > have (or at least I am not aware of it having): > > 1) A strong IDE. > 2) A strong visual GUI developer. > 3) Built-in real-world database support (though Unicon took care of > this with ODBC). > > To be accepted into the world of Windows application programmers, Icon > needs: > > 4) Support for technologies like COM+. > 5) The ability to compile Icon libraries to DLLs for use in other > languages. In the Unix world, the /lack/ of all of those things is generally considered a /benefit/, and if those technologies were added to Icon, that would almost certainly make it look /less attractive/ to the very sorts of people that would be more likely to consider Icon than the "Windows flunkies." And before you dismiss that as a bigoted statement (which, to a goodly degree, it is), ask yourself if Microsoft is likely to add Icon into its "official tool set." The answer is "not bloody likely." The sorts of folks that are a /lot/ more likely to be accepting of Icon are more likely to be "Unix fans" that will fall into the "bigoted" group that would agree with my first paragraph... Note that /everyone/ is a bigot, in this context, whether we're talking about: a) Windows bigots, that would regard any deployment of Icon that /wasn't/ bundled as "Official Microsoft(tm) VisualIcon Studio" as being futile because no /real/ programmer could /possibly/ get any work done without their "VisualIcon Studio," or b) Unix bigots that regard things the exact opposite way... Since it is /totally/ improbable that Microsoft will be replacing VB.Net with "VisualIcon Studio," I suggest that you're better off trying to sell Icon to the Unix bigots... -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/languages.html Oh, no. Not again. -- a bowl of petunias From icon-group-sender Wed Nov 20 08:58:09 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKFv6Y23879 for icon-group-addresses; Wed, 20 Nov 2002 08:57:06 -0700 (MST) Message-Id: <200211201557.gAKFv6Y23879@baskerville.CS.Arizona.EDU> From: jleger@afslogistics.com (Jonathan Leger) X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: 20 Nov 2002 06:11:31 -0800 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote in message news:... > In the Unix world, the /lack/ of all of those things is generally > considered a /benefit/, and if those technologies were added to Icon, > that would almost certainly make it look /less attractive/ to the very > sorts of people that would be more likely to consider Icon than the > "Windows flunkies." I can't say that I personally disagree. I've often wished that the world would go back to text screens and out of Windows (or X-Windows, for the Unix bigots). I love Icon "as is"--I really do. I just wish that I could get a job programming Icon in the "real world." Unfortunately the "real world" is mostly controlled by the Windows bigots, so here I am... > > And before you dismiss that as a bigoted statement (which, to a goodly > degree, it is), ask yourself if Microsoft is likely to add Icon into > its "official tool set." > > The answer is "not bloody likely." Ah, too true... but I can dream, can't I? > Since it is /totally/ improbable that Microsoft will be replacing > VB.Net with "VisualIcon Studio," I suggest that you're better off > trying to sell Icon to the Unix bigots... Well, the problem with that is that Unix bigots would almost never PAY for anything that has to do with software development to begin with. The first thing I'd be asking if Microsoft tried to sell VisualIcon Studio is "Where can I get the OpenSource version?" Jonathan Leger From icon-group-sender Wed Nov 20 09:02:16 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKG2Co24255 for icon-group-addresses; Wed, 20 Nov 2002 09:02:12 -0700 (MST) Message-Id: <200211201602.gAKG2Co24255@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: Subject: Tabs in regular expressions Date: Wed, 20 Nov 2002 14:52:25 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - Is there a way of representing tab characters (ASCII 9) in the regular expressions implemented in the Icon library? Regards _John Sampson_ From icon-group-sender Wed Nov 20 12:56:16 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKJt7w10247 for icon-group-addresses; Wed, 20 Nov 2002 12:55:07 -0700 (MST) Message-Id: <200211201955.gAKJt7w10247@baskerville.CS.Arizona.EDU> Date: Wed, 20 Nov 2002 11:11:15 -0500 (EST) From: Taybin Rutkin X-Sender: trutkin@planck.clarku.edu To: jsampson-indexer cc: icon-group@cs.arizona.edu Subject: Re: Tabs in regular expressions Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Wed, 20 Nov 2002, jsampson-indexer wrote: > Is there a way of representing tab characters (ASCII 9) in the regular > expressions implemented in the Icon library? The usual '\t' doesn't work? Taybin -- http://www.piratesvsninjas.com From icon-group-sender Wed Nov 20 12:56:43 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKJucE10349 for icon-group-addresses; Wed, 20 Nov 2002 12:56:38 -0700 (MST) Message-Id: <200211201956.gAKJucE10349@baskerville.CS.Arizona.EDU> From: Patrick Scheible X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: 20 Nov 2002 17:26:39 GMT X-Newsreader: Gnus v5.3/Emacs 19.34 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Icon's other problem is the name. It was a good name when it was thought of, but now when evangelizing about it, you have to spend the first five minutes of the conversation explaining that it has nothing whatever to do with icons on the computer screen. (Maybe Unicon will help that, too.) -- Patrick From icon-group-sender Wed Nov 20 12:57:21 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKJvI610421 for icon-group-addresses; Wed, 20 Nov 2002 12:57:18 -0700 (MST) Message-Id: <200211201957.gAKJvI610421@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: , Subject: RE: Tab char Date: Wed, 20 Nov 2002 18:01:46 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - I can get "\s" to work, but not "\t". "\t" is not listed in the library source file REGEXP.ICN. I also tried "\\t" in case of some extra escape that might be needed. Regards _John Sampson_ > Would > "\t" > do it? (See pg254 of G&G for the complete list.) > > HTH, > Steve Hunter > > From icon-group-sender Wed Nov 20 16:46:33 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKNjNs00365 for icon-group-addresses; Wed, 20 Nov 2002 16:45:23 -0700 (MST) Message-Id: <200211202345.gAKNjNs00365@baskerville.CS.Arizona.EDU> Date: Wed, 20 Nov 2002 15:22:59 -0500 (EST) From: Taybin Rutkin X-Sender: trutkin@planck.clarku.edu To: jsampson-indexer cc: icon2002@OptOnLine.net, icon-group@cs.arizona.edu Subject: RE: Tab char Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Wed, 20 Nov 2002, jsampson-indexer wrote: > I can get "\s" to work, but not "\t". "\t" is not listed in the library > source file REGEXP.ICN. I also tried "\\t" in case of some extra escape that > might be needed. I had a similar problem with tabs. I fixed it by converting them to spaces using $file = map($file, '\t', ' ') Taybin -- http://www.piratesvsninjas.com From icon-group-sender Wed Nov 20 16:48:37 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKNmVo00686 for icon-group-addresses; Wed, 20 Nov 2002 16:48:31 -0700 (MST) Message-Id: <200211202348.gAKNmVo00686@baskerville.CS.Arizona.EDU> X-Authentication-Warning: weaver.tuc.noao.edu: swampler set sender to swampler@noao.edu using -f Subject: RE: Tab char From: Steve Wampler To: jsampson-indexer Cc: icon2002@OptOnLine.net, icon-group@cs.arizona.edu Date: 20 Nov 2002 13:26:32 -0800 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Wed, 2002-11-20 at 10:01, jsampson-indexer wrote: > Hello - > > I can get "\s" to work, but not "\t". "\t" is not listed in the library > source file REGEXP.ICN. I also tried "\\t" in case of some extra escape that > might be needed. Hmmm, do you have a short sample showing \t as not working? I notice it is used in the definition of Re_Space in regexp.icn. It's a standard Icon string escape and should have worked without any problem at all (no different than using 'a', say). -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Wed Nov 20 16:49:33 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAKNnSo00793 for icon-group-addresses; Wed, 20 Nov 2002 16:49:28 -0700 (MST) Message-Id: <200211202349.gAKNnSo00793@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: , Subject: RE: tab in regex Date: Wed, 20 Nov 2002 23:05:02 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - Thanks for the advice, I'll do some tweaking. > [BTW, what is your application that's prompting the use of regex's? > I always found Icon's native pattern-matching to be more powerful, > & easy to trace.] I know real Iconeers don't use regex's, but the program I am using takes them as user input - being brief one-liners they are suitable for this. In my case here I think mapping tabs to another character and then back again is probably the best kludge. The program searches tab-delimited data files so the tab char has to be distinguished from other white-space chars. Regards _John Sampson_ From icon-group-sender Thu Nov 21 08:27:30 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALFPUk09955 for icon-group-addresses; Thu, 21 Nov 2002 08:25:30 -0700 (MST) Message-Id: <200211211525.gALFPUk09955@baskerville.CS.Arizona.EDU> From: Lyndon Nerenberg X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: 20 Nov 2002 16:37:22 -0700 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Jonathan> Well, the problem with that is that Unix bigots would Jonathan> almost never PAY for anything that has to do with Jonathan> software development to begin with. The first thing I'd Jonathan> be asking if Microsoft tried to sell VisualIcon Studio Jonathan> is "Where can I get the OpenSource version?" The first thing *I* would ask is: why do I need one? What do you need other than text editor and make? --lyndon From icon-group-sender Thu Nov 21 09:03:51 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALG3hM12630 for icon-group-addresses; Thu, 21 Nov 2002 09:03:43 -0700 (MST) Message-Id: <200211211603.gALG3hM12630@baskerville.CS.Arizona.EDU> X-Authentication-Warning: weaver.tuc.noao.edu: swampler set sender to swampler@noao.edu using -f Subject: RE: tab in regex From: Steve Wampler To: jsampson-indexer Cc: icon2002@OptOnLine.net, icon-group@cs.arizona.edu Date: 21 Nov 2002 06:57:35 -0800 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Wed, 2002-11-20 at 15:05, jsampson-indexer wrote: > I know real Iconeers don't use regex's, but the program I am using takes > them as user input - being brief one-liners they are suitable for this. In > my case here I think mapping tabs to another character and then back again > is probably the best kludge. The program searches tab-delimited data files > so the tab char has to be distinguished from other white-space chars. John, I haven't been able to produce a problem with using tabs in REs. For example: ----------------------------------------- link regexp procedure main(args) pat := RePat("\t") str := "now is the time " write(image(str)) str ? { while write(tab(ReFind(pat))) do move(1) } end ------------------------------------------- works as expected, producing: ------------------------------------------- "now\tis the\ttime\t" now is the time ------------------------------------------- Do you have a sample program that illustrates the problem you're having that you can share? Perhaps it's really some other problem masquerading as a problem with tabs in regex's. -Steve -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Thu Nov 21 09:04:06 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALG45A12672 for icon-group-addresses; Thu, 21 Nov 2002 09:04:05 -0700 (MST) Message-Id: <200211211604.gALG45A12672@baskerville.CS.Arizona.EDU> Date: Thu, 21 Nov 2002 14:57:09 +0100 From: Atle X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. X-Complaints-To: abuse@skynet.be To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Christopher Browne wrote: > > In the Unix world, the /lack/ of all of those things is generally > considered a /benefit/, and if those technologies were added to Icon, > that would almost certainly make it look /less attractive/ to the very > sorts of people that would be more likely to consider Icon than the > "Windows flunkies." I think this not only goes in the Unix world, it goes in the world of programmers in general. This preference is generally what separates 'programmers' from 'users'. I don't even think it is limited to programming, the whole thing started at the famous model railroad club where most preferrred to 'play with the trains' but some preferred to stay under the board and 'play with the wiring'. Some like to be behind the wheel, others under the hood. If Icon became an 'IDE' language, it might initially attract some programmers, but the kind of programmers that you can find in the Visual Basic or Visual this-and-that world probably would not come to grips with such a powerful language anyway ... ... those were my to lira ... Atle From icon-group-sender Thu Nov 21 12:34:35 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALJY3s07097 for icon-group-addresses; Thu, 21 Nov 2002 12:34:03 -0700 (MST) Message-Id: <200211211934.gALJY3s07097@baskerville.CS.Arizona.EDU> From: "Shmuel (Seymour J.) Metz" X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: Thu, 21 Nov 2002 10:40:06 -0500 Mail-Copies-To: nobody X-Cise: tanbanso@iinet.net.au X-CompuServe-Customer: Yes X-Coriate: admin@interspeed.co.nz X-Ecrate: tanandtanlawyers.com X-Punge: Micro$oft X-Sanguinate: themvsguy@email.com X-Terminate: SPA(GIS) X-Tinguish: Mark Griffith X-Treme: C&C,DWS X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 X-Complaints-To: abuse@supernews.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In <55640c47.0211200611.6c801821@posting.google.com>, on 11/20/2002 at 06:11 AM, jleger@afslogistics.com (Jonathan Leger) said: >Well, the problem with that is that Unix bigots would almost never >PAY for anything that has to do with software development to begin >with. Have you looked at how expensive some of the Unix software is? The *bsd and Linux communities may be used to free software, but the Unix community is used to paying big bucks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2, Team OS/2, Team PL/I Any unsolicited commercial junk E-mail will be subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. I mangled my E-mail address to foil automated spammers; reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org From icon-group-sender Thu Nov 21 12:36:09 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALJa5A07318 for icon-group-addresses; Thu, 21 Nov 2002 12:36:06 -0700 (MST) Message-Id: <200211211936.gALJa5A07318@baskerville.CS.Arizona.EDU> Subject: Re: I know why Icon isn't popular. To: icon-group@cs.arizona.edu From: "Joel I Bolonick" Date: Thu, 21 Nov 2002 09:31:02 -0800 X-MIMETrack: Serialize by Router on USFRMMTA01/FRM/PEC(Release 5.0.8 |June 18, 2001) at 11/21/2002 12:33:38 PM Errors-To: icon-group-errors@cs.arizona.edu Status: RO Although I hate to get involved in these "my language is better than yours" debates, I can't resist putting my 2 cents into this discussion. Icon is a fine language in the UNIX environment which just hasn't been picked up by commercial developers or the open-source community to popularize it and to add the enhancements which many programmers like. It has the misfortune of overlapping in application and functionality with Perl, which, for better or worse, has become the default high-level text-oriented application language, although Perl's inelegance is enough to horrify many professional programmers like myself. Also, since Icon is not object-oriented it falls short of the current fads in computer languages. Because of these issues, it just hasn't been seen as a sexy language to promote. I've written several very large applications in Icon and can say that, although lacking in some features which would make it more self-documenting, it's a great language for string-oriented problems which require complex data structures. My only real complaints are: (1) it would be nice if there were a more explicit way of defining data structures which would make the structure more obvious and (2) it would have been nice if all the fancy string-parsing stuff from SNOBOL had been incorporated by Griswold as part of the language. The latter feature would make the use of regular expressions completely unncessary except for those committed to their terse syntax. From icon-group-sender Thu Nov 21 16:49:39 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gALNmeQ10829 for icon-group-addresses; Thu, 21 Nov 2002 16:48:40 -0700 (MST) Message-Id: <200211212348.gALNmeQ10829@baskerville.CS.Arizona.EDU> Date: Thu, 21 Nov 2002 12:44:25 -0700 From: Clint Jeffery To: swampler@noao.edu CC: jsampson@indexes.u-net.com, icon2002@OptOnLine.net, icon-group@cs.arizona.edu Subject: Re: tab in regex Errors-To: icon-group-errors@cs.arizona.edu Status: RO In Steve's example, the \t is turned into a tab character by the Icon translator without RePat having to lift a finger. Maybe the problem is when the string supplied to RePat() is typed by a user as input data rather than hardwired into a string literal. In that case \t would be interpreted the same as the string literal "\\t" and the question is whether RePat() does such escape processing. But this is all just a guess as to what the issue is. :-) Clint jeffery@cs.nmsu.edu From icon-group-sender Thu Nov 21 17:20:11 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAM0K5c13075 for icon-group-addresses; Thu, 21 Nov 2002 17:20:05 -0700 (MST) Message-Id: <200211220020.gAM0K5c13075@baskerville.CS.Arizona.EDU> X-Authentication-Warning: weaver.tuc.noao.edu: swampler set sender to swampler@noao.edu using -f Subject: Re: tab in regex From: Steve Wampler To: jeffery@cs.nmsu.edu Cc: jsampson@indexes.u-net.com, icon2002@OptOnLine.net, icon-group@cs.arizona.edu Date: 21 Nov 2002 12:56:29 -0800 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Thu, 2002-11-21 at 11:44, Clint Jeffery wrote: > > In Steve's example, the \t is turned into a tab character by the Icon > translator without RePat having to lift a finger. Maybe the problem is > when the string supplied to RePat() is typed by a user as input data > rather than hardwired into a string literal. In that case \t would be > interpreted the same as the string literal "\\t" and the question is > whether RePat() does such escape processing. But this is all just a guess > as to what the issue is. Yes, that's exactly what I meant by "some other problem masquerading...". But if the user is typing in the text, then they can just type a TAB character and things should work just fine [I tested that case, also]. -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Thu Nov 21 17:20:31 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAM0KTk13109 for icon-group-addresses; Thu, 21 Nov 2002 17:20:29 -0700 (MST) Message-Id: <200211220020.gAM0KTk13109@baskerville.CS.Arizona.EDU> From: jleger@afslogistics.com (Jonathan Leger) X-Newsgroups: comp.lang.icon Subject: Re: I know why Icon isn't popular. Date: 21 Nov 2002 12:00:56 -0800 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Atle wrote in message news:<3ddce97b$0$86562$ba620e4c@news.skynet.be>... > If Icon became an 'IDE' language, it might initially attract some > programmers, but the kind of programmers that you can find in the Visual > Basic or Visual this-and-that world probably would not come to grips > with such a powerful language anyway ... > > Atle I must disagree with this. I am (professionally) a Visual Basic programmer, but if given a choice I would love to be a professional Icon programmer. I have been using Icon for years, and have certainly "come to grips" with the language. Unfortunately there are no jobs out there for Icon programmers. I think that many programmers (such as myself) started with the Visual this-and-that languages because that's what the market was looking for, not because they are "easy." Though your statement may be true for some, or maybe even most, it is certainly not true of all. I am an example of that. Jon From icon-group-sender Thu Nov 21 17:20:43 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAM0KfY13144 for icon-group-addresses; Thu, 21 Nov 2002 17:20:41 -0700 (MST) Message-Id: <200211220020.gAM0KfY13144@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: "Steve Wampler" , Subject: RE: tab in regex Date: Thu, 21 Nov 2002 21:23:21 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - I am sure entering a tab char by pressing the tab key would work, but in your example you are not entering it as user-input, i.e. at run time. I was under the impression that in Perl regexps the usual style was "\t" (see 'Programming Perl', 2nd Edn., p.64). I am really not bothered because I can substitute another character before presenting the input string to the library procedure. The test program I am using is below (hoping the lines don't get disrupted):- ############################################ # # Testing Icon regular expressions # ############################################ link regexp procedure main() write("Enter pattern (regexp)") pattern := read() pattern := map(pattern,"\xdd","\x7c") # vertical slash problem write("Enter string in which pattern is to be found") rope := read() write("pattern is ",pattern) write("string is ",rope) RePat(pattern) write("Match positions:") every write(ReMatch(pattern,rope)) write("Find positions:") every write(ReFind(pattern,rope)) end Regards _John Sampson_ From icon-group-sender Thu Nov 21 17:20:53 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAM0Kpc13174 for icon-group-addresses; Thu, 21 Nov 2002 17:20:51 -0700 (MST) Message-Id: <200211220020.gAM0Kpc13174@baskerville.CS.Arizona.EDU> From: "jsampson-indexer" To: Subject: RE: I know why Icon isn't popular. Date: Thu, 21 Nov 2002 21:23:20 -0000 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Hello - Some of us are stuck with Windows rather than being Windows wallies. Nowadays there are more and better ports to Windows than there were. I don't see why the distinction between Unix and Windows types shouldn't break down in due course, as the distinction between jazz cats and classical music enthusiasts might. It depends on one lot not seeing themselves as superior to the other. Regards _John Sampson_ From icon-group-sender Fri Nov 22 08:30:40 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAMFT1Y20411 for icon-group-addresses; Fri, 22 Nov 2002 08:29:01 -0700 (MST) Message-Id: <200211221529.gAMFT1Y20411@baskerville.CS.Arizona.EDU> X-Authentication-Warning: weaver.tuc.noao.edu: swampler set sender to swampler@noao.edu using -f Subject: Re: tab in regex From: Steve Wampler To: jeffery@cs.nmsu.edu Cc: con2002@OptOnLine.net, icon-group@cs.arizona.edu Date: 22 Nov 2002 07:20:19 -0800 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Thu, 2002-11-21 at 11:44, Clint Jeffery wrote: > > In Steve's example, the \t is turned into a tab character by the Icon > translator without RePat having to lift a finger. Maybe the problem is > when the string supplied to RePat() is typed by a user as input data > rather than hardwired into a string literal. In that case \t would be > interpreted the same as the string literal "\\t" and the question is > whether RePat() does such escape processing. But this is all just a guess > as to what the issue is. (This is going out to icon-group because may the content useful). Clint is, naturally, exactly right. It's not a problem with regexp.icn, per se, but rather with the fact that strings entered as constants in a program are handled differently by Icon than strings entered as input. This difference is a good thing in many cases, but is still a nuisance in situations such as this. It turns out that Bob Alexander was aware of this and addresses the issue in the comments he supplied within regexp.icn. There is a procedure in the IPL that takes a string and maps escape sequences into their internal form in the same manner that Icon translator does with string constants. So, if you have: link regexp ... patstr := read() pattern := RePat(patstr) ... Then you might want to consider: link escape link regexp ... patstr := escape(read()) # map the standard Icon control sequences pattern := RePat(patstr) ... instead. A natural question is "Why doesn't RePat(s) call escape itself"? I can't speak for Bob, but my suspicion is that he expected the more common use to be something like: patstr := "pattern string of some sort" pattern := RePat(patstr) In which case the call to escape() would be an expensive no-op. -- Steve Wampler -- swampler@noao.edu Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? From icon-group-sender Fri Nov 22 08:38:47 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAMFcjk21074 for icon-group-addresses; Fri, 22 Nov 2002 08:38:45 -0700 (MST) Message-Id: <200211221538.gAMFcjk21074@baskerville.CS.Arizona.EDU> From: jleger@afslogistics.com (Jonathan Leger) X-Newsgroups: comp.lang.icon Subject: Speed-up Icon's disk access? Date: 22 Nov 2002 06:03:57 -0800 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Icon's disk access (at least on the Windows platform) is pretty darn fast, no doubt about it. But just in case there are ways to improve it... are there? I'm primarily interested in improving the random access speed. If I buffer the input when reading straight through a file I can get a 20-25% increase in performance, but buffering when you're reading all over the file would probably slow down the performance. Any ideas on improving Icon's random disk access short of using an external C library? Thanks, Jonathan Leger From icon-group-sender Fri Nov 22 12:35:43 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAMJZJ606887 for icon-group-addresses; Fri, 22 Nov 2002 12:35:19 -0700 (MST) Message-Id: <200211221935.gAMJZJ606887@baskerville.CS.Arizona.EDU> Subject: Re: Speed-up Icon's disk access? To: icon-group@cs.arizona.edu From: "Joel I Bolonick" Date: Fri, 22 Nov 2002 09:45:40 -0800 X-MIMETrack: Serialize by Router on USFRMMTA01/FRM/PEC(Release 5.0.8 |June 18, 2001) at 11/22/2002 12:48:16 PM Errors-To: icon-group-errors@cs.arizona.edu Status: RO Interesting...I've also been curious as to why the random access performance of Icon on our Unix platform is so slow. My assumption is that it is inherent in the access mode itself in that every random-access operation involves a separate disk "seek" operation rather than possibly reading from an existing buffer, since one of my coworkers has had similar speed problems implementing random-access operations in C. We finally dealt with the problem by create a RAM-disk on our Unix platform and reading the file into the RAM-disk before running the program. I assume you can do something similar on Windows. jleger@afslog istics.com To: icon-group@CS.Arizona.EDU (Jonathan cc: Leger) Subject: Speed-up Icon's disk access? 11/22/2002 06:03 AM Icon's disk access (at least on the Windows platform) is pretty darn fast, no doubt about it. But just in case there are ways to improve it... are there? I'm primarily interested in improving the random access speed. If I buffer the input when reading straight through a file I can get a 20-25% increase in performance, but buffering when you're reading all over the file would probably slow down the performance. Any ideas on improving Icon's random disk access short of using an external C library? Thanks, Jonathan Leger From icon-group-sender Mon Nov 25 07:54:49 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAPEpkw03382 for icon-group-addresses; Mon, 25 Nov 2002 07:51:46 -0700 (MST) Message-Id: <200211251451.gAPEpkw03382@baskerville.CS.Arizona.EDU> From: ernobe X-Newsgroups: comp.lang.icon Subject: delete( L, i ) Date: Sun, 24 Nov 2002 04:09:03 +0200 X-Newsreader: MicroPlanet Gravity v2.50 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO I got an e-mail from Clint Jeffery in which he says that the delete( L, i ) function is not part of Icon, but of Unicon. Instead of bothering him with more e-mails I thought I'd publish my results here in case some of you want to help me figure out why it does work: procedure main() me := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] ab := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] every 1 to 2 do every delete( ab, !me ) every writes( " ", string( ab[ 1 to 10 ] ) ) end This program prints this: 4 8 Which is what it should if delete(L, i) does work in Icon. -- my esoteric links: http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Mon Nov 25 07:57:00 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAPEtXI03573 for icon-group-addresses; Mon, 25 Nov 2002 07:55:33 -0700 (MST) Message-Id: <200211251455.gAPEtXI03573@baskerville.CS.Arizona.EDU> From: "Michael Borek" X-Newsgroups: comp.lang.icon Subject: Re: delete( L, i ) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sun, 24 Nov 2002 20:06:29 -0400 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO "ernobe" wrote in message news:MPG.184a61341eeee86c98999d@news.CIS.DFN.DE... > > I got an e-mail from Clint Jeffery in which he says that the delete( L, i ) > function is not part of Icon, but of Unicon. Instead of bothering him with [SNIP] It is documented as producing error 122 X not set or table. however, the following occur: delete(L, i) destructively deletes the ith member of L. Fails if i > *L key(L) generates the indices ("keys") of L. Documented as producing error 124 T not table. insert(L, i, x) replaces the ith member of L with x. Fails if i > *L member(L, x) produces error 122 -- |***| Michael Borek "Death before Dishonour; Beer before Lunch" |:. | Independent Software Contractor |. :| http://users.eastlink.ca/~borekking/professionalhome.html \___/ > > procedure main() > me := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] > ab := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] > every 1 to 2 do > every delete( ab, !me ) > every writes( " ", string( ab[ 1 to 10 ] ) ) > end > > > This program prints this: > > 4 8 > > Which is what it should if delete(L, i) does work in Icon. > -- > my esoteric links: > http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Sun Dec 1 13:56:35 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB1KtVI28869 for icon-group-addresses; Sun, 1 Dec 2002 13:55:31 -0700 (MST) Message-Id: <200212012055.gB1KtVI28869@baskerville.CS.Arizona.EDU> X-Sender: whm@mail.mse.com Date: Wed, 27 Nov 2002 22:25:44 -0700 To: icon-group@cs.arizona.edu From: "William H. Mitchell" Subject: I don't know why nothing is popular Errors-To: icon-group-errors@cs.arizona.edu Status: RO Here's a claim to consider: Of languages like Icon, Perl, Python, etc., NONE are popular with the average programmer. I estimate that on average I write one Icon application every week or two to help with some non-Icon project I'm working on. It might be text massage, test case generation, a program to answer a question, etc. I think that most programmers encounter some number of situations where they could write a program to solve an intermediate problem but those programs typically never get written. That's because they're too clumsy to write in Java or C++ or VB, or whatever the programmer's bread-and-butter language is, and the programmer doesn't know anything like Icon or Perl or Python well enough to write the program in a time-efficient fashion. That's pretty sad. From icon-group-sender Tue Dec 3 12:31:26 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB3JUKA19719 for icon-group-addresses; Tue, 3 Dec 2002 12:30:20 -0700 (MST) Message-Id: <200212031930.gB3JUKA19719@baskerville.CS.Arizona.EDU> From: icon-project@cs.arizona.edu X-Newsgroups: comp.lang.icon,comp.answers,news.answers Subject: Icon Programming Language FAQ Date: 3 Dec 2002 08:18:54 -0700 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions about the Icon programming language www.cs.arizona.edu/icon/faq.htm Last updated October 14, 2002 Learning about Icon A1. What is Icon? A2. What is Icon good for? A3. What are Icon's distinguishing characteristics? A4. What is the Icon program library? A5. Where can I learn more about Icon? A6. How about comprehensive documentation? Implementations B1. What platforms support Icon? B2. How do I get started with Icon? B3. Is there a Unicode version of Icon? B4. What happened to the compiler? Administration C1. What is the Icon Project? C2. How often is the on-line material updated? C3. Where did Icon come from? C4. Where is Icon going? Support D1. Is there a users' group for Icon? D2. How do I get technical support? Programming E1. Why doesn't read() work with every? E2. Why doesn't string invocation such as "foo"() work? E3. How can I call a C function? E4. Can I open a bidirectional pipe? _________________________________________________________________ Learning about Icon A1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but with semantics at a much higher level. Icon has a novel expression-evaluation mechanism that integrates goal-directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion: For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. A2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's especially strong at building software tools, for processing text, and for experimental and research applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. Consequently, Icon is used both for short, one-shot tasks and for very complex applications. A3. What are Icon's distinguishing characteristics? * A high-level, general-purpose programming language * Friendly line-oriented syntax (no semicolons needed) * Emphasis on programmer productivity * Usually interpreted * Evolved from programming languages (vs. scripting languages) * Procedural control flow plus generators and goal-directed evaluation * Values have types; variables are typeless, accept any value * Static scoping: global or (procedure) local * Automatic garbage collection * All integers have arbitrary precision * Uses strings (not chars) as basic text datatype * Has lists that function as arrays, queues, and stacks * Also has sets, tables, records (structs), reals (doubles), more * No second-class "primitive types" * Not "object-oriented" (no classes, inheritance, or instance methods) * No exception catching * No concurrency (no threads, monitors, semaphores, or synchronization) * Has co-expressions (coroutines) * Basic least-common-denominator system interface (a la ANSI C) * Procedural graphics (event-driven paradigm available but not mandated) * Retained windows (programs are never called to repaint) * Simple GUI builder that can re-edit its generated code * Turtle graphics package * Large library of contributed procedures and programs A4. What is the Icon program library? The library is a collection of programs and procedures written in Icon. User contributions are welcome and form a significant portion of the library. Library procedures effectively augment the built-in functions available to an Icon program. A wide variety of procedures currently exists, and most graphically-based programs are built around library procedures. The programs in the library range from simple demonstrations to handy tools to complex graphical applications. The library is a resource for both new and experienced programmers. In addition to their basic utility, its programs and procedures serve as examples of how things can be written in Icon. A5. Where can I learn more about Icon? Here are some good places to start. * Ralph Griswold's overview: www.cs.arizona.edu/icon/docs/ipd266.htm * Dave Hanson's introduction: www.cs.arizona.edu/icon/intro.htm * John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon A6. How about comprehensive documentation? Two books define the Icon language. The core language is covered in The Icon Programming Language (third edition), by Griswold and Griswold. Graphics facilities are described in Graphics Programming in Icon by Griswold, Jeffery, and Townsend. These books contain both tutorial and reference material. Icon's internals are detailed in The Implementation of the Icon Programming Language by Griswold and Griswold. Although considerable changes have occurred since Version 6, described in the book, the basic structure of Icon remains the same. Two technical reports, IPD112 and IPD239, describe subsequent changes. The Language and Graphics books are available from RTC Books (www.rtcbooks.com, search for "Icon") or from Jeffery Systems (www.zianet.com/jeffery/books). The Language and Implementation books can be downloaded at no charge from the Icon books page, www.cs.arizona.edu/icon/books.htm. The Icon Programming Language Handbook, by Thomas W. Christopher, is available on the web at www.toolsofcomputing.com/IconHandbook. There is a large amount of additional information at the Icon web site, www.cs.arizona.edu/icon. _________________________________________________________________ Implementations B1. What platforms support Icon? Current implementations with graphics support are available for Unix and Windows. On the Apple Macintosh, Icon runs in the Unix development environment of MacOS X, with graphics using XFree86. Older versions of Icon are available for some other systems. An alternative Java-based implementation for Unix, Jcon, is also available. B2. How do I get started with Icon? Version 9.4.1 of Icon for Unix can be downloaded from www.cs.arizona.edu/icon/v941. Source and binary packages are available, each with the complete Icon program library. Version 9.3 of Icon for Windows is compatible at the source level with version 9.4.1. It can be downloaded from www.cs.arizona.edu/icon/v93w.htm. The Version 9.4.1 library can be obtained separately from www.cs.arizona.edu/icon/v941. For older implementations, start at www.cs.arizona.edu/icon/implver.htm. Jcon is at www.cs.arizona.edu/icon/jcon. B3. Is there a Unicode version of Icon? No. Icon is defined in terms of 8-bit characters, and changing this presents several design challenges that would likely break existing programs. Also, modifying the C implementation is probably infeasible, but a Unicode version of Jcon might be possible. B4. What happened to the compiler? For a while, Unix distributions included both an interpreter and a compiler; but the interpreter is is usually fast enough even for production work, and most people found that using the compiler wasn't worth the extra compilation time or the hassles involved. We no longer advertise the compiler or produce binaries for it. It is still part of the source code distribution, and we have not deliberately broken it, but we no longer support it and we cannot offer help if problems arise. _________________________________________________________________ Administration C1. What is the Icon Project? The Icon Project is a name used by the group that distributes and supports the Icon programming language. The project maintains the Icon web site at www.cs.arizona.edu/icon. A non-commercial organization, the project is supported by the Department of Computer Science at the University of Arizona. C2. How often is the on-line material updated? New material is added when it's available. Established implementations usually are updated only when there's a new version. This typically is every year or two. The Icon program library is updated on a similar schedule. C3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 1960s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at the University of Arizona with support from the National Science Foundation. Although it has similar objectives and many similar capabilities, Icon bears little superficial resemblance to SNOBOL4. Icon implementations were developed by faculty, staff, and students at the University of Arizona, with significant contributions from volunteers around the world. An Icon history by Ralph and Madge Griswold appears in the preprints of the second History of Programming Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol 28, No 3). The name Icon is not an acronym, nor does it stand for anything in particular, although the word iconoclastic was mentioned when the name was chosen. The name predates the now common use of icon to refer to small images used in graphical user interfaces. This sometimes misleads people into thinking that that Icon is designed to create or manipulate icons, but there's no good solution to that problem. C4. Where is Icon going? We continue to use Icon on a daily basis, but no significant changes are planned. We expect to support the Unix version for the forseeable future, and to distribute ports to other systems as supplied by volunteers. The Unicon project is developing an object-oriented language based on Icon. For more information, see unicon.sourceforge.net. An earlier object-oriented extension to Icon, Idol, can be found in the Icon program library. _________________________________________________________________ Support D1. Is there a users' group for Icon? There is no official Icon users' group, but The Icon Project maintains a moderated "Icon-group" electronic mailing list. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between Icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list and is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends its announcements and other messages to the mailing list. D2. How do I get technical support? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please use the appropriate resource when you need assistance: * For programming assistance, submit a query to the mailing list or newsgroup (see above). * For porting assistance or Unix problems, contact icon-project@cs.arizona.edu. * For problems with the Windows implementation, contact the implementor, jeffery@cs.nmsu.edu. * For general information and additional documentation, visit the Icon web site: www.cs.arizona.edu/icon. _________________________________________________________________ Programming E1. Why doesn't read() work with every? every s := read() do {...} doesn't loop because read() produces a single value and then fails if resumed. Other "consumer" procedures such as get() and pop() work the same way. Use a while loop with these procedures, and save every for use with generators such as !x or key(T). E2. Why doesn't string invocation such as "foo"() work? String invocation works if the procedure is present; the catch is that the linker removes unreferenced procedures. To ensure a procedure's presence, reference it in the main() procedure. A simple reference suffices, as in refs := [foo, bar, baz]; it's not necessary to actually call it. (Why does the linker remove unreferenced procedures? Because this can save huge amounts of memory for programs that use the library.) E3. How can I call a C function? You can't call an arbitrary C function, but if you're willing to write a function to Icon's specifications, there are two approaches. Under Unix, which provides loadfunc(), you can load one or more functions from a shared library, and then treat them as if they had been written in Icon. Some examples can be found in the cfuncs and packs/loadfuncs directories of the Icon program library. The more cumbersome approach is to add code to the Icon interpreter and rebuild it; some hooks are provided for this purpose. Both approaches are discussed in Calling C Functions from Icon, www.cs.arizona.edu/icon/docs/ipd240.htm. The Jcon implementation allows Icon programs to call Java code that is written to Jcon specifications. E4. Can I open a bidirectional pipe? No, this is not possible. Although the concept is simple -- write a line to a program via a pipe, then read that program's output -- it probably wouldn't work. Most I/O libraries don't write anything to a pipe until they've filled a buffer, and the most likely consequence would be a deadlock, with each program waiting for the other to send more data. _________________________________________________________________ This FAQ is edited by Gregg Townsend. It includes contributions from Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd Proebsting. From icon-group-sender Fri Dec 6 09:39:07 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB6GbKQ29056 for icon-group-addresses; Fri, 6 Dec 2002 09:37:20 -0700 (MST) Message-Id: <200212061637.gB6GbKQ29056@baskerville.CS.Arizona.EDU> From: "Ladvánszky Károly" X-Newsgroups: comp.lang.icon Subject: Q: Icon compiler Date: Fri, 6 Dec 2002 12:42:02 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Icon is great but the interpreter mode is rather slow. Cristopher's Icon Handbook mentions a compiler that produces C code from Icon. Is it available for Windows? Thanks for any help, Károly From icon-group-sender Fri Dec 6 16:53:09 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB6NpLE09375 for icon-group-addresses; Fri, 6 Dec 2002 16:51:21 -0700 (MST) Message-Id: <200212062351.gB6NpLE09375@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Fri, 06 Dec 2002 19:25:37 GMT X-Complaints-To: abuse@verizon.net To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO The Icon native code compiler is still distributed, but no longer supported. I experimented with making the Icon-to-C compiler work in my recent Cygwin port, and I discovered that the code needed a lot of tweaking. The Icon-to-C (iconc) compiler can produce very fast programs. I recall once using it on the Icon versions of uuencode / uudecode ("iiencode.icn" and "iidecode.icn" in the IPL) and ran some timing checks. The iconc versions of iiencode / iidecode were over 3 times as fast as the interpreted (icont / iconx) versions. More surprisingly, I found that the iconc programs were actually faster than native C uuencode / uudecode programs that I was using at the time! The down side is that the iconc compiler itself is sluggish and a real memory hog. Because of the type inference engine, iconc cannot perform separate compilation. My experience is that iconc is bound to fail for programs beyond a certain size. Also, for iconc debug support is optional, and a performance drag. I would not recommend compiling a program with iconc until it has been thoroughly tested and debugged. Also, some more recent features such as multi-threading is simply not supported (and not really supportable) by iconc. The iconc compiler has to interface with the local C compiler, which creates a real maintenance headache. It is therefore not surprising that the Icon Project decided to drop support for iconc. From icon-group-sender Fri Dec 6 16:55:22 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB6NtLc09524 for icon-group-addresses; Fri, 6 Dec 2002 16:55:21 -0700 (MST) Message-Id: <200212062355.gB6NtLc09524@baskerville.CS.Arizona.EDU> X-Sender: tonym@mail.bearriver.com Date: Fri, 6 Dec 2002 11:46:59 -0800 To: From: Tony Meadow Subject: Icon's popularity in print Errors-To: icon-group-errors@cs.arizona.edu Status: RO I was surprised to see Icon mentioned on an interesting chart of programming languages on pgs 60-61 in the July 2002 issue of Wired. (Ok, I'm a little behind in my reading.) It claims that Snobol is active (in their words "thousands of users"), Snobol 4 is extinct ("no known active users or up-to-date compilers") and the Icon is endangered ("usage dropping off"). No mention of Unicon. Also on the endangered list: Pascal, APL, Smalltalk, Modula 2. It describes Icon as "A general-purpose language known for its beauty and grace. Designed by Ralph Griswold to be successor to Snobol 4". Wow! That would make a nice signature for an Icon mailing list. My suggestion to increase the usage of Icon is for people who are actively using it to write an article for the trade journals .. Dr. Dobbs, New Architect, etc. People aren't going to pick up a language they've never heard of. Off-topic: Other tidbits in this issue: besides articles on a lot of crappy toys for people with too much money, p 37 has an brief blurb of John Poidexter and the new "Information Awareness Office" in the DoD. Rather than cover this with any semblance of objectivity, it closes with "Besides, who better to monitor email than a guy who faced jail for shredding digital paper trails?" Sheesh. Tony Meadow From icon-group-sender Fri Dec 6 16:55:36 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB6NtZ209565 for icon-group-addresses; Fri, 6 Dec 2002 16:55:35 -0700 (MST) Message-Id: <200212062355.gB6NtZ209565@baskerville.CS.Arizona.EDU> X-Sent: 6 Dec 2002 23:24:04 GMT To: "=?iso-8859-1?q?Ladv=E1nszky_K=E1roly?=" Cc: icon-group@cs.arizona.edu Subject: Re: Q: Icon compiler From: Ed L Cashin Date: 06 Dec 2002 18:24:03 -0500 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id gB6NOFj14314 Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Ladvánszky Károly" writes: > Icon is great but the interpreter mode is rather slow. > Cristopher's Icon Handbook mentions a compiler that produces C code from > Icon. > Is it available for Windows? Just in case you haven't seen it, I thought I'd mention that there's a FAQ entry about the compiler: B4. What happened to the compiler? For a while, Unix distributions included both an interpreter and a compiler; but the interpreter is is usually fast enough even for production work, and most people found that using the compiler wasn't worth the extra compilation time or the hassles involved. We no longer advertise the compiler or produce binaries for it. It is still part of the source code distribution, and we have not deliberately broken it, but we no longer support it and we cannot offer help if problems arise. -- --Ed L Cashin | PGP public key: ecashin@uga.edu | http://noserose.net/e/pgp/ From icon-group-sender Mon Dec 9 08:31:09 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9FV7k24216 for icon-group-addresses; Mon, 9 Dec 2002 08:31:07 -0700 (MST) Message-Id: <200212091531.gB9FV7k24216@baskerville.CS.Arizona.EDU> From: ernobe X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler Date: Mon, 9 Dec 2002 15:23:50 +0200 X-Newsreader: MicroPlanet Gravity v2.50 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In article <3df45481$1_7@news.meganetnews.com>, aa@bb.cc says... > Thanks for your answer. > > > The Icon-to-C (iconc) compiler can produce very fast programs. I recall > once > > using it on the Icon versions of uuencode / uudecode ("iiencode.icn" and > > "iidecode.icn" in the IPL) and ran some timing checks. The iconc versions > of > > iiencode / iidecode were over 3 times as fast as the interpreted (icont / > > iconx) versions. More surprisingly, I found that the iconc programs were > > actually faster than native C uuencode / uudecode programs that I was > using > > at the time! > > Well ... I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 > secs to calculate the result for 40 as input and for Icon it takes about 600 > secs. Now with even 3 times speed improvement, it'd still be 200 secs for > Icon. Given that, I think it's very exaggerated to say Icon programs can be > faster than C. However slow compared to C, I do recognise Icon's power and > I'm considering adding it to my software toolchest. > > Icon is meant to enable people to code more efficiently than in C. Given that it is people who produce computer programs, not computers programmed in C, to refer to it as simply another tool in ones toolchest seems rather derogatory. In fact it would probably not be far fetched to say that if everything that is done in C nowadays would be done in Icon, there would not be a noticeable difference, and programs would have much more functionality and attractiveness to users. I don't know much about computers myself, I can't really tell what an Icon to C translator is, but since there is a compiler which produces executables and is itself coded in C, it would probably take just someone well grounded in C to make a translator. Of course the reason it hasn't is obvious to those familiar with the problems of implementing a low-level language across several platforms and OS. Until such time as there is more agreement about such platforms and OS to make generalized low-level language programming efficient, Icon programmers are well advised to familiarize themselves with C or Assembly, and optimize their programs themselves. I think functions programmed in C can be called, I don't know if it is possible to add machine code, but it sounds like something a-lot simpler to accomplish than in most other computer languages. It is a great way to learn Assembly, I think, if one could learn how to optimize generators. -- my esoteric links: http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Mon Dec 9 08:30:32 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9FT8E23905 for icon-group-addresses; Mon, 9 Dec 2002 08:29:08 -0700 (MST) Message-Id: <200212091529.gB9FT8E23905@baskerville.CS.Arizona.EDU> From: "Ladvánszky Károly" X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler Date: Mon, 9 Dec 2002 09:30:40 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Thanks for your answer. > The Icon-to-C (iconc) compiler can produce very fast programs. I recall once > using it on the Icon versions of uuencode / uudecode ("iiencode.icn" and > "iidecode.icn" in the IPL) and ran some timing checks. The iconc versions of > iiencode / iidecode were over 3 times as fast as the interpreted (icont / > iconx) versions. More surprisingly, I found that the iconc programs were > actually faster than native C uuencode / uudecode programs that I was using > at the time! Well ... I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 secs to calculate the result for 40 as input and for Icon it takes about 600 secs. Now with even 3 times speed improvement, it'd still be 200 secs for Icon. Given that, I think it's very exaggerated to say Icon programs can be faster than C. However slow compared to C, I do recognise Icon's power and I'm considering adding it to my software toolchest. From icon-group-sender Mon Dec 9 08:31:28 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9FVQg24308 for icon-group-addresses; Mon, 9 Dec 2002 08:31:26 -0700 (MST) Message-Id: <200212091531.gB9FVQg24308@baskerville.CS.Arizona.EDU> From: "Ladvánszky Károly" X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler Date: Mon, 9 Dec 2002 14:59:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO I'm not sure what is derogatory in considering adding a tool to a software developer's toolchest. My intention was just the opposite, ie. to express that I had recognised it's power. > In fact it would probably not be far fetched to say that if everything that is > done in C nowadays would be done in Icon, there would not be a noticeable > difference, and programs would have much more functionality and attractiveness > to users. There are situations where one has to handle large amounts of data, say 100k of elements of any kind. For such applications, 600s/8s would certainly make a big difference for the user. Icon is powerful but clearly not suitable for this sort of tasks. "ernobe" az alábbiakat írta a következő hírüzenetben: MPG.185ec5e4a40a31c09899a9@news.CIS.DFN.DE... > In article <3df45481$1_7@news.meganetnews.com>, aa@bb.cc says... > > Thanks for your answer. > > > > > The Icon-to-C (iconc) compiler can produce very fast programs. I recall > > once > > > using it on the Icon versions of uuencode / uudecode ("iiencode.icn" and > > > "iidecode.icn" in the IPL) and ran some timing checks. The iconc versions > > of > > > iiencode / iidecode were over 3 times as fast as the interpreted (icont / > > > iconx) versions. More surprisingly, I found that the iconc programs were > > > actually faster than native C uuencode / uudecode programs that I was > > using > > > at the time! > > > > Well ... I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 > > secs to calculate the result for 40 as input and for Icon it takes about 600 > > secs. Now with even 3 times speed improvement, it'd still be 200 secs for > > Icon. Given that, I think it's very exaggerated to say Icon programs can be > > faster than C. However slow compared to C, I do recognise Icon's power and > > I'm considering adding it to my software toolchest. > > > > > > Icon is meant to enable people to code more efficiently than in C. Given that > it is people who produce computer programs, not computers programmed in C, to > refer to it as simply another tool in ones toolchest seems rather derogatory. > In fact it would probably not be far fetched to say that if everything that is > done in C nowadays would be done in Icon, there would not be a noticeable > difference, and programs would have much more functionality and attractiveness > to users. > I don't know much about computers myself, I can't really tell what an Icon to C > translator is, but since there is a compiler which produces executables and is > itself coded in C, it would probably take just someone well grounded in C to > make a translator. Of course the reason it hasn't is obvious to those familiar > with the problems of implementing a low-level language across several platforms > and OS. Until such time as there is more agreement about such platforms and OS > to make generalized low-level language programming efficient, Icon programmers > are well advised to familiarize themselves with C or Assembly, and optimize > their programs themselves. > I think functions programmed in C can be called, I don't know if it is possible > to add machine code, but it sounds like something a-lot simpler to accomplish > than in most other computer languages. It is a great way to learn Assembly, I > think, if one could learn how to optimize generators. > > > > -- > my esoteric links: > http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Mon Dec 9 12:45:35 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9JjQo22267 for icon-group-addresses; Mon, 9 Dec 2002 12:45:26 -0700 (MST) Message-Id: <200212091945.gB9JjQo22267@baskerville.CS.Arizona.EDU> X-Authentication-Warning: weaver.tuc.noao.edu: swampler set sender to swampler@noao.edu using -f Subject: Re: Icon compiler From: Steve Wampler To: =?ISO-8859-1?Q?Ladv=E1nszky_K=E1roly?= Cc: icon-group@cs.arizona.edu Date: 09 Dec 2002 09:23:00 -0700 X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id gB9GN4j29600 Errors-To: icon-group-errors@cs.arizona.edu Status: RO On Mon, 2002-12-09 at 01:30, Ladvánszky Károly wrote: > > Well ... I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 > secs to calculate the result for 40 as input and for Icon it takes about 600 > secs. Now with even 3 times speed improvement, it'd still be 200 secs for > Icon. Given that, I think it's very exaggerated to say Icon programs can be > faster than C. However slow compared to C, I do recognise Icon's power and > I'm considering adding it to my software toolchest. Wow - that must be some benchmark - can we see the Icon version? I ask because computing the first 40 Fibonacci numbers takes no time at all - so you must be doing a lot more in your benchmark. I'm curious as to what it is... Thanks Steve -- Steve Wampler National Solar Observatory From icon-group-sender Mon Dec 9 12:46:02 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9Jk0M22361 for icon-group-addresses; Mon, 9 Dec 2002 12:46:00 -0700 (MST) Message-Id: <200212091946.gB9Jk0M22361@baskerville.CS.Arizona.EDU> Date: Mon, 9 Dec 2002 12:28:21 -0700 From: Clint Jeffery To: icon-group@cs.arizona.edu Subject: Re: Icon compiler Errors-To: icon-group-errors@cs.arizona.edu Status: RO [Ladvansky Karoly asserts:] I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 secs to calculate the result for 40 as input and for Icon it takes about 600 secs... even 3 times speed improvement, it'd still be 200 secs for Icon... I think it's very exaggerated to say Icon programs can be faster than C. I think Ladvansky is doing fine to speak blunt truth, of course Icon is wayyy slower than C *on average*. The original poster wasn't talking about an average case, he was talking about one particular real application where Icon beats C, and I have heard of many others. So Ladvansky, I think you are overgeneralizing the other poster's report, just as you overgeneralize your own test result, and come to a slightly-incorrect conclusion, from which you basically called someone else a liar who was simply reporting a fact. When does Icon beat C, if ever? (1) When there are potentially complex algorithms and data structures needed, but the C code is suboptimal due to limited time (if programmer time is infinite, this goes away). Given the same amount of time to write C or Icon, you may be able to implement a faster algorithm for the Icon version than for C. Do you have the time & technical knowhow to implement hash tables that dynamically resize when you need them? Icon gives you them for free. (2) When the application execution time depends mainly on the things Icon is best at. Then the Icon time is mainly spent in the runtime system, which is quite optimized C code. I think Ladvansky would find, if he did any real testing, that the difference between Icon and C varies radically depending on application. Fibonacci is a highly artificial test of one tiny aspect of performance. But still, C is wayyy faster than Icon on average, even if results vary. Lastly, I would like to say that the quest for optimal performance for the Icon implementation is far from over, and there is a lot of room for the right researchers (maybe, graduate student researchers?) to contribute materially to performance in ways that will benefit this entire community. Maybe some of you-all should consider going back to school to help out. :-) [Ladvansky politely observes] > However slow compared to C, I do recognise Icon's power and > I'm considering adding it to my software toolchest. Thanks for this kind observation. :-) Clint jeffery@cs.nmsu.edu From icon-group-sender Mon Dec 9 16:59:58 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9Nxac19220 for icon-group-addresses; Mon, 9 Dec 2002 16:59:36 -0700 (MST) Message-Id: <200212092359.gB9Nxac19220@baskerville.CS.Arizona.EDU> From: James P Scully X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler Date: Mon, 9 Dec 2002 14:56:02 -0700 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Well I agree that Icon is something that every programmer should have in their little bag of tricks...regardless of how you want to think of it, but as far as speed is concerned, and cross-platform, there are a number of independent groups out there attempting to realize the potential,... but with the exception of DotNet and Java, they're all lightweights...not that its a bad thing, its just that its much harder to impose your own standard on an industry with insufficient support... and its hard to work on this alone when other people are trying to do the same thing, and you get different results...think of the war of the browsers and wysiwyg.. :-). But still, with cross-language or cross-platform code - But it is quite possible, with a few exceptions to compile DotNet code on a macintosh or linux/unix variant... once again... SNOBOL4.NET, Icon.NET... :-D As far as speed is concerned, ugh. It should be entirely possible to optimize Icon even more, considering the fact that there are quite a few functional programming language compilers out there that are much faster under certain benchmarks. The most blatant example comes to my mind in my final project assignment for Stuart Reges' excellent CS 372 class at the University of Arizona ... with the choice of creating a simple 4-15 digit RSA encryption program in Icon or SML, it seems that after you work around the overflows, that, with our own hardware and the specific compilers that we're using, most of the ML implementations are much faster than the icon implementations -- but of course, this is still all dependent on the compiler optimization and the hardware. I regret that I still do NOT yet have enough of an education in this field to make much of an informed opinion on the matter, although it interests me enough to send this reply in hopes of continuing your interesting discussion. PS- I only see four messages... I'm thinking there might be something wrong with my connection to the newsgroup... can anyone enighten me on this? thanks... From icon-group-sender Tue Dec 10 07:58:51 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBAEwno04481 for icon-group-addresses; Tue, 10 Dec 2002 07:58:49 -0700 (MST) Message-Id: <200212101458.gBAEwno04481@baskerville.CS.Arizona.EDU> X-Newsreader: knews 1.0b.1 From: rtr@blueyonder.co.uk (Robby) Subject: Re: Icon compiler X-Newsgroups: comp.lang.icon Date: Tue, 10 Dec 2002 12:34:17 GMT X-Complaints-To: abuse@blueyonder.co.uk To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In article <3df45481$1_7@news.meganetnews.com>, "Ladvánszky Károly" writes: > Well ... I have this Fibonacci test for benchmarks. With MS C ++ it takes 8 > secs to calculate the result for 40 as input and for Icon it takes about 600 > secs. Now with even 3 times speed improvement, it'd still be 200 secs for > Icon. Given that, I think it's very exaggerated to say Icon programs can be > faster than C. However slow compared to C, I do recognise Icon's power and > I'm considering adding it to my software toolchest. Well, it always depends on what you're trying to achieve. I would not choose Icon to solve a numerical problem. I would choose Icon over almost any other choice for anything involving string manipulation and complex data structure mapping (i.e., putting lots of stuff into a set and then looking at what is in there). Icon, as far as my experience goes, excells at any kind of string scanning operation. It even remains readable, which I can't say for any of my Perl programs. And it is soooo much more powerful than regular expressions. Robby -- It's just zeros and ones, it cannot be hard. From icon-group-sender Tue Dec 10 07:57:42 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBAEvWY04347 for icon-group-addresses; Tue, 10 Dec 2002 07:57:32 -0700 (MST) Message-Id: <200212101457.gBAEvWY04347@baskerville.CS.Arizona.EDU> X-Sender: whm@mail.mse.com Date: Mon, 09 Dec 2002 20:35:48 -0700 To: icon-group@cs.arizona.edu From: "William H. Mitchell" Subject: Hack for partial evaluation in Icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO James' mention of ML got me thinking about an ML feature I'd really like to see in Icon: partial evaluation -- the ability to supply some parameters for a function now and some later, with the function call taking place when all parameters have been supplied. It's a hack but here's a way to get that effect in Icon, albeit with an unfortunate finiteness... Here's a main program: invocable all link image procedure main() lftx := partial(left, "x") every write(lftx(1 to 5, ".")) f := partial(left, "y", 5) every write(f(!"abcd")) every w := partial(write, "testing..." | "MORE testing...") do every w(1 to 5) s := set() p := partial(insert,s) p(1) p(2) p(s) write(Image(s)) end Here's the output: x x. x.. x... x.... yaaaa ybbbb ycccc ydddd testing...1 testing...2 testing...3 testing...4 testing...5 MORE testing...1 MORE testing...2 MORE testing...3 MORE testing...4 MORE testing...5 S1:[ 2, 1, S1] Here's the hack... record partial_record(proc, args) global partials procedure partial(args[]) static partial_num initial { partials := table() partial_num := 0 } partial_num +:= 1 partials[partial_num] := partial_record(args[1], args[2:0]) return "do_partial_" || partial_num end # # I need a way to make these on the fly! Until then... # procedure do_partial_1(args[]) r := partials[1] suspend r.proc!(r.args|||args) end procedure do_partial_2(args[]) r:= partials[2] suspend r.proc!(r.args|||args) end procedure do_partial_3(args[]) r:= partials[3] suspend r.proc!(r.args|||args) end procedure do_partial_4(args[]) r:= partials[4] suspend r.proc!(r.args|||args) end procedure do_partial_5(args[]) r:= partials[5] suspend r.proc!(r.args|||args) end Pop quiz for comparative languages students: The above implementation relies on a procedure named "partial" to indicate that partial evaluation should be done. In ML such a cue is not necessary. Can partial evaluation be added to Icon without requiring a cue of some sort? From icon-group-sender Tue Dec 10 07:58:08 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBAEw7204418 for icon-group-addresses; Tue, 10 Dec 2002 07:58:07 -0700 (MST) Message-Id: <200212101458.gBAEw7204418@baskerville.CS.Arizona.EDU> Subject: Re: Icon compiler From: Cheyenne Wills To: Icon Group Date: 09 Dec 2002 20:36:19 -0700 Errors-To: icon-group-errors@cs.arizona.edu Status: RO Speeking of speed and such... A while back I came across the following web site. The person running the site was doing a fairly good job of building some comparitive samples of different programming languages. He created several different test cases and then programmed a sample solution in many different languages, then ran some tests to see how well they performed. http://www.bagley.org/~doug/shootout/ A comment in the intro kind of sums up where he stood in the tests. [ 30 Language Implementations, 25 Benchmark Tests, 750 Total Possible Programs, 632 Written ] Anyway enjoy Cheyenne From icon-group-sender Tue Dec 17 12:46:16 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBHJjAw05436 for icon-group-addresses; Tue, 17 Dec 2002 12:45:10 -0700 (MST) Message-Id: <200212171945.gBHJjAw05436@baskerville.CS.Arizona.EDU> From: aherford@yahoo.de (Alex Steinberg) X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler Date: 17 Dec 2002 05:35:04 -0800 X-Complaints-To: groups-abuse@google.com To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Frank J. Lhota" wrote in message news:... > The Icon native code compiler is still distributed, but no longer supported. > I experimented with making the Icon-to-C compiler work in my recent Cygwin > port, and I discovered that the code needed a lot of tweaking. > > The Icon-to-C (iconc) compiler can produce very fast programs. I recall once > using it on the Icon versions of uuencode / uudecode ("iiencode.icn" and > "iidecode.icn" in the IPL) and ran some timing checks. The iconc versions of > iiencode / iidecode were over 3 times as fast as the interpreted (icont / > iconx) versions. More surprisingly, I found that the iconc programs were > actually faster than native C uuencode / uudecode programs that I was using > at the time! > > The down side is that the iconc compiler itself is sluggish and a real > memory hog. Because of the type inference engine, iconc cannot perform > separate compilation. My experience is that iconc is bound to fail for > programs beyond a certain size. Also, for iconc debug support is optional, > and a performance drag. I would not recommend compiling a program with iconc > until it has been thoroughly tested and debugged. > > Also, some more recent features such as multi-threading is simply not > supported (and not really supportable) by iconc. > > The iconc compiler has to interface with the local C compiler, which creates > a real maintenance headache. It is therefore not surprising that the Icon > Project decided to drop support for iconc. Hello Frank, You are talking about Your recent Cygwin port of Icon, is that port available for the public? I have looked for some time now to such port but without success. thanks, Alex From icon-group-sender Wed Dec 18 12:33:05 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBIJWS221345 for icon-group-addresses; Wed, 18 Dec 2002 12:32:28 -0700 (MST) Message-Id: <200212181932.gBIJWS221345@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Re: Icon compiler X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Wed, 18 Dec 2002 19:04:40 GMT X-Complaints-To: abuse@verizon.net To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO It is my understanding that the next version of Icon for Windows (version 9.4?) is basically my Cygwin port. It should be available soon through the Icon project. From icon-group-sender Thu Dec 19 17:06:05 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBK04Bo00280 for icon-group-addresses; Thu, 19 Dec 2002 17:04:11 -0700 (MST) Message-Id: <200212200004.gBK04Bo00280@baskerville.CS.Arizona.EDU> Date: Thu, 19 Dec 2002 16:10:53 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Re: Cygwin port of Icon Errors-To: icon-group-errors@cs.arizona.edu Status: RO The next release of Icon, 9.4.2, will include Frank Lhota's Cygwin port. I expect that it will be ready in early 2003. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Tue Dec 24 12:29:08 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBOJRgE06414 for icon-group-addresses; Tue, 24 Dec 2002 12:27:42 -0700 (MST) Message-Id: <200212241927.gBOJRgE06414@baskerville.CS.Arizona.EDU> From: ernobe X-Newsgroups: comp.lang.icon Subject: Scanning question Date: Sun, 22 Dec 2002 18:29:26 +0200 X-Newsreader: MicroPlanet Gravity v2.50 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO Can a scanning operation be done within a conjunction? It seems that backtracking into it does not produce the next result but begins the scanning over again. And if the '?' scanning expression is put out of the conjunction, the part that is left in it sets the position back to where it was before scanning when the other expressions in the conjunction are evaluated. -- my esoteric links: http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Tue Dec 24 12:31:45 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBOJVho06509 for icon-group-addresses; Tue, 24 Dec 2002 12:31:43 -0700 (MST) Message-Id: <200212241931.gBOJVho06509@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Scanning question Date: Tue, 24 Dec 2002 11:03:42 +1100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO ernobe wrote: > Can a scanning operation be done within a conjunction? It seems that > backtracking into it does not produce the next result but begins the > scanning over again. And if the '?' scanning expression is put out > of the conjunction, the part that is left in it sets the position > back to where it was before scanning when the other expressions in > the conjunction are evaluated. A sample of code please? Conjunction does backtrack so probably you are doing something to break the scan. From icon-group-sender Tue Dec 24 12:31:58 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBOJVv206539 for icon-group-addresses; Tue, 24 Dec 2002 12:31:57 -0700 (MST) Message-Id: <200212241931.gBOJVv206539@baskerville.CS.Arizona.EDU> From: ernobe X-Newsgroups: comp.lang.icon Subject: Re: Scanning question Date: Tue, 24 Dec 2002 07:12:01 +0200 X-Newsreader: MicroPlanet Gravity v2.50 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO In article , ahamm@mail.com says... > ernobe wrote: > > Can a scanning operation be done within a conjunction? It seems that > > backtracking into it does not produce the next result but begins the > > scanning over again. And if the '?' scanning expression is put out > > of the conjunction, the part that is left in it sets the position > > back to where it was before scanning when the other expressions in > > the conjunction are evaluated. > > A sample of code please? Conjunction does backtrack so probably you are > doing something to break the scan. > > > I wanted to scan thru several lines in a file searching for strings that have been scanned out of another file. So if an operation on a specific line fails to produce results, I need to go to the next line while keeping count of the number of strings that have been scanned ( I need to match the string itself and find its position in the file ). I had something like var := 1 # number of string every line := read() do ( line ? while tab( upto( &letters ) ) do str := tab( many( &letters ) ) \ 1, count +:= 1, if count = var then write( file, str ), count := 0 ) The problem is that if a line has no matches, I need to continue with another line without setting the count back to zero. 'Every' is not a loop structure so I can't put a 'next' in there before the count is set back to zero. I realize now that the scanning expression itself was not the problem after all. I need to re-organize my program. By the way, if the 'then' clause fails in the conjunction, does the 'if' clause itself fail? If one backtracks into a conjunction, does the whole thing resume, or just the final expression? -- my esoteric links: http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Thu Dec 26 18:56:11 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBR1rWM08248 for icon-group-addresses; Thu, 26 Dec 2002 18:53:32 -0700 (MST) Message-Id: <200212270153.gBR1rWM08248@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Scanning question Date: Fri, 27 Dec 2002 11:29:34 +1100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO ernobe wrote: > I wanted to scan thru several lines in a file searching for strings > that have been scanned out of another file. So if an operation on a > specific line fails to produce results, I need to go to the next line > while keeping count of the number of strings that have been scanned > (I need to match the string itself and find its position in the file). > I had something like > > var := 1 # number of string > every line := read() do > ( > line ? while tab( upto( &letters ) ) do > str := tab( many( &letters ) ) \ 1, > count +:= 1, > if count = var then > write( file, str ), > count := 0 > ) OK - I can't see how your sample code does what you mention in the first paragraph, but you did say "something like" so I guess this is not trying to do what you want, but trying to understand what is happening? > The problem is that if a line has no matches, I need to continue with > another line without setting the count back to zero. 'Every' is not > a loop structure so I can't put a 'next' in there before the count is > set back to zero. Yes, "every" can be "next". Run this sample program: procedure main() j := 1 every i := 1 to 10 do { write(i, " ", j) if i % 2 = 1 then next j +:= 1 } end > I realize now that the scanning expression itself > was not the problem after all. I need to re-organize my program. > if the 'then' clause fails in the conjunction, does the 'if' > clause itself fail? Yes. Depending on the "if" condition, the "then" or the "else" part is executed. The outcome of the entire statement will be the outcome of the chosen "then" or "else" part. If the else part is missing, it is like a failure - effectively a missing else part generates zero results which will be a failure that will force backtracking. In either situation, if the "then" or "else" part generates results, that is the result of the entire "if" statement. Note that the condition is never resumed - it is driven to produce ANY result so that the "then" or the "else" part can be selected but after that it is finished. > If one backtracks into a conjunction, > does the whole thing resume, or just the final expression? The whole conjunction. By the way, what you are using is actually called "mutual evaluation" although it is very similar to "conjunction". Conjunction is A & B & C .... but you are using mutual evaluation: (A, B, C, ....) In either case, backtracking can pass through the entire list of A B C as needed to produce a result. In both cases, the result of the expression is the result of the last part. Apart from the syntactical difference, mutual evaluation allows you to select which part you want the value of: for example 2(A, B, C) yields the values of B whenever it produces a result. A, B, and C need to produce a result in each case. For example, run this procedure main() every i := 2(1 to 3, 4 to 6, 7 to 9) do write(i) end And you'll see it write 4,4,4,5,5,5,6,6,6 three times ie 3*3*3 results. Anyway, onto your specific problem. I'm not sure it's worth working on your sample code since it doesn't sound exactly like your goal. Your use of mutual evaluation is unusual but by no means wrong. Perhaps it's just me who doesn't use it very much like this. Actually, since I do use & very often to chain together expressions into one backtracking extravaganza, I suppose I do use it a lot ;-) Whatever the reason, if you still need help, please pass on your actual code so I (or others) can see your goal and where you might be going wrong. -- There's nowt wrong wi' owt what mitherin' clutterbucks don't barly grummit! - Replies directly to this message will go to an account that may not be checked for a week or two. For more timely e-mail response, use (only in an emergency) ahamm sanderson net au with all the usual punctuation. From icon-group-sender Tue Dec 31 15:20:41 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBVMIg617195 for icon-group-addresses; Tue, 31 Dec 2002 15:18:42 -0700 (MST) Message-Id: <200212312218.gBVMIg617195@baskerville.CS.Arizona.EDU> From: ernobe X-Newsgroups: comp.lang.icon Subject: Re: Scanning question Date: Tue, 31 Dec 2002 02:15:39 +0200 X-Newsreader: MicroPlanet Gravity v2.50 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO > > > if the 'then' clause fails in the conjunction, does the 'if' > > clause itself fail? > > Yes. Depending on the "if" condition, the "then" or the "else" part is > executed. The outcome of the entire statement will be the outcome of the > chosen "then" or "else" part. If the else part is missing, it is like a > failure - effectively a missing else part generates zero results which will > be a failure that will force backtracking. > > In either situation, if the "then" or "else" part generates results, that is > the result of the entire "if" statement. Note that the condition is never > resumed - it is driven to produce ANY result so that the "then" or the > "else" part can be selected but after that it is finished. > Thank-you for your very informative post. This particular issue with the if statement was the cause of my problems. I suspect that I must be missing informatin on facts as basic as this, since I hadn't come across it in the documentation. Perhaps it is something one learns in the first year of computer science courses in the university. I found Icon on the Web after nearly a year of searching for and trying several languages, particularly Forth and Euphoria. I have the general impression that most of the documentation is written for advanced students. Perhaps part of it is intentional in order not to share information that may be used maliciously. Just today I found a website of a hacker who has one of the best tutorials on Dos programming that I've seen so far. I've noticed the similarity of some of Icons functions with the Dos functions that are available in my Windows 2000 OS, but proper or even basic information as to how to use these commands is totally missing. I'd appreciate it if anyone could direct me to an appropiate source. -- my esoteric links: http://www.costarricense.cr/pagina/ernobe/ From icon-group-sender Tue Dec 31 15:21:48 2002 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gBVMLlQ17314 for icon-group-addresses; Tue, 31 Dec 2002 15:21:47 -0700 (MST) Message-Id: <200212312221.gBVMLlQ17314@baskerville.CS.Arizona.EDU> From: "Andrew Hamm" X-Newsgroups: comp.lang.icon Subject: Re: Scanning question Date: Tue, 31 Dec 2002 15:52:49 +1100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: RO ernobe wrote: > > Thank-you for your very informative post. This particular issue with > the if statement was the cause of my problems. I suspect that I must > be missing informatin on facts as basic as this, since I hadn't come > across it in the documentation. Perhaps it is something one learns > in the first year of computer science courses in the university. I > found Icon on the Web after nearly a year of searching for and trying > several languages, particularly Forth and Euphoria. I have the > general impression that most of the documentation is written for > advanced students. The homepage (and home) for Icon is http://www.cs.arizona.edu/icon/ You will find tutorials, newsletters and all sorts of useful stuff there. You will also find details of a book "The Icon Programming Language", third edition, and although I don't have this book (I've had the 1st edition and currently use a well-thumbed 2nd edition) I'm sure it's excellent. As a bonus it's now available for free download as a PDF file. If it's anything like the 1st two editions (and it will be) then it will be very readable from chapter one which will take you through in tutorial style. The chapters are suitable for reference purposes once you've learnt, and there is also a comprehensive description of all the functions. Truly, you won't go wrong by handing over some money for this book. Take the time to download and when you find yourself impressed, spend the money for the convenience of a book. From icon-group-sender Wed Jan 1 10:25:11 2003 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id h01HPA621247 for icon-group-addresses; Wed, 1 Jan 2003 10:25:10 -0700 (MST) Message-Id: <200301011725.h01HPA621247@baskerville.CS.Arizona.EDU> From: Pete X-Newsgroups: comp.lang.icon Subject: GUI/print/preview X-Newsreader: Forte Agent 1.91/32.564 X-No-Archive: yes Date: Wed, 01 Jan 2003 02:14:54 +0000 X-Complaints-To: abuse@blueyonder.co.uk To: icon-group@cs.arizona.edu X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id h012Vob23763 Errors-To: icon-group-errors@cs.arizona.edu Status: RO ernobe wrote: >I found Icon on the Web after >nearly a year of searching for and trying several languages, particularly Forth >and Euphoria. A year and a bit ago, I first encountered Icon. I abandoned it in favour of Euphoria because: No easy examples of GUI programming No printer/print preview support I will admit I have learnt alot in the last year from Euphoria, maybe enough to now understand some things I did not last year. Maybe/hopefully someone can point me to something I may or may not have already read which will now make sense to get me to start using what I know in my heart is the best language I have ever seen. Pete >Perhaps part of it is intentional in order not >to share information that may be used maliciously. Highly unlikely. Icon/Euphoria are languages which protect the machine from you, and you from the machine as much as reasonable, which is an honourable goal. For truly malicious stuff you need C or assembly anyway. There is no intent to hide "dirty tricks" in these languages; the idea is that you simply do not need such to get your program to work the way you want it to. From icon-group-sender Wed Jan 1 10:24:12 2003 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id h01HNfw21179 for icon-group-addresses; Wed, 1 Jan 2003 10:23:41 -0700 (MST) Message-Id: <200301011723.h01HNfw21179@baskerville.CS.Arizona.EDU> From: Pete X-Newsgroups: comp.lang.icon Subject: Re: Scanning question X-Newsreader: Forte Agent 1.91/32.564 X-No-Archive: yes Date: Wed, 01 Jan 2003 02:26:28 +0000 X-Complaints-To: abuse@blueyonder.co.uk To: icon-group@cs.arizona.edu X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id h012Vob23759 Errors-To: icon-group-errors@cs.arizona.edu Status: RO "Andrew Hamm" wrote: >You will also find details of a book "The Icon Programming Language" ... >As a bonus it's now available for free download as a PDF file. I should have read this post before replying to the previous post, shouldn't I? Guess I should read that then. Thanks, Pete