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