Menu
▾
▴
unicon-group
|
From: Dennis D. <den...@ya...> - 2006-08-28 05:45:47
|
Brainstorm.txt by dennis darland started 8/21/06 for dbcodegen2 basic operations ..add ..update ..delete add exceptions ..record with key already exists ....really duplicate(remove all except 1) ....really different update exceptions ..update key(copy - delete - add) ..two or more records from 1(divorce) ..2 or more records with same key(same name) ..record not found delete exceptions ..record not found ..multiple records with key |
|
From: Lu S. <so...@bj...> - 2006-08-30 02:55:09
|
RGVhciBFdmVyeW9uZSwNCg0KSSBmb3VuZCBvbmUgcGhlbm9tZW5vbiBpbiBVbmNpb24uDQoNClRo ZSBwYXRoIG9mIHRoZSBjb2RlIGlzICJEOlxWYW5mdXR1cmVcUitEIC0g56CU5Y+RXFByb2plY3Rz X+mhueebrlxkIOWKqOaEn+S4lueVjFxkZXZlbG9wbWVudC3lvIDlj5FccGVyc29uYWxJbmZvXG15 U1FMLXJlbGVhc2VcQ29sbGVjdG9yQW5hbHlzZVx3b21hbiINClRoZXJlIGFyZSBzb21lIENoaW5l c2UgQ2hhcmFjdGVycyBpbiBwYXRobmFtZS4NCg0KQW5kIHRoZSBuYW1lIG9mIHRoZSBjb2RlIGlz ICJkZV9nZXRpbmZvX2RiX3JlYWx0aW1lX2JhYnlfcWFfYmFieXNjaG9vbF8xLjAuaWNuIg0KDQpU aGUgc3RlcCBvZiBDb21waWxlIGFuZCBMaW5rIGlzIHJpZ2h0Lg0KQnV0IHdoZW4gdGhlIGNvZGUg LmV4ZSBpcyBzdGFydGVkLCAgT1Mgd291bGQgc2hvdyB0aGF0IHRoZXJlIGlzIGVycm9yIHRvIGNs b3NlIHRoZSBwcm9ibGVtLg0KDQpXaGVuIHRoZSBmaWxlbmFtZSBpcyBjaGFuZ2VkIHRvICJkZWJ1 Zy5pY24iLCBldmVyeXRoaW5nIGlzIE9LLg0KQW5kIHdoZW4gdGhlIHBhdGhuYW1lIGlzICJkOlx0 ZW1wXCIsIGV2ZXJ5dGhpbmcgaXMgYWxzbyBPSy4NCg0KU28gSSBndWVzcyB0aGUgbGVudGggb2Yg dGhlIHBhdGgrZmlsZW5hbWUgaXMgdGhlIGtleSBvbiB0aGlzIHBoZW5vbWVub24uDQoNCklzIHRo ZXJlIHNvbWUgc2V0dGluZ3MgdGhhdCBjb3VsZCBleHBhbmQgdGhlIGxlbnRoIGxpbWl0cz8NCg0K DQpMVQ0KDQoNCg0K |
|
From: Clint J. <je...@cs...> - 2006-08-30 05:01:10
|
[Lu Song asks about executing from pathnames with chinese characters, and whether Unicon can execute code it reads in from an input file.] Dear Lu Song, Unicon's system() function and its relatives seem to have a bug executing programs with spaces in the path. Also, the Unicon VM does not know much about multi-byte or variable-width character sets. Depending on the chinese characters' encoding this might cause failure. I am interested in improving Unicon's support for such character sets, but it won't happen unless some volunteers or sponsors step forward. The question of whether Unicon can execute data as code is also interesting. Lisp has an "eval" function that treats data as code, and this is a frequently requested feature. As far as I know, simple subsets of eval() functionality have been developed for the Icon Program Library, but no one has sat down and attempted to write a complete eval() in Unicon or add one to the runtime library. Some features written for the monitoring facilities could make an eval() written in Unicon more capable than what was possible in standard Icon, and someday the load() function may be extended to support an efficient eval() capability. But at the moment a full-fledged "eval" function is not available. Examples of Unicon features that make an eval() subset written in Unicon more flexible than what was done earlier for Icon: variable(s) : produce the variable whose string name is s constructor(recname, fields...) : produce a record constructor The part that is not easy about writing eval() is to actually generate VM bytecode from the strings of source text. For simple expressions one could write an interpreter, but for a full-fledged eval(), more is needed, such as the ability to define new procedures. The load() function can almost help with this, but not quite. Clint je...@cs... |
|
From: lusong <so...@bj...> - 2006-09-30 13:18:07
|
Hi Everyone, Recently read some articles about ruby, python and java. One of them is named "ruby beyond java". They are very interesting. On google, I searched=20 "ruby programming"(21,400,000 pages)=20 "python programming"(36,400,000 pages) "java programming"(85,600,000 pages) "icon programming"(26,900,000 pages)=20 "unicon programming"(84,200 pages) . Then I touched ruby deeply. One or two features of ruby are better than Icon/Unicon, such as multithread. But I confirm Icon/Unicon is better = than ruby and python carefully. Why is Icon/Unicon not popular from its start to now? Icon/Unicon is excellent, they should be have a better position in programming = language. I learned that depending on ruby on rails, ruby is more popular now.=20 So I think maybe we should make at least a killer application in = Icon/Unicon to promote Icon/Unicon. If that killer app.(s) is available for = Internet, it is the best method. Lu Song -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: uni...@li... [mailto:uni...@li...] =B4=FA=B1=ED Clint = Jeffery =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C230=C8=D5 13:01 =CA=D5=BC=FE=C8=CB: so...@bj... =B3=AD=CB=CD: uni...@li... =D6=F7=CC=E2: Re: [Unicon-group] long path and code name [Lu Song asks about executing from pathnames with chinese characters, and whether Unicon can execute code it reads in from an input file.] Dear Lu Song, Unicon's system() function and its relatives seem to have a bug executing programs with spaces in the path. Also, the Unicon VM does not know much about multi-byte or variable-width character sets. Depending on the chinese characters' encoding this might cause failure. I am interested in improving Unicon's support for such character sets, but it won't happen unless some volunteers or sponsors step forward. The question of whether Unicon can execute data as code is also = interesting. Lisp has an "eval" function that treats data as code, and this is a frequently requested feature. As far as I know, simple subsets of = eval() functionality have been developed for the Icon Program Library, but no one has sat down and attempted to write a complete eval() in Unicon or add one to the runtime library. Some features written for the = monitoring facilities could make an eval() written in Unicon more capable than what was possible in standard Icon, and someday the load() function may be extended to support an efficient eval() capability. But at the moment a full-fledged "eval" function is not available. Examples of Unicon features that make an eval() subset written in Unicon more flexible than what was done earlier for Icon: variable(s) : produce the variable whose string name is s constructor(recname, fields...) : produce a record constructor The part that is not easy about writing eval() is to actually generate VM bytecode from the strings of source text. For simple expressions one could write an interpreter, but for a full-fledged eval(), more is needed, such as the ability to define new procedures. The load() function can almost help with this, but not quite. Clint je...@cs... -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Unicon-group mailing list Uni...@li... https://lists.sourceforge.net/lists/listinfo/unicon-group |
|
From: <Bar...@ch...> - 2006-09-30 20:55:41
|
lusong <so...@bj...> skribis: > Then I touched ruby deeply. One or two features of ruby are better than > Icon/Unicon, such as multithread. But I confirm Icon/Unicon is better than > ruby and python carefully. >=20 > Why is Icon/Unicon not popular from its start to now? Icon/Unicon is > excellent, they should be have a better position in programming language. I imagine it is mainly because Arizona Icon never tried to be usable as an all-purpose scripting language for Unix/BSD/GNU, and so Unicon had no following to inherit. Another reason could be that goal-directed evaluation is very unusual. I myself learned about Icon through noweb, which I don=E2=80=99t use anymor= e, and Icon is only optional for noweb. --=20 Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) |
|
From: Sudarshan G. <sud...@ac...> - 2006-10-04 03:13:37
|
I am interested in finding how many people use Unicon in production. Let us loosely define production as any piece of code that you are emotionally attached to ;-). If you are using Unicon why have you not switched to a "more popular" language ? What are the features that you would want Unicon to borrow from the more popular languages? I am hoping that this conversation might lead us to the real strengths of Unicon as well as the future directions this language should take. In my personel experience I worked on the Unicon compiler while at NMSU. However I was never really able to pick up Unicon or really gork goal directed evaluation. I guess one of the reasons is I have only been exposed to pseudo C languages (C, C++, C#, Java). The other is I did not work on a project that would have me reading and modifying a large body of Unicon code. I guess most of the languages program in I am comfortable with a subset of the language features and tend to stay within my comfort zone. What ever little Unicon I wrote was primarly using features that agree with C. regards Sudarshan On 9/30/06, Bar...@ch... < Bar...@ch...> wrote: > > lusong <so...@bj...> skribis: > > Then I touched ruby deeply. One or two features of ruby are better than > > Icon/Unicon, such as multithread. But I confirm Icon/Unicon is better > than > > ruby and python carefully. > > > > Why is Icon/Unicon not popular from its start to now? Icon/Unicon is > > excellent, they should be have a better position in programming > language. > > I imagine it is mainly because Arizona Icon never tried to be usable > as an all-purpose scripting language for Unix/BSD/GNU, and so Unicon > had no following to inherit. Another reason could be that > goal-directed evaluation is very unusual. > > I myself learned about Icon through noweb, which I don't use anymore, > and Icon is only optional for noweb. > > -- > Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org > Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) > 'Democracies don't war; democracies are peaceful countries.' - Bush > (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > Unicon-group mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-group > > > > -- Sudarshan Gaikaiwari www.sudarshan.org sud...@ac... |
|
From: Eleanor <el...@go...> - 2006-10-06 14:32:41
|
On 1 Oct 2006, at 03:39, Sudarshan Gaikaiwari wrote: > I am interested in finding how many people use Unicon in production. > Let us loosely define production as any piece of code that you are > emotionally attached to ;-). Well I have a couple of live CGI scripts on my personal website, although I never got around to finishing them off. Too many other pressing things... > If you are using Unicon why have you not switched to a "more > popular" language ? > What are the features that you would want Unicon to borrow from the > more popular languages? I'd really like the object model to be a bit more like that of Ruby, which is incredibly flexible. I do a lot of work in Ruby because it's fun and growing in commercial acceptance, it's also the closest I've come to the buzz when I first learnt Icon (way back in 1989 - how little most of the software world has progressed since then). Threading would also be nice. I even looked into adding this myself a few years back but I really hate messing in the Icon internals. That of course brings me to the biggest change - a new runtime implementation that was easier to hack around with. Of course that's a serious project to contemplate... > I am hoping that this conversation might lead us to the real > strengths of Unicon as well as the future directions this language > should take. > > In my personel experience I worked on the Unicon compiler while at > NMSU. However I was never really able to pick up Unicon or really > gork goal directed evaluation. I guess one of the reasons is I have > only been exposed to pseudo C languages (C, C++, C#, Java). I think it's hard for anyone with preconceptions about software design to pick up Icon/Unicon which might explain why so many of the people who show an interest in it are either language designers or people with non-computing backgrounds. Ellie Eleanor McHugh -- http://eleanor.goth-chic.org/ http://feyeleanor.livejournal.com/ |
|
From: Steve W. <swa...@no...> - 2006-10-06 14:51:54
|
Eleanor wrote:
> Threading would also be nice. I even looked into adding this myself a
> few years back but I really hate messing in the Icon internals. That
> of course brings me to the biggest change - a new runtime
> implementation that was easier to hack around with. Of course that's
> a serious project to contemplate...
I agree! This would be nice. Every so often I think that I'd like to
get back into working on some implementation issues, but the current
code hurts my brain. I understand the motivations behind the
current solution, but that doesn't keep my brain from hurting.
(I also agree that such a redesign would be, uh, non-trivial.)
Some form of threading ('live co-expressions', perhaps?) would be
wonderful. I'd like to see it designed right, however, and not just
another "let's throw POSIX threads in" solution. It would be fun
to talk about possible approaches and what would fit well in Unicon.
--
Steve Wampler -- swa...@no...
The gods that smiled on your birth are now laughing out loud.
|
|
From: Clint J. <je...@cs...> - 2006-10-06 09:09:46
|
Sudarshan, Some may find it comical that I am willing to work with students on Unicon without bothering to "convert" them into believers first. Ralph Griswold worked with many students on Icon who didn't see the light, so this is not unprecedented. If you don't have time to "get it" by reading enough Icon documents or writing enough Icon code, I doubt that you will "get it" by hearing a few positive testimonials, if you even get any. I collect positive testimonials, by the way, so if you get any posted privately you might ask their author(s) if you can forward them to me for public display. I myself saw the light when I took a comparative languages course and wrote a mini LISP interpreter in Icon in less than a week. Far far easier than doing it in a C-like language. You have no idea. You already know about some production uses of Unicon, which include NLM's SSEUS database peer review management system, and the collaborative virtual environment. The former might just be saving the government over $1 million per year in maintenance over the Visual Basic system that it replaced, and the latter is still under construction but hopefully will turn out to be a Killer App for Unicon. In any case it has stretched the Icon family of languages into new territory, which is Fun. Anyhow, I hope you get positive testimonials but I am skeptical that your skeptical inquiry will produce whatever it would take to cause you to open your mind. That can only be done by taking the time to write some programs in Icon or Unicon and/or reading others' programs (there are lots and lots available, I still encounter amazing new idioms in this language that others have invented on the fly while coding their apps). Cheers, Clint |
|
From: Eleanor <el...@go...> - 2006-10-06 14:53:17
|
On 6 Oct 2006, at 10:09, Clint Jeffery wrote: > I myself saw the light when I took a comparative languages course > and wrote > a mini LISP interpreter in Icon in less than a week. Far far > easier than > doing it in a C-like language. You have no idea. I used Icon to rewrite the examples from "Programming Languages: An Interpreter-Based Approach" by Samuel N. Kamin. At the time I was also playing with Pop-11 (much to my tutor's irritation - none of this was part of my undergrad physics curriculum...) and I couldn't get over how easy it is to write parsers with Icon's scanning and goal direction features. It's made me very dismissive of Lisp ever since lol > You already know about some production uses of Unicon, which > include NLM's > SSEUS database peer review management system, and the collaborative > virtual > environment. The former might just be saving the government over > $1 million > per year in maintenance over the Visual Basic system that it > replaced, and > the latter is still under construction but hopefully will turn out > to be a > Killer App for Unicon. In any case it has stretched the Icon > family of > languages into new territory, which is Fun. I'm interested that you've replaced a VB system with an Unicon one as I spent years writing VB5 code that relied heavily on several Icon- like idioms - especially success/failure and generators. A lot of the work I was doing then involved VB in the embedded avionics space and for system-level coding, and those idioms made delivering reliable code much easier than with the third-party certified C libraries most people relied upon. I just wish I could have been working in Icon/ Unicon in the first place... Ellie Eleanor McHugh -- http://eleanor.goth-chic.org/ http://feyeleanor.livejournal.com/ |
|
From: Eleanor <el...@go...> - 2006-10-06 15:05:36
|
On 6 Oct 2006, at 15:51, Steve Wampler wrote:
> I agree! This would be nice. Every so often I think that I'd like to
> get back into working on some implementation issues, but the current
> code hurts my brain. I understand the motivations behind the
> current solution, but that doesn't keep my brain from hurting.
> (I also agree that such a redesign would be, uh, non-trivial.)
Yes, I tried getting into the JCon code during one of my brief
infatuations with Java, but that was just as bad.
Another idea that might be fun (but not even vaguely justifiable)
would be to implement Icon as a DSL in Ruby, and then build Unicon on
top of that. I find the idea of running up an Unicon application
inside Rails sick enough to be appealing >8D
> Some form of threading ('live co-expressions', perhaps?) would be
> wonderful. I'd like to see it designed right, however, and not just
> another "let's throw POSIX threads in" solution. It would be fun
> to talk about possible approaches and what would fit well in Unicon.
That's the biggest problem - how to do it naturally. I don't really
like the threading models most languages use anyway, as they're too
concerned with flow of control and not enough with generation of
expressions - perhaps the best approach would be to extend the
monitoring/profiling extensions in some way although I've not played
with them enough to be certain. Or else some kind of parallel
generator which kicks out more than one result at the same time but
thinking about that's making my brain feel weird.
Ellie
Eleanor McHugh
--
http://eleanor.goth-chic.org/
http://feyeleanor.livejournal.com/
|
|
From: Kent P. <pa...@ex...> - 2007-03-08 17:30:32
|
I just saw this thread and I thought I would put my two cents in. I use Unicon for searching large texts and reformatting them occasionally. When it comes to text manipulation no other language is better than the Unicon/Icon/Snobol family. But I think Ruby is popular because its syntax is elegant, because it is entirely object oriented, like small talk, because it is a scripting language like that, and because it has some text processing features built in like some of the other scripting languages. I would like to see some marriage between Ruby and Unicon. The idea of making Unicon a DSL on top of Ruby would be very appealing to me. But I don't know what that would do for performance. Both Icon and Ruby have C interfaces. Perhaps there is some way to marry them via their interfaces. Is that possible? I talked to Clint about XML and Unicon several years ago. It seems to me the advent of XML was a lost opportunity for Unicon. Unicon is obviously the best way to deal with XML, but somehow no one recognized this fact in the larger world. Now I think Ruby has displaced any possibility for Unicon to become popular because it has enough text processing power to make it a good candidate for that use, plus it has all the other features that makes it desirable for programmers who believe in object oriented programming. I think the object model in Unicon, just like the functional model in Icon, something added on to the original language idea in Snobol The problem is that there are interference between these ideas and the basic idea of Snobol. What was needed was a rethinking of the way that the functional and object models relate to the fundamental concept of snobol, and the production of an elegent language that promoted all these various programming ideas without their interfering with each other. When I write Unicon programs I don't use either the functional or the object ideas, but rather use the string searching directly, i.e. I use the Snobol Core of the language. It is usually very small programs I am writing to get at some aspect of the text I am processing that I cannot get to in any other way. This sting searching core, which goes beyond what is available in other languages is precisely what is needed for XML applications or anything that has to do with complex string searching within texts or parsing. If that was made available in RUBY then that would be excellent. I don't think the folks who are into Ruby know that there is more to string searching than what they have currently. I would really have liked to see Unicon in the position that Ruby is in now, but with the advent of Ruby there is no chance of that. Ruby has one of the most sophisticated and elegant syntaxes of any programming language to date. That is why people like it so much. The Uncon syntax is not that elegant, and so despite its power for parsing and text manipulation, it cannot have wide appeal. It's power is too specialized. And everything else it does is just like other languages. Ruby on the other hand sets itself apart from other languages by it over all sophistication and elegance of syntax in every aspect of the language. Anyway this is my two cents on this subject. Sorry it took me so long to see this thread and respond to it. Kent Palmer ke...@pa... http://think.net At 07:05 AM 10/6/2006, you wrote: >On 6 Oct 2006, at 15:51, Steve Wampler wrote: > > I agree! This would be nice. Every so often I think that I'd like to > > get back into working on some implementation issues, but the current > > code hurts my brain. I understand the motivations behind the > > current solution, but that doesn't keep my brain from hurting. > > (I also agree that such a redesign would be, uh, non-trivial.) > >Yes, I tried getting into the JCon code during one of my brief >infatuations with Java, but that was just as bad. >Another idea that might be fun (but not even vaguely justifiable) >would be to implement Icon as a DSL in Ruby, and then build Unicon on >top of that. I find the idea of running up an Unicon application >inside Rails sick enough to be appealing >8D > > > Some form of threading ('live co-expressions', perhaps?) would be > > wonderful. I'd like to see it designed right, however, and not just > > another "let's throw POSIX threads in" solution. It would be fun > > to talk about possible approaches and what would fit well in Unicon. > >That's the biggest problem - how to do it naturally. I don't really >like the threading models most languages use anyway, as they're too >concerned with flow of control and not enough with generation of >expressions - perhaps the best approach would be to extend the >monitoring/profiling extensions in some way although I've not played >with them enough to be certain. Or else some kind of parallel >generator which kicks out more than one result at the same time but >thinking about that's making my brain feel weird. > >Ellie > > >Eleanor McHugh >-- >http://eleanor.goth-chic.org/ >http://feyeleanor.livejournal.com/ > > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Unicon-group mailing list >Uni...@li... >https://lists.sourceforge.net/lists/listinfo/unicon-group |
|
From: Eleanor <el...@go...> - 2007-03-09 01:20:11
|
On 8 Mar 2007, at 17:29, Kent Palmer wrote: > I would like to see some marriage between Ruby and Unicon. > > The idea of making Unicon a DSL on top of Ruby would be very > appealing to me. But I don't know what that would do for performance. > > Both Icon and Ruby have C interfaces. Perhaps there is some way to > marry them via their interfaces. Is that possible? Well I must admit to being a bit of a Rubyista these days, mainly thanks to the elegant syntax and the ease of meta-programming. It's not a better language than Un/icon, and where string handling is concerned I find Regular Expressions the most infuriating alternative to a decent scanning environment, but as mainstream languages go it's by far the most enjoyable to work with. It's also a dream for network coding or anything where native bindings are useful. To my way of thinking it's Lisp for those of us who like syntax ;) A couple of times I've considered the possibility of an Iconish DSL for Ruby or a Ruby translator for the Unicon runtime, but these are both substantial projects. There are implementations of generators and scanning environments for Ruby but they don't fit as well as they do in Icon, but more frustrating is the lack of goal direction. That's what hooked me on Icon back in the v5 days, and the addition of this has been discussed several times in the Ruby community but it's a hard feature to sell to people who've never used it. It's disappointing that the two great language loves of my life are basically incompatible at this point in time :( Ellie Eleanor McHugh Games With Brains ---- raise ArgumentError unless @reality.responds_to? :reason |
|
From: Kent P. <thi...@ex...> - 2007-03-09 07:32:31
|
Eleanor--- I have just been looking at ANTLR parser generator. Too bad there is no Ruby interface for that, it might be a way to integrate Icon like features. Kent At 05:20 PM 3/8/2007, you wrote: >On 8 Mar 2007, at 17:29, Kent Palmer wrote: > > I would like to see some marriage between Ruby and Unicon. > > > > The idea of making Unicon a DSL on top of Ruby would be very > > appealing to me. But I don't know what that would do for performance. > > > > Both Icon and Ruby have C interfaces. Perhaps there is some way to > > marry them via their interfaces. Is that possible? > >Well I must admit to being a bit of a Rubyista these days, mainly >thanks to the elegant syntax and the ease of meta-programming. It's >not a better language than Un/icon, and where string handling is >concerned I find Regular Expressions the most infuriating alternative >to a decent scanning environment, but as mainstream languages go it's >by far the most enjoyable to work with. It's also a dream for network >coding or anything where native bindings are useful. To my way of >thinking it's Lisp for those of us who like syntax ;) > >A couple of times I've considered the possibility of an Iconish DSL >for Ruby or a Ruby translator for the Unicon runtime, but these are >both substantial projects. There are implementations of generators >and scanning environments for Ruby but they don't fit as well as they >do in Icon, but more frustrating is the lack of goal direction. >That's what hooked me on Icon back in the v5 days, and the addition >of this has been discussed several times in the Ruby community but >it's a hard feature to sell to people who've never used it. > >It's disappointing that the two great language loves of my life are >basically incompatible at this point in time :( > > >Ellie > >Eleanor McHugh >Games With Brains >---- >raise ArgumentError unless @reality.responds_to? :reason > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Unicon-group mailing list >Uni...@li... >https://lists.sourceforge.net/lists/listinfo/unicon-group |
|
From: bryan r. <ras...@gm...> - 2007-03-09 10:15:49
|
Hi, I'm a newbie with Unicon, I basically decided to start with it because, well I like learning new languages especially ones with an easily perceived niche. I think the niche of Unicon as you say is text processing. I use XML a lot in my day to day, I'm not sure I understand the assertion that Unicon would be great for XML, since the main thing one needs for XML programming is easy tree manipulation, such as is provided with XSL-T. I'm hoping you can give me a description of what would make Unicon so great for XML and some examples (or relevant links) since I figure this might help me learn Unicon quicker, being able to relate it to an area in which I have especial expertise. Cheers, Bryan Rasmussen On 3/8/07, Kent Palmer <pa...@ex...> wrote: > I just saw this thread and I thought I would put my two cents in. > > I use Unicon for searching large texts and reformatting them occasionally. > > When it comes to text manipulation no other language is better than > the Unicon/Icon/Snobol family. > > But I think Ruby is popular because its syntax is elegant, because it > is entirely object oriented, like small talk, because it is a > scripting language like that, and because it has some text processing > features built in like some of the other scripting languages. > > I would like to see some marriage between Ruby and Unicon. > > The idea of making Unicon a DSL on top of Ruby would be very > appealing to me. But I don't know what that would do for performance. > > Both Icon and Ruby have C interfaces. Perhaps there is some way to > marry them via their interfaces. Is that possible? > > I talked to Clint about XML and Unicon several years ago. It seems to > me the advent of XML was a lost opportunity for Unicon. > > Unicon is obviously the best way to deal with XML, but somehow no one > recognized this fact in the larger world. > > Now I think Ruby has displaced any possibility for Unicon to become > popular because it has enough text processing power to make it a good > candidate for that use, plus it has all the other features that makes > it desirable for programmers who believe in object oriented programming. > > I think the object model in Unicon, just like the functional model in > Icon, something added on to the original language idea in Snobol > > The problem is that there are interference between these ideas and > the basic idea of Snobol. > > What was needed was a rethinking of the way that the functional and > object models relate to the fundamental concept of snobol, and the > production of an elegent language that promoted all these various > programming ideas without their interfering with each other. > > When I write Unicon programs I don't use either the functional or the > object ideas, but rather use the string searching directly, i.e. I > use the Snobol Core of the language. It is usually very small > programs I am writing to get at some aspect of the text I am > processing that I cannot get to in any other way. > > This sting searching core, which goes beyond what is available in > other languages is precisely what is needed for XML applications or > anything that has to do with complex string searching within texts or parsing. > > If that was made available in RUBY then that would be excellent. I > don't think the folks who are into Ruby know that there is more to > string searching than what they have currently. > > I would really have liked to see Unicon in the position that Ruby is > in now, but with the advent of Ruby there is no chance of that. Ruby > has one of the most sophisticated and elegant syntaxes of any > programming language to date. That is why people like it so much. > > The Uncon syntax is not that elegant, and so despite its power for > parsing and text manipulation, it cannot have wide appeal. It's power > is too specialized. And everything else it does is just like other languages. > > Ruby on the other hand sets itself apart from other languages by it > over all sophistication and elegance of syntax in every aspect of the language. > > Anyway this is my two cents on this subject. Sorry it took me so long > to see this thread and respond to it. > > Kent Palmer > ke...@pa... > http://think.net > > > > > > > At 07:05 AM 10/6/2006, you wrote: > >On 6 Oct 2006, at 15:51, Steve Wampler wrote: > > > I agree! This would be nice. Every so often I think that I'd like to > > > get back into working on some implementation issues, but the current > > > code hurts my brain. I understand the motivations behind the > > > current solution, but that doesn't keep my brain from hurting. > > > (I also agree that such a redesign would be, uh, non-trivial.) > > > >Yes, I tried getting into the JCon code during one of my brief > >infatuations with Java, but that was just as bad. > >Another idea that might be fun (but not even vaguely justifiable) > >would be to implement Icon as a DSL in Ruby, and then build Unicon on > >top of that. I find the idea of running up an Unicon application > >inside Rails sick enough to be appealing >8D > > > > > Some form of threading ('live co-expressions', perhaps?) would be > > > wonderful. I'd like to see it designed right, however, and not just > > > another "let's throw POSIX threads in" solution. It would be fun > > > to talk about possible approaches and what would fit well in Unicon. > > > >That's the biggest problem - how to do it naturally. I don't really > >like the threading models most languages use anyway, as they're too > >concerned with flow of control and not enough with generation of > >expressions - perhaps the best approach would be to extend the > >monitoring/profiling extensions in some way although I've not played > >with them enough to be certain. Or else some kind of parallel > >generator which kicks out more than one result at the same time but > >thinking about that's making my brain feel weird. > > > >Ellie > > > > > >Eleanor McHugh > >-- > >http://eleanor.goth-chic.org/ > >http://feyeleanor.livejournal.com/ > > > > > > > >------------------------------------------------------------------------- > >Take Surveys. Earn Cash. Influence the Future of IT > >Join SourceForge.net's Techsay panel and you'll get the chance to share your > >opinions on IT & business topics through brief surveys -- and earn cash > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >_______________________________________________ > >Unicon-group mailing list > >Uni...@li... > >https://lists.sourceforge.net/lists/listinfo/unicon-group > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Unicon-group mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-group > |
|
From: <Bar...@ch...> - 2007-03-09 11:21:49
|
bryan rasmussen <ras...@gm...> wrote: > I'm a newbie with Unicon, I basically decided to start with it > because, well I like learning new languages especially ones with an > easily perceived niche. I think the niche of Unicon as you say is text > processing. >=20 > I use XML a lot in my day to day, I'm not sure I understand the > assertion that Unicon would be great for XML, since the main thing one > needs for XML programming is easy tree manipulation, such as is > provided with XSL-T. There's an XML parser in the uni/xml directory of the CVS. I haven't used it a lot, though it is likely I will be soon. I agree with Kent Palmer that the syntax of Icon/Unicon isn't great, but I'm not sure how much effect that has on popularity, considering that languages with significant syntax difficulties, such as Perl and C++, have been adopted anyway. Personally, my best hypothesis would be that Icon hasn't become more popular mainly because you had to go buy the book, 'The Icon Programming Language', and thus only the most curious people ever tried Icon, for they had to go to some effort and spend money doing it. Perl is an example of a language that became popular in part because you could try it without buying a book, though of course you might buy a book or two later. The copylefted Unicon book as a PDF is a start towards a remedy, but you need more stuff similar to the Perl manpage(s), the GNU info pages, on-line HTML tutorials and documentation, and so forth. --=20 Barry.SCHWARTZ =C4=89e chemoelectric punkto org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) |
Thanks for helping keep SourceForge clean.
X