From icon-group-sender Thu May 11 07:58:43 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA01669 for icon-group-addresses; Thu, 11 May 2000 07:58:05 -0700 (MST) Message-Id: <200005111458.HAA01669@baskerville.CS.Arizona.EDU> Date: Thu, 11 May 2000 10:23:01 -0400 (EDT) From: Taybin Rutkin To: icon-group@optima.CS.Arizona.EDU Subject: Re: VIB for Linux? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 727 On Wed, 10 May 2000, Steve Wampler wrote: > Taybin Rutkin wrote: > > > I've got a general question though. Is it based on Tk? > > No, it's pure Icon code, originally written by a student > of Ralph's for a course. I don't think the student > knew about Tk at the time. Actually, I'm asking about the entire graphics system. Does it call X-Windows directly? How is it cross-platform then? I'm just asking 'cause a lot of other languages found Tk a really easy way to add graphic capabilities. I never liked having to install Tcl to use Python though. I'm wondering how hard it would be to add gtk+ support. It's been something I've been considering working on for a while. Taybin Rutkin trutkin@black.clarku.edu From icon-group-sender Thu May 11 12:47:55 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA16266 for icon-group-addresses; Thu, 11 May 2000 12:47:08 -0700 (MST) Message-Id: <200005111947.MAA16266@baskerville.CS.Arizona.EDU> To: Taybin Rutkin cc: icon-group@optima.CS.Arizona.EDU Subject: Re: VIB for Linux? Date: Thu, 11 May 2000 09:11:55 -0700 From: Clinton L Jeffery Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 625 > Actually, I'm asking about the entire graphics system. Does it call > X-Windows directly? How is it cross-platform then? I wrote the bulk of the Xlib code. Then Gregg Townsend and Sandy Miller improved it. Then Darren Merrill ported it to OS/2. Then I further separated out the platform-dependencies, and wrote the MS Windows code. The built-in functions are native and cross-platform. The higher level GUI toolkits are Icon-specific and cross-platform. > I'm wondering how hard it would be to add gtk+ support. I guess it would not be easy, but I'd be glad if you proved me wrong. :-) Clint, jeffery@cs.unlv.edu From icon-group-sender Fri May 12 10:19:29 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA00987 for icon-group-addresses; Fri, 12 May 2000 10:18:52 -0700 (MST) Message-Id: <200005121718.KAA00987@baskerville.CS.Arizona.EDU> From: "Ian Trudel" To: "Ray Pereda" , Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: Fri, 12 May 2000 01:14:09 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 4053 ----- Original Message ----- From: "Ray Pereda" To: ; Sent: Tuesday, May 02, 2000 1:36 AM Subject: Re: Is Anyone Working On A Unicode Version Of Icon? > Hi Ian, > > >How about investigate a "pluginizable" data type for Icon? > > The Jcon design makes it easy to add new data types. In the object-oriented > implementation every data type is derived from a common base class that has > many useful defaults. Go to the www.cs.arizona.edu/icon to read more about > Jcon. > > >Data type could be added to the Icon's runtime system on the fly. > > I've heard this idea mentioned before. This would take a little bit more > thinking things through, but it would be a big win for Icon programmers. Hello, I agree on this, the extra flexibility given by such system would be really interesting. It would probably also avoid multiple version, or distribution, of Icon, such as Unicon, MT Icon, etc. (Speaking of 'distroing', that's something I dislike from Linux. There is like a gazilion of distro, making the thing hard sometime..) I've glanced the Jcon source code. Truely remarkable, adding a new data type is pretty simple. That's not so true for the original Icon system though. The main problem is the primitive data types are embedded in some switch()s', so adding a new type requires editing many files and stuff. That's error prone. However, it would certainly be possible to add a new dynamic primitive, which would allow us to add new primitives on the fly. This could also allow either statically linked (with Icon source) or dynamically linked (shared library or dynamic linked library). This special primitive could let a third party 'register' his new data type along his special functions. The primitive system would, of course, expecting some basic functions such as data convertion or Icon operators, for example. Note the dynamic primitive data type would requires us to add only one new descriptor. But Hey, hang on a minute.. why not rewrite the whole primitive system (*giggles*) now we speaking of it! A certain system dictionary could maintain the primitive set and manage them. No need of a dynamic dictionary, I think the primitive data types should be a limited ressource anyway. A limit of 255 primitives would be just enough for a while! Anyway, we should be able to register a primitive to the system (or) primitive dictionary, along the new functions. If name spacing possible, no need to register basic functions (such as convertion), they could have standard name (such as toString, toCSet, toInteger, ..., or fromInteger, etc) or if none found, the prim's function is automatically failing. This would be also good at the source code level, each primitive could be a new C file. So, if I want to dig into CSet functionalites, I glance in primCSet.c (or whatever). Things are clear in the implementation book and the tech reports, but at the source code level, it's somehow mixed up and there is no roadmap. Erm.. There is some bad sides of this, of course, like changing the whole source is not so trivial or making primitives co-existing may be sometimes hard (hey, what happen if you add a new prim? do we have to add convertion functions to each other prims? etc)... what else.. a new C interface (for loadable C fonction) would be needed? Anyway, I'm pretty sure you can find others. Icon implementation is not as simple as Smalltalk, for example, but it's nonetheless interesting. There is lotsa things from Smalltalk (or Squeak) that could be good in Icon without changing the whole Icon's implementation. I know the Icon project ppl seeking the stability and portability of their programming language, but I think the dynamic primitive data type system would just be awesome!! It'd certainly worth the effort. Any thoughts? Ok, I'm off to bed.. Ian Trudel PS: If you're curious, check out these URL (Squeak primitive stuff): http://www.create.ucsb.edu/squeak/DIYSqPrims.html http://minnow.cc.gatech.edu/squeak/464 From icon-group-sender Fri May 12 12:34:30 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA06511 for icon-group-addresses; Fri, 12 May 2000 12:34:17 -0700 (MST) Message-Id: <200005121934.MAA06511@baskerville.CS.Arizona.EDU> From: collberg@optima.CS.Arizona.EDU (Christian S. Collberg) X-Newsgroups: comp.lang.icon Subject: XML tools in Icon? Date: 12 May 2000 10:44:10 -0700 To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 122 Are there any XML readers/writers available for Icon? Thanks. -- /CC _______________________ http://www.collberg.com From icon-group-sender Fri May 12 12:35:09 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA06563 for icon-group-addresses; Fri, 12 May 2000 12:34:57 -0700 (MST) Message-Id: <200005121934.MAA06563@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Fri, 12 May 2000 14:57:07 -0000 X-Trace: client 958157853 38.163.203.81 (Fri, 12 May 2000 14:57:33 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1128 I would agree that it is much easier to add a new primitive type to the Java implementation of Icon, as opposed to the C implementation. In either case, however, adding a new primitive type involves coding in a language other than Icon. Ideally, it would be nice to be able to write a new type, along with its associated primitive operations, in Icon. Currently, Icon permits one to define a new type with a record declaration, such as record Unicode_cset( ... ) A programmer can then define procedures for the new record type. A record type, however, fails to extend the set of primitive types, for the following reasons: 1. You cannot (re)define the primitive operators, such as "*", "++", or "<<", for a record type; 2. You cannot define implicit /explicit type conversions between a record type and the existing types; and 3. You cannot define the behaviour of functions such as image and write for the new record type. Now imagine that we modify Icon so that we could define operators, type conversions, etc. for user-defined Icon types. Would this give us a "pluggable" capability, similar to Squeak? From icon-group-sender Tue May 16 12:23:51 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA28222 for icon-group-addresses; Tue, 16 May 2000 12:22:54 -0700 (MST) Message-Id: <200005161922.MAA28222@baskerville.CS.Arizona.EDU> From: "F.G. van DORP" X-Newsgroups: comp.lang.icon Subject: Re: Reversible assignment really reversible ? X-Newsreader: Forte Agent 1.7/32.534 Date: Tue, 16 May 2000 18:42:07 GMT X-Complaints-To: abuse@chello.nl X-Trace: flipper 958502527 212.187.67.243 (Tue, 16 May 2000 20:42:07 MET DST) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1131 On 24 Apr 2000 15:36:45 -0400, "Frank J. Lhota" wrote: >... My problem with reversible assignment was partly due to an (in hindsight) obvious oversight about the nature of resumption within backtracking. A generator that has spent all of its results will NOT make the whole expression fail, but will make the subexpression(s) in front of it resume and on their success will then resume providing its own results all over again. See GEN2() below #------------------------------------------------------------------------- procedure main() write(a:=gen1(),b:=gen2(),9<(a+b)) end procedure gen1() local p; p:=0 while (p<5) do {p +:=1;write("p=",p);suspend p} end procedure gen2() local q; q:=4 while (q<8) do {q +:=1;write("q=",q);suspend q} end #------------------------------------------------------------------------ BTW, #------------------------------------- procedure revass(a,b) local c; c:=a suspend (a:=b|(a:=c, &fail)) #------------------------------------- doesn't seem to work in the 8queens example, neither does MYREVASS() (without the &FAIL), but that was no big surprise. From icon-group-sender Wed May 17 07:39:25 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00548 for icon-group-addresses; Wed, 17 May 2000 07:38:12 -0700 (MST) Message-Id: <200005171438.HAA00548@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 17 May 2000 02:40:50 GMT X-Trace: vishnu.jussieu.fr 958531250 5464 132.227.81.128 (17 May 2000 02:40:50 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1504 In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>, Ian Trudel wrote: >Yes, but there are many factors that may not be in favor of doing primitive >types in Icon. Speed issue may be a problem. Or when the primitive uses >system depend things, such as sockets or some database API. Yet, the spirit >of Icon is not "everything should be made in Icon" such as Smalltalk >communities. Icon is not even bootstrapped. This latter made me surprised, >Icon is so powerful and his text processing feature would just let anyone >write good, complete and yet understandable compiler/interpreter! I've always been under the impression that the Icon project has a shortage of man power, which means that many cool things actually don't exist. Personally, I would love to see Icon extended to be Idol (without the preprocessing, which makes things awkward enough to debug for me that I seldom use idol), or I would love to see the icon compiler resurrected, and extended to handle separate compilation and direct translation to C primitive numeric types (well, C++ looks like a more viable alternative, but then I'm weird). Unfortunately, I don't believe that the projet has resources to do that, and I also know that I'm tangled up in enough programming projects that I can't afford yet another one :( -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed May 17 07:40:12 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00581 for icon-group-addresses; Wed, 17 May 2000 07:39:57 -0700 (MST) Message-Id: <200005171439.HAA00581@baskerville.CS.Arizona.EDU> From: "Ian Trudel" X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 17 May 2000 02:32:35 GMT X-Complaints-To: abuse@cgocable.ca X-Trace: carnaval.risq.qc.ca 958530755 24.226.208.172 (Tue, 16 May 2000 22:32:35 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 4406 Hello Frank, really interesting comments here. > I would agree that it is much easier to add a new primitive type to the Java > implementation of Icon, as opposed to the C implementation. In either case, > however, adding a new primitive type involves coding in a language other > than Icon. Ideally, it would be nice to be able to write a new type, along > with its associated primitive operations, in Icon. Yes, but there are many factors that may not be in favor of doing primitive types in Icon. Speed issue may be a problem. Or when the primitive uses system depend things, such as sockets or some database API. Yet, the spirit of Icon is not "everything should be made in Icon" such as Smalltalk communities. Icon is not even bootstrapped. This latter made me surprised, Icon is so powerful and his text processing feature would just let anyone write good, complete and yet understandable compiler/interpreter! > Currently, Icon permits one to define a new type with a record declaration, > such as > > record Unicode_cset( ... ) > > A programmer can then define procedures for the new record type. A record > type, however, fails to extend the set of primitive types, for the following > reasons: > > 1. You cannot (re)define the primitive operators, such as "*", "++", or > "<<", for a record type; > 2. You cannot define implicit /explicit type conversions between a record > type and the existing types; and > 3. You cannot define the behaviour of functions such as image and write > for the new record type. Good points here. I'm not sure it should be part of Icon programming language though. It appears much more like "object orientation" than the old procedural language style. (BTW, is it a feature of Idol? I never used it..) To be honest, I'm not sure if it's a good idea to have primitive data type ability at Icon's level. Primitive should be a limited resource. It would also require much more work and I have no idea on the position of Icon Project Group. Yet my intend is not to go against their vision and I do not want to start a new dialect. > Now imagine that we modify Icon so that we could define operators, type > conversions, etc. for user-defined Icon types. Would this give us a > "pluggable" capability, similar to Squeak? Not exactly, but it'd be impressive as well. Actually, Squeak and Icon are different in their nature. Squeak is a Smalltalk dialect. Smalltalk is a pure object-oriented programming environment/language. Icon is not an environment nor OO. Smalltalk is also bootstrapped. Smalltalk is written in Smalltalk. Usually, the virtual machine is not in Smalltalk though. But here comes Squeak, they're cheating!! The Squeak virtual machine is written in Slang, a Smalltalk subset, and debugged under Squeak environment! It's just awesome.. but it does not end here, because Squeak generate portable C code. Did you guess? Yes, they're generating the virtual machine in C code and compile it for virtually any plateforms! Enough of Squeak/Smalltalk, let's talk about Icon again. Yes, that'd be nice to write primitive in Icon. If we had a dynamic primitive data types system. And no, we wouldn't have to change Icon's implementation for being able to write primitive in Icon. Why? As I said earlier, Icon's text processing features could just be great for compiler things. We could write a Icon to C generator. I've seen a little thing provided with Icon (icn2c.icn, I think), would not be too hard to extend it or rewriting it for that purpose. Primitives could still be written in the old C way as well.. Anyway, I think adding dynamic primitive data type system would be valuable at all points. IMHO, it'd be also acceptable for Icon Project Group, because it doesn't require to change everything in their actual implementation. I know they strive for some ultime stability and portability, which is great! On the other hand, that would allow a faster evolution of Icon without changing the base system, the work of Icon Project Group. Plus, if someone like me does a new primitive data type and Icon Project Group likes it, this could be easily integrated to the next release.. without redownloading the whole Icon or even recompiling Icon *mega grin*. PS: It'd be also nice to bootstrap Icon. Ok, ok, there's enough work to do yet. ::)) -- Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ From icon-group-sender Wed May 17 07:40:50 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00658 for icon-group-addresses; Wed, 17 May 2000 07:40:36 -0700 (MST) Message-Id: <200005171440.HAA00658@baskerville.CS.Arizona.EDU> From: "Ian Trudel" X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 17 May 2000 05:26:27 GMT X-Complaints-To: abuse@cgocable.ca X-Trace: carnaval.risq.qc.ca 958541187 24.226.208.172 (Wed, 17 May 2000 01:26:27 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 4795 "Marc Espie" a écrit dans le message news: 8ft0ri$5ao$1@vishnu.jussieu.fr... > In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>, > Ian Trudel wrote: > >Yes, but there are many factors that may not be in favor of doing primitive > >types in Icon. Speed issue may be a problem. Or when the primitive uses > >system depend things, such as sockets or some database API. Yet, the spirit > >of Icon is not "everything should be made in Icon" such as Smalltalk > >communities. Icon is not even bootstrapped. This latter made me surprised, > >Icon is so powerful and his text processing feature would just let anyone > >write good, complete and yet understandable compiler/interpreter! > I've always been under the impression that the Icon project has a shortage > of man power, which means that many cool things actually don't exist. Well, yet I just mean things that already exist.. but maybe Icon can help us to do these in some easier manners?! ::) > Personally, I would love to see Icon extended to be Idol (without the > preprocessing, which makes things awkward enough to debug for me that I > seldom use idol), or I would love to see the icon compiler resurrected, and > extended to handle separate compilation and direct translation to C > primitive numeric types (well, C++ looks like a more viable alternative, > but then I'm weird). My feeling about Idol is: this is just the same as C and Objective-C. Having Idol implemented in the core of Icon's implementation may not be trivial task at all. I don't know Idol, but Objective-C allows many dynamic things that you just couldn't do in C++. If Idol does so, it makes the full C implementation harder to write. Since I haven't tried Idol, I can't speak with much concern, but it may just be matter of changing few things out the current preprocessing implementation to make it stronger. Yet, you could also build a special debugging tool. I'm some C fellow, but I'm just thinking as an Icon programmer, we should get out of any direct contact with C. Hence I'm getting interest in some bootstrapping, writting primitives in Icon (which they would be translated in C for compilation and linking). If Icon would allow us to write shared library, that'd really rocks. We could write some high level primitives that really needs to be written in Icon (only few cases, IMO). Unfortunatly, handling shared library is often OS-oriented. Under *NIX, it's pretty easy, but under Windows and OS/2, it requires some special structure. Anyway, this is just a thought! As you write about C++, I don't see any point of it. Icon is implemented in C and C is available on a *lot* of platforms and works quite same (I've got a weird feeling "quite same", "quite same", [..]). You should not forget that the interface with generated code and Icon would probably be in C rather than C++ anyway. I think the standard translator should translate Icon to C, but nothing says there should not be a C++ translator available as well. BTW, I just like your "icon compiler resurrected" ! It's an interesting thing that talks by itself. Actually, the current Icon implementation is a little bit complex. I've seen worst, of course, Icon is nonetheless clearly written. But since I'm some VM hacker wannabe (*LOL*), I got in touch with some implementations out there. Smalltalk's VM came up the easiest one. Squeak in particular is bringing a new vision of VM implementations. Squeak's VM is pretty easy to understand, even for a newbie VM hacker. I don't think it should remplace Icon. I'm not promoting Smalltalk here. I just think it could help to reimplement Icon in a new, fresh, and very simple manner. For exemple, block contexts in Smalltalk are just the same as "scanning environment", but they are not specific to strings, not specific at all! This would be a long term project that IPG would probably not want to do. However, the dynamic primitive data types would be much more interesting and smaller project. > Unfortunately, I don't believe that the projet has resources to do that, > and I also know that I'm tangled up in enough programming projects that > I can't afford yet another one :( I don't know the position of IPG in the moment, they'll probably hook on our thread this week. I don't know if I would do it myself, I'm kinda concerned in professional development and willing to write software(s) in Icon. The fact is I need something to pay my university fees. ::) Another fact is, if I would do it.. will IPG integrate it to Icon? If the answer is no, I would not even write a line of code because this would lead to ANOTHER dialect of the language. I'd rather support fully Icon. cheer, -- Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ From icon-group-sender Wed May 17 07:41:46 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00700 for icon-group-addresses; Wed, 17 May 2000 07:41:01 -0700 (MST) Message-Id: <200005171441.HAA00700@baskerville.CS.Arizona.EDU> From: "Ian Trudel" X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 17 May 2000 07:24:25 GMT X-Complaints-To: abuse@cgocable.ca X-Trace: carnaval.risq.qc.ca 958548265 24.226.208.172 (Wed, 17 May 2000 03:24:25 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1677 > I'm some C fellow, but I'm just thinking as an Icon programmer, we should > get out of any direct contact with C. Hence I'm getting interest in some > bootstrapping, writting primitives in Icon (which they would be translated > in C for compilation and linking). If Icon would allow us to write shared > library, that'd really rocks. We could write some high level primitives that > really needs to be written in Icon (only few cases, IMO). Unfortunatly, > handling shared library is often OS-oriented. Under *NIX, it's pretty easy, > but under Windows and OS/2, it requires some special structure. Anyway, this > is just a thought! Oh yeah, I forgot some things. First, Icon generates bytecodes which are interpreted by the virtual machine. But hey, Java is bytecoded and there is no executable files? Yeah, right, the virtual machine is copied and the code is appended or something. That's why a simple "hello world" takes 300k! he he he. Basically, the problem comes from this issue and the calling convention. Shared library are modeled from C language and its calling convention. Icon as no such support! So, adding support for generation of shared library is like having a special virtual machine that handle calling convention and "understand" it to run proper procedures. That'd also make big shared library.. Anyway, if I'd be worrying about something, I would do for the calling convention thing. ::) I'm not sure about "how hard" it'd be to do. However, that'd be another cool thing about Icon. Gee, wouldn't be nice to do plugins for your favorite apps in Icon?! see ya, -- Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ From icon-group-sender Wed May 17 07:42:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00760 for icon-group-addresses; Wed, 17 May 2000 07:41:59 -0700 (MST) Message-Id: <200005171441.HAA00760@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 17 May 2000 09:45:59 GMT X-Trace: vishnu.jussieu.fr 958556759 17223 132.227.81.128 (17 May 2000 09:45:59 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1885 In article <74qU4.790$to2.107064@carnaval.risq.qc.ca>, Ian Trudel wrote: >As you write about C++, I don't see any point of it. Icon is implemented in >C and C is available on a *lot* of platforms and works quite same (I've got >a weird feeling "quite same", "quite same", [..]). You should not forget >that the interface with generated code and Icon would probably be in C >rather than C++ anyway. I think the standard translator should translate >Icon to C, but nothing says there should not be a C++ translator available >as well. C++ is available on a lot of platforms. Find me a platform that doesn't support a C++ compiler. I've seen Icon runtime library, I know C, I know C++. I know that the translation to C++ of quite a few concepts would be fairly direct (most icon objects would just get a class, and handling polymorphism is not much harder, especially with type deduction running along, since you don't always need polymorphism). There are also fairly reasonable ways to `invert' Icon concepts such as generators into fast C++ constructs. My main concern with the icon-to-C compiler was size and speed: it's not reasonable to use over a 3000 lines project which translate to >90000 lines of C, which then proceeds to exceed 80MB of memory to compile... At a guess, the corresponding translation to C++ would be 10 times smaller, and much more easy to tweak. But then, this means having someone with free time on their hands, and knowing C++... As far as byte-code and the java analogy goes, I'm not convinced at all. We already have a perfectly good working, somewhat slow, icon implementation. What's the benefit of doing yet another slow implementation ? -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed May 17 07:43:13 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00794 for icon-group-addresses; Wed, 17 May 2000 07:42:44 -0700 (MST) Message-Id: <200005171442.HAA00794@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: Re: Reversible assignment really reversible ? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 17 May 2000 09:21:29 -0000 X-Trace: client 958569712 38.163.203.81 (Wed, 17 May 2000 09:21:52 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1452 "F.G. van DORP" wrote in message news:h553is4c3ulev333pul872qcr7e5uvubih@4ax.com... > BTW, > #------------------------------------- > procedure revass(a,b) > local c; c:=a > suspend (a:=b|(a:=c, &fail)) > #------------------------------------- > doesn't seem to work in the 8queens example, neither > does MYREVASS() (without the &FAIL), > but that was no big surprise. There may be a misunderstanding here. In Icon, all procedure parameters are passed by value, not by reference. When the procedure revass is called, a and b are assigned the values of the first and second actual parameters (or &null if these parameters are not specified). If the statements in revass changes in a and b, these changes are NOT copied back to the actual parameters. If we were to execute the following Icon code: c := 3 revass( c, 4 ) the value of c would not be affected. The revass function would assign 4 to the local variable a, but that would have no impact on c. The situation is similar in the C language. The C function int Assign( int a, int b ) { return ( a = b ); } does NOT simulate C integer assignment, since the assignment statement ( a = b ) only changes the local variable a. If you want to simulate reversible assignment, you need a more sophisticated approach. Icon structures such as lists and records use pointer semantics, and can be used to get the effect of pass by reference. From icon-group-sender Wed May 17 07:44:01 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00845 for icon-group-addresses; Wed, 17 May 2000 07:43:27 -0700 (MST) Message-Id: <200005171443.HAA00845@baskerville.CS.Arizona.EDU> From: "Ian Trudel" X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Wed, 17 May 2000 13:52:48 GMT X-Complaints-To: abuse@cgocable.ca X-Trace: carnaval.risq.qc.ca 958571568 24.226.208.172 (Wed, 17 May 2000 09:52:48 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2899 1/ I ain't no C++ support, fellow, fan, or not even like the language. Let's not talk about it. ::) 2/ The point of my original post is not really Icon reimplementation, but adding a new feature to the language. 3/ I feel your post "hide" something, like transforming Icon to some OOP language. If we change Icon's nature, we're no longer having Icon. It'd be better to support Idol instead, in that concern. 4/ My point about platform availability was about backward compatibility. I know that nowaday's machines and system have C++ compilers available, but Icon also runs on older machines/systems. 5/ and finaly, speed issue only speaks by benchmarking. > My main concern with the icon-to-C compiler was size and speed: it's not > reasonable to use over a 3000 lines project which translate to >90000 lines > of C, which then proceeds to exceed 80MB of memory to compile... Actually, we should not forget one thing about Icon. Even though Icon looks to my eye pretty young, fresh and complete, the fact is the first implementation was made in 1979! I'm not sure when the C implemention has started, but it's sure old. Most concepts of Icon implementation just rocks, but it doesn't mean these are using the newer and better techniques. > At a guess, the corresponding translation to C++ would be 10 times smaller, > and much more easy to tweak. But then, this means having someone with free > time on their hands, and knowing C++... Well, I agree on this. But good C code can be just similar. A *small* reminder: C is a simple language, even though pointer arithmetics may drive some crazy, it has few keywords and structures. C++ is a complex language, it has full C compatibility, plus it has its own good and bad things. There is a *lot* of concepts in C++ and avanced one are even not usually convered by popular books. There is many things that was not even concerned in the seventies and eighties, such as resuability, portability, information hidding and stuff. So, the techniques have lot changed and there is more and more valuable documents on the newer way of implementing old concepts (nowaday's GC implementations are just crazy, it almost worth any custom made memory management. There is just almost no reason to not use GC now ::). You should also dig into Squeak's Virtual Machine source code. You'd probably be impressed how clean/clear their C implementation is made. Don't forget it's generated C code, for most parts. I guess they found no reason to implement it in C++. Squeak is much more portable than Icon, it runs on everything gcc do (and runs virtually the same on every platform!), the only exception is the need of bitblt functionalities. Anyway, I still recall my primary concern was/is about dynamic primitive data types in Icon. Wouldn't it be nice if.. Cheer, ::) -- Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ From icon-group-sender Wed May 17 09:34:16 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04298 for icon-group-addresses; Wed, 17 May 2000 09:33:54 -0700 (MST) Message-Id: <200005171633.JAA04298@baskerville.CS.Arizona.EDU> Date: Wed, 17 May 2000 08:01:08 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1225 Ian Trudel wrote: > Actually, we should not forget one thing about Icon. Even though Icon looks > to my eye pretty young, fresh and complete, the fact is the first > implementation was made in 1979! I'm not sure when the C implemention has > started, but it's sure old. Most concepts of Icon implementation just rocks, > but it doesn't mean these are using the newer and better techniques. Just for historical accuracy... 1979 is the first C implemenation of Icon (done by Cary Coutant and me) - the first implementation of Icon (an amazing beast written in FORTRAN that producing FORTRAN (really RatFor) executables) was several years old by that time. Also, the C implementation was done on a PDP 11/70, with its 64K address space - so some of the implementation decisions were driven by considerations that are no longer relevant! Cary produced a compiler for Icon at the same time, but there was surprisingly little improvement over the interpreter because Icon spends most of its time in the run-time system, which is already compiled code. It wasn't until later that Ken Walker's work produced a more efficient optimizing compiler. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Wed May 17 09:36:02 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04442 for icon-group-addresses; Wed, 17 May 2000 09:35:49 -0700 (MST) Message-Id: <200005171635.JAA04442@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 17 May 2000 10:41:08 -0400 X-Newsgroups: comp.lang.icon X-Trace: vishnu.jussieu.fr 958531250 5464 132.227.81.128 (17 May 2000 02:40:50 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) X-Filter: mailagent [version 3.0 PL68] for efeustel@cs.ida.org To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1505 In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>, Ian Trudel wrote: >Yes, but there are many factors that may not be in favor of doing primitive >types in Icon. Speed issue may be a problem. Or when the primitive uses >system depend things, such as sockets or some database API. Yet, the spirit >of Icon is not "everything should be made in Icon" such as Smalltalk >communities. Icon is not even bootstrapped. This latter made me surprised, >Icon is so powerful and his text processing feature would just let anyone >write good, complete and yet understandable compiler/interpreter! I've always been under the impression that the Icon project has a shortage of man power, which means that many cool things actually don't exist. Personally, I would love to see Icon extended to be Idol (without the preprocessing, which makes things awkward enough to debug for me that I seldom use idol), or I would love to see the icon compiler resurrected, and extended to handle separate compilation and direct translation to C primitive numeric types (well, C++ looks like a more viable alternative, but then I'm weird). Unfortunately, I don't believe that the projet has resources to do that, and I also know that I'm tangled up in enough programming projects that I can't afford yet another one :( -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed May 17 12:23:02 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA09657 for icon-group-addresses; Wed, 17 May 2000 12:22:45 -0700 (MST) Message-Id: <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: Wed, 17 May 2000 10:49:08 -0700 x-sender: cary@adlmail.cup.hp.com From: Cary Coutant To: "Steve Wampler" , "icon-group" Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2096 >Just for historical accuracy... > >1979 is the first C implemenation of Icon (done by Cary Coutant and me) - >the first implementation of Icon (an amazing beast written in FORTRAN that >producing FORTRAN (really RatFor) executables) was several years old by >that time. Also, the C implementation was done on a PDP 11/70, with >its 64K address space - so some of the implementation decisions were driven >by considerations that are no longer relevant! > >Cary produced a compiler for Icon at the same time, but there was >surprisingly >little improvement over the interpreter because Icon spends most of its time >in the run-time system, which is already compiled code. It wasn't until >later >that Ken Walker's work produced a more efficient optimizing compiler. To clarify a bit more, the first implementation we did in 1979 was sort of a compiler. The icon translator still generated the "u-code" -- our intermediate representation -- and the icon linker then generated a single, large, PDP-11 assembly-language source file. This file was then assembled and linked against the large Icon runtime library to produce a native executable. The assembly code was really little more than calls to the runtime system, and was a very straightforward and simple translation of the Icon intermediate code. The problem with this approach was that the runtime library was so huge that link times were large even for a simple "hello, world" program. Around 1981, I think, I spent a week modifying the Icon linker to produce the Icon byte code instead of PDP-11 assembly language, and then built a small interpreter, linked to the runtime system. Now, the Icon linker needed only to produce a small bytecode file that could be read and interpreted by "iconx." The result was greatly improved compile and link times, very little runtime performance difference, and -- finally -- easier portability to other Unix machines. At the time, I was just copying the idea of a bytecode interpreter from the Pascal p-system. Little did I realize that Sun had yet to "invent" bytecode! -cary From icon-group-sender Wed May 17 12:23:58 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA09697 for icon-group-addresses; Wed, 17 May 2000 12:23:23 -0700 (MST) Message-Id: <200005171923.MAA09697@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 17 May 2000 18:46:29 GMT X-Trace: vishnu.jussieu.fr 958589189 2939 132.227.81.128 (17 May 2000 18:46:29 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1821 In article <200005171443.HAA00845@baskerville.CS.Arizona.EDU>, Ian Trudel wrote: >3/ I feel your post "hide" something, like transforming Icon to some OOP >language. If we change Icon's nature, we're no longer having Icon. It'd be >better to support Idol instead, in that concern. Wow, powerful drugs. Read what I write, and not what you feel like I'm writing. >4/ My point about platform availability was about backward compatibility. I >know that nowaday's machines and system have C++ compilers available, but >Icon also runs on older machines/systems. I'm perfectly aware of the machines Icon runs upon. Don't speak about `older machines/systems', give me the name of one such system which does not support a C++ compiler. Speaking in generalities lead nowhere. >5/ and finaly, speed issue only speaks by benchmarking. I've run some fairly large icon projects in the past. I have a fairly good idea about what slowed them down eventually. I even have a submitted paper to a conference that pits icon against maple and C++. >There is many things that was not even concerned in the seventies and >eighties, such as resuability, portability, information hidding and stuff. >So, the techniques have lot changed and there is more and more valuable >documents on the newer way of implementing old concepts (nowaday's GC >implementations are just crazy, it almost worth any custom made memory >management. There is just almost no reason to not use GC now ::). Like wow, I was around in the eighties, and I haven't noticed portability and reusability coming out of nowhere... It was around pretty much forever... -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed May 17 16:24:48 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA19139 for icon-group-addresses; Wed, 17 May 2000 16:24:21 -0700 (MST) Message-Id: <200005172324.QAA19139@baskerville.CS.Arizona.EDU> From: "Ian Trudel" To: "Icon Project Group" Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: Wed, 17 May 2000 17:24:01 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3837 "Marc Espie" a écrit dans le message news: 200005171923.MAA09697@baskerville.CS.Arizona.EDU... > In article <200005171443.HAA00845@baskerville.CS.Arizona.EDU>, > Ian Trudel wrote: > >3/ I feel your post "hide" something, like transforming Icon to some OOP > >language. If we change Icon's nature, we're no longer having Icon. It'd be > >better to support Idol instead, in that concern. > Wow, powerful drugs. Read what I write, and not what you feel like I'm > writing. Is it OK with you if my feeling is wrong? Whatever, you confirmed my feeling was wrong, no need to add insult with it. ::) > >4/ My point about platform availability was about backward compatibility. I > >know that nowaday's machines and system have C++ compilers available, but > >Icon also runs on older machines/systems. > I'm perfectly aware of the machines Icon runs upon. > Don't speak about `older machines/systems', give me the name of one such > system which does not support a C++ compiler. Speaking in generalities > lead nowhere. I'm sorry about this point. Indeed, I don't really care about C++, I usually avoid projects requiring it. I'm not taking part of an official C++ opposition! I'm not going to build a list of plateforms that don't support C++, if any. That'd be pointless as well as speaking about generalities. > >5/ and finaly, speed issue only speaks by benchmarking. > I've run some fairly large icon projects in the past. I have a fairly good > idea about what slowed them down eventually. I even have a submitted paper > to a conference that pits icon against maple and C++. Now that's interesting, is your paper online? > >There is many things that was not even concerned in the seventies and > >eighties, such as resuability, portability, information hidding and stuff. > >So, the techniques have lot changed and there is more and more valuable > >documents on the newer way of implementing old concepts (nowaday's GC > >implementations are just crazy, it almost worth any custom made memory > >management. There is just almost no reason to not use GC now ::). > > Like wow, I was around in the eighties, and I haven't noticed portability > and reusability coming out of nowhere... It was around pretty much forever... Funny, they're still talking about it today. Actually, I haven't worked for huge companies that have plenty of money to pay me to make things fully reuseable. But I've been pretty lucky cause most of the time, my bosses allowed me to take the time to think about reusable components. However, many of my friends are working in small and average companies that are willing them to produce results fast-fast-fast. They know and talk about reusability with me, they have interesting point of views on it.. but they actually never reuse anything nor making things to be reusable. My point is, they are nice words, but the code doesn't always show their significations. It was true yestarday, in eighties, it's still (too often, in my taste) true today. Yet, I'm younger, so the eighties is sometime blurry in my mind, but I have plenty of books that reminds me the decade. I'm not willing to fight with you or anyone. My interests are not in rewriting Icon, though having an intelligent conversation with people on this list may be instructive and interesting. I'm primarly interested in adding ONE specific feature to Icon so it would let us extent some parts of the language without remodeling/rewriting the whole implementation and create some new dialect(s). Some other things along this feature such as Icon to "whatever language you want" may be interesting as well. If you're not personally interested by this topic, it's ok, let's just stop messages here. regards, Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ From icon-group-sender Wed May 17 16:25:44 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA19236 for icon-group-addresses; Wed, 17 May 2000 16:25:36 -0700 (MST) Message-Id: <200005172325.QAA19236@baskerville.CS.Arizona.EDU> From: "Ian Trudel" To: "icon-group" Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: Wed, 17 May 2000 17:29:12 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2812 Thanks for the enlightement, I was not aware of this. "The Implementation Of The Icon Programming Language" book says: "The first implementation of Icon (Griswold and Hanson 1979) was written in RatFor, a preprocessor for Fortran that supports structured programming features (Kernighan 1975).", p.6. regards, Ian Trudel, aka BackOrder StarTrip Server Administrator http://startrip.gene6.com/ ----- Original Message ----- From: "Cary Coutant" To: "Steve Wampler" ; "icon-group" Sent: Wednesday, May 17, 2000 1:49 PM Subject: Re: Is Anyone Working On A Unicode Version Of Icon? > >Just for historical accuracy... > > > >1979 is the first C implemenation of Icon (done by Cary Coutant and me) - > >the first implementation of Icon (an amazing beast written in FORTRAN that > >producing FORTRAN (really RatFor) executables) was several years old by > >that time. Also, the C implementation was done on a PDP 11/70, with > >its 64K address space - so some of the implementation decisions were driven > >by considerations that are no longer relevant! > > > >Cary produced a compiler for Icon at the same time, but there was > >surprisingly > >little improvement over the interpreter because Icon spends most of its time > >in the run-time system, which is already compiled code. It wasn't until > >later > >that Ken Walker's work produced a more efficient optimizing compiler. > > To clarify a bit more, the first implementation we did in 1979 was sort > of a compiler. The icon translator still generated the "u-code" -- our > intermediate representation -- and the icon linker then generated a > single, large, PDP-11 assembly-language source file. This file was then > assembled and linked against the large Icon runtime library to produce a > native executable. The assembly code was really little more than calls to > the runtime system, and was a very straightforward and simple translation > of the Icon intermediate code. > > The problem with this approach was that the runtime library was so huge > that link times were large even for a simple "hello, world" program. > > Around 1981, I think, I spent a week modifying the Icon linker to produce > the Icon byte code instead of PDP-11 assembly language, and then built a > small interpreter, linked to the runtime system. Now, the Icon linker > needed only to produce a small bytecode file that could be read and > interpreted by "iconx." The result was greatly improved compile and link > times, very little runtime performance difference, and -- finally -- > easier portability to other Unix machines. > > At the time, I was just copying the idea of a bytecode interpreter from > the Pascal p-system. Little did I realize that Sun had yet to "invent" > bytecode! > > -cary > From icon-group-sender Thu May 18 07:56:14 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA14529 for icon-group-addresses; Thu, 18 May 2000 07:53:43 -0700 (MST) Message-Id: <200005181453.HAA14529@baskerville.CS.Arizona.EDU> From: Patrick Scheible X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 18 May 2000 00:11:21 GMT X-Newsreader: Gnus v5.3/Emacs 19.34 Cache-Post-Path: dns2.serv.net!unknown@itchy.serv.net X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 760 espie@liafa.jussieu.fr (Marc Espie) writes: > >There is many things that was not even concerned in the seventies and > >eighties, such as resuability, portability, information hidding and stuff. > >So, the techniques have lot changed and there is more and more valuable > >documents on the newer way of implementing old concepts (nowaday's GC > >implementations are just crazy, it almost worth any custom made memory > >management. There is just almost no reason to not use GC now ::). > > Like wow, I was around in the eighties, and I haven't noticed portability > and reusability coming out of nowhere... It was around pretty much forever... Yes, portability and reusability have been concerns since Fortran and COBOL were invented. -- Patrick Scheible From icon-group-sender Thu May 18 12:21:29 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA21692 for icon-group-addresses; Thu, 18 May 2000 12:21:15 -0700 (MST) Message-Id: <200005181921.MAA21692@baskerville.CS.Arizona.EDU> Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: Thu, 18 May 2000 10:23:07 -0700 x-sender: cary@adlmail.cup.hp.com From: Cary Coutant To: "Ian Trudel" , "icon-group" Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 794 Steve said: >> >1979 is the first C implemenation of Icon (done by Cary Coutant and me) - >> >the first implementation of Icon ... was several years old by >> >that time. And I replied: >> To clarify a bit more, the first implementation we did in 1979 was sort >> of a compiler. Then Ian quoted this from the Icon implementation book: >"The first implementation of Icon (Griswold and Hanson 1979) was written in >RatFor, a preprocessor for Fortran that supports structured programming >features (Kernighan 1975).", p.6. In replying to Steve's message, I was referring to the first implementation that Steve and I did in C on the PDP/11. Yes, there was the Ratfor version (on the DEC-10) by Tim Korb (aka "bikmort"), et. al., before that. Sorry, I didn't mean to mislead anyone. -cary From icon-group-sender Thu May 18 16:24:39 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA28120 for icon-group-addresses; Thu, 18 May 2000 16:23:25 -0700 (MST) Message-Id: <200005182323.QAA28120@baskerville.CS.Arizona.EDU> From: "J.R. Sampson" To: icon-group@optima.CS.Arizona.EDU Date: Thu, 18 May 2000 22:52:24 +0100 Subject: Logicon Prolog interpreter Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1143 Hello - I have been looking at Alan Finlay's Prolog interpreter v.4 which Mr Van Dorp kindly sent me some time ago. Impressions so far: At first I thought it didn't like me, but I have found postings about it in the newsgroup file group90a.txt in the newsgroup directory in the Icon FTP site. For the first time I was able to enter material to the interpreter without it complaining of a syntax error every time - a 'Eureka' moment for me as always. There is documentation in group90a.txt for Version 2, but Version 4 is more advanced, implementing assert and retract clauses etc. I have not been able to find the test files test1.plg etc. that are mentioned in the postings. Queries should not have spaces after the prefix ':-' or ?-' e.g. :-predicate,....,predicate. I think on the whole LogIcon does not like spaces at all, but I haven't experimented much. I think files for it to 'consult' should strictly be UNIX format text files rather than MS-DOS format. The interpreter itself is in the above-mentioned archive file, as well as its predecessors, but beware of emailer mangling of the format. Regards _John Sampson_ From icon-group-sender Fri May 19 07:54:04 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA24950 for icon-group-addresses; Fri, 19 May 2000 07:53:32 -0700 (MST) Message-Id: <200005191453.HAA24950@baskerville.CS.Arizona.EDU> Date: Fri, 19 May 2000 17:26:43 +1000 (EST) From: Rohan McLeod To: icon_group Subject: Stupid newbie query re Icon compiler Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 357 When I first started to learn Icon the options for executables on both Linux and NT were: (1)run with interpreter (2)compile to C then compile the C code. Has anything much changed? eg is it possible (or will it ever be) to compile direct? thanks Rohan Melbourne,Australia From icon-group-sender Fri May 19 12:25:07 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA02361 for icon-group-addresses; Fri, 19 May 2000 12:24:33 -0700 (MST) Message-Id: <200005191924.MAA02361@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 19 May 2000 15:09:30 GMT X-Trace: vishnu.jussieu.fr 958748970 2780 132.227.81.128 (19 May 2000 15:09:30 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3699 In article <200005172324.QAA19139@baskerville.CS.Arizona.EDU>, Ian Trudel wrote: >> >5/ and finaly, speed issue only speaks by benchmarking. >> I've run some fairly large icon projects in the past. I have a fairly good >> idea about what slowed them down eventually. I even have a submitted paper >> to a conference that pits icon against maple and C++. > >Now that's interesting, is your paper online? Not yet, sorry. There are proceedings involved, and I'll have to see if there is red tape involved with Springer. Briefly put, the gist of the matter was to compare methods to generate Dyck words (well-parenthesized words). I asked a friend who is a typical user of maple to write it in a way natural to maple, which I compared to the typical icon generator: procedure dyck(n) if n = 0 then suspend "" else every i := 0 to n-1 do suspend "("||dyck(i)||")"||dyck(n-i-1) end As far as C++ goes, I exposed a simple technique to `revert' generators control, e.g, model every write(gen()) as an `application of' every(write(.)) to gen. The traditional icon implementation does have write call gen repetitively. Instead, we have gen produce results and pass them to a `continuation' of write that tells whether it needs more results. This combines nicely with the Template Method design pattern, and leads to an almost automatic translation to C++ that does not need any extra control structures to handle generators (e.g., the program flow is more or less hardcoded into templates). For Dyck words, the results looks like (more or less, generator.h left aside for brevity): #include #include "generator.h" class DyckWord3: public Function { const Function& f; const string& b; public: DyckWord3(const string& b_, const Function& f_): f(f_), b(b_) {} bool operator() (const string& e) const { return f(b+e); } }; class DyckWord2: public Generator { const string& a; int r; public: DyckWord2(const string& a_, int r_): a(a_), r(r_) {} bool iterate(const Function& consume) const; }; class DyckWord1: public Function { const Function& f; const int n; public: DyckWord1(const Function& f_, int n_): f(f_), n(n_) {} bool operator()(const string &a) const { return DyckWord2("("+a+")", n).iterate(f); } }; class DyckWord: public Generator { const int n; public: DyckWord(int n_): n(n_) {} bool iterate(const Function& consume) const { if (n == 0) return consume(""); else for (int i = 0; i < n; i++) if (!DyckWord(i).iterate(DyckWord1(consume, n-1-i))) return false; return true; } }; bool DyckWord2::iterate(const Function& consume) const { return DyckWord(r).iterate(DyckWord3(a, consume)); } Granted, this is somewhat longer than the icon version. Both the Icon and C++ version outperform Maple by a huge factor (as maple is not geared toward generators, and the traditional Dyck word generator is memory-heavy). Somewhat surprisingly, the C++ implementation is not much faster than the Icon implementation (factor of 3). This was traced down to the particular C++ string implementation not being well-suited to the job at hand. In similar cases where strings are not involved and where memory consumption can be taken out of the way (permutations, with in-place list construction), C++ outperforms icon by a factor of 10 or more, which is quite logical. The Icon compiler does not gain that much, which was to be expected as well. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Mon May 22 08:02:27 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA06633 for icon-group-addresses; Mon, 22 May 2000 08:01:21 -0700 (MST) Message-Id: <200005221501.IAA06633@baskerville.CS.Arizona.EDU> From: corre@alpha1.csd.uwm.edu (Alan D Corre) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 22 May 2000 04:21:06 GMT To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 837 In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant writes: > >At the time, I was just copying the idea of a bytecode interpreter from >the Pascal p-system. Little did I realize that Sun had yet to "invent" >bytecode! This prompts me to ask a question that has been bothering me for some time, and to which I would appreciate a reply that is not overly technical. I used Apple Pascal what seems like eons ago. It was a really nice system, invented by Ken Bowles, if I remember correctly. My question is, why is there so much fuss about Java working across different platforms? Was not the p-system a "virtual machine" which could function in just that way? -- Alan D. Corre Emeritus Professor of Hebrew Studies University of Wisconsin-Milwaukee http://www.uwm.edu/~corre/ From icon-group-sender Mon May 22 08:02:57 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA06721 for icon-group-addresses; Mon, 22 May 2000 08:02:43 -0700 (MST) Message-Id: <200005221502.IAA06721@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Date: 22 May 2000 08:03:05 GMT X-Trace: vishnu.jussieu.fr 958982585 29937 132.227.81.128 (22 May 2000 08:03:05 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 773 In article <8gacji$ob4$1@uwm.edu>, Alan D Corre wrote: >This prompts me to ask a question that has been bothering me for some time, >and to which I would appreciate a reply that is not overly technical. I used >Apple Pascal what seems like eons ago. It was a really nice system, invented >by Ken Bowles, if I remember correctly. My question is, why is there so much >fuss about Java working across different platforms? Was not the p-system a >"virtual machine" which could function in just that way? Yes, it was. As for java, the answer is simple: marketing hype. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Mon May 22 12:33:55 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA13937 for icon-group-addresses; Mon, 22 May 2000 12:33:36 -0700 (MST) Message-Id: <200005221933.MAA13937@baskerville.CS.Arizona.EDU> Date: Mon, 22 May 2000 12:15:57 -0500 From: "Charles Hethcoat" To: , Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Content-Disposition: inline X-Guinevere: 1.0.13 ; Oceaneering Int'l X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id KAA10273 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1827 Absolutely the same, except that the Java system purports to be more security-aware. Moreover, the original portable Pascal compiler by N. Wirth was done the same way, so the UCSD system wasn't the first, by a long shot, but it was pretty popular on Apples for a time. But it was basically just a copy of Wirth's original portable Pascal kit. (BTW, I still have a copy of the Pascal P-Machine spec from ETH Zurich!) The only thing UCSD Pascal lacked, and the only thing that Java lacks, is a hardware implementation. It puzzles me: all the complaints about Java's speed, or lack of it, could easily be fixed by a hardware implementation of the virtual machine--a plug-in board, say--but I never hear anyone asking for it or proposing to do it. Odd. Is anyone old enough to remember the Burroughs B-5500? The HP 9000? These were stack machines that implemented Algol semantics in hardware. Charles Hethcoat >>> Alan D Corre 00-05-21 11:21:06 PM >>> In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant writes: > >At the time, I was just copying the idea of a bytecode interpreter from >the Pascal p-system. Little did I realize that Sun had yet to "invent" >bytecode! This prompts me to ask a question that has been bothering me for some time, and to which I would appreciate a reply that is not overly technical. I used Apple Pascal what seems like eons ago. It was a really nice system, invented by Ken Bowles, if I remember correctly. My question is, why is there so much fuss about Java working across different platforms? Was not the p-system a "virtual machine" which could function in just that way? -- Alan D. Corre Emeritus Professor of Hebrew Studies University of Wisconsin-Milwaukee http://www.uwm.edu/~corre/ From icon-group-sender Mon May 22 12:34:31 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA13969 for icon-group-addresses; Mon, 22 May 2000 12:34:08 -0700 (MST) Message-Id: <200005221934.MAA13969@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Mon, 22 May 2000 12:37:45 -0500 Subject: Re: Is Anyone Working On A Unicode Version Of Icon? To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1343 >>At the time, I was just copying the idea of a bytecode interpreter from >the Pascal p-system. Little did I realize that Sun had yet to "invent" >bytecode! > This prompts me to ask a question that has been bothering me for some time, and to which I would appreciate a reply that is not overly technical. I used Apple Pascal what seems like eons ago. It was a really nice system, invented by Ken Bowles, if I remember correctly. My question is, why is there so much fuss about Java working across different platforms? Was not the p-system a "virtual machine" which could function in just that way? Yes of course, and in fact that's part of why those of us who have been in the business for so long have quite a "big deal, ho-hum" attitude about Java. Especially given Sun's repugnant attempt to blatantly use it as a blunt tool to bludgeon their biggest software competitor. Besides the fact that, given (legitimate) security concerns, I *really* do not want Webmasters to be able to run their own executable code on my machine just because I stop in to browse their Web site. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Mon May 22 12:56:57 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14412 for icon-group-addresses; Mon, 22 May 2000 12:56:46 -0700 (MST) Message-Id: <200005221956.MAA14412@baskerville.CS.Arizona.EDU> To: corre@alpha1.csd.uwm.edu (Alan D Corre) cc: icon-group@optima.CS.Arizona.EDU Subject: Re: Is Anyone Working On A Unicode Version Of Icon? User-Agent: EMH/1.10.0 SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (mips-dec-ultrix4.4) MULE/4.0 (HANANOEN) Date: Mon, 22 May 2000 20:32:06 +0100 From: "Olivier Lecarme" Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2348 >>>>> Regarding Re: Is Anyone Working On A Unicode Version Of Icon?; corre@alpha1.csd.uwm.edu (Alan D Corre) adds: ADC> In article <200005171922.MAA09657@baskerville.CS.Arizona.EDU> Cary Coutant ADC> writes: >> >> At the time, I was just copying the idea of a bytecode interpreter from >> the Pascal p-system. Little did I realize that Sun had yet to "invent" >> bytecode! ADC> This prompts me to ask a question that has been bothering me for some time, ADC> and to which I would appreciate a reply that is not overly technical. I used ADC> Apple Pascal what seems like eons ago. It was a really nice system, invented ADC> by Ken Bowles, if I remember correctly. My question is, why is there so much ADC> fuss about Java working across different platforms? Was not the p-system a ADC> "virtual machine" which could function in just that way? Pcode was not invented by Ken Bowles at all. It was only the result of a practical project by three or four undergraduate students of Niklaus Wirth in Zurich Polytechnicum. The Pcode-generating compiler and Pcode interpreter, both written in Pascal of course, were first published in two working documents of the Zurich Computer Science Department (characteristic small yellow booklets; I should still have them at work). Since it was public domain, Ken Bowles managed to make money with the idea, without ever acknowledging his debt to the Zurich team. He did not ever attempt to complete the compiler, which did not implement some features considered too complicated, like procedural parameters for example. The unimplemented features of this compiler managed to remain intact in Borland Turbo-Pascal, but that is another history... Anyway, this is simply one more example of the perpetual re-inventing of the wheel. It works very well when people no longer remember that the wheel has been in use for years. Thus, most of the fuss about Java virtual machine, portability by interpretation, bytecode and so on, is completely unjustified, since there is nothing new in this approach. The authors of the initial idea are Niklaus Wirth, his assistant Urs Amman, and the student team, whose names I can retrieve in a few days. Of course, language implementation by interpretation is much older, and comes back to the very first programming languages. -- Olivier Lecarme From icon-group-sender Tue May 23 07:39:43 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA09912 for icon-group-addresses; Tue, 23 May 2000 07:38:54 -0700 (MST) Message-Id: <200005231438.HAA09912@baskerville.CS.Arizona.EDU> Date: Tue, 23 May 2000 15:37:39 +1200 (NZST) From: "Richard A. O'Keefe" To: CHETHCOA@oss.oceaneering.com, corre@alpha1.csd.uwm.edu, icon-group@optima.CS.Arizona.EDU Subject: Re: Is Anyone Working On A Unicode Version Of Icon? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1462 Moreover, the original portable Pascal compiler by N. Wirth was done the same way, so the UCSD system wasn't the first, by a long shot, but it was pretty popular on Apples for a time. I still have a copy of UCSD Pascal running on a Mac Plus. I wonder what the status of the source code is these days? But it was basically just a copy of Wirth's original portable Pascal kit. Well, it added concurrent processes, so it wasn't JUST a copy. I'm not quite sure where BCPL fits into the chronology. The published BCPL compiler compiled to an abstract instruction set; there was an interpreter available for that. The only thing UCSD Pascal lacked, and the only thing that Java lacks, is a hardware implementation. It puzzles me: Sun designed a Java machine. I've seen a photograph of one The problem with a Java machine is that it doesn't support legacy software (well, there is a COBOL to JVM compiler, so I guess it does support legacy software). Make that "doesn't support legacy *C* code." Like it won't run Microsoft Outlook. Which is why Microsoft tried to impair the portability of Java... And the market share for hardware that doesn't support good virus hosts is fairly limited. Is anyone old enough to remember the Burroughs B-5500? Will B6700 and HP 3000 do? Generating code for the B6700 was so easy an undergraduate could do it in a couple of days. The B6700 architecture has had a fair few implementations, including one PC-sized. From icon-group-sender Tue May 23 07:40:17 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA09991 for icon-group-addresses; Tue, 23 May 2000 07:40:04 -0700 (MST) Message-Id: <200005231440.HAA09991@baskerville.CS.Arizona.EDU> Date: Tue, 23 May 2000 08:59:11 -0500 From: "Charles Hethcoat" To: Subject: Hardware for HLLs Content-Disposition: inline X-Guinevere: 1.0.13 ; Oceaneering Int'l X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id HAA09150 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 674 >>> Hugh Sasse Staff Elec Eng 00-05-23 4:19:45 AM >>> >http://www.sun.com/970722/cover/javace.html > and a better reference I have lost suggest Sun are on to this and > have a java non-virtual machine. I checked that out and it looks like you're right. Oh, well, I guess there's nothing new under the sun. > "Richard A. O'Keefe" wrote: > And the market share for hardware that doesn't support good virus hosts is fairly limited. 2 + 2 = ... Awright! Hardware virus acceleration! We're gonna get RICH!!! Charles Hethcoat P. S. I can't help but notice that we got way off the topic of the original post, so I changed it... From icon-group-sender Tue May 23 16:34:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA27759 for icon-group-addresses; Tue, 23 May 2000 16:33:28 -0700 (MST) Message-Id: <200005232333.QAA27759@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Tue, 23 May 2000 14:53:24 -0500 Subject: Hardware for HLLs To: Icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2949 >> ...and a better reference I have lost suggest Sun are on to this and > have a java non-virtual machine. > I checked that out and it looks like you're right. Oh, well, I guess there's nothing new under the sun. >> "Richard A. O'Keefe" wrote: >> And the market share for hardware that doesn't support good virus hosts is fairly limited. > 2 + 2 = ... Awright! Hardware virus acceleration! We're gonna get RICH!!! Some years ago a company called Proximity Technology developed a marvelous LSI chip to do proximity ranking of a series of [near-]matches. The idea was wonderful, although within just a few years the software version was faster when running on widely available standard PCs. The reasons you don't see more of these specialized HLL processors are simple. The market is limited; few people need the additional performance badly enough to put up with the cost and configuration hassles (need an available slot and of the right kind etc etc). Given the limited money available to support the development, you'll probably never be able to keep up in the throughput technology curve with the general-purpose, mass-market processors. Eventually (and probably SOON) your balls-out high-speed specialized custom processor will be blown away by a simple interpreter running on cheap generic iron. If you go back about 7-8 years there was a lot of press about how Sun's revolutionary SPARC RISC processor was going to put the Intel-family CISC processors out of business, and redefine the PC. It hasn't really happened that way, has it? The HP9000 at one of my consulting customers (a $50K+ box) uses their fancy-schmancy HP/PA microprocessor. (You will remember that the whole raison d'etre of RISC was that by designing a brain-damaged processor with a crippled primitive instruction set, they could turn the crank faster...) Anyhow, the HP/PA "we can turn the crank faster" microprocessors runs at... wait for it... 100MHz. (!!) Anyhow, after designing a specialized, custom-built processor (which only works for SOME of the workload you have, and probably isn't even DRAMATICALLY faster for that segment) you then have to figure out how to find the money to keep REdesigning it to compete with the constantly raised bar coming from companies like AMD and Intel (which probably have a LOT more money to play the high-stakes game than you do). So anyhow it's scarcely surprising that there aren't a lot of such specialized HLL-based processors out there. If anybody was going to do it for JAVA, it would probably be Sun... and even there, they haven't exactly been hugely successful selling even their SPARC chips. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Thu May 25 12:39:54 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA03284 for icon-group-addresses; Thu, 25 May 2000 12:38:32 -0700 (MST) Message-Id: <200005251938.MAA03284@baskerville.CS.Arizona.EDU> Date: Thu, 25 May 2000 11:15:45 -0500 From: "Charles Hethcoat" To: Subject: Re: Hardware for HLLs Content-Disposition: inline X-Guinevere: 1.0.13 ; Oceaneering Int'l X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id JAA27165 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3311 >>> 00-05-23 2:53:24 PM >>> writes: > The market is limited; few people need the additional performance badly enough > to put up with the cost and configuration hassles Video cards, sound cards, DSP chipsets, ... . Some do find it useful to speed up software by means of custom hardware, and are willing to pay for it. Of course, that by itself is no guarantee of financial success for companies supplying such hardware. As for configuration hassles, well, a cynic would say that's what generic PCs are all about. > Given the limited money available to support the development, you'll probably never > be able to keep up in the throughput technology curve with the general-purpose, > mass-market processors. Money is always limited, which is precisely why people must always ask what is the correct way to do things. I would frame the following general question: Where, disregarding historical accidents and existing market factors, is the line properly drawn between hardware and software? > Eventually (and probably SOON) your balls-out high-speed > specialized custom processor will be blown away by a simple interpreter running on > cheap generic iron. True, if it is not on the Intel learning curve. I'm sure a present day "Winvideo" display running off one of today's Intel CPUs would outrun the best video card on the market of 5 years ago. But speed isn't my main issue (read on). > If you go back about 7-8 years there was a lot of press about how Sun's revolutionary > SPARC RISC processor was going to put the Intel-family CISC processors out of > business, and redefine the PC. It hasn't really happened that way, has it? I won't comment on the RISC/CISC wars---not smart enough---but I think your point is that the chip fab technology is capital-intensive, that Intel has the most capital, and therefore nobody but Intel could succeed at it today. I somewhat forlornly agree (and would hope to be shown wrong). This is the money issue again. It's understandable why Intel chose the 4004/8008 CPU model over something like the Burroughs B5500/B6700 model in the year 197X---it wasn't possible to put a mainframe CPU on a controller chip then. Today, it is. But Intel's subsequent market success has, as you rightly point out, foreclosed all questions similar to these we are dealing with in this discussion for two decades. > (You will remember that the whole raison d'etre of RISC was that by designing a brain- > damaged processor with a crippled primitive instruction set, they could turn the crank > faster...) To me, it's not so much seeing who's faster as simplifying life by replacing multiple software layers with silicon hardware designs informed by enduring software principles, i. e. HLL hardware. Once it's in silicon, it will be on the same chip-fab curve that the current Intel processors are on (especially if Intel did our hypothetical HLL chip and could make it a market success). I do share your scepticism about the RISC concept. I was never really convinced that the RISC designs I used to see in Byte magazine articles would be intrinsically better for general purpose computing than, say, the Shannon-encoded stack machine that Tanenbaum (I believe it was) designed, _if_ both were designed as rippin' fast hardware. From icon-group-sender Thu May 25 16:36:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA12383 for icon-group-addresses; Thu, 25 May 2000 16:34:42 -0700 (MST) Message-Id: <200005252334.QAA12383@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Thu, 25 May 2000 17:07:40 -0500 Subject: Re: Hardware for HLLs; side helping of computer history To: Icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 9488 >>>> 00-05-23 2:53:24 PM >>> writes: > The market is limited; few people need the additional performance badly enough to put up with the cost and configuration hassles > Video cards, sound cards, DSP chipsets, ... . Some do find it useful to speed up software by means of custom hardware, and are willing to pay for it. True enough, for THOSE applications (where, in fact, you pretty much need the hardware anyhow whether it has its own CPU capability or not). In the case of Java, it's harder to justify *every* user paying for a hardware solution when the *easier* and better solution is simple... just say NO to Java, and write the software in a language that's inherently that much more efficient (or more) to begin with. :-) > Of course, that by itself is no guarantee of financial success for companies supplying such hardware. Absolutely. I think it's a safe guess that the company developing such a specialized Java hardware processor would fail (and probably after investing a LOT of money in development). Even Sun, which apparently HAS such a processor developed, isn't exactly racing to market with it. > As for configuration hassles, well, a cynic would say that's what generic PCs are all about. I'm not THAT cynical. It's more an issue of "what kind of slot would you plug the board into?" and "do you HAVE a spare slot of that type?" etc etc. And of course, these "legacy-free PCs" and other sealed-box "PCs" that some dumb companies keep trying to promote would simply not allow adding such a board, anyhow. >> Given the limited money available to support the development, you'll probably never be able to keep up in the throughput technology curve with the general-purpose, mass-market processors. > Money is always limited, which is precisely why people must always ask what is the correct way to do things. I would frame the following general question: Where, disregarding historical accidents and existing market factors, is the line properly drawn between hardware and software? Well, I'd give an example which I think clearly errs in terms of putting too much in software: these stupid "Winmodems" where they replace a $2.00 dedicated processor on the modem card with 30-50% of a $200 processor... >> Eventually (and probably SOON) your balls-out high-speed > specialized custom processor will be blown away by a simple interpreter running on cheap generic iron. > True, if it is not on the Intel learning curve. Or tha AMD learning curve, or the Cyrix learning curve, or the IBM learning curve, or one of the other such curves. And it's not even an issue of "learning", it's an issue of how much money you have to keep developing more and more complex and sophisticated versions to keep up. If the market for a Java processor is limited to begin with, I think there's not going to be enough money there to stay competitive (if there is even enough money to get a competitive product to market to begin with). >> If you go back about 7-8 years there was a lot of press about how Sun's revolutionary > SPARC RISC processor was going to put the Intel-family CISC processors out of > business, and redefine the PC. It hasn't really happened that way, has it? > I won't comment on the RISC/CISC wars---not smart enough---but I think your point is that the chip fab technology is capital-intensive, that Intel has the most capital, and therefore nobody but Intel could succeed at it today. Certainly there is an *enormous* installed base of software and hardware, which is not going to disappear overnight. Like in the case of the mainframe wars of the 60's and 70's, even companies like Amdahl and Memorex developing "compatible" mainframes wasn't enough to dislodge IBM... it took a major change of paradigm (the PC combined with the LAN that allowed clustering a nearly arbitrarily large bunch of them around one or more shared databases) that simply made the old-style mainframe largely irrelevant... to pretty much consign those monsters to history. I think that Intel (who _ought_ to understand that lesson well) is making a *major* strategic mistake in the incompatible architecture of their next-generation processors... one which is likely to leave AMD with a much larger piece of the pie than they presently have. > I somewhat forlornly agree (and would hope to be shown wrong). This is the money issue again. I think you'll see a lot of advance by AMD into Intel's current territory. This will be the biggest goof by Intel since their braindead CPU-serial-number thing they built into the Pentium III. > It's understandable why Intel chose the 4004/8008 CPU model over something like the Burroughs B5500/B6700 model in the year 197X---it wasn't possible to put a mainframe CPU on a controller chip then. There's actually an interesting story there. Turns out that Intel designed the 4004, but a company called Computer Terminal Corporation in San Antonio (later Datapoint Corporation) developed the architecture and instruction set for the 8008... Intel was one of several companies which was approached to build it for them, and in fact both TI and Intel made (sorta) working prototypes. Intel did it very reluctantly, because they were convinced that there WAS no market for a general-purpose microcomputer-on-a-chip. The only reason they agreed to build the part at all was because Intel back then considered themselves a MEMORY company, and Computer Terminal Corporation was at the time the world's largest buyer of MOS memory. So Intel was hoping to cement the loyalty (and memory business) of Datapoint by building this "foolish" CPU chip for them. As it turned out, the TI chip was electrically noisy enough that it barely worked at all, and by the time Intel's was finally ready Datapoint had already advanced enough on their own temporary design that the LSI part wasn't really all that attractive. Datapoint signed away to Intel the rights to the design basically in exchange for being relieved of the obligation to buy it from them, and Intel (which had meanwhile leaked rumors about the 8008 project to other customers, and found that there indeed MIGHT be a market for a microcomputer-on-a-chip after all) went ahead to sell it for their own account. The rest, as they say, is history. :-) Datapoint, of course, is also the company that in 1976 developed the first commercially successful local area network (hardware and software delivered to first customer in Sept 1977 and announced in Dec 1977) and together with the cheap/powerful single-chip microprocessor that Datapoint also had invented, these two products (and their successors) later merged to create the world of computing that we have today. >> (You will remember that the whole raison d'etre of RISC was that by designing a brain-damaged processor with a crippled primitive instruction set, they could turn the crank faster...) > To me, it's not so much seeing who's faster as simplifying life by replacing multiple software layers with silicon hardware designs informed by enduring software principles, i. e. HLL hardware. I think it's basically a strategic error to presume that "the solution" is to try to make one single processor go infinitely fast. I think a much better solution (and this is part of what Datapoint's (and my as primary developer of the software for it) LAN concept was about) is to try to eliminate the horsepower race BY DESIGN. To produce simple, to-be-cheap modules and to arrange things to maximize the potential fanout... so you can easily cluster as much processing horsepower units around a given database as its load requires (regardless of how many individual processors that means). Meanwhile, I think it's much easier (and faster and cheaper to develop) to manage complexity in software than in hardware. > Once it's in silicon, it will be on the same chip-fab curve that the current Intel processors are on (especially if Intel did our hypothetical HLL chip and could make it a market success). It's not just fab technology, though. If it was, we'd still be making hugely-fast 8008's. To get the speed up, they've developed *hugely* more complicated and expensive processor designs, at enormous cost (although clearly the market has repaid that investment many times over). > I do share your scepticism about the RISC concept. I was never really convinced that the RISC designs I used to see in Byte magazine articles would be intrinsically better for general purpose computing than, say, the Shannon-encoded stack machine that Tanenbaum (I believe it was) designed, _if_ both were designed as rippin' fast hardware. Absolutely. If you want performance, it seems pretty obvious to ME that putting the subroutine or macro to execute a complex series of microinstructions RIGHT ON THE DIE makes a lot more sense than to force the processor to fetch the (maybe dozens of) RISC instructions from main memory to accomplish the same thing. And I think that a good part of what eventually put Byte Magazine out of the business was their having made SO MANY bad calls through the 80's and early 90's. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Fri May 26 08:34:04 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02191 for icon-group-addresses; Fri, 26 May 2000 08:33:22 -0700 (MST) Message-Id: <200005261533.IAA02191@baskerville.CS.Arizona.EDU> From: "F.G. van DORP" X-Newsgroups: comp.lang.icon Subject: CODE() and @/2 X-Newsreader: Forte Agent 1.7/32.534 Date: Fri, 26 May 2000 09:38:12 GMT X-Complaints-To: abuse@chello.nl X-Trace: flipper 959333892 212.187.67.243 (Fri, 26 May 2000 11:38:12 MET DST) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 866 Although ICON has PROC() and VARIABLE(), there doesn't seem to be a built-in to translate & execute string data as a (more substantial) piece of code in runtime, hence SNOBOL's CODE(). Is this because of certain implementation features ? Can somebody please explain the infix @ operator ? The closest I can get is something like: @'s first argument gets pushed onto its second argument's stack before the latter is activated (and at this point my mind goes blank... OK, so the infix is just a prefix @ with &NULL as the first argument, which doesn't help me a lot either). Its purpose is apparently to have co-expressions communicate between themselves (thus enabling them to gang up against the programmer ?) Does ICON provide for local auxiliary variables other than within the body of a named procedure ? Thanks a bunch, Bob. From icon-group-sender Fri May 26 08:35:41 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02292 for icon-group-addresses; Fri, 26 May 2000 08:35:31 -0700 (MST) Message-Id: <200005261535.IAA02292@baskerville.CS.Arizona.EDU> From: Steve Wampler X-Newsgroups: comp.lang.icon Subject: Re: CODE() and @/2 Date: Fri, 26 May 2000 07:54:20 -0700 X-Trace: noao.edu 959352862 96002 140.252.38.6 (26 May 2000 14:54:22 GMT) X-Complaints-To: abuse@noao.edu X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3044 "F.G. van DORP" wrote: > ... > Can somebody please explain the infix @ operator ? > The closest I can get is something like: @'s first argument gets pushed > onto its second argument's stack before the latter is activated (and > at this point my mind goes blank... OK, so the infix is just a prefix > @ with &NULL as the first argument, which doesn't help me a lot either). > Its purpose is apparently to have co-expressions communicate between > themselves (thus enabling them to gang up against the programmer ?) Think of co-expressions a threads that don't execute simultaneously. Instead, co-expressions cooperate by explicitly passing control between them using the @ operator as a "transfer point". Logically, the CPU resource is being passed among the co-expressions (remember that Icon's execution starts in a co-expression, referenced by &main). Now, think of the @ operator from the point of view of the co-expression that is invoking it - the behavior of the @ is very much like that co-expression making a function call - execution of the co-expression (call it "A") is suspended until execution "returns" from the @ - perhaps by some other co-expression (call it "B") invoking the first via an @ [think about that for a moment, it's probably the confusing part!]. If B uses the infix @ - as in (say) "foo" @ A, then A will see its @ operator as "returning" the value "foo". So, each co-expression sees @ as an operator that "invokes" another co-expression to produce a result. The result can be produced in one of two ways: (1) Since a co-expression is an expression, and since all expressions in Icon produce results, there is an implicit transfer of the result of that expression back to the invoking co-expression. This is how most people use co-expressions, as in: nextLabel := create "L" || seq() to produce a unique label whenever activated. (Note that this can also be done using a procedure, as in: procedure newLabel() static suffix initial suffix := 0 return "L" || (suffix +:= 1) end but some people find the co-expression form simpler. Also note that procedure newLabel2() return "L" || seq() end and procedure newLabel3() suspend "L" || seq() end do *not* perform the same function.) (2) A co-expression may explicitly return a value to a waiting co-expression using the binary @ operator. The explicit transfer of control used here more closely matches the role of coroutines found in some other languages, and is likely to be used only in situations where coroutines would be used in those other languages. However, useful situations for applying coroutines are few and far between and almost always very complex situations. It is difficult to find simple examples where using coroutines is cleaner than alternatives. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Mon May 29 08:47:25 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA28734 for icon-group-addresses; Mon, 29 May 2000 08:45:42 -0700 (MST) Message-Id: <200005291545.IAA28734@baskerville.CS.Arizona.EDU> X-Priority: 3 (Normal) Date: Mon, 29 May 2000 14:27:56 +0200 (CEST) From: Guido Milanese To: icon-group@optima.CS.Arizona.EDU Subject: Lists: sort on more than one field? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 737 I am currently working on a small databaseof library data. Data is the output of a database program and is in comma-delimited format, therefore easily accesible as lists or records. I would like to sort data not only by one field (I use sortf for that) but one more than one field: i.e. sort on field_1 and osrt all data with the same value for field_1 by field_4, for example. Is it possible? I did not find anything in the Icon library for that. May I ask for advice? Thank you all! gm -------------------------------------------w E-Mail: Guido Milanese Homepage: http://fly.to/arsantiqua 29-May-00 - XFMail on Linux SuSE *************NON NOBIS DOMINE************* ------------------------------------------- From icon-group-sender Mon May 29 11:57:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA02046 for icon-group-addresses; Mon, 29 May 2000 11:57:10 -0700 (MST) Message-Id: <200005291857.LAA02046@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Mon, 29 May 2000 11:39:43 -0500 Subject: Lists: sort on more than one field? To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 946 > I am currently working on a small databaseof library data. Data is the output of a database program and is in comma-delimited format, therefore easily accesible as lists or records. I would like to sort data not only by one field (I use sortf for that) but one more than one field: i.e. sort on field_1 and osrt all data with the same value for field_1 by field_4, for example. Is it possible? I did not find anything in the Icon library for that. May I ask for advice? The answer is so simple as to be trivial.... simply build an additional (single) field (perhaps temporarily) which contains all the fields you wish to sort on, in the order of precedence (most important first). :-) Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Tue May 30 07:38:07 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA23286 for icon-group-addresses; Tue, 30 May 2000 07:37:36 -0700 (MST) Message-Id: <200005301437.HAA23286@baskerville.CS.Arizona.EDU> Date: Tue, 30 May 2000 20:17:59 +1000 From: Rohan McLeod X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: silly question about iconc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 519 This will no doubt demonstrate my beginners status but here is my problem: there is mention of an Icon compiler; iconc eg "Icon Programming Language Handbook" p141 "On some systems an Icon compiler is available." Now in a previous query I gathered that this still produces C , which has then to be put through a C compiler...I guess I can live with that;but what systems is an Icon compiler available for and where (URL?) can I find binaries ? I have looked all over http://www.cs.arizona.edu/icon/ without avail! From icon-group-sender Tue May 30 12:07:40 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA19353 for icon-group-addresses; Tue, 30 May 2000 12:06:08 -0700 (MST) Message-Id: <200005301906.MAA19353@baskerville.CS.Arizona.EDU> From: "F.G. van DORP" X-Newsgroups: comp.lang.icon Subject: Re: CODE() and @/2 X-Newsreader: Forte Agent 1.7/32.534 Date: Tue, 30 May 2000 18:55:33 GMT X-Complaints-To: abuse@chello.nl X-Trace: flipper 959712933 212.187.67.243 (Tue, 30 May 2000 20:55:33 MET DST) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1209 On 26 May 2000 11:38:34 -0400, Steve Wampler wrote: >"F.G. van DORP" wrote: >> >... >> Can somebody please explain the infix @ operator ? >> The closest I can get is something like: @'s first argument gets pushed >> onto its second argument's stack before the latter is activated.... >>... > >So, each co-expression sees @ as an operator that "invokes" another >co-expression >to produce a result. The result can be produced in one of two ways: > >(1) Since a co-expression is an expression, and since all expressions in Icon > produce results, there is an implicit transfer of the result of that > expression back to the invoking co-expression. This is how most people > use co-expressions, as in: > > nextLabel := create "L" || seq() > Thanks for replying. I tried nextLabel := create "L" || (1 to 10) || ("foo" @ &source) write(@nextlabel) .... and to my very surprise it did act as a regular RETURN (no ASSEMBLER jargon necessary after all), writing L1foo .... Unfortunately results are quite unpredictable: either some aren't written at all, or Win32 preempts further execution with an "illegal operation" error. > From icon-group-sender Tue May 30 17:06:44 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28345 for icon-group-addresses; Tue, 30 May 2000 17:06:32 -0700 (MST) Message-Id: <200005310006.RAA28345@baskerville.CS.Arizona.EDU> Date: Tue, 30 May 2000 13:40:37 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Re: CODE() and @/2 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1611 "F.G. van DORP" wrote: > I tried > > nextLabel := create "L" || (1 to 10) || ("foo" @ &source) What did you intend the above to do? I'm confused as to why you have the ("foo" @ &source) there. If all you want are labels Lxfoo, where x is replaced by 1 to 10, you should use nextLabel := create "L" || (1 to 10) || "foo" > write(@nextlabel) This must have been write(@nextLabel), right? > .... > > and to my very surprise it did act as a regular RETURN (no > ASSEMBLER jargon necessary after all), writing > > L1foo > .... I don't see how the co-expression you've given would produce the above, are you sure that isn't the output from some other try? In fact, I would expect to see "foo" printed by itself first, followed by a "string expected, offending value: &null" error if you activate nextLabel a second time without passing a value to it... Try the following sample program: procedure main() nextLabel := create "L" || (1 to 10) || "foo" write("Label 1 is ", @nextLabel) write("Label 2 is ", @nextLabel) write("Label 3 is ", @nextLabel) write("Label 4 is ", @nextLabel) write("Label 5 is ", @nextLabel) every write("Label ",6 to 10," is ",@nextLabel) end You should see the output: Label 1 is L1foo Label 2 is L2foo Label 3 is L3foo Label 4 is L4foo Label 5 is L5foo Label 6 is L6foo Label 7 is L7foo Label 8 is L8foo Label 9 is L9foo Label 10 is L10foo -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Tue May 30 17:07:50 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28385 for icon-group-addresses; Tue, 30 May 2000 17:07:41 -0700 (MST) Message-Id: <200005310007.RAA28385@baskerville.CS.Arizona.EDU> From: Bob Ardler To: Icon-group Date: Tue, 30 May 2000 21:42:49 +0100 Subject: coexpression history User-Agent: Pluto/2.02b (RISC-OS/3.60) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 161 Did the word 'coexpression' or the associated idea originate with icon? Or is it a high school computer science thing? -- Bob Ardler, ardler@argonet.co.uk From icon-group-sender Tue May 30 17:08:16 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA28470 for icon-group-addresses; Tue, 30 May 2000 17:08:06 -0700 (MST) Message-Id: <200005310008.RAA28470@baskerville.CS.Arizona.EDU> Date: Tue, 30 May 2000 15:43:45 -0700 (MST) From: Gregg Townsend To: icon-group@optima.CS.Arizona.EDU, rohan@micom.asn.au Subject: Re: silly question about iconc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 518 what systems is an Icon compiler available for and where (URL?) can I find binaries ? Because of limited resources, we no longer support the compiler or produce binaries for it. Most people found that using the compiler wasn't worth the extra compliation time or the hassles involved. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Wed May 31 08:37:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17431 for icon-group-addresses; Wed, 31 May 2000 08:37:07 -0700 (MST) Message-Id: <200005311537.IAA17431@baskerville.CS.Arizona.EDU> From: "Jim Mehl" To: "icon-group" Subject: Re: coexpression history Date: Tue, 30 May 2000 19:45:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 386 I don't think so. I have this vague remembrance that coexpression/coroutine was actually proposed many years ago in the context of a COBOL compiler of all things. Maybe someone with a better sense of computer science history can help me out here. Jim Mehl > Did the word 'coexpression' or the associated idea originate with icon? > Or is it a high school computer science thing? From icon-group-sender Wed May 31 08:38:06 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17464 for icon-group-addresses; Wed, 31 May 2000 08:37:55 -0700 (MST) Message-Id: <200005311537.IAA17464@baskerville.CS.Arizona.EDU> From: "Jim Mehl" To: "icon-group" Subject: Re: coexpression history Date: Tue, 30 May 2000 20:15:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 369 OK, I think I found it. The reference is M. E. Conway, "Design of a separable transition-diagram compiler", CACM, Vol. 6, No. 7, July 1963, pp 396-408. If I'm wrong, I'm sure there are enough scholars on this list to tell me so. Jim Mehl > Did the word 'coexpression' or the associated idea originate with icon? > Or is it a high school computer science thing? From icon-group-sender Wed May 31 08:38:42 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA17496 for icon-group-addresses; Wed, 31 May 2000 08:38:33 -0700 (MST) Message-Id: <200005311538.IAA17496@baskerville.CS.Arizona.EDU> Date: Wed, 31 May 2000 06:49:35 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Re: coexpression history Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 525 Bob Ardler wrote: > > Did the word 'coexpression' or the associated idea originate with icon? > Or is it a high school computer science thing? The word originated with Icon. The associated idea grew out of talks between Ralph and me but has roots in several places, with the two most prominent ones being the general concept of coroutines (several languages) and a feature found in the pattern matching language that is embedded in SNOBOL4. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Wed May 31 12:45:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA25222 for icon-group-addresses; Wed, 31 May 2000 12:43:57 -0700 (MST) Message-Id: <200005311943.MAA25222@baskerville.CS.Arizona.EDU> Date: Wed, 31 May 2000 08:47:44 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Re: coexpression history Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 886 Jim Mehl wrote: > > OK, I think I found it. The reference is M. E. Conway, "Design of a > separable transition-diagram compiler", CACM, Vol. 6, No. 7, > July 1963, pp 396-408. If I'm wrong, I'm sure there are enough > scholars on this list to tell me so. > > Jim Mehl > > > Did the word 'coexpression' or the associated idea originate with icon? > > Or is it a high school computer science thing? Yes, that's the original reference (as far as I can remember) for the coroutine side of co-expressions. Coroutines were then implemented in a number of languages. The one that comes to mind as having the most influence here is Simula. Note that coroutines were/are considerably more heavyweight than coexpressions as they have always been implemented as full procedures, not just single expressions. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Thu Jun 1 13:40:20 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA08649 for icon-group-addresses; Thu, 1 Jun 2000 13:38:26 -0700 (MST) Message-Id: <200006012038.NAA08649@baskerville.CS.Arizona.EDU> From: Bob Ardler To: icon-group Date: Thu, 01 Jun 2000 17:36:39 +0100 Subject: Re: coexpression history User-Agent: Pluto/2.02b (RISC-OS/3.60) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 981 Steve Wampler wrote: > Jim Mehl wrote: > > OK, I think I found it. The reference is M. E. Conway, "Design of a > > separable transition-diagram compiler", CACM, Vol. 6, No. 7, July > > 1963, pp 396-408. If I'm wrong, I'm sure there are enough scholars on > > this list to tell me so. > Yes, that's the original reference (as far as I can remember) for the > coroutine side of co-expressions. Coroutines were then implemented in a > number of languages. The one that comes to mind as having the most > influence here is Simula. Note that coroutines were/are considerably > more heavyweight than coexpressions as they have always been > implemented as full procedures, not just single expressions. Ah, coroutines, so that's where to look. Knuth I elaborates the history a bit on p.226, starting with Conway, mentioning earlier ('primitive') & later stuff. He also explains coroutines thoroughly, to those who speak MIX. Thanks to you both. -- Bob Ardler, ardler@argonet.co.uk From icon-group-sender Thu Jun 1 13:46:33 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA08842 for icon-group-addresses; Thu, 1 Jun 2000 13:46:26 -0700 (MST) Message-Id: <200006012046.NAA08842@baskerville.CS.Arizona.EDU> From: "F.G. van DORP" X-Newsgroups: comp.lang.icon Subject: Re: CODE() and @/2 X-Newsreader: Forte Agent 1.7/32.534 Date: Thu, 01 Jun 2000 18:56:01 GMT X-Complaints-To: abuse@chello.nl X-Trace: flipper 959885761 212.187.67.243 (Thu, 01 Jun 2000 20:56:01 MET DST) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1324 On 30 May 2000 20:09:35 -0400, Steve Wampler wrote: >"F.G. van DORP" wrote: > >> I tried >> >> nextLabel := create "L" || (1 to 10) || ("foo" @ &source) > >What did you intend the above to do? ....to find out if binary @ behaves like a regular RETURN > > nextLabel := create "L" || (1 to 10) || "foo" > >> write(@nextlabel) > >This must have been write(@nextLabel), right? Yes. I can't copy&paste because ICON is on another machine, which in fact is entirely "dedicated" to ICON because of all those illegal co-ex operations ...just kidding. Under my ICON (Windows Icon v.9.3.1, Wi v.1.01) above example prints "L1foo" immediately followed by an illegal op. error. I f you change it to, let's say procedure main nextLabel := create (("L" || (1 to 10) || "foo") @ &source) write("1 ",@nextLabel) write("2 ",@nextLabel) write("3 ",@nextLabel) write("4 ",@nextLabel) write("5 ",@nextLabel) end it prints "1 L1foo" "2" "3 L2foo" "4" illegal op error This behavior doesn't change if you replace ("L" || (1 to 10) || "foo") with any other generator, nor &source with &main in this particular example. From icon-group-sender Thu Jun 1 16:56:55 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA15837 for icon-group-addresses; Thu, 1 Jun 2000 16:56:35 -0700 (MST) Message-Id: <200006012356.QAA15837@baskerville.CS.Arizona.EDU> Date: Thu, 01 Jun 2000 14:10:08 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group Subject: Re: CODE() and @/2 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2115 "F.G. van DORP" wrote: > > On 30 May 2000 20:09:35 -0400, Steve Wampler wrote: > > >"F.G. van DORP" wrote: > > > >> I tried > >> > >> nextLabel := create "L" || (1 to 10) || ("foo" @ &source) > > > >What did you intend the above to do? > ....to find out if binary @ behaves like a regular RETURN Ah, it "sortof" does, but when you reactivate the co-expression, you're going to resume execution as if you've returned from "foo" @ &source (with the &null value since the activation "@nextLabel" is unary.) This &null value can't be concatentated to the string you're building. > > > > > nextLabel := create "L" || (1 to 10) || "foo" > > ... > > Under my ICON (Windows Icon v.9.3.1, Wi v.1.01) above example > prints "L1foo" immediately followed by an illegal op. error. Hmmm, can you email me the full program where this is happening? I'd like to take a closer look... > I f you change it to, let's say > procedure main > nextLabel := create (("L" || (1 to 10) || "foo") @ &source) > write("1 ",@nextLabel) > write("2 ",@nextLabel) > write("3 ",@nextLabel) > write("4 ",@nextLabel) > write("5 ",@nextLabel) > end > it prints > > "1 L1foo" > "2" > "3 L2foo" > "4" > illegal op error > > This behavior doesn't change if you replace ("L" || (1 to 10) || "foo") > with any other generator, nor &source with &main in this particular example. Well, that's nearly correct (except for the illegal op error at the end...): I get: 1 L1foo 2 3 L2foo 4 5 L3foo You shouldn't have the @source there, it's not doing what you want, because you're "returning" into the co-expression... However, it does look like there is a bug in 9.3.1 for Windows. Please email me the exact program (I can tell you had to type the above one in by hand...)! I don't see this problem under either 9.3 or 9.3.2 with either Linux or Solaris. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Thu Jun 1 16:58:42 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA15892 for icon-group-addresses; Thu, 1 Jun 2000 16:58:34 -0700 (MST) Message-Id: <200006012358.QAA15892@baskerville.CS.Arizona.EDU> Date: Thu, 1 Jun 2000 16:15:16 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Icon Newsletter #60 published Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 512 The sixtieth Icon Newsletter is now available on the web at: http://www.cs.arizona.edu/icon/inl/inl60/inl60.htm This is the final edition of the newsletter. In the future, we plan to utilize other avenues of communication, including the Icon Analyst, our website, and this mailing list. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Fri Jun 2 07:56:46 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02816 for icon-group-addresses; Fri, 2 Jun 2000 07:56:12 -0700 (MST) Message-Id: <200006021456.HAA02816@baskerville.CS.Arizona.EDU> From: "Bernard Diaz (Diz)" Subject: Co-expression history ... To: icon-group@optima.CS.Arizona.EDU Date: Fri, 2 Jun 2000 10:39:53 +0100 (BST) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 850 Hi, I believe Conway's paper is also used as introduction in describing Java threads ... is there more similarity than the "separate processing" which treads and co-routines imply ? Regards - Diz +===========================================+==================================+ | e-mail: b.m.diaz@csc.liv.ac.uk | Dr Bernard M. Diaz | | | Department of Computer Science | | Tel: 0151 794 3696 (direct office line) | The University of Liverpool | | 0151 794 6923 (Departmental office | Chadwick Building, Peach Street | | Fax: +44 151 794 3715 (International no) | Liverpool, ENGLAND. | | Tlx: 627095 UniLpl G | L69 7ZF | +===========================================+==================================+ From icon-group-sender Fri Jun 2 14:07:34 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA13288 for icon-group-addresses; Fri, 2 Jun 2000 14:04:31 -0700 (MST) Message-Id: <200006022104.OAA13288@baskerville.CS.Arizona.EDU> Date: Fri, 02 Jun 2000 10:56:45 -0500 From: "Charles Hethcoat" To: Subject: Coexpressions, etc. Content-Disposition: inline X-Guinevere: 1.0.13 ; Oceaneering Int'l X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id IAA04192 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 509 Couldn't some of the more esoteric aspects of Icon (suspend/resume, coexpressions) be expressed as the state changes of an SECD machine, or an extension to it, or something similar? For an example of what I mean, consult (for example) Burge's book on functional programming, especially the discussions of extensions to the lambda calculus to handle a variety of messy real-life programming constructs in Algol-like languages. Charles Hethcoat Senior Engineer Oceaneering Space Systems Houston, Texas USA From icon-group-sender Fri Jun 2 14:09:57 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA13423 for icon-group-addresses; Fri, 2 Jun 2000 14:08:16 -0700 (MST) Message-Id: <200006022108.OAA13423@baskerville.CS.Arizona.EDU> From: "Charles Evans" X-Newsgroups: comp.lang.icon Subject: Re: silly question about iconc Date: Fri, 2 Jun 2000 17:46:20 -0400 X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Trace: 2 Jun 2000 16:50:25 -0400, bris-c-208-27-20-254.intermediatn.net X-Original-NNTP-Posting-Host: 206.107.125.34 To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 359 Rohan McLeod wrote in message <200005301437.HAA23286@baskerville.CS.Arizona.EDU>... >there is mention of an Icon compiler; iconc... >"On some systems an Icon compiler is available."... >which has then to be put through a C compiler...I guess I can live >with that;but what systems is an Icon compiler available for and ... What C compiler do you have? From icon-group-sender Mon Jun 12 08:47:19 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19743 for icon-group-addresses; Mon, 12 Jun 2000 08:45:53 -0700 (MST) Message-Id: <200006121545.IAA19743@baskerville.CS.Arizona.EDU> From: "Frank J. Lhota" X-Newsgroups: comp.lang.icon Subject: User defined operators for Icon X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: Tue, 6 Jun 2000 10:39:33 -0000 X-Trace: client 960302410 38.163.203.81 (Tue, 06 Jun 2000 10:40:10 EDT) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1042 In the thread on a Unicode version of Icon, a topic came up that deserves more investigation. Currently, an Icon programmer can create new types in Icon using a record declaration, e.g. record complex( x, y ) The programmer can then write new procedures that work with the new type. This ability to create new types is quite useful, but extending the types in Icon is not as convenient as it could be. It is hard to integrate the new type with the others due to the following reasons: 1. You cannot (re)define the primitive operators, such as "*", "++", or "<", for a record type; 2. You cannot define implicit /explicit type conversions between a record type and the existing types; and 3. You cannot define the behavior of functions such as image and write for the new record type. Languages such as C++ and Ada permit the programmer to define the behavior of operators and predefined functions for user defined types. Would it be desirable to add such a capacity to Icon? If so, what would this facility look like? From icon-group-sender Mon Jun 12 08:47:45 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19788 for icon-group-addresses; Mon, 12 Jun 2000 08:47:29 -0700 (MST) Message-Id: <200006121547.IAA19788@baskerville.CS.Arizona.EDU> From: Steve Wampler X-Newsgroups: comp.lang.icon Subject: Re: User defined operators for Icon Date: Tue, 06 Jun 2000 08:36:26 -0700 X-Trace: noao.edu 960305789 18654 140.252.38.6 (6 Jun 2000 15:36:29 GMT) X-Complaints-To: abuse@noao.edu X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2383 "Frank J. Lhota" wrote: > > Languages such as C++ and Ada permit the programmer to define the behavior > of operators and predefined functions for user defined types. Would it be > desirable to add such a capacity to Icon? If so, what would this facility > look like? Well, I have an opinion, though unicon is probably the place to pursue this, as I don't see any major enhancements being made to Icon right now. Perhaps whatever works in unicon could be backed into Icon later. There are several parts (others probably have better ways to do this): (1) Have keywords for every function (as apposed to procedures) that always get you the "original" definition. This would be useful now as it would allow access to the original functions even when procedure definitions attach new meanings to the names. There may be a problem where existing keywords match existing function names - that would need to be resolved. (2) Have keywords for every operand (e.g. &+, &:=, etc.) which would act in the same way that string invocation of operators does now, but always reference the original definitions for the operators. (3) add a way to assign new definitions to operators, perhaps with syntax: operator "+"(a,b) ... end where the number of parameters determines which operation is being redefined [could even generate compile-time error if no such operation exists]. So, adding complex numbers could be (well, you could do better than this, but it's a start): operator +(a,b) if (type(a) == "complex") & (type(b) == "complex") then { return complex(a.x + b.x, a.y + b.y) # or: return complex( &+(a.x, b.x), &+(a.y,b.y)) } return &+(a,b) end Or course, unicon, with its inheritance, may be able to provide considerably more flexibility, since the above scheme only allows one level of redefinition... Why do I like this?: (a) most of the mechanisms for implementing this are already in place. (b) there are minimal syntactic changes to the language (even less if you go with using the reserved work "procedure" instead of adding the reserved work "operator"). (c) with proper implementation, there should be little, if any, performance penalty involved. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Mon Jun 12 08:48:29 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19816 for icon-group-addresses; Mon, 12 Jun 2000 08:47:55 -0700 (MST) Message-Id: <200006121547.IAA19816@baskerville.CS.Arizona.EDU> From: espie@liafa.jussieu.fr (Marc Espie) X-Newsgroups: comp.lang.icon Subject: Re: User defined operators for Icon Date: 6 Jun 2000 17:04:00 GMT X-Trace: vishnu.jussieu.fr 960311040 3784 132.227.81.128 (6 Jun 2000 17:04:00 GMT) X-Complaints-To: Newsmaster@jussieu.fr. X-Newsreader: trn 4.0-test70 (17 January 1999) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 882 In article , Frank J. Lhota wrote: >1. You cannot (re)define the primitive operators, such as "*", "++", or >"<", for a record type; >2. You cannot define implicit /explicit type conversions between a record >type and the existing types; and >3. You cannot define the behavior of functions such as image and write >for the new record type. >Languages such as C++ and Ada permit the programmer to define the behavior >of operators and predefined functions for user defined types. Would it be >desirable to add such a capacity to Icon? If so, what would this facility >look like? idol, or an extension of idol, most certainly. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Mon Jun 12 08:49:16 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19862 for icon-group-addresses; Mon, 12 Jun 2000 08:48:49 -0700 (MST) Message-Id: <200006121548.IAA19862@baskerville.CS.Arizona.EDU> Date: Wed, 07 Jun 2000 13:11:59 +1000 From: rebeccal@library.lib.rmit.edu.au X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: cross.icn X-Trace: 7 Jun 2000 13:11:19 +1000, carltonrebeccal.lib.rmit.edu.au To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 166 Hello Why is the program waiting for more input ? I tried using 2 different versions (ms-dos and ms-windows) but everytime i run cross, the result is the same. TIA From icon-group-sender Mon Jun 12 08:50:27 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19978 for icon-group-addresses; Mon, 12 Jun 2000 08:50:11 -0700 (MST) Message-Id: <200006121550.IAA19978@baskerville.CS.Arizona.EDU> Date: Sat, 10 Jun 2000 11:38:46 -0500 From: Bob Hamilton X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: Icon; missing functions Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 799 --------------98F4815ED066F13756E60A9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I downloaded and installed Icon for Windows. Several of the functions are missing: e.g. trunc, ceil, floor and many others. Are these functions in some other FTP site? TIA, bob hamilton mail@bobh.to --------------98F4815ED066F13756E60A9F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I downloaded and installed Icon for Windows.  Several of the functions are missing:
e.g. trunc, ceil, floor and many others.  Are these functions in some other FTP site?

TIA,

bob hamilton
mail@bobh.to
  --------------98F4815ED066F13756E60A9F-- From icon-group-sender Tue Jun 13 07:47:06 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02504 for icon-group-addresses; Tue, 13 Jun 2000 07:46:28 -0700 (MST) Message-Id: <200006131446.HAA02504@baskerville.CS.Arizona.EDU> To: "Frank J. Lhota" Cc: icon-group@optima.CS.Arizona.EDU Subject: Re: User defined operators for Icon Date: Mon, 12 Jun 2000 17:30:38 -0700 From: Clinton L Jeffery Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1525 The discussion of extending Icon with new types is very interesting. I have a couple additions to the ideas people have contributed so far: 1. You can define the behavior of functions such as image() and write() for new types, by providing procedures with those names. It is awkward to make this work when independently written types (say, in procedure libraries) need to be used together; they can't both supply a definition of image(), though you can devise passable workarounds for this. 2. You can always get at the original definitions of overloaded functions, using the proc() function. 3. You can devise explicit type conversion functions between record types and existing types, you just can't do implicit ones. Object oriented programming is all about creating a strong facility for writing user-defined types. I can't say whether operator overloading or implicit type conversions are appropriate or desirable for Icon, but Unicon's object-oriented facilities (the successor and replacement for Idol) would benefit directly from Frank's suggestions. There are some controversial issues (read this as: "problems") involving operator overloading and type conversions as found in C++. I will probably think about them carefully, and discuss them on the Unicon mailing list, before I go and implement them for Unicon. Besides, I have to finish implementing packages and get the UNLV release of Unicon for UNIX and Windows out the door, before I think about any other features. :-) Clint, jeffery@cs.unlv.edu From icon-group-sender Tue Jun 13 07:48:53 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02562 for icon-group-addresses; Tue, 13 Jun 2000 07:48:45 -0700 (MST) Message-Id: <200006131448.HAA02562@baskerville.CS.Arizona.EDU> Date: Tue, 13 Jun 2000 19:15:38 +1000 From: Gowri Raviganesh X-Accept-Language: en X-Newsgroups: comp.lang.icon Subject: setting environment variables X-Trace: 13 Jun 2000 19:10:27 +1000, lv13-17-1.bf.rmit.edu.au To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 89 Hi How can you set an environment variable in a dos window from an icon program ? tia From icon-group-sender Tue Jun 13 10:16:17 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA06876 for icon-group-addresses; Tue, 13 Jun 2000 10:15:19 -0700 (MST) Message-Id: <200006131715.KAA06876@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Tue, 13 Jun 2000 10:35:29 -0500 Subject: setting environment variables To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1795 > How can you set an environment variable in a dos window from an icon program ? I'm not sure that you can. Some time back, I recall hearing that Windows was changed to crunch out unused space in the environment area when opening DOS windows (as a way to reduce memory usage... not that that's QUITE so important anymore). I'm curious what you intend to accomplish by setting the environment variables, though. If you open a DOS window from an Icon program, and if you COULD set the environment variable within that DOS window, you ought to understand that that environment variable would disappear anyhow when the DOS window closes (i.e. upon return to Icon) since environment variables do NOT propagate back to higher DOS windows. You don't therefore change the environment variables that the Icon program would see, for instance. If you CAN set them at all (subject to the space available, which MIGHT be zero) for use in later programs running under that SAME DOS shell) you would probably need to do that using a batch file which includes a SET statement prior to the command that runs the target program. The workaround for the "collapsed environment area" that was usually discussed back when this "feature" of Windows came out was to create in the AUTOEXEC.BAT file one or more dummy "placeholder" environment variables which could be undefined (or defined to a null string, or at least something shorter, thus releasing the space) within your Icon program's invoked DOS shell prior to adding the new environment variable. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Thu Jun 15 12:44:20 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA29861 for icon-group-addresses; Thu, 15 Jun 2000 12:43:10 -0700 (MST) Message-Id: <200006151943.MAA29861@baskerville.CS.Arizona.EDU> From: Kostas Oikonomou Date: Thu, 15 Jun 2000 14:47:42 -0400 (EDT) To: icon-group@optima.CS.Arizona.EDU Subject: Comparisons of reals Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 412 I'm trying to write Icon procedures that implement the approximate <, >, and = relations for real numbers that are in Knuth Vol. 2, section 4.2.2, p. 218 in the 2nd ed. It seems to me that to write these efficiently one needs access to the floating point representation of reals, i.e. fractional part and exponent. Is that possible? Even better, has anybody already written something like this? Kostas From icon-group-sender Mon Jun 19 12:22:29 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA10487 for icon-group-addresses; Mon, 19 Jun 2000 12:20:34 -0700 (MST) Message-Id: <200006191920.MAA10487@baskerville.CS.Arizona.EDU> From: Lloyd Uhler To: "'icon-group@cs.arizona.edu'" Subject: RE: Questions on ICON Date: Mon, 19 Jun 2000 10:10:01 -0500 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3703 Any fix for textbox input in VIB? Thanks. > -----Original Message----- > From: Lloyd Uhler > Sent: Wednesday, April 26, 2000 8:52 AM > To: 'icon-group@cs.arizona.edu' > Subject: Questions on ICON > > 1) For Version 9.3.1 on WIN NT and WIN 98, textbox input does not work for > VIB generated code as follows: > > ########################################################################## > ## > # > # File: C:\Icon9.3\vib_tst.icn > # > # Subject: Program to ... > # > # Author: > # > # Date: January 21, 1999 > # > ########################################################################## > ## > # > # > # > ########################################################################## > ## > # > # Requires: > # > ########################################################################## > ## > # > # Links: vsetup > # > ########################################################################## > ## > > # This vib interface specification is a working program that responds > # to vidget events by printing messages. Use a text editor to replace > # this skeletal program with your own code. Retain the vib section at > # the end and use vib to make any changes to the interface. > > link vsetup > > procedure main(args) > local vidgets, root, paused > > (WOpen ! ui_atts()) | stop("can't open window") > vidgets := ui() # set up vidgets > root := vidgets["root"] > > paused := 1 # flag no work to do > repeat { > # handle any events that are available, or > # wait for events if there is no other work to do > while (*Pending() > 0) | \paused do { > ProcessEvent(root, QuitCheck) > } > # if is set null, code can be added here > # to perform useful work between checks for input > } > end > > procedure text_input_cb1(vidget, value) > # write("value = ", value) > return > end > > #===<>=== modify using vib; do not remove this marker line > procedure ui_atts() > return ["size=600,378", "bg=#C0C0C0"] > end > > procedure ui(win, cbk) > return vsetup(win, cbk, > [":Sizer:::0,0,600,378:",], > ["button1:Button:regular::270,349,32,20:OK",button_cb1], > ["text_input1:Text::46:95,111,367,20:Enter Your > Name:\\=",text_input_cb1], > ) > end > #===<>=== end of section maintained by vib > procedure button_cb1(vidget, value) > # > > # write("button_cb1") > # > # This does not work with the original viface module > # The local one has been revised to detect Window closure > # and do this without error. This will return to the statement > # after GetEvents. The program can then process or do what it > # needs with the results for the GUI data capture. Data values > # can be inserted into global variables so they are available > # to the rest of the program. > # > # WClose( &window ) > return > end > > 2) There seems to be no way to gather a set of file names from a specified > directory: > (System & popen do not work the same as command-line version of ICON > (Nticont, Nticonx)). > (F.F and pipe.001 are empty) > > link graphics, dialog, popen, xio > > procedure main() > # > # > # the 45 is the width > # > txt := TextDialog("Specify Directory Path:", "Path", "C:\\temp" , 45) > > Path := dialog_value[1] > write("Path = ", Path) > > cmd := "Dir /b/l " > # > # See if F.F Generated fro BAT File > # > system( "CALL C:\\ICON9.3\\WDIR.CMD" || Path ) > # > # Try popen to get file of file names > # > fin := popen( cmd || Path, "r") > while line := trim(read(fin)) do write(line) > > pclose(fin) > > end > > REM > REM Wdir.BAT > REM > REM Purpose: Directory Listing > REM > DIR /b/l %1 > F.F From icon-group-sender Fri Jun 23 07:42:26 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA10510 for icon-group-addresses; Fri, 23 Jun 2000 07:41:12 -0700 (MST) Message-Id: <200006231441.HAA10510@baskerville.CS.Arizona.EDU> From: "J.R. Sampson" To: icon-group@optima.CS.Arizona.EDU Date: Fri, 23 Jun 2000 12:34:06 +0100 Subject: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 854 Hello - I am an occasional Icon user, which means I have to look everything up instead of assuming I know anything. Is there a key to, or description of, the error messages and reports that occur while compiling or running Icon programs? I had an error message 114, 'Invalid type to subscript operation' which I eventually traced to the fact that I had typed square brackets where there should have been parens. However, the phrase quoted doesn't make sense to me as it stands. What I had done was to write, in effect, 'foo := set[bar]' - perhaps if I don't make sense to the compiler I can't expect it to make sense to me! It is really a syntax error. Also, some of the library functions, although documented, look as if they were added as part of various studies. Are there references to these projects anywhere? Regards _John Sampson_ From icon-group-sender Fri Jun 23 08:15:13 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA11792 for icon-group-addresses; Fri, 23 Jun 2000 08:15:03 -0700 (MST) Message-Id: <200006231515.IAA11792@baskerville.CS.Arizona.EDU> Date: Fri, 23 Jun 2000 07:57:52 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group , jsampson@indexes.u-net.com Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1071 "J.R. Sampson" wrote: > I had an error message 114, 'Invalid type to subscript operation' > which I eventually traced to the fact that I had typed square > brackets where there should have been parens. However, the > phrase quoted doesn't make sense to me as it stands. What I had > done was to write, in effect, 'foo := set[bar]' - perhaps if I don't > make sense to the compiler I can't expect it to make sense to me! > It is really a syntax error. Actually, no - it's not a syntax error. Function names are not reserved names, but simply global variables with predefined values. Somewhere earlier (in the execution of the program) you may have done: set := table() and then the line foo := set[bar] makes complete sense. (This type of language flexibility does make it difficult to produce error messages that always make sense to the user, who may be thinking of something entirely different - which is why having a traceback that includes line numbers is so useful!) -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu From icon-group-sender Tue Jun 27 10:09:53 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA09414 for icon-group-addresses; Tue, 27 Jun 2000 10:06:39 -0700 (MST) Message-Id: <200006271706.KAA09414@baskerville.CS.Arizona.EDU> Date: Tue, 27 Jun 2000 10:27:30 -0400 From: "Steve Graham" To: Subject: Permutations/Combinations Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id HAA05105 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 603 We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L. I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter. Can anyone help me? Thanks, Steve Graham --------------------------------------------------------------------------------------- Steve Graham Senior Programmer/Analyst LabCorp Phone: (972) 437-5255, ext 5224 Fax: (972) 454-1040 Mail: grahams@labcorp.com --------------------------------------------------------------------------------------- From icon-group-sender Tue Jun 27 12:49:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14033 for icon-group-addresses; Tue, 27 Jun 2000 12:49:15 -0700 (MST) Message-Id: <200006271949.MAA14033@baskerville.CS.Arizona.EDU> Date: Tue, 27 Jun 2000 10:31:35 -0700 (MST) From: Gregg Townsend To: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Permutations/Combinations Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 907 From: "Steve Graham" We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L. I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter. Can anyone help me? If you have a list of English words, an easy solution to the brain teaser is to run the list through this filter: procedure main() local word while word := read() do if *word = 6 & cset(map(word)) == 'aerbml' then write(word) end Of course, I have managed to avoid entirely your question about reversible assignment. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Tue Jun 27 12:51:19 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14139 for icon-group-addresses; Tue, 27 Jun 2000 12:51:11 -0700 (MST) Message-Id: <200006271951.MAA14139@baskerville.CS.Arizona.EDU> Date: Tue, 27 Jun 2000 14:21:56 -0400 From: "Steve Graham" To: Subject: Re: Permutations/Combinations Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id LAA11829 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1779 You're right, Gregg, you did avoid the reversible assignment topic. Although I do not know how to utilize Icon's built-in features to generate all possible combinations/permutations (which one is it?) where the letters appear once and only once, I do believe that, given the generated list, I will recognize the valid words. And I'm sure that Icon can EASILY produce the list, whether the algorthim utilizes reversible assignment or not. Can someone show me how? TIA, Steve === --------------------------------------------------------------------------------------- Steve Graham Senior Programmer/Analyst LabCorp Phone: (972) 437-5255, ext 5224 Fax: (972) 454-1040 Mail: grahams@labcorp.com --------------------------------------------------------------------------------------- >>> Gregg Townsend 06/27/00 12:31PM >>> From: "Steve Graham" We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L. I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter. Can anyone help me? If you have a list of English words, an easy solution to the brain teaser is to run the list through this filter: procedure main() local word while word := read() do if *word = 6 & cset(map(word)) == 'aerbml' then write(word) end Of course, I have managed to avoid entirely your question about reversible assignment. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Tue Jun 27 12:52:55 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA14195 for icon-group-addresses; Tue, 27 Jun 2000 12:52:47 -0700 (MST) Message-Id: <200006271952.MAA14195@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Tue, 27 Jun 2000 14:39:11 -0500 Subject: Permutations/Combinations To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1351 > We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L. I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter. Can anyone help me? First off, one has to presume that you have available a list of English words from which universe you will find matching words that meet the criteria. You can then either generate all possible permutations (which seems to be the approach you're taking) and then look each such word up in the list of valid English words, or else you can work the other way and use your list of words and qualify each to see if it fits the criteria. I'd think that the second approach is simpler, although perhaps the first is faster. Presuming that you have a file with one English-language word (all in lower case) per line: procedure main() while line := trim(read()) do { if *line = 6 then if *(line ** 'aerbml') = 6 then write(line) } end Character sets really make short work of many such problems. :-) Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Tue Jun 27 16:55:20 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21064 for icon-group-addresses; Tue, 27 Jun 2000 16:55:06 -0700 (MST) Message-Id: <200006272355.QAA21064@baskerville.CS.Arizona.EDU> Date: Tue, 27 Jun 2000 13:08:59 -0700 (MST) From: Gregg Townsend To: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Permutations/Combinations Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1054 From: "Steve Graham" Although I do not know how to utilize Icon's built-in features to generate all possible combinations/permutations (which one is it?) where the letters appear once and only once, I do believe that, given the generated list, I will recognize the valid words. And I'm sure that Icon can EASILY produce the list, whether the algorthim utilizes reversible assignment or not. Can someone show me how? The Icon program library contains a nice little permutation generator (in the procs/strings.icn file): procedure permute(s) local i if *s = 0 then return "" suspend s[i := 1 to *s] || permute(s[1:i] || s[i+1:0]) end So to generate all 720 permutations you'd just do this: procedure main() every write(permute("abelmr")) end --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Tue Jun 27 16:58:58 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21141 for icon-group-addresses; Tue, 27 Jun 2000 16:58:51 -0700 (MST) Message-Id: <200006272358.QAA21141@baskerville.CS.Arizona.EDU> To: Gregg Townsend cc: Steve_Graham@labcorp.com, icon-group@optima.CS.Arizona.EDU, wgg@cs.ucsd.edu Subject: Re: Permutations/Combinations Date: Tue, 27 Jun 2000 13:28:05 -0700 From: William Griswold Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1705 Or you can turn it around and generate all possible 6 letter permutations and run the results through a spell checker. 6 factorial isn't that bad. :) A small catch is that spell checkers tell you what is bad, rather than good, and some make mistakes and let stuff through. procedure main(args) every write(genstrings(cset(args[1]))) end procedure genstrings(chars) if *chars = 1 then return chars every c := !chars do suspend (c || genstrings(chars -- c)) end Here is a Unix shell script that completes the job: #!/bin/csh set tmp = /tmp/tmp$$ permute $1 > $tmp.perm spell $tmp.perm > $tmp.misp cat $tmp.misp $tmp.perm | sort | uniq -u rm -f $tmp.perm $tmp.misp --bill In msg <200006271949.MAA14033@baskerville.CS.Arizona.EDU>, Gregg Townsend says: > From: "Steve Graham" > > We have a brain teaser floating around work whose object is to find all > 6-letter English words which can be made from the letters A, E, R, B,M > and L. I'm sure you can do this with Icon's reversible assignment, > but I don't understand the latter. Can anyone help me? > >If you have a list of English words, an easy solution to the brain teaser >is to run the list through this filter: > > procedure main() > local word > while word := read() do > if *word = 6 & cset(map(word)) == 'aerbml' then > write(word) > end > >Of course, I have managed to avoid entirely your question about >reversible assignment. > > --------------------------------------------------------------------------- > Gregg Townsend Staff Scientist The University of Arizona > gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA > > From icon-group-sender Tue Jun 27 16:59:29 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA21185 for icon-group-addresses; Tue, 27 Jun 2000 16:59:18 -0700 (MST) Message-Id: <200006272359.QAA21185@baskerville.CS.Arizona.EDU> Date: Tue, 27 Jun 2000 16:38:22 -0400 From: "Steve Graham" To: Subject: Re: Permutations/Combinations Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id NAA15678 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1544 Gregg, That's exactly what I was looking for. Now, let me have some time to ponder why it works... --------------------------------------------------------------------------------------- Steve Graham Senior Programmer/Analyst LabCorp Phone: (972) 437-5255, ext 5224 Fax: (972) 454-1040 Mail: grahams@labcorp.com --------------------------------------------------------------------------------------- >>> Gregg Townsend 06/27/00 03:08PM >>> From: "Steve Graham" Although I do not know how to utilize Icon's built-in features to generate all possible combinations/permutations (which one is it?) where the letters appear once and only once, I do believe that, given the generated list, I will recognize the valid words. And I'm sure that Icon can EASILY produce the list, whether the algorthim utilizes reversible assignment or not. Can someone show me how? The Icon program library contains a nice little permutation generator (in the procs/strings.icn file): procedure permute(s) local i if *s = 0 then return "" suspend s[i := 1 to *s] || permute(s[1:i] || s[i+1:0]) end So to generate all 720 permutations you'd just do this: procedure main() every write(permute("abelmr")) end --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Wed Jun 28 12:53:21 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA24028 for icon-group-addresses; Wed, 28 Jun 2000 12:51:30 -0700 (MST) Message-Id: <200006281951.MAA24028@baskerville.CS.Arizona.EDU> Date: Wed, 28 Jun 2000 11:11:18 -0700 (MST) From: Gregg Townsend To: icon-group Subject: Wanted: beta testers for map viewing program Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 459 A new application for viewing USGS topo maps under Unix is described in the last Icon newsletter: http://www.cs.arizona.edu/icon/inl/inl60/inl60.htm#USGS If you'd be interested in beta testing this application, please send me a note. --------------------------------------------------------------------------- Gregg Townsend Staff Scientist The University of Arizona gmt@cs.arizona.edu Computer Science Tucson, Arizona, USA From icon-group-sender Thu Jun 29 08:24:53 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA26522 for icon-group-addresses; Thu, 29 Jun 2000 08:23:06 -0700 (MST) Message-Id: <200006291523.IAA26522@baskerville.CS.Arizona.EDU> Date: Thu, 29 Jun 2000 16:43:25 +1000 From: Rohan McLeod X-Accept-Language: en To: Steve Graham CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Permutations/Combinations Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1083 Nope! But here is another ;in case your bored after you solve the first one. (First some back ground.) I was horrified when I realized that the sentence: "the quick brown fox jumped over the lazy dog" actually repeats some letters; (yes compulsive/obsessive personality disorder).So the problem is : "What is the greatest number of non-repeating alphabetic characters (case insensitive) in a gramatically correct English sentence." Steve Graham wrote: > We have a brain teaser floating around work whose object is to find all 6-letter English words which can be made from the letters A, E, R, B,M and L. I'm sure you can do this with Icon's reversible assignment, but I don't understand the latter. Can anyone help me? > > Thanks, > > Steve Graham > > --------------------------------------------------------------------------------------- > Steve Graham > Senior Programmer/Analyst > LabCorp > > Phone: (972) 437-5255, ext 5224 > Fax: (972) 454-1040 > Mail: grahams@labcorp.com > --------------------------------------------------------------------------------------- From icon-group-sender Thu Jun 29 12:30:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA03447 for icon-group-addresses; Thu, 29 Jun 2000 12:29:52 -0700 (MST) Message-Id: <200006291929.MAA03447@baskerville.CS.Arizona.EDU> X-Authentication-Warning: clayton.cs.monmouth.edu: rclayton set sender to rclayton@monmouth.edu using -f From: "R. Clayton" Date: Thu, 29 Jun 2000 12:20:58 -0400 (EDT) To: icon-group@optima.CS.Arizona.EDU Subject: Oh, wow - synchronicity. Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 911 I was horrified when I realized that the sentence: "the quick brown fox jumped over the lazy dog" actually repeats some letters; (yes compulsive/obsessive personality disorder).So the problem is : "What is the greatest number of non-repeating alphabetic characters (case insensitive) in a gramatically correct English sentence." You may think this is an idle, fatuous problem but it's not. I recently bought a set of 26 magnetic letters for my office door and made the same shocking discovery that Rohan McLeod made, which immediately led me to a similar question: What's the best 26 non-repeating letter sentence? Unfortunately, my icon investigations into this problem are unfinished, having been stopped at the words-into-sentences part by other matters (which, co-incidentally enough, include the data structures course I'm teaching this summer - perhaps there is some synegery here too). From icon-group-sender Thu Jun 29 13:35:10 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05215 for icon-group-addresses; Thu, 29 Jun 2000 13:34:49 -0700 (MST) Message-Id: <200006292034.NAA05215@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Thu, 29 Jun 2000 15:14:07 -0500 Subject: Oh, wow - synchronicity. To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1309 >> I was horrified when I realized that the sentence: "the quick brown fox jumped over the lazy dog" actually repeats some letters; (yes compulsive/obsessive personality disorder).So the problem is : "What is the greatest number of non-repeating alphabetic characters (case insensitive) in a gramatically correct English sentence." > You may think this is an idle, fatuous problem but it's not. I recently bought a set of 26 magnetic letters for my office door and made the same shocking discovery that Rohan McLeod made, which immediately led me to a similar question: What's the best 26 non-repeating letter sentence? Unfortunately, my icon investigations into this problem are unfinished, having been stopped at the words-into-sentences part by other matters (which, co-incidentally enough, include the data structures course I'm teaching this summer - perhaps there is some synegery here too). If you can't repeat letters, you have a very basic problem... there are only five or six vowels and you must have at least one per word... Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Thu Jun 29 13:58:04 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05871 for icon-group-addresses; Thu, 29 Jun 2000 13:57:44 -0700 (MST) Message-Id: <200006292057.NAA05871@baskerville.CS.Arizona.EDU> From: David S Cargo Date: Thu, 29 Jun 2000 15:52:57 -0500 (CDT) To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Oh, wow - synchronicity. Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 89 One other alternative that remember is "Pack my bags with five dozen liquor jugs." dsc From icon-group-sender Thu Jun 29 13:58:34 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA05910 for icon-group-addresses; Thu, 29 Jun 2000 13:58:21 -0700 (MST) Message-Id: <200006292058.NAA05910@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Thu, 29 Jun 2000 16:14:22 -0500 Subject: Re: Oh, wow - synchronicity. To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 449 > One other alternative that remember is "Pack my bags with five dozen liquor jugs." Right, but way too much reuse of vowels... at least for the "all twenty-six letters, ONCE EACH" challenge. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Thu Jun 29 16:57:18 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA10913 for icon-group-addresses; Thu, 29 Jun 2000 16:56:52 -0700 (MST) Message-Id: <200006292356.QAA10913@baskerville.CS.Arizona.EDU> From: Charles G Shirley X-Newsgroups: comp.lang.icon Subject: Re: Oh, wow - synchronicity. Date: Thu, 29 Jun 2000 15:40:51 -0600 X-Accept-Language: en,pdf To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1267 Zing! vext cwm fly jabs Kurd qoph. That's one I recall from a book titled _Literary Oddities and Curiosities_. The sentence describes an irritated fly from a high mountain valley attempting to sting a Hebrew letter being written by a Kurd. Not often useful in real life, but it is grammatically correct. "R. Clayton" wrote: > > I was horrified when I realized that the sentence: "the quick brown fox > jumped over the lazy dog" actually repeats some letters; (yes > compulsive/obsessive personality disorder).So the problem is : "What is the > greatest number of non-repeating alphabetic characters (case insensitive) in > a gramatically correct English sentence." > > You may think this is an idle, fatuous problem but it's not. I recently bought > a set of 26 magnetic letters for my office door and made the same shocking > discovery that Rohan McLeod made, which immediately led me to a similar > question: What's the best 26 non-repeating letter sentence? Unfortunately, my > icon investigations into this problem are unfinished, having been stopped at > the words-into-sentences part by other matters (which, co-incidentally enough, > include the data structures course I'm teaching this summer - perhaps there is > some synegery here too). From icon-group-sender Fri Jun 30 08:03:17 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA04466 for icon-group-addresses; Fri, 30 Jun 2000 08:02:19 -0700 (MST) Message-Id: <200006301502.IAA04466@baskerville.CS.Arizona.EDU> Date: Thu, 29 Jun 2000 23:22:07 -0700 (PDT) From: Shamim Mohamed To: gep2@terabites.com Cc: icon-group@optima.CS.Arizona.EDU Subject: Re: Oh, wow - synchronicity. Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 300 >> One other alternative that remember is "Pack my bags with five dozen >> liquor jugs." > Right, but way too much reuse of vowels... at least for the "all > twenty-six letters, ONCE EACH" challenge. Try "Cwm fjord bank glyphs vext quiz." (With a little imagination it even makes sense!) -s From icon-group-sender Fri Jun 30 08:05:28 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA04572 for icon-group-addresses; Fri, 30 Jun 2000 08:05:20 -0700 (MST) Message-Id: <200006301505.IAA04572@baskerville.CS.Arizona.EDU> Date: 30 Jun 2000 09:31:28 BST From: rjhare@ed.ac.uk Subject: Re: Oh, wow - synchronicity. To: "R. Clayton" cc: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 718 > question: What's the best 26 non-repeating letter sentence? Unfortunately, \ > my > icon investigations into this problem are unfinished, having been stopped at > the words-into-sentences part by other matters (which, co-incidentally \ > enough, > include the data structures course I'm teaching this summer - perhaps there \ > is > some synegery here too). There's a good article on just this topic in one of Stephen Jay Goulds books - from memory, it's in `Bully For Brontosaurus', but I'm not absolutely sure. I think that one of the attempts in the article is: The five boxing wizards jump quickly. If it's not, I have no memory of where I got that one, but it's `better' than the fox thing... Roger Hare From icon-group-sender Fri Jun 30 12:31:59 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12426 for icon-group-addresses; Fri, 30 Jun 2000 12:31:08 -0700 (MST) Message-Id: <200006301931.MAA12426@baskerville.CS.Arizona.EDU> From: Kostas Oikonomou X-Newsgroups: comp.lang.icon Subject: Approximate comparisons of reals Date: Fri, 30 Jun 2000 11:32:55 -0400 X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 550 I'm trying to write Icon procedures that implement the approximate <, >, and = relations for real numbers that are in Knuth Vol. 2, section 4.2.2, p. 218 in the 2nd ed. I would like to put these in a library. It seems to me that to write such procedures efficiently one needs access to the floating point representation of reals, i.e. fractional part and exponent. Is it possible ro access the representation of reals in Icon? Or has someone already written something like this? Kostas From icon-group-sender Fri Jun 30 12:46:54 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12801 for icon-group-addresses; Fri, 30 Jun 2000 12:46:45 -0700 (MST) Message-Id: <200006301946.MAA12801@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: coexpression history Date: Fri, 30 Jun 2000 19:06:58 -0100 X-Trace: news0.skynet.be 962384486 19918 195.238.7.176 (30 Jun 2000 17:01:26 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 358 Jim Mehl wrote: > > I don't think so. I have this vague remembrance that > coexpression/coroutine was actually proposed many years > ago in the context of a COBOL compiler of all things. > Maybe someone with a better sense of computer science > history can help me out here. In any case, it was part of Simula, I think Simula started around 1967 ... Atle From icon-group-sender Fri Jun 30 12:47:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA12839 for icon-group-addresses; Fri, 30 Jun 2000 12:47:14 -0700 (MST) Message-Id: <200006301947.MAA12839@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: coexpression history Date: Fri, 30 Jun 2000 19:12:07 -0100 X-Trace: news1.skynet.be 962384795 6678 195.238.7.176 (30 Jun 2000 17:06:35 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 790 Steve Wampler wrote: > > Yes, that's the original reference (as far as I can remember) for the > coroutine side of co-expressions. Coroutines were then implemented in > a number of languages. The one that comes to mind as having the most > influence here is Simula. The idea of coroutines is being 'revamped' as 'component object' in Beta, the successor to Simula. Beta takes the idea of 'object oriented programming' one step further, to 'pattern-oriented programming'. I first saw coroutines in Icon, but now, when I have looked a little at Beta and gotten a very superficial overview of what they were part of, I realy feel i understand it better. People interested in these aspects of Icon would progrably find Beta interesting: www.mjolner.dk -- at least I assume so :-) Atle From icon-group-sender Wed Jul 5 08:03:33 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24576 for icon-group-addresses; Wed, 5 Jul 2000 08:02:11 -0700 (MST) Message-Id: <200007051502.IAA24576@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: Error messages Date: Sat, 01 Jul 2000 12:21:15 -0100 X-Trace: news0.skynet.be 962446543 8139 194.78.236.172 (1 Jul 2000 10:15:43 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1414 Steve Wampler wrote: > > > set := table() > > and then the line > > foo := set[bar] > > makes complete sense. (This type of language flexibility does > make it difficult to produce error messages that always make > sense to the user, who may be thinking of something entirely > different - which is why having a traceback that includes line > numbers is so useful!) This may not be related to Icon at all (although I feel that Icon, ProLog, Simula and Beta are 'close cousins :) - but I have been fooling around with the idea of writing a parser in ProLog - I started out with something close to the grammar for 8086 assembly. Why? Because the syntax is simple, so syntax errors wont contain much information as to what the error actually is, but the semantics possibilities are enormous compared to, say, Pascal. Now, this is where I think it might be relevant: Wouldn't some kind of knowledge base help in producing more meaningful error messages? I have been through Icon enough to write small programs in it, and I had the same impression: The error messages really only say: "Error" - and you have to find the rest out for yourself. The case here about the [] could be added to the knowledgebase, so the next time, the error would be "I told myself I wouldn't use [] here!" :-) Any thoughts? Should I drop the idea of using an AI language to build an assembler? (I actually wanted to use Beta) From icon-group-sender Wed Jul 5 08:05:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24721 for icon-group-addresses; Wed, 5 Jul 2000 08:05:15 -0700 (MST) Message-Id: <200007051505.IAA24721@baskerville.CS.Arizona.EDU> From: "Mark Evans" To: Subject: A better GUI for the next generation Date: Mon, 3 Jul 2000 14:29:17 -0500 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2506 Dear Iconeers, The Visual Interface Builder (VIB) has never been more than a toy. This note is a public encouragement to the Icon and Unicon development teams to drop the current VIB and consider another approach. The inspiration for this idea is the awesome wxPython. http://www.wxPython.org http://www.Python.org Python is an open-source interpretive script language with roots in Modula-3 and borrowings from Icon, Lisp, and C++ (plus a byte-code execution model like Java). Many consider it the best interpreted language and it has a wide following. It is running some real-world web pages for example. It is object-oriented and scalable. Now the "wx" in wxPython comes from the wxWindows cross-platform C++ GUI library. So "wxPython" is not a variant of Python, which is standardized; it is a set of Python-language wrapper classes for the wxWindows C++ library. In effect it marries the best of both worlds. You get the ease of Python with the efficiency of C++ for GUI development. The wxPython library is a set of Python classes that essentially mirror the underlying C++ classes in wxWindows. You must run the wxPython demo to understand the power and ease of this GUI tool. The demo offers a list of GUI displays with corresponding wxPython code available in a separate tab frame. One of the most impressive demos is a million-cell spreadsheet. In many respects wxPython is a lot like Visual Basic in its ease of use, but without the language problems. It must be said that wxPython lacks a GUI editor per se. However Python can build stand-alone GUI executables on any platform. (There is a second cross-platform GUI suite for Python, but wxPython is light years ahead of it.) The proposal then is a set of Unicon "wrapper" classes in the spirit of wxPython. Other people in the open-source world have already done the C++ GUI development work. Given the limited resources of the Unicon team, I would suggest leveraging this work and not extending the poor old VIB. Incidentally it would be nice if Unicon adopted the open source model more completely. Over at the Python site, I can get daily builds of the current development version, and its issues are openly discussed by Pythoneers. This is true open-source. The Icon/Unicon model is open source but not open source development. There are just a few people working on the language in their spare time, and that is why it takes so long. Still I look forward to the release of Unicon! Best regards, Mark Evans From icon-group-sender Wed Jul 5 08:06:03 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24756 for icon-group-addresses; Wed, 5 Jul 2000 08:05:52 -0700 (MST) Message-Id: <200007051505.IAA24756@baskerville.CS.Arizona.EDU> X-Priority: 3 (Normal) Date: Mon, 03 Jul 2000 23:28:51 +0200 (CEST) From: Guido Milanese To: icon-group@optima.CS.Arizona.EDU Subject: RE: setting environment variables Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 866 A simple question, I hope. I am writing, as exercise, a little database program. The program scans data from input file and I would like data to be output in a (graphic) window this way: Field1 Dat1 Field2 Dat2 ... ... Fieldn Datn User must be able to modify Dat(1:n), therefore I have chosen TextDialog. However, the problem is that I find no way to allow data entry of more than one line, which is very inconvenient if data is very long. I also tried to chop data separating portions with a newline char, but this was totally wrong... Any suggestion, please? Many thanks, Guido ------------------------------------------- E-Mail: Guido Milanese Homepage: http://fly.to/arsantiqua 03-Jul-00 - XFMail on Linux + + + + + + NON NOBIS DOMINE + + + + + + ------------------------------------------- From icon-group-sender Wed Jul 5 08:06:28 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA24792 for icon-group-addresses; Wed, 5 Jul 2000 08:06:14 -0700 (MST) Message-Id: <200007051506.IAA24792@baskerville.CS.Arizona.EDU> Date: Mon, 03 Jul 2000 21:56:47 -0400 From: David Gamey To: icon-group@optima.CS.Arizona.EDU Subject: Icon and Palm? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 153 Has anyone ported Icon (any release) to the Palm? I recall reading a few years ago of an old release being run on some kind of PDA. Thanks, David From icon-group-sender Wed Jul 5 09:47:32 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA27523 for icon-group-addresses; Wed, 5 Jul 2000 09:47:16 -0700 (MST) Message-Id: <200007051647.JAA27523@baskerville.CS.Arizona.EDU> Date: Wed, 5 Jul 2000 09:40:57 -0700 (PDT) From: Shamim Mohamed To: "Mark Evans" Cc: Subject: Re: A better GUI for the next generation Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1035 Mark Evans writes: > Dear Iconeers, The Visual Interface Builder (VIB) has never been more > than a toy. This note is a public encouragement to the Icon and Unicon > development teams to drop the current VIB and consider another approach. [...] > Incidentally it would be nice if Unicon adopted the open source model > more completely. Over at the Python site, I can get daily builds of the > current development version, and its issues are openly discussed by > Pythoneers. This is true open-source. The Icon/Unicon model is open > source but not open source development. There are just a few people > working on the language in their spare time, and that is why it takes so > long. Hmmm... sounds to me like you're volunteering. Wonderful! The "daily build" model makes sense when many developers are actively working on the system. In our case, there are just a few people (as you said) - but not because we want to keep secrets. If you can help out, why don't you drop Clint a line? -s From icon-group-sender Wed Jul 5 09:48:10 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA27563 for icon-group-addresses; Wed, 5 Jul 2000 09:47:56 -0700 (MST) Message-Id: <200007051647.JAA27563@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Wed, 05 Jul 2000 11:57:46 -0500 Subject: Re: Error messages To: trollet@skynet.be, icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1734 > This may not be related to Icon at all (although I feel that Icon, ProLog, Simula and Beta are 'close cousins :) - but I have been fooling around with the idea of writing a parser in ProLog - I started out with something close to the grammar for 8086 assembly. Why? Because the syntax is simple, so syntax errors wont contain much information as to what the error actually is, but the semantics possibilities are enormous compared to, say, Pascal. Now, this is where I think it might be relevant: Wouldn't some kind of knowledge base help in producing more meaningful error messages? I have been through Icon enough to write small programs in it, and I had the same impression: The error messages really only say: "Error" - and you have to find the rest out for yourself. The case here about the [] could be added to the knowledgebase, so the next time, the error would be "I told myself I wouldn't use [] here!" :-) > Any thoughts? Should I drop the idea of using an AI language to build an assembler? (I actually wanted to use Beta) Well, you could probably write the assembler to run on a Turing machine, too. That doesn't mean it's the best tool for the job. For something that is so line-oriented as assembler language is, I'd think that either Icon or SNOBOL/SPITBOL would be relatively ideal tools for writing your assembler. Although you COULD probably write it in Prolog, I have to wonder if the benefits of making that choice are enough to justify the hassle. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Thu Jul 6 07:35:43 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02281 for icon-group-addresses; Thu, 6 Jul 2000 07:34:07 -0700 (MST) Message-Id: <200007061434.HAA02281@baskerville.CS.Arizona.EDU> To: "Mark Evans" Cc: icon-group@optima.CS.Arizona.EDU Subject: Re: A better GUI for the next generation Date: Wed, 05 Jul 2000 17:39:47 -0700 From: Clinton L Jeffery Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 752 Mark Evans recently suggested that we develop better GUI tools. If the suggestion was for Icon, it should say Icon not Unicon, otherwise you confuse (and maybe irritate) some people. From the Icon standpoint, but not speaking for the Icon project, I would say your request for better GUI tools is valid, and you are welcome to develop and distribute such tools. I used to sponsor student projects to improve VIB, but have given up on it. Since Mark suggests new GUI "wrapper" classes for Unicon, I will post a longer reply to the message to the Unicon list and hopefully we can have a discussion of it there. Unicon stuff is accessed via http://icon.cs.unlv.edu; the mailing list is up but not archived yet. Regards, Clint, jeffery@cs.unlv.edu From icon-group-sender Thu Jul 6 08:35:22 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA03576 for icon-group-addresses; Thu, 6 Jul 2000 08:35:05 -0700 (MST) Message-Id: <200007061535.IAA03576@baskerville.CS.Arizona.EDU> From: "Mark Evans" To: Cc: "Clinton L Jeffery" Subject: RE: A better GUI for the next generation Date: Thu, 6 Jul 2000 10:04:43 -0500 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2823 No irritation intended. The situation is intrinsically confusing which is why I used the term "next generation." Between AZ and NV there have been several sprouts (Icon, Idol, Godiva, Unicon, Jcon, Iconc) plus sounds to the effect that Icon qua Icon is now frozen in time, and the future is Unicon. The wrapper concept applies equally to either Icon or Unicon. If Icon qua Icon has any sort of future, then I formally recommend the wrapper concept for it as well. Anyone wishing to cross-post my notes to Unicon is welcome to do so. Since Unicon is not even released yet (for Windows, the major platform) and Clint told me the traffic is still light over there, I felt the Icon list a more appropriate place to post. I would certainly appreciate any etiquette FAQs that either AZ or NV teams would like to manufacture and post. What exactly *is* the future of Icon after all? From what I understand, the only active development is taking place under the Unicon banner. To answer S. Mohamed's points, I might well volunteer if the development were more transparent. The lack of transparency keeps Icon/Unicon/whatever in the minor leagues and limits the volunteer base. Icon has been around at least as long as Python's 10 years. There are plenty of open-source teams doing this sort of thing, e.g. SourceForge. The number of Python support resources and web sites is truly astounding. So the suggestion stands, that open-source development should go all the way and follow the model of similar endeavors. That does not mean that control is relinquished but it means a team can form around the effort and the world can know what they are doing at all times. Python for example has formal mechanisms for improvement proposals and standing releases of last-final plus current-alpha software builds and a source code repository. Mark -----Original Message----- From: Clinton L Jeffery [mailto:jeffery@bo.Egr.UNLV.EDU] Sent: Wednesday, July 05, 2000 7:40 PM To: Mark Evans Cc: icon-group@cs.arizona.edu Subject: Re: A better GUI for the next generation Mark Evans recently suggested that we develop better GUI tools. If the suggestion was for Icon, it should say Icon not Unicon, otherwise you confuse (and maybe irritate) some people. From the Icon standpoint, but not speaking for the Icon project, I would say your request for better GUI tools is valid, and you are welcome to develop and distribute such tools. I used to sponsor student projects to improve VIB, but have given up on it. Since Mark suggests new GUI "wrapper" classes for Unicon, I will post a longer reply to the message to the Unicon list and hopefully we can have a discussion of it there. Unicon stuff is accessed via http://icon.cs.unlv.edu; the mailing list is up but not archived yet. Regards, Clint, jeffery@cs.unlv.edu From icon-group-sender Fri Jul 7 07:44:18 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA11378 for icon-group-addresses; Fri, 7 Jul 2000 07:42:22 -0700 (MST) Message-Id: <200007071442.HAA11378@baskerville.CS.Arizona.EDU> Date: Fri, 7 Jul 2000 14:43:26 +1200 (NZST) From: "Richard A. O'Keefe" To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU, trollet@skynet.be Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 762 Gordon Peterson wrote (in extremely long lines): > Although you COULD probably write [an assembler] in Prolog, > I have to wonder if the benefits of making that choice are > enough to justify the hassle. I just _have_ to ask: WHICH hassle? Let's face it, analysing the input hasn't been the hard part of assembler writing for decades. Writing the output is the tricky part. The real hassle is finding out what the wretched output is supposed to look like. For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write a new kind of assembler would be mad not to re-use as much of the GNU binutils as practical. By all means put a smart new front end on an assembler, but let someone else deal with the *real* hassle. From icon-group-sender Fri Jul 7 08:45:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA12521 for icon-group-addresses; Fri, 7 Jul 2000 08:45:08 -0700 (MST) Message-Id: <200007071545.IAA12521@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: Error messages Date: Fri, 07 Jul 2000 11:12:29 -0100 X-Trace: news0.skynet.be 962960788 28207 194.78.239.13 (7 Jul 2000 09:06:28 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 690 > For something that is so line-oriented as assembler language is, I'd think that either Icon or >SNOBOL/SPITBOL would be relatively ideal tools for writing your assembler. Although you COULD >probably write it in Prolog, I have to wonder if the benefits of making that choice are enough to >justify the hassle. Well, it wasn't really the low-level routines for IO or code generation I though about, but the part where the assembler/compiler decides what to do - and that is something ProLog should be good at - ant 'decide what to do' in most cases is either pass it on stop with error message so deciding what err message to put out, should be be a ProLog problem, right? Atle From icon-group-sender Fri Jul 7 12:31:12 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA18301 for icon-group-addresses; Fri, 7 Jul 2000 12:30:52 -0700 (MST) Message-Id: <200007071930.MAA18301@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: Error messages Date: Fri, 07 Jul 2000 18:16:05 -0100 X-Trace: news0.skynet.be 962986201 3807 195.238.7.245 (7 Jul 2000 16:10:01 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 959 "Richard A. O'Keefe" wrote: > > For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write > a new kind of assembler would be mad not to re-use as much of the GNU binutils > as practical. By all means put a smart new front end on an assembler, but > let someone else deal with the *real* hassle. I think this is where things come together: Different languages for different parts of an application. Icon would have its place here for analyzing the input - maybe as far as to storing tokens in a tokenarray. Maybe an assembler was a bad example - but still: Wouldn't ProLog be ideal for making decisions? And then there is another matter: The instructions must be provided to the processor (Pentium) in the optimal sequence, making sure the pipelines are full at all times (as far as possible). Even the GNU tools haven't fully kept up here, since this is a big job, and, in my mind, C is not the ideal tool for this job. ????? Atle From icon-group-sender Fri Jul 7 14:18:23 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA20851 for icon-group-addresses; Fri, 7 Jul 2000 14:16:41 -0700 (MST) Message-Id: <200007072116.OAA20851@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Fri, 07 Jul 2000 16:18:50 -0500 Subject: Re: Error messages To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 3091 >Gordon Peterson wrote (in extremely long lines): Sorry if you don't like those... I've got the choice of not breaking lines, or of breaking them manually, or of breaking them automatically at (say) 80 columns. Whichever I choose seems to have at least SOME nasty artifacts, and someone bitches. I think I'm going to just set it back for force a break at 80 columns and let it go at that. >> Although you COULD probably write [an assembler] in Prolog, > I have to wonder if the benefits of making that choice are > enough to justify the hassle. > I just _have_ to ask: WHICH hassle? I've written a **lot** of such stuff (admittedly in SNOBOL/SPITBOL rather than Icon, but the principle is certainly similar). I don't think you have anything like the same capabilities and ease of programming in Prolog that you have in S*BOL or in Icon. Now it could be that you don't program in S*BOL or Icon the way I do, or that maybe you'd just rather do it (for whatever perverse reason) in Prolog. Hey, whatever floats your own personal boat... > Let's face it, analysing the input hasn't been the hard part of assembler writing for decades. Analyzing the input is a tiny part of the area where S*BOL or Icon shine. It's the other areas surrounding the project where the real benefits show up. The script compiler I wrote for the French Social Security Administration was written in a day and a half, and produced the most beautifully complete and detailed listings (cross references, formatted symbol tables, error summaries, and even a listing table of contents) you ever saw. It would have taken at least six months to write the same thing in C/C++, and maybe not a whole lot less to have written it in Prolog. > Writing the output is the tricky part. The real hassle is finding out what the wretched output is supposed to look like. I claim that THAT is only part of the hassle too. But hey, as I said, I've got better things to do than to go through a detailed point-by-point argument with you if you really want to do it in Prolog (or for that matter if you want to write it to run on a Turing-machine emulator). It's your time and your money. And you'll have to live the resulting product when you're done with it. Since I'm reasonably sure that *I* will never have to use it, it matters really not one whit to me. :-) > For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write a new kind of assembler would be mad not to re-use as much of the GNU binutils as practical. By all means put a smart new front end on an assembler, but let someone else deal with the *real* hassle. Well, I guess it depends on whether you want an assembler that works like everyone else's or not. (Buf if you're happy with existing ones, why write a new one at all?) Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Fri Jul 7 14:21:52 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA21021 for icon-group-addresses; Fri, 7 Jul 2000 14:21:44 -0700 (MST) Message-Id: <200007072121.OAA21021@baskerville.CS.Arizona.EDU> From: gep2@terabites.com Date: Fri, 07 Jul 2000 16:28:44 -0500 Subject: Re: Error messages To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2450 > I think this is where things come together: Different languages for different parts of an application. Maybe you should build a vehicle which is simultaneously a boat, an airplane, a car and a submarine, too. That way you can meld those disparate parts into a cohesive (cough!) whole, too. ;-) > Icon would have its place here for analyzing the input - maybe as far as to storing tokens in a tokenarray. To suggest that Icon's appeal for writing an assembler is limited only to the initial syntactical parsing of tokens is pretty ludicrous. > Maybe an assembler was a bad example - but still: Wouldn't ProLog be ideal for making decisions? No, not if those decisions are relatively simple... that's like using atomic weapons to kill mosquitos. Icon's goal-directed evaluation can be a wonderful tool for analyzing various possible instruction sequences and rating them based on size, performance, and other criteria. Icon also makes it hugely simpler to create all manner of statistics and summaries and other information (and present it nicely) regarding the program being processed, too. > And then there is another matter: The instructions must be provided to the processor (Pentium) in the optimal sequence, making sure the pipelines are full at all times (as far as possible). That was more of an issue in the days when there was one overwhelmingly dominant microprocessor out there. With AMD, Cyrix, and others out there (even several quite different-internally designs from Intel) it is largely impractical to optimize for a specific microprocessor's internal architecture (unless you're doing an embedded app for a specific KNOWN CPU architecture, such as a TI DSP or something). And if you were GOING to optimize for just one processor, I'd think it would make more sense to do it for an AMD processor, since I believe that with recent stupid moves by Intel, I think you're going to see a lot of market share slip out of Intel's hands and into those of AMD. > Even the GNU tools haven't fully kept up here, since this is a big job, and, in my mind, C is not the ideal tool for this job. C isn't ideal for most anything that isn't really low level. Gordon Peterson http://web2.airmail.net/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: the day the Conservatives demonstrated their scorn for their fraudulent sham of representative government. Voters, remember it! From icon-group-sender Mon Jul 10 07:46:06 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA19920 for icon-group-addresses; Mon, 10 Jul 2000 07:44:44 -0700 (MST) Message-Id: <200007101444.HAA19920@baskerville.CS.Arizona.EDU> Date: Fri, 07 Jul 2000 20:50:58 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: Friday puzzle... Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 4363 This is a multi-part message in MIME format. --------------F23570175734CDBF613A10C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Every so often I've posed a programming problem here for Iconites to work on. Here's another one, but this time I'm providing an initial solution and the challenge is to find a faster solution (the solution attached here is pretty slow...) My son David asked me today a question about genetics: "If blood type O is a recessive gene, then why does it dominate in the population?" (~46% of the population is either O positive or O negative). Well, I don't have an answer, so attached is a program to simulate a population w.r.t a genetic trait (in this case, blood type). The program is patterned (uh, loosely) after a real population - there are humans, couples, births, and deaths, after a fashion. Interestingly enough, starting with a population that is ~25% O (the program combines positive and negative into the types), the percentage is around 22% after 116 generations (which is as far as the program has gotten while I'm typing this). Anyway, can you find a faster way to simulate the population across generations? I'd also appreciate a correct answer to David's question that both he and I can understand! --- Steve Wampler {sbw@tapestry.tucson.az.us} The gods that smiled upon your birth are laughing now. -- fortune cookie --------------F23570175734CDBF613A10C4 Content-Type: text/plain; charset=us-ascii; name="blood.icn" Content-Disposition: inline; filename="blood.icn" Content-Transfer-Encoding: 7bit # # Simulate the gene pool w.r.t. blood types # global btypes # Genetic trait is blood type record human(gene1, gene2) # A human has two blood type genes record couple(p1, p2) # Takes two to tango procedure main(args) # introduce some randomess from one run to the next write("Random seed: ",randSeed := &clock) &random := map("HhMmSs","Hh:Mm:Ss", randSeed) btypes := "ON" # simplify things "O" and "Not O" nHumans := 10000 # small population pool := createGenePool(nHumans) analyzePool(pool) every generation := 1 to 1000 do { # run for a lot of generations pool := alterPool(pool) if (generation % 1) == 0 then { # display every so often write("Generation ",generation) analyzePool(pool, "\t") } } end # # Create the initial population # procedure createGenePool(size) pool := set() every 1 to size do insert(pool, newHuman()) return pool end # # Create a new human, about 1 in 4 will be O blood type # procedure newHuman() static initOdds initial initOdds := repl("O",50) || repl("N",50) return human(?initOdds, ?initOdds) # random genes end # # See how the population is doing # procedure analyzePool(pool, prefix) /prefix := "" nO := nN := 0 every person := !pool do { if (person.gene1 == "O") & (person.gene2 == "O") then nO +:= 1 else nN +:= 1 } write(prefix, "Pool Size is: ",*pool) write(prefix, "\tNumber O type: ",nO) write(prefix, "\tNumber not O type: ",nN) write(prefix, "\t% O type: ",real(nO)/*pool) write() end # # Put the population through a generation # procedure alterPool(pool) static childProb # help in selecting number of children initial childProb := [0,0,1,1,1,2,2,2,3,3,4] newPool := set() parents := [] every put(parents, marryOff(pool)) # wow, everyone marries! # create the next generation # every pair := !parents do { insert(newPool, pair.p1) insert(newPool, pair.p2) every 1 to ?childProb do { # children get a gene from each parent person := human(?(pair.p1), ?(pair.p2)) insert(newPool, person) } } # now kill off enough to keep the population growth small * deaths := integer(*newPool * 0.46) every 1 to deaths do { delete(newPool, ?newPool) } return newPool end # Marry pairs of humans off (ok, so apparently the sex of each parent # isn't important - must be New Hampshire?) # procedure marryOff(pool) while *pool > 1 do { delete(pool, p1 := ?pool) delete(pool, p2 := ?pool) suspend couple(p1, p2) } end --------------F23570175734CDBF613A10C4-- From icon-group-sender Mon Jul 10 08:00:10 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA20182 for icon-group-addresses; Mon, 10 Jul 2000 07:59:59 -0700 (MST) Message-Id: <200007101459.HAA20182@baskerville.CS.Arizona.EDU> Date: Fri, 07 Jul 2000 20:56:06 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: More on Friday puzzle Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 271 I forgot - I'd also appreciate critiques on whether or not the approach used in the sample solution has *any* basis in genetic reality! Thanks. --- Steve Wampler {sbw@tapestry.tucson.az.us} The gods that smiled upon your birth are laughing now. -- fortune cookie From icon-group-sender Mon Jul 10 08:01:18 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20341 for icon-group-addresses; Mon, 10 Jul 2000 08:01:11 -0700 (MST) Message-Id: <200007101501.IAA20341@baskerville.CS.Arizona.EDU> From: Atle X-Newsgroups: comp.lang.icon Subject: Re: Error messages Date: Sat, 08 Jul 2000 15:18:30 -0100 X-Trace: news0.skynet.be 963061936 2886 194.78.236.183 (8 Jul 2000 13:12:16 GMT) X-Complaints-To: abuse@skynet.be X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1938 gep2@terabites.com wrote: > > > I think this is where things come together: Different languages for different > parts of an application. > > Maybe you should build a vehicle which is simultaneously a boat, an airplane, a > car and a submarine, too. That way you can meld those disparate parts into a > cohesive (cough!) whole, too. ;-) I don't understand: What is the relevance? How is using different tools (Icon,ProLog,C, etc. - or hammer, wrench, screwdriver, etc) to build something related to building things that are many things at the same time? > > To suggest that Icon's appeal for writing an assembler is limited only to the > initial syntactical parsing of tokens is pretty ludicrous. If someone would suggest something like that, I would have to agree ... > > No, not if those decisions are relatively simple... that's like using atomic > weapons to kill mosquitos. We don't use atomic weapons to kill anything ... we build things, and a part of that is to consider different tools. > > Icon's goal-directed evaluation can be a wonderful tool for analyzing various > possible instruction sequences and rating them based on size, performance, and > other criteria. Icon also makes it hugely simpler to create all manner of > statistics and summaries and other information (and present it nicely) regarding > the program being processed, too. Suddenly a fresh breath of common sense. Than you! > > something). And if you were GOING to optimize for just one processor, I'd think > it would make more sense to do it for an AMD processor, since I believe that > with recent stupid moves by Intel, I think you're going to see a lot of market > share slip out of Intel's hands and into those of AMD. First the decision should be made whether to optimize, and find good tools for that. Deciding what processor to optimize for - that will be done automatically: Whatever processor is available to me. > Stay focused! Atle From icon-group-sender Mon Jul 10 08:02:48 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20447 for icon-group-addresses; Mon, 10 Jul 2000 08:02:40 -0700 (MST) Message-Id: <200007101502.IAA20447@baskerville.CS.Arizona.EDU> Date: Mon, 10 Jul 2000 16:51:56 +1200 (NZST) From: "Richard A. O'Keefe" To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 4073 I wrote: > I just _have_ to ask: WHICH hassle? Gordon Peterson wrote: I've written a **lot** of such stuff (admittedly in SNOBOL/SPITBOL rather than Icon, but the principle is certainly similar). I don't think you have anything like the same capabilities and ease of programming in Prolog that you have in S*BOL or in Icon. I've been a SNOBOL user off and on since the mid-70s. I still use SNOBOL on UNIX, quite happily. One of the first things I did when I met Prolog was to figure out the equivalents in Prolog. It used to surprise people when I pointed out that there was prior art for "!" in SNOBOL's FENCE. The thing is that SNOBOL gives you *almost* but not quite the same power and convenience for parsing text as Prolog does, but there it stops. As an anthropologist pointed out to me in the mid-70s when I was trying to persaude everyone to use SNOBOL, "if it can't parse anything but strings, what's the big deal?" Icon is a step backwards for parsing strings, but a big step forward for matching other kinds of data structures. But even Icon has a long way to go to match the ease of programming in Prolog. Now it could be that you don't program in S*BOL or Icon the way I do, or that maybe you'd just rather do it (for whatever perverse reason) in Prolog. Hey, whatever floats your own personal boat... You don't have to be perverse to prefer Prolog. You just have to like being able to use labelled trees as data structures and the ease of pattern matching on them. Seriously, the two big differences between Icon and Prolog here are - Icon has assignment statements, Prolog doesn't. - Icon looks a lot like C, Prolog doesn't. It's the other areas surrounding the project where the real benefits show up. Which areas, exactly? That's really what this thread is about. Generating binary output as such isn't a problem in Icon _or_ Prolog. I've identified "figuring out what the output structure is" as a problem. The script compiler I wrote for the French Social Security Administration was written in a day and a half, and produced the most beautifully complete and detailed listings (cross references, formatted symbol tables, error summaries, and even a listing table of contents) you ever saw. It would have taken at least six months to write the same thing in C/C++, and maybe not a whole lot less to have written it in Prolog. Can you give any *reason* why it would have been hard in Prolog? > Writing the output is the tricky part. The real hassle is finding out what the wretched output is supposed to look like. I claim that THAT is only part of the hassle too. My point is that it is a *major* hassle, given the state of the documentation, and that it is a *language-independent* hassle. But hey, as I said, I've got better things to do than to go through a detailed point-by-point argument with you if you really want to do it in Prolog This is an Icon mailing list, and "what language features help or hinder for this kind of task" is *exactly* what this thread is about. Surely you have better things to do than hurling around unjustified (and unjustifiable) insults against other programming languages. Shouldn't explaining *how* Icon helped you so much be one of them? > For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write a new kind of assembler would be mad not to re-use as much of the GNU binutils as practical. By all means put a smart new front end on an assembler, but let someone else deal with the *real* hassle. Well, I guess it depends on whether you want an assembler that works like everyone else's or not. (Buf if you're happy with existing ones, why write a new one at all?) This is a rather strange comment. The original question came from someone who wanted to do a new kind of analysis of the input. Nothing was said about wanting to produce incompatible binary object files. If it is to be useful, presumably that person *does* want an assembler whose *output* conforms to the same interface requirements as everyone else's. From icon-group-sender Mon Jul 10 08:03:12 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20479 for icon-group-addresses; Mon, 10 Jul 2000 08:02:58 -0700 (MST) Message-Id: <200007101502.IAA20479@baskerville.CS.Arizona.EDU> Date: Mon, 10 Jul 2000 16:57:02 +1200 (NZST) From: "Richard A. O'Keefe" To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 941 > And then there is another matter: The instructions must be provided to the processor (Pentium) in the optimal sequence, making sure the pipelines are full at all times (as far as possible). That was more of an issue in the days when there was one overwhelmingly dominant microprocessor out there. But there is a role for processor-model-specific scheduling. This is where an assembler-source to assembler-source front end in a compact high level form, relatively easy to plug new model-specific information into, could really pay off. It's not really practical for someone to write 10 different highly-tuned versions of a piece of assembly code, but it _might_ be practical for them to write one clean generic piece and let the front end adapt it. It would even be practical, in such a system, to plug in advice that is specific to the file being assembled. Just think of the variation there is in graphics support opcodes. From icon-group-sender Mon Jul 10 13:31:34 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA04115 for icon-group-addresses; Mon, 10 Jul 2000 13:31:03 -0700 (MST) Message-Id: <200007102031.NAA04115@baskerville.CS.Arizona.EDU> To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU, "Richard A. O'Keefe" From: "Alexandre E. Kopilovitch" Date: Mon, 10 Jul 2000 20:22:36 +0400 (MSD) Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 1574 "Richard A. O'Keefe" wrote: >Seriously, the two big differences between Icon and Prolog here are > - Icon has assignment statements, Prolog doesn't. > - Icon looks a lot like C, Prolog doesn't. > > It's the other areas surrounding the project where the real > benefits show up. Icon vs. Prolog: 1. Notation matters. Suppose that you have to show your Icon program to another person that have no slightest idea about the Icon and Snobol. Surely you will have serious difficulties trying to explain Icon syntax to a novice. At the same time, in a similar situation with a Prolog program you will feel yourself much better (if you were restricting yourself to the "pure Prolog", i.e. if you did not use "clever" built-in predicates). 2. Lie backfires. The Prolog predicates generally aren't the predicates in the mathematical sense -- in fact, they produce not simply sets, but the ordered sets, and a Prolog program often depends heavily on that ordering. On the contrary, Icon use the proper name - the generators. So, Prolog tries to hide the true nature of its major entity, while Icon exhibits it in its full power. 3. Conclusion. If your program deals mostly with a "static" structures, i.e. unordered sets, then Prolog has evident advantages, especially for reviewing and maintenance. If your program is heavily "dynamic", i.e. deals with the ordered sets, then Icon may have significant advantages, especially if the complicated ordering are needed. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia From icon-group-sender Mon Jul 10 16:23:54 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA09634 for icon-group-addresses; Mon, 10 Jul 2000 16:23:26 -0700 (MST) Message-Id: <200007102323.QAA09634@baskerville.CS.Arizona.EDU> Date: Mon, 10 Jul 2000 18:29:48 -0400 (EDT) From: Taybin Rutkin To: icon-group@optima.CS.Arizona.EDU Subject: Re: Error messages Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 870 On Mon, 10 Jul 2000, Alexandre E. Kopilovitch wrote: > "Richard A. O'Keefe" wrote: > 1. Notation matters. > > Suppose that you have to show your Icon program to another person that have > no slightest idea about the Icon and Snobol. Surely you will have serious I think that the paradigm shift from procedural to logical is made easier with Icon. The syntax is (and here I'm assuming that you mean operaters and keywords and their respective order) much more familiar than prolog. I found prolog to be this bizarre alien creature. It was really out of my world. If by syntax you mean the operators, then the learning curve is slightly lower than, say, PERL. Well, maybe not that high. But there are many many operators. Taybin Rutkin -- trutkin@black.clarku.edu Creativity can only be anarchic, capitalist, Darwinian -- Umberto Eco From icon-group-sender Wed Jul 12 16:28:16 2000 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26521 for icon-group-addresses; Wed, 12 Jul 2000 16:26:12 -0700 (MST) Message-Id: <200007122326.QAA26521@baskerville.CS.Arizona.EDU> From: "F.G. van DORP" X-Newsgroups: comp.lang.icon Subject: Re: Error messages X-Newsreader: Forte Agent 1.7/32.534 Date: Wed, 12 Jul 2000 20:00:41 GMT X-Complaints-To: abuse@chello.nl X-Trace: flipper 963432041 212.187.67.243 (Wed, 12 Jul 2000 22:00:41 MET DST) To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Content-Length: 2695 On 10 Jul 2000 19:25:27 -0400, Taybin Rutkin wrote: >On Mon, 10 Jul 2000, Alexandre E. Kopilovitch wrote: > >> "Richard A. O'Keefe" wrote: > >> 1. Notation matters. >> >> Suppose that you have to show your Icon program to another person that have >> no slightest idea about the Icon and Snobol. Surely you will have serious > >I think that the paradigm shift from procedural to logical is made easier >with Icon. The syntax is (and here I'm assuming that you mean operaters >and keywords and their respective order) much more familiar than >prolog. I found prolog to be this bizarre alien creature. It was really >out of my world... > >Taybin Rutkin -- trutkin@black.clarku.edu Actually Prolog is much more similar to Icon than one would suspect: PROLOG pred1(P1,P2,P3,R1) :- pred2(P1,P2,R2), pred3(P3,R2,R1). ICON procedure pred1(P1,P2,P3) return (R2:=pred2(P1,P2) & R1:=pred3(P3,R2)) end This Icon return-expression is a backtracking context and known as "mutual evaluation" or a "compound conjunction" (and *NOT* a "compound expression" as I erroneously wrote in one of my previous postings. Quite the contrary: such expressions, seperated from each other by semicolons (sometimes implicated, see manual), will not get resumed if the next in line fails. So the semicolon acts as a "fence" to backtracking). The difference between Icon and Prolog lies in the nature of the procedure/predicate parameters (the P's; R's are the return values). In Icon these must have a value other than the default NULL value or else an error message will be generated. In Prolog a parameter variable can have a value when passed or not, the so-called "logical variable". An example: addlist(List1,List2,Newlist) If List1 and List2 have values when addlist is called, Newlist returns the sum of List1 and List2. When called with Newlist and either List1 or List2 with values, addlist returns the difference list. When called with only Newlist valued, addlist can generate (through backtracking) all sublist pairs of Newlist. There are functional languages with the power of the logical variable, implemented through a mechanism called "narrowing" (similar to Prolog's unification). One such language is CURRY http://www.informatik.uni-kiel.de/~curry/ I doubt if this behavior could be coded in Icon, or even added to its implementation, should one wish to do so. Another way is to add a Prolog engine to your program with an interface to your Icon code, as mr.LaPalme (lapalme@IRO.UMontreal.CA) managed to do a while back (see Icon archives). =====================================================