jwhitnel@csib.UUCP (Jerry Whitnell) (06/05/87)
Could someone please email me the address and pricing information for the source to ICON? I'm also looking for it on either an IBM PC or a Macintosh (source please, I know of executable only), I'd also like the source as well. Thanks Jerry Whitnell Communications Solutions, Inc.
gudeman@arizona.edu (David Gudeman) (01/16/88)
cef@H.GP.CS.CMU.EDU (Charles Fineman) writes:
HOWEVER, I still can't see ICON as any more than a toy language. It
may be good for quick prototyping of complex algorithms but you probably
wouldn't want to write anything *real* in it because it is interpreted.
For a good time, say that in comp.lang.lisp. By the way, Icon's
"interpreted" code is what Lisp people call "compiled". That is, the
Icon translator converts from Icon source code to a virtual machine
code that is run by an interpreter. Most "compiled" lisps work the
same way.
In case anyone is interested, there are a _lot_ of real programs
written in Icon, for mainframes and micros both. There have been
cases of large software projects written in Icon as a prototype
language, then never converted to another language because the Icon
was version fast enough. The developers were concerned that
conversion to another language would make the program so huge that it
would not be cost-effective to ever modify or upgrade the code.
... once you've written your prototype in ICON, all you have to do
is formalize your data types....
It's not quite that simple. Icon is based on a programming language
paradigm that is a superset of the paradigm implemented by CLU. If
you want to eventually convert from Icon to a procedural language, you
should write your Icon program without depending too much on
generators and goal-directed evaluation. This takes a lot of the fun
out of Icon, but it is still easier to program in than most other
languages.pierson@encore.UUCP (Dan Pierson) (01/19/88)
In article <3473@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >For a good time, say that in comp.lang.lisp. By the way, Icon's >"interpreted" code is what Lisp people call "compiled". That is, the >Icon translator converts from Icon source code to a virtual machine >code that is run by an interpreter. Most "compiled" lisps work the >same way. Uhm, not quite true... Virtual machine compilation (a.k.a. byte-code compilation) is indeed used by many lisp and scheme systems where portablility and low maintenance are valued more than execution speed. GNU Emacs and MIT CScheme are two of the most widely used examples. Real production lisps use real compilation. There have been cases of Lisp compilers successfully competing with compilers for such languages as Fortran and C since the mid-seventies. MacLisp, Franz Lisp, T, InterLisp, and all Common Lisps that I know of compile to native machine code. -- In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson Internet: pierson@multimax.arpa
gudeman@arizona.edu (David Gudeman) (01/20/88)
In article <2506@encore.UUCP> pierson@encore.UUCP (Dan Pierson) writes: >In article <3473@megaron.arizona.edu> gudeman@arizona.edu goofs: >>...the Icon translator converts from Icon source code to a virtual >>machine code that is run by an interpreter. Most "compiled" lisps >>work the same way. > >Uhm, not quite true... > <<discussion of lisp implementations>> I guess this is a good time to admit that the only lisp implementation I know anything about is GNU elisp which is compiled into virtual machine code. I'm afraid I was making unwarranted assumptions based on my experience with Prolog implementations. Incidentally, you mention that portability and low maintenance are advantages to virtual machine code; another advantage is the small size of the object code files. For applications where space is scarce, this could be important. However I suspect that the biggest advantage of this is for programs/systems where the time to load a program is longer than the execution time of the program. For such applications, virtual machine code programs might load-and-execute noticeably faster than native machine code. (Assuming the interpreter is already in memory.) David Gudeman Department of Computer Science gudeman@arizona.edu Gould-Simpson Science Building {allegra,cmcl2,ihnp4,noao}!arizona!gudeman The University of Arizona 602-621-2858 Tucson, AZ 85721
fxtv@litp.UUCP (01/23/88)
In article <2506@encore.UUCP> pierson@encore.UUCP (Dan Pierson) writes: ... >MacLisp, Franz Lisp, T, InterLisp, and all >Common Lisps that I know of compile to native machine code. What about the T compiler? Any references, pointers, performances? Francois-Xavier Testard-Vaillant
bevan@cs.man.ac.uk (Stephen J Bevan) (04/01/91)
In <1991Apr1.043321.11251@midway.uchicago.edu> Richard L. Goerwitz writes :- >> - no packages. Everything is in one namespace. However ... > >The "however" is for Idol, I gather. For people who don't want to add >yet another level of indirection to their Icon programs, though, naming >conflicts remain a problem. I was thinking about the indirection stuff myself, however I received a message from Clinton Jeffery <cjeffery@cs.arizona.edu> about Idol and in it he says :- ``... its method lookup is a constant time operation unlike Smalltalk's'' I'm not exactly sure how this is achieved, but maybe it removes some of the worries about slow execution. >>- no exceptions. > >Have you looked at the Icon "error conversion" capability? No this one slipped me by. >> - regular expressions not supported. >> However, in many cases, you can use an Icon functions `find', >> `match', `many' and `upto' instead. > >"In many cases" ain't so. ANY pattern representable by regular >expressions can also be represented via Icon's builtin string >processing control structures and functions. Excuse the poor phrasing on my part. I didn't mean to imply that Icon couldn't handle the expressions. What I meant was that in a lot of cases, you can replace a regexp with one of the above functions, and in all cases, you can replace it with a combination of the above. >> - co-expressions haven't been implemented on Sun 4s (the type of >> machine I use) > >Please correct me if I'm wrong, but I believe I saw the coexpression >code for the Sun4 posted almost a year ago. You are right, I've only been reading comp.lang.icon for about month and so wasn't aware of it. All I can say is that the copy of Icon v8 I retrieved, explicitly mentioned the fact that co-expressions didn't work on Sun4s. I assume the code will be in the next release. >> E.2.4 Add a regular expression data type. Modify the functions find >> and match to perate appropriately when their first argument is a >> regular expression. > >I'd modify this to say, add findre() and matchre() to the list of >builtin functions. Most C libraries have regexp routines that can be >drafted to serve in these capacities. Well after spending a day adding regular expressions to ELK, I wouldn't be so sure about the regexp facilies of C libraries. For example the regexp library with SunOS 4.1 only has ed/grep style regular expression, not egrep ones. I therefore used the GNU regexp code which implements Emacs like regexps i.e. egrep standard, but with different quoting conventions. This works well for me as I've written more Emacs Lisp code than egrep/awk code. If you prefer the standard egrep style, I'd recommend Henry Spencer's regexp code. (This is used by both Python and TCL, in slightly modified forms) >> E.2.5 \ All of these suggest extending >> E.5.4 | the string scanning facilities to >> E.5.5 / cope with files and strings in a uniform way. > >Not sure what you mean. Well to quote ``The Implementation of the Icon Programming Language'' by Ralph E. Griswold and Madge T. Griswold :- E.2.5 ``Unify string and file data types so that string operations can be performed on files.'' E.4.1 (this is E.5.4 refered to above. There is a typo in the book which refers to E.4 as 5.4. This was somehow further mangled by me to produce E.5.4!) ``Many problems that should be easy to deal with using string scanning are complicated by the fact that the data to be processed is contained in a file that consists of a sequence of lines that logically constitute a single string. ...'' E.4.2 (this was E.5.5, reason as above) ``Extend string scanning to apply to files'' This topic is also mentioned in a recent post by David Gudeman in alt.lang.cfutures >> E.12.1 Provide a way to load functions (written in C) at runtime >I'm curious why it is that you would see any advantage in run-time >loading other than decreased in-core mem. reqs. Maybe you should ask Madge or Ralph Griswold, it's in their book! Personally, I thought it would be useful for the reason you mention i.e. you only load what you need. However given the following I don't think it is necessary :- >If you were to use the Icon compiler (i.e. Icon->C translator), you >wouldn't even have to worry about adding any code to any run-time >system. I knew that an Icon compiler was been developed, but I didn't actually know that it was available until after I posted. Personally I wouldn't be looking for an increase in speed (although its alway welcome, even on a SPARCstation!), I'd be more interested in the C interface i.e. how easy would it be to add extensions like, for example, dbm support? (note. that was a rhetorical question) Stephen J. Bevan bevan@cs.man.ac.uk
goer@ellis.uchicago.edu (Richard L. Goerwitz) (04/02/91)
Stephen J Bevan writes: >>> E.2.4 Add a regular expression data type. Modify the functions find >>> and match to perate appropriately when their first argument is a >>> regular expression. >> >>I'd modify this to say, add findre() and matchre() to the list of >>builtin functions. Most C libraries have regexp routines that can be >>drafted to serve in these capacities. > >Well after spending a day adding regular expressions to ELK, I >wouldn't be so sure about the regexp facilies of C libraries. For >example the regexp library with SunOS 4.1 only has ed/grep style >regular expression, not egrep ones. The findre() prototype I wrote for Icon (slow) does egrep-style pat- terns. In fact, to test it I generally run it through Henry Spencer's egrep test suite. Clinton Jeffery wrote to me a day or two ago pointing out that one big reason why Icon has no regular expressions is that no one can agree on what they should look like and how they should be used. I can only speak from practical experience. I need both a find() and a match() function that can take regular expressions as their string arguments. Of course, strictly speaking the find() one isn't necessary, since we can just tab(&pos to *&subject+1), attempting a match at each position. If we're talking egrep-stype expressions, then things like anyRE() and uptoRE() would be wholly unnecessary. I have several things I'm still wondering about: If there were a findRE() function, how would the ^ be interpreted when it referred to the beginning of a line? Would it refer to &subject[&pos] or to &subject[1]? I would see the former as more useful. If someone really wants to match a line beginning, then pos(1) is quite suf- ficient. One other thing I wonder about is how, if we have a findRE function, would we tab past the substring matched by the regular ex- pression? It would certainly be possible to use findRE() and matchRE() in concert (as in tab((findRE(pattern), matchRE(pattern)))). This seems quite inelegant, though. I'd rather see a keyword such as &endpoint used to retrieve the next position after the match. >...[H]ow easy would it be to add extensions like, for >example, dbm support? (note. that was a rhetorical question) I'm not sure what it is about the dbm routines that you need that you can't get from Icon. Just recently I posted a set of routines called "gettext," which implement some dbm-type functionality, though in a somewhat crude fashion. I'll happily mail out the latest version to anyone who wants to look it over. Full-blown dbm-type emulation without all the nutty restrictions (e.g. one database open at a time) would not be all that hard to do in Icon (using much less space than the dbm routines do). I just wrote a small package called "retrieve," which offers the basic tools not only for dbm-type key/value accesses, but for regexp pattern matching and boolean search specifications with ranges as well. It really wasn't too hard to do, and I'll be happy to pass these on to anyone who wants them. I still have a few things to do to the "retrieve" package, mostly adding docs and demos (it's part of a larger project of mine). If there is a demand, I'll post it when I'm done. Indexing and retrieval is really one of Icon's fortes. Adding native regular expression pattern matching facilities would only put an extra layer of icing on the cake. -Richard (goer@sophist.uchicago.edu) -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer