From bvg@mac.com Wed Jan 2 07:28:01 2002 From: bvg@mac.com (=?ISO-8859-1?Q?Bj=F6rnke_von_Gierke?=) Date: Wed Jan 2 07:28:01 2002 Subject: Introducing myself and 2 questions In-Reply-To: Message-ID: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> > The TunesLearningLounge > (http://tunes.org/cgi-bin/TunesWiki?TunesLearningLounge) > > a good start to understand what tunes is about. but you will need a lot > of patience and opennes. and reading many things several times... i > remember! :) > > 101 Bad thing about that is, that im on a dialup, and its almost impossible to get all that info in an offline archive, as it is scatteret all over the net, including many downloadable archives... well, il just wait till weekend (when I am back on internet) Until then I have some additional sugg/qu-estions: since I registered (29th) until now (2th) there where 3 posts in the main mailinglist. As the others seem to have less activity (Didn't sign up, so it's a guess). Why are there even other mailinglists? It's rather strange to me that comunication is scattered on purpous like this, only for subproject's sake. Diffrent maillists only make sens if theres too much happening for one single list IMHO. Is the whole homepage generated automaticly, or is it updated by hand? Me thinks it's much too clumsy arranged and unintuitiv presentet, maybe for compatibility with CLI-Browsers? Would step in here for a new design/s if other think too that changes are nessecary. Faq is too detailed, shoud only give simple clue about what Tunes is. Rename current FAQ to "Detailed Info over this Project/OS" or similar. Is there already a deccission made what userinterface the first version will use? (I mean that 'run on top of other os' -thingie) Is It CLI, GUI? Or are you targeting directly at voice, gesture, psycokinetic input? Wouldn't it be funny if the logo would be a picture with a tag on it: "This is not a Logo" Are there webrings for alternative/"homebred" OSes? Why /Why not? Well I have to go now, Happy new Year! BvG From fare+NOSPAM@tunes.org Wed Jan 2 12:41:02 2002 From: fare+NOSPAM@tunes.org (Francois-Rene Rideau) Date: Wed Jan 2 12:41:02 2002 Subject: Languages with Macro capability In-Reply-To: References: Message-ID: <87advw8p7o.fsf@Samaris.tunes.org> cubicle584@mailandnews.com (Software Scavenger) writes on comp.lang.lisp, "Re: Macros in Elisp, Xlisp, Scheme, Dylan, etc.": > Which other languages have this capability, of using the full power of > the language in the implementation of each macro, and working with > high level data such as lists and symbols instead of raw source code? Popular languages with the ability to manipulate source-code as high-level structure: * ANSI Common LISP, maybe the first language with macro capability. http://www.lisp.org/ * OCAML can manipulate structured source code with camlp4. http://caml.inria.fr/camlp4/ * Erlang has such capability with parse_transform. http://www.bluetail.com/wiki/showOldPage?node=ParseTransform&index=3 More obscure languages that have compile-time reflection include * Most Scheme dialects include some kind of CL-like defmacro, but no side-effect can be portably relied upon. http://www.schemers.org/ * Squeak, is an open implementation Smalltalk implementation: http://www.squeak.org/ * Maude notably builds its object system on such reflective capabilities. http://maude.csl.sri.com/ * Pliant is built around the concept of an open compiler http://pliant.cx/ * Upper/Mute is an open compiler framework: http://uppermute.org/ * OpenC++ is C++ extended with compile-time reflection http://www.hlla.is.tsukuba.ac.jp/~chiba/openc++.html * OpenJava is Java extended with compile-time reflection http://www.csg.is.titech.ac.jp/~mich/openjava/ * CRML is Compile-time Reflective ML http://www.cse.ogi.edu/~sheard/crml.html * FORTH is a pattern of low-level languages with compile-time reflection (its dialect with most advanced macro capability may be macro4th/thisforth): http://www.forth.org/ This list is certainly not authoritative. I'm sure there are plenty of other systems with some kind of advanced compile-time reflection, whereas some of the latter systems in the list might not allow as full of a high-level reflection as you'd like. If you can send me positive/negative feedback on how to amend this list, it will be most welcome. Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] "I'm not a procrastinator, I'm temporally challenged" From Shaolin@btinternet.com Fri Jan 4 10:20:02 2002 From: Shaolin@btinternet.com (User) Date: Fri Jan 4 10:20:02 2002 Subject: Introducing myself and 2 questions References: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> Message-ID: <000a01c1954b$fe27edc0$3f68fea9@comp2> I think that the logo should be left as it is :) ----- Original Message ----- From: Björnke von Gierke To: Sent: Wednesday, January 02, 2002 3:26 PM Subject: Re: Introducing myself and 2 questions > > The TunesLearningLounge > > (http://tunes.org/cgi-bin/TunesWiki?TunesLearningLounge) > > > > a good start to understand what tunes is about. but you will need a lot > > of patience and opennes. and reading many things several times... i > > remember! :) > > > > 101 > > Bad thing about that is, that im on a dialup, and its almost impossible > to get all that info in an offline archive, as it is scatteret all over > the net, including many downloadable archives... > well, il just wait till weekend (when I am back on internet) > > Until then I have some additional sugg/qu-estions: > > since I registered (29th) until now (2th) there where 3 posts in the > main mailinglist. As the others seem to have less activity (Didn't sign > up, so it's a guess). Why are there even other mailinglists? It's rather > strange to me that comunication is scattered on purpous like this, only > for subproject's sake. > Diffrent maillists only make sens if theres too much happening for one > single list IMHO. > Is the whole homepage generated automaticly, or is it updated by hand? > Me thinks it's much too clumsy arranged and unintuitiv presentet, maybe > for compatibility with CLI-Browsers? Would step in here for a new > design/s if other think too that changes are nessecary. > Faq is too detailed, shoud only give simple clue about what Tunes is. > Rename current FAQ to "Detailed Info over this Project/OS" or similar. > Is there already a deccission made what userinterface the first version > will use? (I mean that 'run on top of other os' -thingie) Is It CLI, > GUI? Or are you targeting directly at voice, gesture, psycokinetic input? > Wouldn't it be funny if the logo would be a picture with a tag on it: > "This is not a Logo" > Are there webrings for alternative/"homebred" OSes? Why /Why not? > > Well I have to go now, Happy new Year! > BvG > From alex.lists@freenet.de Fri Jan 4 11:17:02 2002 From: alex.lists@freenet.de (Alex) Date: Fri Jan 4 11:17:02 2002 Subject: Introducing myself and 2 questions In-Reply-To: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> References: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> Message-ID: <200201041915.g04JFfc08507@hilbert.pci.uni-heidelberg.de> On Wednesday 02 January 2002 16:26, Björnke von Gierke wrote: > Until then I have some additional sugg/qu-estions: > > since I registered (29th) until now (2th) there where 3 posts in the > main mailinglist. As the others seem to have less activity (Didn't sign > up, so it's a guess). Why are there even other mailinglists? It's rather > strange to me that comunication is scattered on purpous like this, only > for subproject's sake. > Diffrent maillists only make sens if theres too much happening for one > single list IMHO. This is what I thought when I came across the Tunes project a couple of weeks ago. The mailing lists really should be merged. Cheers, Alex From beholder@unios.dhs.org Fri Jan 4 21:48:02 2002 From: beholder@unios.dhs.org (Pat Wendorf) Date: Fri Jan 4 21:48:02 2002 Subject: Introducing myself and 2 questions References: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> <200201041915.g04JFfc08507@hilbert.pci.uni-heidelberg.de> Message-ID: <3C3692DD.3060500@unios.dhs.org> Alex wrote: > On Wednesday 02 January 2002 16:26, Björnke von Gierke wrote: > >>Until then I have some additional sugg/qu-estions: >> >>since I registered (29th) until now (2th) there where 3 posts in the >>main mailinglist. As the others seem to have less activity (Didn't sign >>up, so it's a guess). Why are there even other mailinglists? It's rather >>strange to me that comunication is scattered on purpous like this, only >>for subproject's sake. >>Diffrent maillists only make sens if theres too much happening for one >>single list IMHO. >> > > This is what I thought when I came across the Tunes project a couple of weeks > ago. The mailing lists really should be merged. > > Cheers, > > Alex > The variety of mailing lists is a throwback from a (better/older) time when Tunes had many active members, each with a unique idea on how the future of computers was to unfold. There was much discussion on the subject of signal to noise ratio which resulted in splitting some threads of discussion off into their own mailing list. At least this is what I remember, please correct me if I'm wrong (which I am most of the time :) I agree that the current state of Tunes does not warrant multiple mailing lists, frankly I'd love to see a bit more noise in here, hopefully it will produce some "signal". Anyone working on anything interesting at the moment? -- Pat Wendorf From arigo@ulb.ac.be Sat Jan 5 09:45:02 2002 From: arigo@ulb.ac.be (Armin Rigo) Date: Sat Jan 5 09:45:02 2002 Subject: Introducing myself and 2 questions References: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> <200201041915.g04JFfc08507@hilbert.pci.uni-heidelberg.de> <3C3692DD.3060500@unios.dhs.org> Message-ID: <3C372DE2.8600B26C@ulb.ac.be> Hello Pat, Pat Wendorf wrote: > Anyone working on anything interesting at the moment? A quick update on Psyco, the compiler-specializer for Python. Still not quite usable for large projects, but with a few simple things like measuring execution times of various functions and applying Psyco on the most time-consuming ones, I guess we will quickly have interesting results. Besides, I am still trying to merge into my mind my own experience, various things I read, computing models from Faré, and the HLL description page. A long-term project of mine would be to do some work for the HLL. Armin From kyle@arcavia.com Sun Jan 6 00:01:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Sun Jan 6 00:01:02 2002 Subject: Noise References: <289C4C80-FF95-11D5-8D08-003065AD94A4@mac.com> <200201041915.g04JFfc08507@hilbert.pci.uni-heidelberg.de> <3C3692DD.3060500@unios.dhs.org> <3C372DE2.8600B26C@ulb.ac.be> Message-ID: <3C380408.BBC1B1E1@arcavia.com> Someone wanted noise? I have been working on the Database Cruiser (DBC) for quite some time now. The name "DBC" is quite unfortunate because it tries to incorporate many of the Tunes ideas, and therefore is quite far from having anything to do with databases. But let us use the term "DBC" to refer to my project without decomposing it's meaning in literal terms. Anyway, the DBC is an attempt to create a reflective programming environment. My first goal is to build something close to Microsoft Access and Lotus Notes with a sophisticated, multiple language, interface. Once the first goal is achieved I suspect I will be able to work on Tunes aspects directly. How far am I from my first goal? Quite far. Here is a list of what I have done: - Generic object interface (named SITH) - Reflective environment that is a little better than Java. - Functions are objects, so second order functions are easy - Garbage collector (needed for any persistent environment) - A single memory image holds all state information (a bitfield!) - Standard format (called MSM format) for programs that is easily extendable - Compiles the MSM format to *.class files - Debugger, quite bad. What am I working on now? - I have recently converted the standard primitives (ints floats and string) to bitfields (sets of bits of size 2^n). - A graphic system that will be an improve and replace what I have written already. What is to come? - The graphic system is a little interesting, it uses the concept of templates to define new classes of objects using examples. This is much like generics or C++ templates, but more general. I believe Self has a similar concept called prototypes. - Compilers are just sophisticated serialization programs (think of turning a parse tree into machine code). I will be defining language(s) (like lexx or yacc) that will turn program specifications into machine code. This same set of languages should be able to handle all serialization. - Context is always needed to specify a program. The DBC will use bijective specifications to be able to convert between these contexts. I will need to make a bijection language. So what? You can see what I have written here http://www.arcavia.com/rd/dbc-html/index.html I would like appreciate any feedback on the documents I have written. You can download here http://www.arcavia.com/rd/dbc-html/download.html I would not suggest downloading unless you have lots of time on your hands and are willing to understand what the hell I have built. From fare@tunes.org Mon Jan 7 11:01:01 2002 From: fare@tunes.org (Francois-Rene Rideau) Date: Mon Jan 7 11:01:01 2002 Subject: [comp.lang.functional,comp.lang.ml] Postdoctoral Research Associate, "Refactoring Functional Programs" Message-ID: <87d70mhtpc.fsf@Samaris.tunes.org> --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Tunesers, in case one of you could be interested yet missed it, here is a job offer for research on "Refactoring Functional Programs"... [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] Toleration is not about respecting other people's ideas. We have every right to fight ideas we think are stupid. Toleration is about respecting other people's persons. We have every duty to respect even persons we think are stupid. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: "Claus Reinke" Newsgroups: comp.lang.functional,comp.lang.ml Subject: Postdoctoral Research Associate, "Refactoring Functional Programs" Date: 7 Jan 2002 18:16:30 GMT Organization: University of Kent at Canterbury Lines: 27 Approved: comp-lang-ml@cs.cmu.edu Distribution: world Message-ID: Reply-To: "Claus Reinke" NNTP-Posting-Host: nuked.fox.cs.cmu.edu X-Trace: cantaloupe.srv.cs.cmu.edu 1010427390 6891 128.2.181.171 (7 Jan 2002 18:16:30 GMT) X-Complaints-To: postmaster@cs.cmu.edu NNTP-Posting-Date: 7 Jan 2002 18:16:30 GMT Originator: leaf@nuked.fox.cs.cmu.edu Path: norfair.nerim.net!nerim.net!feed.ac-versailles.fr!out.nntp.be!propagator-SanJose!in.nntp.be!nntp-relay.ihug.net!ihug.co.nz!news-hog.berkeley.edu!ucberkeley!newsfeed.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!not-for-mail Xref: norfair.nerim.net comp.lang.functional:4541 comp.lang.ml:447 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Just a quick reminder that the closing date for this position, advertised here earlier, is *this Friday*, 11/01/2002. Happy New Year, Claus --------------------------------------------------------------- Applications are invited for a three year Postdoctoral Research Associate position at the University of Kent at Canterbury, to work under the direction of Professor Simon Thompson and Dr Claus Reinke on an EPSRC funded project entitled "Refactoring Functional Programs". ... Please telephone the Personnel Office for further particulars on 01227 827837 (24 hours) or email: Personnel@ukc.ac.uk , quoting the reference number R02/15. Text phone users please telephone 01227 823674. The closing date is Friday 11 January 2002. Informal enquires can be directed to either Simon or Claus: {S.J.Thompson,C.Reinke}@ukc.ac.uk. More details of the project and further particulars for the position can be found at: http://www.cs.ukc.ac.uk/people/staff/sjt/Refactor/ --=-=-=-- From joe@culturematic.net Mon Jan 7 14:18:03 2002 From: joe@culturematic.net (Joe) Date: Mon Jan 7 14:18:03 2002 Subject: Anyone working on anything interesting...? Message-ID: I just got to take a look at the newly specified Haskell "Core" language (an intermediate representation GHC Haskell compiler uses) Neat low level language, readable to most haskellers, strongly typed. Might be of interest to ya'll low level language folks. It's at http://www.haskell.org/ghc/docs/papers/core.ps.gz (not that I've been working on this myself, but you did say "anyone"... :) joe at culturematic dot net http://www.culturematic.net From mblazevic@omnimark.com Mon Jan 7 14:49:02 2002 From: mblazevic@omnimark.com (Mario Blazevic) Date: Mon Jan 7 14:49:02 2002 Subject: More noise Message-ID: <3C3A264B.30608@omnimark.com> Ok, you asked for it. Here's a paper on a small language of mine called GENS that might have something useful to offer to Tunes. Go to the following URL, the paper starts on the page 97 of the MPOOL 2001 wokshop proceedings: http://www.fz-juelich.de/nic-series/Volume7/Volume7.html The language has some similarities with Arrow, in my opinion. It's based on environments, though, instead of "arrows". An environment is a mapping from labels to expressions, and can be thought of as a set of arrows. It turns out that this one construct can be very expressive. The main thrust of the project (and my master's thesis) was to demonstrate that environments can be used as a multiparadigm programming language, which is out of the scope of Tunes, I believe. But still, I'd like to know if anybody else finds the idea interesting. And I'm especially curious about relationship between arrows and environments. From renaud@aopsys.com Mon Jan 7 21:07:01 2002 From: renaud@aopsys.com (Renaud Pawlak) Date: Mon Jan 7 21:07:01 2002 Subject: An aspect-oriented middleware Message-ID: <3C3A4F80.3010307@aopsys.com> Hi everybody, I guess that many of you have heard about Aspect-Oriented Programming. It allows the programmer to reach better modularity when programming very complex applications where crosscutting concerns inherently exist whithin your code. I think that aspect-oriented features should be furnished by any modern OS or middleware layers. This is why I'd like to notify you for the JAC project that enables dynamic and distributed aspects on Java. If anybody wants to discuss about aspects within the Tunes context, I'd be glad to. --- Renaud, PhD student. emails: pawlak@cnam.fr, renaud@aopsys.com From tunes@tunes.org Tue Jan 8 06:00:02 2002 From: tunes@tunes.org (=?ISO-8859-1?Q?Bj=F6rnke_von_Gierke?=) Date: Tue Jan 8 06:00:02 2002 Subject: (no subject) Message-ID: well, im definitively trying to do some reading, but time is my most restricted resource right now, so sorry for shortness, and the unrefined status of this text, im in hurry! Why cant i just hit reply to answer a mail to the mailing list, is it my app or the server? In future i will add a "reply to: tunes@tunes.org"-header to my mails. does anybody have info on my other questions? theyre here for rereading: Is the whole homepage generated automaticly, or is it updated by hand? Me thinks it's much too clumsy arranged and unintuitiv presentet, maybe for compatibility with CLI-Browsers? Would step in here for a new design/s if other think too that changes are nessecary. Faq is too detailed, shoud only give simple clue about what Tunes is. Rename current FAQ to "Detailed Info over this Project/OS" or similar. Is there already a deccission made what userinterface the first version will use? (I mean that 'run on top of other os' -thingie) Is It CLI, GUI? Or are you targeting directly at voice, gesture, psycokinetic input? Wouldn't it be funny if the logo would be a picture with a tag on it: "This is not a Logo" Are there webrings for alternative/"homebred" OSes? Why /Why not? From Francois-Rene Rideau Tue Jan 8 07:32:01 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Tue Jan 8 07:32:01 2002 Subject: TUNES In-Reply-To: References: Message-ID: <20020108153135.GA3711@hell.mine.nu> Dear Björnke, > From: Björnke von Gierke > Date: Tue, 8 Jan 2002 14:57:21 +0100 > Why cant i just hit reply to answer a mail to the mailing list, is it my > app or the server? As with many mailing-lists, you have to use "Group Reply" to reply to everyone rather than just the originator of the mail. > Is the whole homepage generated automaticly, or is it updated by hand? It's still done by hand at the moment. > Me thinks it's much too clumsy arranged and unintuitiv presentet, maybe > for compatibility with CLI-Browsers? Compatibility with CLI-Browsers is a requirement, although if you're willing to write a system that adds features for other browsers without sacrificing compatibility with lynx, links and w3m, you're most welcome. > Faq is too detailed, shoud only give simple clue about what Tunes is. On the other hand, I don't know how to do without details, or else, the answers might betray the issue and confuse the reader. Maybe have a short answer in larger size and a longer answer in small size, for every question? > Is there already a deccission made what userinterface the first version > will use? (I mean that 'run on top of other os' -thingie) Is It CLI, > GUI? To begin with, we'd just have a listener, that takes strings as input, and evaluates them sequentially. It could be tested with precompiled strings, then with lines from stdin, then with lines from a socket or SYSV messages, or HTTP requests, or whatever. Then a front-end could be built that would match GUI events to messages that be sent back to a server, and events from the server as modifications to an abstract GUI. As long as we're dealing with such unstable things as Xlib, Gtk, Qt, etc., we'd better keep the frontend in a separate process (which can still be written mostly in the same language -- using proper meta-objects so to differentiate the persistent state in a stable server from the transient GUI state). > Or are you targeting directly at voice, gesture, psycokinetic input? This could be another front-end. > Wouldn't it be funny if the logo would be a picture with a tag on it: > "This is not a Logo" Could be nice. But not before there's code. > Are there webrings for alternative/"homebred" OSes? Why /Why not? I dunno. Some of them are listed in Review/OSes.html Most of them are very short-lived and without any well thought-out purpose or design, which might explain the absence of persistent webring. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] The older I grow, the more I distrust the familiar doctrine that age brings wisdom. -- H.L. Mencken From schizophonic@tiscali.it Tue Jan 8 18:34:02 2002 From: schizophonic@tiscali.it (PB) Date: Tue Jan 8 18:34:02 2002 Subject: (no subject) References: Message-ID: <001c01c19860$4e2e63f0$2410af83@elet.polimi.it> (snip) > Are there webrings for alternative/"homebred" OSes? Why /Why not? > http://www.osdev.org (look for OSDev Ring) Also check my bookmarks http://web.tiscali.it/~ph/ (note that many of them are grabbed from TUNES review, but not all) Pietro From Francois-Rene Rideau Wed Jan 9 05:15:01 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Wed Jan 9 05:15:01 2002 Subject: low-level approach Message-ID: <20020109131444.GA7108@hell.mine.nu> Dear Tunesers, as far as low-level approaches to system development go, our own Tom Novelli makes slow but sure progress with retro. http://retro.tunes.org/ Another promising approach is Rick Hohensee 's "compembler" osimplay. It's kind of the essence of FORTH metaprogramming, but without FORTH as either the source or target language. Instead, the target language is raw binary (and then 386 assembly, thanks to some layer of metaprogramming), and the source language is bash 2 (which makes the whole thing at the same time slow, ugly and unwieldy). I think this verily makes the proof of concept conclusive. The official site is ftp://linux01.gwdg.de/pub/cLIeNUX/interim/osimplay.tgz But since the file lacks read permission at this time, I put a copy on ftp://ftp.tunes.org/pub/tunes/utilities/osimplay.tgz I always wanted something like that in a high-level language for the heart of TUNES. Will someone step forward and freely adapt osimplay to a decent metalanguage, like Common Lisp, OCaml, or MzScheme? Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] The secret of survival is: Always expect the unexpected. -- Dr. Who From u.hobelmann@tu-bs.de Thu Jan 10 02:51:03 2002 From: u.hobelmann@tu-bs.de (Ulrich Hobelmann) Date: Thu Jan 10 02:51:03 2002 Subject: Inheritance? Message-ID: <3C3D71D7.B91ACB01@tu-bs.de> The TUNES glossary states that inheritance as subtyping doesn't work with static languages like C++ or Java... In what way? Somehow I don't get this, but then I have too much aversions to actually try to program in these languages, to try it out... I'm asking this, because I like most static languages out there (ML, Haskell), mostly for compile efficiency, but what exactly is the diff btw. say, OCaml, and Java OO, apart from the functional aspects, and ML being actually _more_ static (compile-time) than Java? Regards, Ulrich From attila.lendvai@encorus.com Thu Jan 10 11:44:02 2002 From: attila.lendvai@encorus.com (Lendvai, Attila 101.) Date: Thu Jan 10 11:44:02 2002 Subject: osdev.org Message-ID: :: (snip) :: > Are there webrings for alternative/"homebred" OSes? Why /Why not? :: >=20 ::=20 :: http://www.osdev.org (look for OSDev Ring) there's no tunes link on the site, first i tought i will add one, but then i realized that many of you could write a much better twoliner about tunes. so go on everyone! 101. From fare@tunes.org Fri Jan 11 14:30:02 2002 From: fare@tunes.org (Francois-Rene Rideau) Date: Fri Jan 11 14:30:02 2002 Subject: [comp.lang.lisp] Call for Participation/Call for Papers Message-ID: <876668cyhv.fsf@Samaris.tunes.org> --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit This could be an opportunity to advertise our ideas. What problems are we trying to solve? Can we state it in a few intelligible sentences, then explain it in a short speech? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: norfair.nerim.net!nerim.net!isdnet!195.115.0.4.MISMATCH!esplande3000.net!fr.clara.net!heighliner.fr.clara.net!feed2.onemain.com!feed1.onemain.com!feed1.newsreader.com!netnews.com!xfer02.netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: "Richard P. Gabriel" Newsgroups: comp.lang.lisp Subject: Call for Participation/Call for Papers Date: Fri, 11 Jan 2002 10:02:20 -0800 Organization: MindSpring Enterprises Lines: 19 Message-ID: References: <3C342D72.1000605@hotmail.com> <3C35B37C.23F12812@kfunigraz.ac.at> <3C36E851.811A278F@kfunigraz.ac.at> NNTP-Posting-Host: d8.af.7a.84 X-Server-Date: 11 Jan 2002 18:02:22 GMT User-Agent: Microsoft-Entourage/9.0.1.3108 Xref: norfair.nerim.net comp.lang.lisp:15008 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I am organizing two events which could be of interest to folks on this list. The first is a workshop called Biological Framings of Problems in Computing, to be held April 17-19 at the Santa Fe Institute. The idea is to come up with a set of "Hilbert's Problems" whose solutions would push forward the idea of using more biological metaphors in the foundations of computing. The URL is http://www.dreamsongs.com/BiologicalFramings.html The second is a conference within a conference at OOPSLA 2002, called Onward!: Seeking New Paradigms and New Thinking. There is a separate program committee for it and we expect to have our own keynote etc. The idea is to try to get some larger vision type papers, but backed up with some initial work if possible. The URL is http://oopsla.acm.org/2n_onward.html -rpg- --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit -- [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] Bon Dieu ! que de peine à prouver, en économie politique, que deux et deux font quatre; et, si vous y parvenez, on s'écrit: « c'est si clair, que c'en est ennuyeux. » - Puis on vote comme si vous n'aviez rien prouvé du tout. -- Frédéric Bastiat, "Ce qu'on voit et ce qu'on ne voit pas", 1850 --=-=-=-- From tunes@tunes.org Fri Jan 11 17:18:02 2002 From: tunes@tunes.org (=?ISO-8859-1?Q?Bj=F6rnke_von_Gierke?=) Date: Fri Jan 11 17:18:02 2002 Subject: TUNES In-Reply-To: <20020108153135.GA3711@hell.mine.nu> Message-ID: <22A14BC2-06FA-11D6-9309-003065AD94A4@mac.com> Much snipping happening in this mail: >> Why cant i just hit reply to answer a mail to the mailing list, is it=20= >> my >> app or the server? > As with many mailing-lists, you have to use "Group Reply" to reply > to everyone rather than just the originator of the mail. My app only has a "Reply to all Sender" function. It adds "Bcc:=20 Tunes@tunes.org" to the mail header, so the originator of the mail will=20= get the mail personally, AND over the Group. Very annoying... >> Me thinks it's much too clumsy arranged and unintuitiv presented, = maybe >> for compatibility with CLI-Browsers? > Compatibility with CLI-Browsers is a requirement, although if you're > willing to write a system that adds features for other browsers = without > sacrificing compatibility *snip* Well, thats quiet simple with an intro-page, which has a link for=20 text-only content (as is) and more detailed (same content framed or=20 within a table). One could also Use javascript to redirect every browser=20= to a more detailed Page. As text-only-browsers do not support=20 javascript, they keep on the first page anyway, and can proceed from=20 there manually. >> Faq is too detailed, shoud only give simple clue about what Tunes is. > On the other hand, I don't know how to do without details, or else, > the answers might betray the issue and confuse the reader. > Maybe have a short answer in larger size and a longer answer in small=20= > size, for every question? A FAQ should only give simple clue about the FAQ-ed term, IMHO. As a reader, I would expect the FAQ to contain short info on where the=20= project came from, what it is, short roadmaps, targets and methods=20 (etc.). All very short but with links to the adequate information in the=20= documentation. I.E. the targets part of the FAQ could explain the=20 general target, the quintessence but also contain links to the examples,=20= the HLL-project or/and the "Why a new OS?" article... >> Is there already a deccission made what userinterface the first = version >> will use? (I mean that 'run on top of other os' -thingie) Is It CLI, >> GUI? > To begin with, we'd just have a listener, that takes strings as input,=20= > *snip* Listener? well ok it crunches strings... does it understand sentences?=20= Or do you mean string as in "long" ? There may be some detailed info=20 about that some where on that tunes-page-thing... *snip* >> Wouldn't it be funny if the logo would be a picture with a tag on it: >> "This is not a Logo" > Could be nice. But not before there's code. Before code comes info, which then can be coded so that the machine=20 understands it... but what info? I really have to dig trough that=20 homepage, it MUST be hidden somewhere, as the truth lies in there... ;) uninformed Bj=F6rnke PS: "short" sentences for the OSdev page: We don't want to make a new OS, we develop a new computing philosophy. It has to do with selfscripting code, relational=20 filesystems, metatranslation of static programming languages, cool=20 acronyms like "Tunes" or "HLL" and much more! We even=20= regret the idea of a logo, so come over and dig into our project! From Francois-Rene Rideau Fri Jan 11 17:53:01 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Fri Jan 11 17:53:01 2002 Subject: TUNES In-Reply-To: <22A14BC2-06FA-11D6-9309-003065AD94A4@mac.com> References: <20020108153135.GA3711@hell.mine.nu> <22A14BC2-06FA-11D6-9309-003065AD94A4@mac.com> Message-ID: <20020112015248.GB13624@hell.mine.nu> On Sat, Jan 12, 2002 at 02:17:24AM +0100, Björnke von Gierke wrote: > My app only has a "Reply to all Sender" function. It adds "Bcc: > Tunes@tunes.org" to the mail header, so the originator of the mail will > get the mail personally, AND over the Group. Very annoying... Should be a Cc: - and usually the sender doesn't mind receiving a copy (he might be unsubscribed to the list), plus you can remove him manually from the destinations, if you know for sure he's subscribed. >> if you're willing to write a system that adds features for other >> browsers without sacrificing compatibility [with CLI browsers] *snip* > Well, thats quiet simple with an intro-page, which has a link for [...] Just do it - you seem to know better about it than I, anyway. If you don't have write access to the CVS yet, just fill in the membership form and ask an account to root@bespin.org. >> Maybe have a short answer in larger size and a longer answer in small >> size, for every question? > A FAQ should only give simple clue about the FAQ-ed term, IMHO. > As a reader, I would expect the FAQ to contain short info on where the > project came from, what it is, short roadmaps, targets and methods > (etc.). All very short but with links to the adequate information in the > documentation. I.E. the targets part of the FAQ could explain the > general target, the quintessence but also contain links to the examples, > the HLL-project or/and the "Why a new OS?" article... > The problem being here that we lack coherent documentation outside of the FAQ, that the FAQ could point to. In absence of it, a two-sized FAQ might do. If linuxdoc-sgml can't handle it, we might migrate to HeVeA or to TeX2page. > Listener? well ok it crunches strings... does it understand sentences? Not unless you teach it too. Begin simple, elaborate as you go, refactor the simple thing afterwards. Be ready to see your code refactored, knowing that since the code AND the execution environment in which it was successfully run are versioned, so that you will be able to run your old code despite incompatible new refactorings, evolutions, modifications. > Or do you mean string as in "long" ? I mean "string" as in source code that you can evaluate incrementally, input from primitive but standard means of communication such as text file editors, line editors, raw terminal input, etc. Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] Is eating the flesh around one's nails to be considered as anthropophagy, and does it qualify one for eternal damnation to burn in hell? From tunes@tunes.org Fri Jan 11 19:15:02 2002 From: tunes@tunes.org (=?ISO-8859-1?Q?Bj=F6rnke_von_Gierke?=) Date: Fri Jan 11 19:15:02 2002 Subject: TUNES In-Reply-To: <20020112015248.GB13624@hell.mine.nu> Message-ID: <7C0F6A23-070A-11D6-9309-003065AD94A4@mac.com> > Should be a Cc: - and usually the sender doesn't mind receiving a copy > (he might be unsubscribed to the list), plus you can remove him = manually > from the destinations, if you know for sure he's subscribed. Err... thats on purpose? Well, thats the reason why most people hate=20 computers :( the originator sends a mail to the list, is subscribed, and I reply: as is "reply": Header:(to:originator) mails received: originator: 1 list member: 0 myself: 0 as i suggest "reply to: list" Header:(to:list) mails received: originator: 1 list member: 1 myself: 1 the originator sends a mail to the list, is NOT subscribed, and I reply: as is: mails received: originator: 1 list member: 0 myself: 0 as i suggest: mails received: originator: 0 list member: 1 myself: 1 Now we have the same causes when users rearrange and uses the "reply to=20= all" feature: as is: mails received: originator: 2 list member: 1 myself: 1 as I suggest: mails received: originator:1 list member:1 myself:1 I think that you would like that the originator always get's a response,=20= but hes only one, and thus i think the list members are first priority=20= here. Also if he want's a response, why doesn't he subscribe to the = list? >>> if you're willing to write a system that adds features for other >>> browsers without sacrificing compatibility [with CLI browsers] = *snip* >> Well, thats quiet simple with an intro-page, which has a link for = [...] > Just do it - you seem to know better about it than I, anyway. > If you don't have write access to the CVS yet, just fill in the > membership form and ask an account to root@bespin.org. Is that a Joke? I mean you don't know me, and I didn't even tell you=20 that im here to overtake the project and cripple it, by order of his=20 billyness ;-) Also I don't really know anything about programming and what exactly is=20= a CVS? May I now add my own homepage to the project? > The problem being here that we lack coherent documentation outside of > the FAQ, that the FAQ could point to. In absence of it, a two-sized = FAQ > might do. If linuxdoc-sgml can't handle it, we might migrate to HeVeA > or to TeX2page. well I would write a new faq, and put it into the introduction/welcome=20= part of the homepage, and then use the old faq as a base to grow from in=20= the documentation. >> Listener? well ok it crunches strings... does it understand = sentences? > Not unless you teach it too. > Begin simple, elaborate as you go, refactor the simple thing = afterwards. > Be ready to see your code refactored, knowing that since the code AND > the execution environment in which it was successfully run are=20 > versioned, > so that you will be able to run your old code despite incompatible new > refactorings, evolutions, modifications. > >> Or do you mean string as in "long" ? > I mean "string" as in source code that you can evaluate incrementally, > input from primitive but standard means of communication such as > text file editors, line editors, raw terminal input, etc. > I still don't get the diffrence between a runtime compiler and your=20 approach... but its 4:20 at night, and il go to sleep now, maybe i'l=20 understand tomorrow. have a nice day bj=F6rnke From dnvennik@yahoo.com.au Fri Jan 11 20:56:03 2002 From: dnvennik@yahoo.com.au (David Vennik) Date: Fri Jan 11 20:56:03 2002 Subject: unsubscribe Message-ID: <001501c19b25$805da300$5f178690@AlleyneLearmonth> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C19B79.50C1A2A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C19B79.50C1A2A0" ------=_NextPart_001_0012_01C19B79.50C1A2A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Citrus Punch unsubscribe unsubscribe Couldn't find any info on how to tell the list engine to take me off, so = could someone please inform me??? ------=_NextPart_001_0012_01C19B79.50C1A2A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Citrus Punch

unsubscribe
unsubscribe
 
Couldn't find any info on how to tell the list engine to take me = off, so=20 could someone please inform me???

------=_NextPart_001_0012_01C19B79.50C1A2A0-- ------=_NextPart_000_0011_01C19B79.50C1A2A0 Content-Type: image/gif; name="citbannA.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01c19b25$7f0df180$5f178690@AlleyneLearmonth> R0lGODlhWAI8APcAAJkAM/8zZswAM/8AM/+ZmcwzZv/M/8xmmZkzZmYAM8wzmf+ZzP9mzP+Z//9m mcwAZv8AZv8zmf8Amf8zzP8AzP9m//8z//9QUNYAk5kAZsxmzMwzzMyZ/8xm/8wz/5kzmcwAzMwA /5kAzJkAmcyZzJlmmWYzZmYAmZkzzGYAZpkA/5kz/5lmzDMAM2YzmWYzzGYAzJlm/zMAZmYA/2Yz /8zM/5mZ/5mZzGZmzGZm/2ZmmTMzZjMzmTMAmTMAzDMAzDMz/zMzzABm/wAzzDNm/zNmzAAAZgAA MwAA/wAAmQAzzAAAzDNmmQBmzJnM/2aZ/wAzZmaZzABmmTOZzACZzGbM/zOZ/wAzmQCZ/zPM/wDM /5n//2b//wAzMwD//wDMzACZmWaZmZnMzMz//zPMzGbMzDOZmTNmZgBmZgAzMwD/zDP/zDPMmQDM mWb/zJn/zAD/mTOZZgBmMzNmM2aZZmbMZpn/mWb/ZjOZM5nMmWb/mTP/mTPMZgDMZmbMmQCZZgCZ MzP/ZgD/Zsz/zMz/mZn/Zpn/MwDMMzP/MwDMMzPMMzPMM2b/M2bMMwBmAAAzAACZADPMAGb/AJn/ AGbMAADMADPMADOZAJnMZmaZM5nMMzNmAGaZAJnMAMz/Zsz/M8z/AJmZAMzMAMzMMzMzAGZmAJmZ M8zMZmZmM5mZZszMmf//zP//mf//Zv//M///AP/MAP/MZv/MM8yZM5lmAMyZAP+ZAMxmAJkzAMxm M2YzAP+ZZv9mM/+ZM/9mAMwzAJlmMzMAAGYzM5lmZsyZmZkzM8xmZv/MzP8zM8wzM/9mZmYAAJkA AMwAAP8AAP8zAMyZZv/MmczMzJmZmWZmZjMzMwAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAWAI8AEAI/wBt+bIl kOBAgggJwuoFaxQsWRAjSpxIseLEh7AyZpSFkaPHh7ZgJRRJUmPIhChTqkR5sKXBlwVjuiw4sKZN gb5y6tyZk+ZKlrZuEaxFkCFDiBhPivzJNGGvWbNOeWJFiKonVZ48SZWK6VRXT10LndKEaRQmsmjP qv2kFhNYTW8xGVKrKa1du4VGFdJ0ylBfvaMMjdL0SdOowoEPK/50irHZUaegmpp1q5cvXpd5ad58 uXNnzJtDg+ZJurRp0s98pV6tWidr1q1Zj559eufrnLdAh/78WXdm0aEv9OK1q5fxia5kJV+uvHny VtCjs5pOvTp16LFaZZdo3Lit2bo1///WPHw4r+Gec2Iu3734rve7Yr2PJf+mz4MEhRIlaktU/5Ci zAKSKBk55JAoECE4ikUMPvSRR0g9KIstE5q01EIkMaQSfjBxiNOHBtVE00wi9mRfiSF22FRKSyHU olIrwiQjh73IAtUprXjSCiFZSeUJY2xpVUhWYg15il58wYWWJ2Jh8oknZAnJVSFd8YVJWU0i6dVg Z+WlliFJllVXXpoIttcngwlWmCeDQckmm0d6ktyC3Z0nXnidIaPeZc/cyRtmqq2WWm2qAYrZoIEG +oyghe6pp2uegcYee7x818t3OBmaS3nQuFceZrmASt6o5+1ygafw9bILcaoeJ9FyzDn/5xysELli 63KxLNeKLNr1Gh12vcYCUY3eDfedoZ6ZR95l6El6maXdtTfffUyJ5B+BtVz7HyzYwlJLQxn1QqBD 4BIoC4IIMtgcRRtF2NGDGJEE44RGhRtjSiLOKKOKLpWIn4cj3SvwTxzmS6Mts4wySiuseMLjVmzq BaSPYElZsVtinTKkWxdnxTFXWWlV8SlcaewWJkUyeWWTc+2FVl1k9UVWmnAFtiZhh5XFJmMiu7Lr sL1syhlt6fEZ6XiX6cnLojndFhugOh2ak56vrSZ1bOqRp+p89MUnX3F1Svt1NLtE0zWq0bb6ntrv seqpqrLUWGusrrwii90QveIKLMz1/523c3w3Z/feyiXXXK6/+gqdLMICbcul4ZEamrKRfpeZZTKN dFSBG2lk7kMEcpvRtdwC6K212/r30LcIviuRsI2rG6GESclb0klxL0ThiwP37vuGKwGMkPCZx+RT 8U4pCF3DVfHIY8jQQ/+8WEKOzNZYTbIFl1wae+Xjx1oR0j2TPhZZMpVg6YWlWZqIVddZY2E/GGH0 D4amYH6hCaQsowgb9m6jwRpskAUc4PSpMwdsGqRuw5pfLOqBi3Jgo0o1HwKY7YIYjIYGN6jBWBDA gyAsmwjl8zX4pGptxgGb3BgnK+YMzlYPiZWs7DY45dBQOYHD4d52CAsa7i2GEXkOsP+yg53Ydedx BUxielDiLVnUQnaugB0LYydF/kXEIfxriBNH8R9RdKs/pQMXFrVIEcOta3YQughHancShdRrQnGj UBvxZTzi/S54CSGeHf+Vonz5Lm7KWV7zrPK86H3ve2Bhi176wkgnOXKRVyqZHaB3CkIUQhVuqSTH RDYkVQyJR5kES8bgR0oo2WUsTkKMmgjjpMP86DBAGoWOciUsFQLwaFPLEwJzuSfMUA1qAkxUa1qj tMvkZjPGmQV8OBiNY6wiGqs4BiukeYxmbvCD8CFhfEzIzW6ubW2x6EXs1pWcHPrNVs654Q4Lx7d2 9u2cOuwhDu/mTnn2LTtEZEV0aBn/kcdZplmT200ZyVmrghK0Vo372a5oqZ0pRtEiCwKJRjiCRQFZ 0YoLkt0aN/ouB8UrI3NUyhpDUiGmzGR4d6TjvoDHL5SqtFohOUoQeRWd5g1SZCHji1/St5cjjcUT fsmL+XR2MpFtxXw9oh7GRFZIrFQyZOXrHl1gRtWzkKUwZxHMWQrjFyXpj373O0xj2BQLxlixF7fI xTHHAxxewmZQiEJUaWhjp629R4MW3GA199pMafaVmds84TftuqriCGdUuWDWeVw1UxnS7ZyBQ6c7 BddCWRE0VjWU5w3VyTchMmw6DCPiz4blz8yYljNqxN1J3jjR0J1LI63tSEYROsWZ/0akccLK6Gxn q1HeJui1HZnoRkIa086tUV4Ds6PxXlKwfTXXpc3lY1NEkruBonNX0qHKdAjBXed5xS1kKUv8hLoV RGrMqD3qEcS+MjLqGcliIXuejwoZvayILw+gvNKVqPqyJG3JfYFxk/0MoT9X8oxnrVDYLGxUi8Te ImpsHRqEB0XXuhKHm9HIKzM1yNe/MpMAgTUh21D1zcL24rDD+aZ8GIfbVxUUnsnB2zrvRuMY01id M9RhPHn4zkD+Kjv6jEYroqHP68RCn0SkSNh4c5lGOPnJUI6ylKdM5Spb+cpYzrKWt8zlLnv5y2AO s5jHTOYym/nMaE6zmtfM5ja7Of/KJEIRQvZzuv6ICxYC0uJDfKvRi3g0uPDaXUgwpJQMITelKioe iZhLLRTdhCfUWu5KiMKhklZIQ4fGI/KKgrBRQGNHO2IeVKnHl6xsjzF+0WqqkXSW9HVlLhqb2V7c FF66ONIwrYbZWOjXvsfUD3+HwRlQZUnsiGXUO5G7E3h6ObQA2gZrhDINA4fpNLhCOzV03ROEd/Lg ZySWF8fczLFM+23fhGpywjEVq1glzsYWrrLMGeLy9okdJA85WNox4hHP0xPw+AaZmrFcTdaz2PZs TZxe28XxVmqL/TS8i/0RBeu+BVJ0vfbi7aJIrlwskXilEUJ/ZghILwTH4l4qpY7//pCcFy7nnkR6 JbYLKe8Qncc6IqRGN4qFw3KkFUO8qWbkY1LHROm9K2klLEcq0ldQdt6TdW9jXiFfzFBm1fb9tC6+ xrphyrR1+zkJZzoNmSx0xMI63VI8uXyUL/+kJ6oxjVEKdNrSRuM0YhYKNNj+k9bUxvc6PQ6JlvJm q4xjYfOc2D2mQvypeqEMvpfxsX+78Yv5hmMc960VUQQWvqVILGRjClCGl5xuLEfwxS5W4SvndLhg 67nThS50rEMdbFWH59F9JF2zFRZ2z2jFjrILKWwEacktTdzkMtq5NT+eH2nelOgyHKUeIspkTLEw h6W3kT/6SpOu4t7zHh2RQiV2/8oqFjKOGWljovQY0YVElrksskxbkgtaujqWwSSGwIbJn1gd079R QGUWoYd2VxNMB5Rsm1FMTbM0CrRLOyE1CRQbgvJ2b3c5qkIf9GE226RNJGRBsQBYZJOBJSZig3VC anNbllU3NRYRMnZZ77YckTVZ87ROL1Qr2EVv+aZvhFd6yqIsfuJsklZc8NJnFDU7Y0QgEudF/TEL Encg1iIKDBFRF1VbvPJ7DmIRwWUhbYQhH0FoM8d8KKdpy9UveLR80gVdCTELT+Qz2mVTWcFzUIVe nNQ9ftEXuQYl2Mde5ncVUoJU43N9e+h0QvVqdLEXWLJ1+VcmifEXeaE/P3IKrv/wCfzjP2YnYUWz bQroC8XUbKalNIzyQBDYGr8gQKvxYHfHLMu0YdUUTdZ0TbsAYiCETR9ENiXkTYhXgivUgikoOLZS Qzu0TjY2OO5EOHoTWfTEQ3azETxWOPi2eY2TNuOxg5IzEP4RN771UA+1UFHETwvFOPkWRT7TYhc1 WxiBIKyzRq8HfGjEcWpkXCAHciPXIsJHIUghRyzlIakHFMkHhjb3gy11fM83XfIIEcuzXVTBXTtC SRejMbIEPzdTf0MSJVXCUxBTMQ9DCBhzXuJDPXkgdBsZPksnFeHFPlZFiO9Tkodof4SRP6mkGGMl Vpi3jf/TbNnGS5cIbcPkVpD/AmHIlEIm1IEaplfH4EzQRGTVdE2zSIueQhxKaSd1NXixYzh0A2+V tVmA44Lo5DdTSVn1hIJU6VmsIGT2Rh8RcXLKFmG+oFGAxnoPcoxmBJWwY41VpC5Y5BFzyWd9lpZV iJeHRhLHNXICAzDK5VJmKJiJFoYsR5gwVyNV+GKiFWqDRAg7QjJOgkqD8VNdARngRX7jIxXbh16h lEnUUzHoZzEa8zyeZEhi4XNyYWom+TLypyTts3VkAmyJUWwT4wljFwv+Zwq50GBqdTQFlB7TRhpQ A3A8eVd4xUFFyVfL+WFHOR8hiHhrU3h7Vxxx+WIs6Dc1pGPESIzkBJUtFIwv/4hOvGgrRIRP1lFk DKMdZhQ3kIMsO/Fm8jmf9Fmf9nmf+Jmf+rmf/Nmf/vllJnIiKFFSrQNyc1kRsbJxFdERuxOEHiFo WagQHCFHmUZHgfloGKpyGdpyOGETHroTKsePKSEUQcFpDRovMLIii3aGUaEjzaMK9OWH6fUkP/Ij RaIkQvUkpRZ0QRVUSPIWe2EWsDYXn5BqiURg3IMmhYAY97cYkPEJPPMjCeZ/R9QbZ9coVnqAvBFX NxltpTFt1taJwZSAf9KA2/ZsvvAL4KY0ogGcl1FuBXRimrEq0cJC2AljueIz0AGWnxVarHBkRHZv +PRQY+lPjwOcBmhhlYIZmf/iC4YXLSVGQvVhcy6XEPtBZ9/yRBZnXAVqEQqqRrMDaBERXPUCIyWB aSrafC1lMNCnaI02ImIook5xc0ykECl6IapamE8BGYJkfekFh+QTmmFXF2wyazXjPTuFMnxRCObj F7ZmFli1PWWyX6Z0a/CXkgoDVsH2Sm9CbD9TLJYRnLNBYadVpm+1gF56kwxUbQS4gLrxKc2ibekh KlpjYWUKHJ9SHMTReKfiNox1p3PTQhv3HN+oOOe5jMFigWNZLJZjHs/iJwEYrgUBegWXQrLANaj3 qkxBFN6ChKIDW1zEEQXaqciBlhuVRh4FfIO2eoOGaRriO9JlIqsaaf3iaH7/pFyZ9iJdeEexihAQ ERXQAZnQ8yRj1RhOon4VEyRdoaxPZ7TFKiRFJSXgxbRTa3Rf8n6BwUpcVRdokia1uWo7oxVP0gqf sDju+SltpRnY9oCZuImfaJMLiChqF3dV03ZuyycVNilpwx6HeimOWnC1GC2kAo1bc2EHV1i70HjF AUguRisudFCFE5XnlHmap3liCTSX8k+OymyKxZS+Ea5/W7Ep9Gj/6B+1kKlHqC20V46ZulGf83HY uaDoOKoo+xEiJy+XJhKl+jti6C+GqXwj8nIwZ6temKo9SxAJIxVBmxU8I0t5kT5J1YfkA4hRt3Tt 9XQewzEfOSQdw6zs4zGK/1R18INrOJNqUPojUHq+NFq2OmK2Z8uDpoW3OvEocxsefXK/iQKm80ph YUptUZN3mbiTiEdCF6tCgjtiIDhYB6yUbHO4wqG44rRCkEc4dyOD8MSLNQaD6FQ4B1u543RExpE1 AOe58Asa40YewusiKzs6GUEU2qIRsRc6wsVRM7yYr9Oe6ZiyvteX8yJHa3QpJcWzrbqPQLFygVm8 gylprLpcC1Z9DTO0YtuIlNRJIcO9R6d+VsyZmmnFVcyZoKm9RCeIcjG17wMWcyF/YAIlwdYmgTEW hfEkcAwdnwA7T4G28dult6F2ScSJcCuvZAptgIK/E/ga74qxHZhwKDTAIv+UYRcEnWgjnbVIgm/D Qj12Q0hBOD1WTn0TOFQ5nrOyK5Rrg5f7vg7ruaIXcJRoGSuXuXwpXKz3yq93OrPXeiLFqbbFOIQK qovpe9T1jqZKUhoSxDBLxEhcvPZIqfoCFPsRCtSnc5BZSONDPZwpFeIjPepnXkDVGBvzCUNixc8D Sr5aPdDzmWARP2VxzkiiPaQkpPWHP3ChJonhGGhyJLIADQCItj14QOzKuWWptgrYtn7MS7sUgREE gQ9GHtkUiyBkgT65YWbzQa6ITRqYTSL4yICke7NCWZKlyQG7yYZTQ7zIyTQmnu/GK5SLT/vkP2eL RCPcVvEqsx4SzEGYcen/shGbWoSw1xAhkam1dzrfcnEaZzifCqqyi6J+SV0UOqHCXMxeWIY/eMQt waH5yES10Av9M282FWr1VV+ZFEra/FN26KxJar1C5yMgMzLl94cdc5FjjEqxORZ+MT9v/HWHAc/5 I6U+U3Zmd1p5V3dGw6YR5hvIgHdjOsgRRNCrEYrPcNAURDYZ5NAeKELYZDYbSNG02HcQISxRqU63 oosAC9I0pkM8Nlk3lBEwBJ6ZB2SW24yC27lxyhkqAUc6XLJyOREU0jpPpKnZ8rHnKDoUVYVm9Kng iUZ56S4SddRAuBAccSk7u6JMbXz4SDCbtnxNUQsLxjj69JhCa0hGZcXU/5OsihR+SxoW1pvFlmSR lrSHT+U8Ww0yXuE+51wlt7YW9AMlqBbP+gMkaKIjDwU2nvsbZ6pLA93P4wo1ht2/5xopo1JBzPRM 1ORhHeSKCTfRz4mU7mGCuDi5G/y4K0iVwFiVGi3SmlWMsmK5m4e5fxuuAbUb/PE4ImGX/CRFbymW +DSFDRWFUBiyq1N737Ky57KFBjURT9lxNtyOxzVoKowhcoPU0q0vwkPd+ngvx3x8vYuYK6LcvAJk BMldU0FfFAMyTJdqIFkx23PObIF06LXeT0XN1mxf1vcwWNw9dmFKhMg+7ZyIBPbG6Yu+Y1W2ZbuN BkzguLR2hcK/wOQoOf/pv2YqKacHH7EIlEP5TJK+YT0JnbNoVyl2YqqiuN9kpzkGY58u0lY50jDG 4ZK3lQ+BN9spHX2KHQu7uTK5G/1hET8Dl8qB0bhu41M4qDQOURCxIORSEk/kcbDbluuiw7Nd3LCV hTK9OyL3l/94xE0+1c91sy8lMLojEdGhI2tYkNETJFLBGFQiflfFStksFuCuVFD1PKGUMk7l5uFD SYV0MiJZkuJrF4qkJo70xjsDx0ASMn++UIKrbP4GnzWZ6HK1bYjib4QVHz+pV3/lTH5VlBbUk4db 0Rdmyo9aI7twyxR8lSVNNzE0WTbGlfDmuCAuecPoQ8Sop/rU6tvRT5n/e1pt6m6VJZUeHxG1PuO0 dJ0d5y4/Di5ROPQNAvQZF6o8PBIVsuw7i5hQHSOACfUvJ+0sQlKLSbBY7ZhWkUhb4aPozhVBwiTO W17jBzFHddZxzt0OQ8VPZUhKcnVVNRh5ASZnoTBdhSSAAVZcG7ay1L4NBRWVgScGyIDnmvA8Qa6j wpPy4dDN2WFByUEelIENH52GpSpMufG3CLAnKLmyItI15rhQCeq5CIzJGG80FWR/qp7syR0sjUtn KbsctYWdo5cQgsO3/lCaPU6+TvQWMdzNkZd4adwTcqsr7Je9Q/VR/7tkiHxPDpAk9XHg+SuQWZBr WM2ZFNdLy/VXEvbl/5xenUkyIsMxZpFI3Usxv2pJbP6G6q+938VfWcVKZjGZX7ekYPfGBtYYRZsV /wcVvwkQvHwN9MXL4EGEvp4RXKiQ4EOBBQ326rWr4q5dsQhE2xjN47FoID+GHOkxmsZYGFVmVHkR o0uLFi/04iWTosVYOWXF2inLlSyfQX8OFVr0JyxXSJUmZYr0lVGgTIs+lUrVFVFXrbTG0tqKK6to rViNFRtWq6xWQNVS7GVLYMSBvBrNpVvX7l28efXu5dvX71/AgQUPJlzY8GHEiRUvZtzY8WPIkSVP plzZ8mXMmTVv5tzZ82fQoUWPJl3a9GnUqVWvZv3Yli1fr2PDnv26F/8sW7BmwZLFW5Ss32qFD+9Z nCfxUbCSJxcFy3lv6Lx52+qd+7Vz69hxv+bOPXbt7t2/w5Zdnvz52enLjx9Im/b39vHdsz8fPnat 2Lde13oty9bt26jDbcABwzPwwP5mmWWUWFhphRBCPPFEFQkx8eSUQkYpRBNPOOTwFEMw+QSTUQwZ pUNPNBwFEw81ERETQzAcBUQaNbFxxBFj1CRGHVM0MUMRT/SwRE0++USTEpM05JMTj5zxk1lMmaWW twqy0iCJroxLSyzfWuhLhx4Cc0yHyDSzTIXIRBNMZJ55hpc3ubTyzDFv+fIWXvCUM08+34qoz4lm 2qWmmirqRS2soCL/yitGvXIwmrEidRCsrtJKa63/2qqyyyx96cVTXmiiKdRNYxOIrZt6iUVVllLK yLzawLOFv1qm3G2UWnAFTpZRdgWqV+KEi+Wn4X6T7jlko4sOQAKz0w7B+qClDz1Yq61PPfnoI4g8 +LhdD8HZ+OvOP3JzC3C7AqGldtwFTxGLFU8ivHDeUzyx0EVMTuGQRX1ZHMXGFTWhkUVMNiRxQwwF JtjFG18cscQXBebxk1NEPOUTQ4pEckkkNT7SyCY9+USrUzDt0k+J4pyTU5QFQmbNh2Cms8yZ3UQz TDLbLPXPiFSOC8wwBcrloKGt1FNoP5MONNRBC7XoUER9ShQrV4bl/6qrq8Miy0GxKvWqaqAOpei/ UEE9qKBPC3JLVIPcKtUtUFPFiSWVYuFWPW9pnbWWWkTpRZRagNMNt1GSgy7YoIQjdjhkpVOWt2W1 8w+3ybMD1zzvvo2vW20519xbba+dVl0ExbWNcsuvIz1zzKlTcBSxCHmQXglpLETfeTWUWF+J+R2x w0JgzHfDC4MPeGEPgcdXx32P7PDefx/WWMlRPq6++hQ9ceWUGcNmq+WTrbxyU4TetLmhhnCWef0x zz9T5oXg3HPLP8WH662hcxk1Sz+H5sV/hNDkAoOqiEEsEiqKKM4oVJOaT7DGqKtF0GtboeBxZMGW TLWtSvxjG6l44f82LY0KVXOjm93SM55vzUqFfbOFKFo4oFrAwliGgxzkFBg1xkUnWcdSy7GcU6AB TQ4WAVrd5fCGwnVlq1qxAt0J11XEtnBnO6oLzxSlda3WyWIWsnAXKyIEr9p54nYpAtKFKPYJ4nmi R7rDHSYKNqLbBW9ecdSQGzVRCHvZK0T3YpGOdKexDqnoRv9aUvU8xiQmiUxkrciK9zqYkFIVJE5K M4j51Me+S6bPZmliH5y85EmFkI9sFPlg2SLJMwQWyoOURIgHe6GMXgxwJgMkFFt2oUCqTS0olgLb UIjFyKs9kCvB5IkFv0c2U5EPSyIk30CYKbdbqoSJ9iGPuPgWQxb/ulCGLZRF4GLYnN44zobBAlYO HRdOoNiQh9RxlnUmR8QDySqF6GEiCo9IrXva01tFTF26+KmuaWKuF+0Siydmd4p60QhFCa2dIexV r+Sp6EV5dKO9xoghi2KIYA8tRIhup6N7VcxGG7qdjUhEoiPtyJCGBNnHRPYJT8jCoGshpdvOtkG4 cAkhL3uZQNA3MzExJJMwe9kke+qLolYJVUsl5afK5otceKogsxjUSw7YQZoMTYQXYFpNaFlVBKIq alPT5VWktjhfQqWCjRqmV4w5Nk05VSJvWdtEJiLVK4lQbjcJnbr6hk3ADchvsMhVrl7ow8ONE3E9 TGw6lZXYY50r/zeVG6IV/5k5feLziUvEXD0v60/LXpazrOvOQGfUtQglVEUUrde8XGshDamxXjCy nRstBKLbjrFgGKrYHDmqRoftdkf8YtEdhQS8M3LIoSvl0PWuF1Oask1OW2KIMm+KVKGiL0wQCap2 v3Q+7MaPf5NEG9NcYqilljJuN1nJS0TV1ImIaiZO+6oqlzpWoRDLrPuVxSt8qd/+SiWtP7GUBCW4 k7eSDW7gs2spabJgUHnqvTfRbOtWSNgWZtg5MZRh37qZG9+EOJ3jXJwFF1vDczo2nM16VmUFZB3R gmdang3oE2ccrdVNMV2h5ScScZygBRXUoLnLUPFONEYJVehCGP/NUBzzGLw26nZeFuIok0Uax5NS 1KR3dFGIPLQhE4GoRBQr0nGdhD0mMbInqGrln15GEPmNr5WdAhrQYrbd+HmXTPLrKShBKRH25oRu T2uqhG2ZkZS4yr3wHWFVL+I09Ip1rAPeL9WQYpSl+OTSaUVL1Sj4aZ0cB1ULpkle7SrdU1kJbqQM VTwPpE0Qa+eHs5bhhp1jLOUgi4aI4wlaGTtixdYwnJYbUICqM0QYixaz+8RW66b5bGVHu4gyPpAW uagV2dWuEGhMEW/xSOUk4zGPc2wtlS1E5Ti2dtxPlhAee8vbfJ37eb37nYd4xEYm+VFgD2vpxYyU lZx8b3/XFer/QBriSUhK0uALT9+d7eeQOLNpIEWVJE+x60ynCVrQ0Rx1WDGSk1hEo1UtYZuhYqIS p0Ga0MTh9FD8GxVFIWUomX4KVWQelapdpa0RLOZbx0aqBZ/ag1JVb0TSFsUKq46wt451c26NG6dr 85sE0rU4gwW2G/ZQ2MQ51ouBCGIAgVja7pkP6H4sT9KOXe2uFk8WFYRQrXgCXhfDEMViRDxwJ5kQ CbWQu8NI0QsVbNyqwGOE+t5a3lIUtnjXl0gPBiIb6ethJCoSiUx0+eol8noUAyZPZgFfSKrMzvSr EjK8VHBNim/iqr+4wr2LVPPBqU1xQWCrTgLyjCz15Dk5yUk2/7Jxk5v85FYNfkwoYmKY89cV/k0r VRrIX+fXXNNX4Y3zzQoUtrLVxBj8VPcD6MoI5xTON5bibWh9flpzODccZs7Sf9Mcw73/6ot17NaF g+Jj7zg7t6mctJ14z7ZbOwEMwMvZp7TrprdrBYNKrdtCoxWRrSTTuwmZECersopxIyiLt9w6BcND KCm7LTeCt4KpqHxZHpFykX9pPI9psnyLHh85ETTTCrBhs5valIaLmaNqGYWzOEnCKS2hn4WjuDVx H0Crm13wCJBLNJgQtN5rwiNUtPaKwvbaq6cxsZabvpdTPgaSvp+wvgBziulLnKzwtLZyK6y7ILgi m+87iAc7iP/32BazKz8eQr8fcjoOc6Gow8PeEIXdyDXBMZbDob/hABZhGydxehbLIRfzk6x/qjFZ QbsBHEBqY7s4fI1QeB2DOqgGbLzfKTcJiRAKma12yxcUGR430pCK8cQKQajUCrzA87Y6up1zC547 ciMvO0Ud4ZiP8RDucZIfQbMUaQUG+TwF0Z85E787a4g3YyXTy8EuOTiD86nuWj1f+AWFsBM3eYZf WIiecgmUCDncS7SMaMLf64iQK6GRg8KVKD5DWRVcworqo7Tn27QAC8OmYIqq0LQGcqCdaBSsMbH/ UEOb+r4OurN5Oh38+6HocDo6nDWGrLVcWw5ukr9ywj5EGRb/rnusjKS11CkXZKGiHjMQSIxEkbSw 1UEilCRAH5uVXuiVriAEeIGQCJxJmty7PEqob4MpIBkR3ilBdQO8CEm3D/Q2LLOoWSwYhXERFMkY EykRkWmuRCqzFDGSeskKr5CFpxm6DdquZMQuVoKkTwql1KsuM9GzbIS42kvC3tMIjjAJt/SIcswJ AhBHcRy0KWwJ47NCobi0p+ANLSyreuxCLLRHvoSO5TsrtPBHRkEL4RA4s2mwghQ/A4widGqc+kOn x5E6bao1PJSh3mAO6JA/XhkOYsFIc7K/x1mxdKEs/vsPf2pEkoyxkrwi9mi2kfyxlkzMsYAQL5od mmQohhKj/+KBNzSSvHzRkQtstzDqO8LTtnqRRefULRfBMo3SF+Npsh3Rl+U6GCXhHhM5IxicKZ7I yvBZRoe7mfpps/LpGfWxMzqxEzvhpIOrPUR7S/t8y7jMiLk8Qv6sSym8CJPDynfENJzLLwHbS6yI PnjMR+ZzjsMcimBihTLcvp+rK8jUyoj4Mcu0OhXbyORgut5QP4ictVsRMeXAIYtEUcZSitRkMRhD HRfrv9ic0UdMO2pKoWaLltvsj36MHS+CSZmkSSH9SRG5HZjqEIwCEd+ayeeUF3nJO9fCIyTzNns5 zhI0noMRmDuCqX0rkYv5ziRBJOzZip0AvZYRL+qyM1SaK/+CqzOGeD0w2UZrtEZtXAhrnIiPO8L7 HAmRMIlzFMeTwAiR888oDD5VKQ4AY6DFWSAEDQrrswqY40Kao76+TBSs4ZqvEY6AJBU2ZSaUQZBk ySFBFA4aMhxb+FANg6Eh+o3cMBZAHE2YAwrTNKfGukwXRZe28I9F5LEZDcnOstGRvDH4CFZ1kVWt 2E1kDdKfTDLEW84YmaiDGR5yq529EzfXes7WMjwxEsVV/Lbdsi17cZERYRgUQcEU8Zgyc550TbJG WhUaTAiv5MY7M0+e4R/VK0uaKRP4fIZbqEaHSAZfwBP9uYiQe8tjYAWQWAVI6dPbI4C6mUt1lMK7 rIie6DX//DpQRBHMBFWU/JqK/po+vqQ+qbg0qbmaSamUxswUp1LPBpOnUGU5xbGanEM+tSgnH2oc 89sVAVGWikycYhLVc1Kn+vuhF20L1Mk/SuzV2dRRlZzNHLXNHTUQyunRZAVS3xTSMMLWDvmdF4k3 b3tOZvWEPIgX1yqeIQ3bWdS2okTKu0sejWGRQAIYdAVGitEeYELDR3rG9IwZ8drbSPouhvspriS9 ggAggu0IkzgGkFhchXVLjbBLh41YiV1HnJDVjg0KeiQKn/BCl/vYsjpQSe1CMLzH/to0TzvWrhmm 6Aq6BmvZ/cgwjVzUtJBZq0GL2p3dX6lZoDhV55DIXAMn//ibNV8hzZ5YVK2rv6RYUR8Su2JDrGQj QCzyVbxhWuidXmcLQBozSXWBnK/wUSAFo99UMuD8qIrBETeCo94CvNshBEyAECTzBDuYl72LXw50 TrPVNqMMV3xBkj4SEXKVmI7x0o05I5g6EYBbs+85RiDcSpzSpK3UrpuB4IBVmvd6WPtU3JDAYIYd ucklvv+0qlv62bQATBJ2VJDVWI19PhMmCqqwuXuEBevbCgmVUArCFIoIv1ban+twOpjFSJ7gpdql XdvVieLISPlTyFobhRYyv98wHOK4lMTRyBS7v8rCDrFzTQGhnNd0tZUcnRvFsUnUXjD+YmZTNnIx Vu/1Iv8vop3lpCi7K0HgabydlDdwKzyyddIL0dYIcdJmpcl0uyMZocXGC5EcwS0VKSSUKhJ/e6nC kRCrLNMErkE5m5+fGT+fKbhLGj82pM+PK9iRQNgM1mC3zFPJNT6MIBWbICBC+1mLFUOOLeGaK0zl 69hEkT7/Worq640YLkMHGabFaQtRIbo19IXKAsSe7bUf3omfuF3GtBrVvcozzF1euVn325Uk3pWe LeKN7FAqjg7mVZ1jk1GAOrtK/LFIdMRlA8AcO5zTTdYfbYXgTKhntRiDWRGufcBoLUWMshd5qd9P rBdVwKg9zmNqFTdxozIu6xAUtBGGOWRD5pHp+U4O4VL/HJnKrpBVNhsfNt2UZcwzrkyfNwuqhdPk kntYTyYJkADlxWXYQIVCRRM+QyEVT61gy43VfdRcLVRh0Z05FtbpATthW4aOvvRcn2irsWiQi15d UzoZLPk1HLoU/WrlKAabYVLdZMbdjQSx5RhR+AtE0qTZWlWsoaWsRNwh0ola67VN2ITezdKsqJVa r66UqiXbrM0tgbmdOgoRIUlfdYNSrL3jCGzSeGnfeCk8f47SP2JoxWYYxg4YE/GX6fFfkfmX6rmY 6lHAT+CJUWCLXLiFqGJqlsES8wSvkS4T+bnB8Wm0cbxgklDYY2hcls5TiRU++1LP+4LZmxZDRcXH E37l/+er5Zl7uaCu1F1iK0qhYa6ILhzW6FEdVV9LUTNsq+KtXZvtlYjUsPj7TFJtbg4Na+hoJxhN J3jyVewV47O+UXWmphy1UQMhFxua2a6QOyAdaIZqnnvRoxfZayO1suzpO+Ec0ovC1kKgEEIohNQK ylYczsdebAYvLstjo+nJEez5l3P1UpjK7O0Jm1no7J0By1JRk5pRPT8RlZUQuftc3GhwbZbmCHVU woltifkiyJvQZsVhoI6Nvnps4VeutN/e3ME8UJ4eCgjqmkhhKxv2Pv4RiCi26VHt7litmmGZXSjP OcYMluDYlRlqbgCj1UJUXiJCxGR53nEm4zFe2mUzyf+++uIaqyJ38mpfqhT53mN5CTcvbbKLGcFO pJgN9LvotF9mndIwipD4tck539Y8UkotdSjGZnAtBZ7oyZDMyzwnMRKpJGDtAYop0R/qUk97jbPS PpOdqeASZ22UzmBQdsv9VEcAHb4CQrlN9riKZfKfBsxbxselQOGbJmGedmGO9ZruHYuwkG5HWupO 8YWiAFqN1CHh9UviLTBlrt0lh9VesW5BNN4TszpD/O7XDCLHEfOTXFpiZZ3MKm8DLPciQjb7s9SX fBAICdJ54ZH73pciQzwRcU51w6i8y7vEWzIl+0SyPexQ/DZXRKgKUeziYuiTGhIYoXCGN5G5pcq6 HRn/WZASYOiFW/DsauSFXwDtLBE91IM42jsVPF0JlDjxUn/tkvAI2U6JVTdl41OGU24aBBogig01 xClhwcxCmbt1Wv4vE7a+wiRu/oryxOyKGW4FSBGLCPrlnwttYz8xYEux3kW/ynzyIk6U5KvyxXJJ GhdEbA9E6WAny9Jib+bVpP1V9s6slcTRg2xraOEN/rshAiv62PleZY1ADcEjmJqtI+1js21WKeWt EdH3sg3sdstW+TV8KqsXCHE8hjn4c+Oycf3F6JmeJNk3unNkeB6FLfo5wlXg03M4BmsqkkfcxHVL DC51VHcV/4RpVgcrsGIanAg1sMb5L2SK4SZqnp6+/6ogXRdmUQg9XUd5F+KHFExNbqYnJdYrCPGu rEPpD+sIEKgZItUUHFoDJ7E+9kQtaqrmtZ6A4u1GnIQcsWHb9pydDv/w9m+PXmAt44BSe+qFoucg XgWS6/lWY5mMZyS7rewBiEKfMHk6VdBgoVMJPS1MuNATJkwGPRVcqJAiRogUTxEqlPGjQY6EPBEq qeqUxIiYNK1kydLQykKaThlSOErTp084Nd0c+OnUKE8/N7by1KrVqF69ZvnK5YvXs6dPeVGtymuq L6lXtVLt1VVpr11id0WLFe0s2mjH0K5de9Yt2lgExsYau6tu2Ly79PIS27fXhV1/xfaKZVjWYcSy WpzJkuWq8ePIjidHfuUY1qvHll/B0izLsufNlC+D7mza1WnHrmKtbhWLFatWsGHLjiZbduyjrFs9 btxLVi9bV7dmfdroOPLkypczb+78OfTo0qdTr279Ovbs2rdz7+79O/jw4seTL2/+PPr06tezb+/+ Pfz48ufTr2//Pv78+vfz7+//P4ABCjgggQUaeCCCCSq4IIMNOvgghBE+GBAAOw== ------=_NextPart_000_0011_01C19B79.50C1A2A0 Content-Type: image/gif; name="Citrus Punch Bkgrd.gif" Content-Transfer-Encoding: base64 Content-ID: <001001c19b25$7f0df180$5f178690@AlleyneLearmonth> R0lGODlhmQB9AKL/AP//////zP/M///MzMz//8z/zMzM/8zMzCwAAAAAmQB9AEAD/wi63P4wykmr vTjrvccAXxUEQCGZXKo241p5yheKJUm6T4vvzEgAgV+GYAreMkYerYiyfAICkJJyTFWnvJGB1MQC BdDAAHxlAc+ZQhfTIgTPZa8cMtLNJQeAW1Es6RdrEUl3AjM9Jj8miDZCd447XDVxj5SPMFZwUkc3 AQUkjYJolSs+LTZAXDacnxmGC3ajXgUCs7MHk7G5lTZRrrpzuBZ1aMFUCsW/yQuJUZTNfCU/yMrC Y1JgohgFP6C7ewZ+1BgD0zsfz1jlIjrq4u6hpi6n2e/1ECbo9vrH1uTYFUU60dsnrwksYTUc9GJz bN6cRE6oBUIIpJuEdlM8+TkoB/8KGBm+epzC6IAkBBgwoDyRQrAkuSdQJjhcMeuEwEZvqIWUWfFV S0FEWHEoZfLFtoqMZsopRGJMmJ89jmW6lfNCUajyeGa6aoYj1JGfEEEjkSfJjYmVUGJdKzXZtJg+ o8Blq0IopU01LNK9oHYgBAIDAOt15GbR3gbnAID552KPslODS/o8nCJxOqlcRbalzLmz5wW0PhO8 ZMUNONG/+pFDWCQyasyVyGDbWXKP19cP1CAdimuACRlWDxS+ozEzFiECSXoi4iKgcZmK+rxgOSoI WiqDaDyNZcPTVZIxVY5yrc+s4zkfZTRdtxkT1rNKecD055cFp/pzDG9ajI3x3hH//pSTVAoHXJdD JtvE54gYuF0kxRpJiAUHeY8Uop004RhoTx5+MLGRBvd5YWFDZ8wSCX4NbsBcKjwAZt4vDDaz2l62 7QbiTwvR9k48MSmykXQ8PYebjnSggs0ktx0oZIoLkKbZSFPEkU9jBICxRR4CnJaGKnp8MohGNUJj z0e9EBllaM/5gIIQ0qCZCZOCfAQnNZnxQsJHSxKk4UWroDIndw66xmWeeYp2A5sc3qXYMoWuVQ5g IOzphZeS/hdDjhhAmmh1HaK41mJOLZbkBHkwp8sbh1L2xEJzmAkMEiT+qZCrN47KEJeyOkBrrZ4i pGCurzYKrCx5VDqsPgX4Zuyx/8hqxKwjTvIpAaTLPivCDALCYWC11l4UwlxU7AEknKWMEsJq/sGT oLWm3pGSqOydyCxy58EawbnbadeeEmdBxa1UegU4InbrCtsQixRES9yadZECxKZ3DOOst9QRpgCG sP4qQrIG12ZKvRMA90g8N2KsjY2ULNedOmGUiYRTvm5gAjjq+PiLbe0u2LLGZmyA6nUdI+FGJyBP OpsmSHA1ca+5GGFd0ECsxOCubw479HAdiSqnVZOVlwnV0v5r1WIgtBMid/Kueul6h0UhJ8t+Qt1A cQps0aRitmJlYbpayc3AUTUFsAWF1p4tc2jCCGaWMmC/gjW/OxQ7kVCdROK3g/8XKCLu5Sm4UWUT 6yrCiKRQzygIIyWK+Z4nBqAgFphmJ9SRA2ItLu9ndnFwtbBHLIKh63MSLlMqhd6Hj+rd+uz0vlZx rgF9hw2DcvME3SAbuF/pIJ3Zzl/wT75flahKa3nHnfxlx4SJyiLIQHk+A42/qaBAkgTJdLeuslN1 w/cnTyTJUTpQlBJEwO4FsH/VQwo3lkYR3yXBcxfzXCLoxxcBykFhsuiJ2C4GDQI4ZiTiSh0Dk0Gm 8EyJMnZRxRuOEiEIvu9UsHlhVM5hQBk6SACioqEN3bEfMTBoWBA7oM/oUD5Z4UJ6W2GevXYYihw4 JDsUYYALmYg5XWywQV24D16RxtOlK75GAFOMWjhmt8V/ePFPmhtZbUAgPNT4w1W+GWN1UCWrGZzL KoJRBkRqGCWVhAF8wrhFMkLIRxx86484TEGy4tccMNisMwH6AtusYDdduHCE0tJJ2bAnHxhBMFuF jEFaKpYF3lnLdJArHgJFs5JJKfFGeHsWKlO5yiLxDE6MNMYrb1VLKvbslvrypawSAAA7O56jxumI CKN7sA2Wk9zMHCGUv2KIjA+bzAey8LchrFAMSR60VtL2oEAymlGa+aoWXx4YrmPyKSJjQl0iGVfN BqZynLuIAAA7KqsGGHsPF3bot7U5/6pZkWnqdJoBaqY2tmgwHr5e1skBEJbBvzEuZ6Vcl6j4uQrF nbl6V12umUCN2dYbAGlL6/mt9bVtrbZ9rR6xit6m3nJ3fhkZLOwIDtx3yN39FJrr+UnYsUwnnwtq rmIHm7MBw6eXPNbPB7u3UZu16O/pl12P/ZypAr+9l7b5LPn3GvrsPfkoxW4W0wZ1j/55K4W90ern v98UxA1xmO74VY57mUrZIQ5HlsK/OZGABPUTiaFmBaYFAQ19UCLWWhQCQKRhqENK4kqHEiibuxWo aAL5DYJotRQPnceBW2FI8aKlFw7SSXJXykoBFeLAz7RrenY5DXXEFaW1mKBgwinhf/9a0qsPGe6D PXwIzGbIkKoR0G+Zi9wKpSKpjCRRiWtKXkd4t5t0Lchn2RNLWLIllWK5BYqNw5t/TECUDyEMLAgr kKuCwkQxlbAEbYzLu2A0FgQAKXqrstoDoyIig4XFj8TRHt7k45HmcYlDLnzIIR/HQKxdUTg6E4iM RCjCOtqlj++alHEAORIjnYRNyYkcKdkzlsf9cWH1iWRIhKYTNoFwbLqKj0gu5iucHOAnGwvOFDOi I0LWZHf9UtMsd2ipSVVLZZ40inNc06TaBcl70STIMG/iJJ15EHx4ZBZQfOc/ZdlqSVXRkYEMFEn8 zG2VHeEQ/AJHsmm181S3pMwXM3j/NpUBh3L2W8tnZjawVVoGao/CUpvgY1DC4M6R8zmLf8BGrmyO ZEoW7B+DauWSjrKPRg0N6OZ4NJUrDQUnJjSLIkUKAIj26yxkTA5RrqbSI7I0IS4tDv9WetOtjZSn xaqLJ1HFxiSYj09l49yq8uKzJOTFhUFqHTuJhUDAFfM1ZYrLNqPCVJ+IRG57yVibiKXMvrDnN09b nsdMw0hTJsYtciNnT7+Uq7nq5yIftWt1PMI837hSr+KJiW8mRr7nOOtzsPHaXI8zGp2SxKJaG456 xgokgwATsMjpzj3HRiGH9RCylkWMXg1w2a70jXWCFUjOdLJZ7IEEjB86TE5+ib6HezUEL00yHnVA yxuM4jBHvNRsWHn7LdhVESI3au0uvXk7vMZpIjcy7G6EhhjiWuWhWw3MfXjzTjSC1GQoKsySgrMY ZkKPvNk1CkKpx8RRWpc56utTSLkJy8vF13rzdY9i0ZfeoAL1lflFqksZqqnH/hez8rskfHaGYM8F BAA7 ------=_NextPart_000_0011_01C19B79.50C1A2A0-- From attila.lendvai@encorus.com Sat Jan 12 02:30:02 2002 From: attila.lendvai@encorus.com (Lendvai, Attila 101.) Date: Sat Jan 12 02:30:02 2002 Subject: TUNES Message-ID: :: >>> if you're willing to write a system that adds features for other :: >>> browsers without sacrificing compatibility [with CLI=20 :: browsers] *snip* :: >> Well, thats quiet simple with an intro-page, which has a=20 :: link for [...] :: > Just do it - you seem to know better about it than I, anyway. :: > If you don't have write access to the CVS yet, just fill in the :: > membership form and ask an account to root@bespin.org. :: Is that a Joke? I mean you don't know me, and I didn't even tell you=20 :: that im here to overtake the project and cripple it, by order of his=20 :: billyness ;-) :: Also I don't really know anything about programming and what=20 :: exactly is=20 :: a CVS? :: May I now add my own homepage to the project? i belive in that people dont do harm without any point... and i mean _without any_! noone would even start arguing with you, no fame (low trafic site), no nothing. simply a backup would be rewritten and you removed from the users... cvs is code versioning system. a server that keeps track of changes made to files... you check out the cvs tree, make your local changes and then check in. it can be done by many people simultaneously. :: well I would write a new faq, and put it into the=20 :: introduction/welcome=20 :: part of the homepage, and then use the old faq as a base to=20 :: grow from in=20 :: the documentation. i think the current faq is good. there were toughts that there's no point in collecting many enthusiasts with little CS background because they can not help the project to develop in it's current state. later when there will be some environmnet where you can try your new ideas... (btw, i'm also one of these, i dont have the knowledge to work on the core of the system, but i have many ideas how to write smarter code. i'm just lacking the appropiate language...) talking about the core, Brian, do you have some news to share with us? :: I still don't get the diffrence between a runtime compiler and your=20 :: approach... but its 4:20 at night, and il go to sleep now, maybe i'l=20 :: understand tomorrow. to make a language statically compilable you must have this requirement when designing the language. java, c++, etc are all statically compilable, so you can not have second order functions (functions that process program code), and things that are only available in a runtime environment. i think what you are thinking of are for example the java JIT machines... they are runtime compilers, but the code they are working on is still statically compilable without the nice features of a dynamic language. (i'm a newbie, correct me if i draw a blurred picture) bye, 101. From kyle@arcavia.com Sat Jan 12 07:38:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Sat Jan 12 07:38:02 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> Message-ID: <3C40582A.7046A81F@arcavia.com> The reasons for a particular language preference appear to be lacking in the TUNES discussions. I would like to see more detail on the benefits of a language that is claimed to be better than another. For instance, I doubt that Lisp is a superior language to Java or even C. I would rather accept that it has certain aspects that make it superior. The separation of a language into it's semantic aspects allow the TUNES community to see the benefits of these aspects and be able to construct a better language that contains them all. Ultimately all language aspects compete on the field of semantic efficiency. It is important that each of these aspects are demonstrated in a code example to show their semantic efficiency. For example, the difference between C and Java can be summed in three aspects: Java has garbage collection Java has inheritance (limited polymorphism) C has function pointers The advantages of one language over anther give clues as to the aspects we would like to incorporate into our TUNES HLL. My comparison gives a clue to the advantage of allowing function objects in Java "JPP - A preprocessor for the Java language" (use Google cache). This new advanced Java is better than either language. Now let me tackle Lisp and it's advantages over C and Java. Note that I have limited experience in Lisp and Scheme (I am able to read them, but writing is another matter). So this post will be the beginning of a two way discussion over the advantageous aspects of Lisp over Java and C. Here is what I have come up with. All compound objects are treated as lists. Function references, using quotation, are available. Lisp syntax is simple The first advantage can be easily overcome by using library functions in any procedural language. I have seen a comparison of Lisp (Prechelt?) to C and Java with respect to development time, with Lisp winning. The positive result was a side effect of having a string intensive program requirement. Lisp naturally handles strings, but Java and C require the developer to make/find good string libraries to compete. The second advantage is significant compared to Java (as discussed), but not too significant with respect to C (which has function pointers). Many Lisp "superiority" examples compare themselves to "equivalent" C programs, but I have yet to see one that does not use a deliberately verbose C equivalent. The last, when combined with the second may be something significant. It allows for dynamic specification of functions. But it has been my experience that most dynamic function specifications are simply generic programming with partial evaluation. C does this easily (albeit inefficiently). The rare case of true dynamic function specification requires a compiler to be added to either Java or C. Java has a minor advantage over C here because an object framework already exists that can support a dynamic compiler. But even with a compiler, the simplicity of Lisp syntax allows for simpler automated specification. Unfortunately, the case of automated function specification is so rare that I have yet to stumble across an example that exposes a Lisp semantic advantage over C or Java. SUMMARY I have considered these aspects and included them in my own language specification, especially the step of simplifying the language semantics. But my inexperience with other languages (such as Forth and Haskell) makes me unsure if I have included all the advantageous aspects from those languages too. I would appreciate if the "experts" in these languages could come forward and describe the beneficial semantic aspects, and give examples if unclear. From bpt@tunes.org Sun Jan 13 18:04:01 2002 From: bpt@tunes.org (Brian P Templeton) Date: Sun Jan 13 18:04:01 2002 Subject: TUNES In-Reply-To: <7C0F6A23-070A-11D6-9309-003065AD94A4@mac.com> =?iso-8859-1?q?(Bj=F6rnke?= von Gierke's message of "Sat, 12 Jan 2002 04:14:26 +0100") References: <7C0F6A23-070A-11D6-9309-003065AD94A4@mac.com> Message-ID: <87u1tq3n9e.fsf@tunes.org> Bj=F6rnke von Gierke writes: >> Should be a Cc: - and usually the sender doesn't mind receiving a copy >> (he might be unsubscribed to the list), plus you can remove him manually >> from the destinations, if you know for sure he's subscribed. > Err... thats on purpose? Well, thats the reason why most people hate > computers :( >=20 > the originator sends a mail to the list, is subscribed, and I reply: > as is "reply": > Header:(to:originator) > mails received: originator: 1 list member: 0 myself: 0 > as i suggest "reply to: list" > Header:(to:list) > mails received: originator: 1 list member: 1 myself: 1 >=20 > the originator sends a mail to the list, is NOT subscribed, and I reply: > as is: mails received: originator: 1 list member: 0 myself: 0 > as i suggest: mails received: originator: 0 list member: 1 myself: 1 >=20 > Now we have the same causes when users rearrange and uses the "reply > to all" feature: > as is: mails received: originator: 2 list member: 1 myself: 1 > as I suggest: mails received: originator:1 list member:1 myself:1 >=20 > I think that you would like that the originator always get's a > response, but hes only one, and thus i think the list members are > first priority here. Also if he want's a response, why doesn't he > subscribe to the list? >=20 >>>> if you're willing to write a system that adds features for other >>>> browsers without sacrificing compatibility [with CLI browsers] *snip* >>> Well, thats quiet simple with an intro-page, which has a link for [...] >> Just do it - you seem to know better about it than I, anyway. >> If you don't have write access to the CVS yet, just fill in the >> membership form and ask an account to root@bespin.org. > Is that a Joke? I mean you don't know me, and I didn't even tell you > that im here to overtake the project and cripple it, by order of his > billyness ;-) > Also I don't really know anything about programming and what exactly > is a CVS? CVS is the Concurrent Version Control system. Although IMHO PRCS is a better VC system, CVS is more common. Other versioning systems include PRCS, RCS, Aegis, SCCS, etc. From FOLDOC (following some references from the definition for CVS): __________________________ ____/ `dict "code management"' \______________________________________ | 1 definition found |=20 | From The Free On-line Dictionary of Computing (07Oct99) [foldoc]: |=20 | code management |=20=20=20 | A source code management system helps program developers keep | track of version history, releases, parallel versions etc. | There are several in popular use. |=20=20=20 | (1994-12-23) |_____________________________________________________________________ > May I now add my own homepage to the project? >=20 No. When you join the project, you'll get a Bespin account. After placing your WWW files in ~/html on the bespin.org machine (using SCP or SSH), you can reach ~/html/foo with the URLs (assuming you select the username bvg): http://www.bespin.org/~bvg/foo http://www.tunes.org/~bvg/foo and, if you ask Tril to (if I'm guessing right) set up a new Apache virtual host (it's required if you want to use CGI, and otherwise optional): http://bvg.tunes.org/foo Your homepage is separate from the actual TUNES Project pages. >> The problem being here that we lack coherent documentation outside of >> the FAQ, that the FAQ could point to. In absence of it, a two-sized FAQ >> might do. If linuxdoc-sgml can't handle it, we might migrate to HeVeA >> or to TeX2page. > well I would write a new faq, and put it into the introduction/welcome > part of the homepage, and then use the old faq as a base to grow from > in the documentation. >=20 >>> Listener? well ok it crunches strings... does it understand sentences? >> Not unless you teach it too. >> Begin simple, elaborate as you go, refactor the simple thing afterwards. >> Be ready to see your code refactored, knowing that since the code AND >> the execution environment in which it was successfully run are >> versioned, >> so that you will be able to run your old code despite incompatible new >> refactorings, evolutions, modifications. >> >>> Or do you mean string as in "long" ? >> I mean "string" as in source code that you can evaluate incrementally, >> input from primitive but standard means of communication such as >> text file editors, line editors, raw terminal input, etc. >> > I still don't get the diffrence between a runtime compiler and your > approach... but its 4:20 at night, and il go to sleep now, maybe i'l > understand tomorrow. >=20 > have a nice day > bj=F6rnke >=20 --=20 BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From bpt@tunes.org Sun Jan 13 18:04:06 2002 From: bpt@tunes.org (Brian P Templeton) Date: Sun Jan 13 18:04:06 2002 Subject: TUNES In-Reply-To: <22A14BC2-06FA-11D6-9309-003065AD94A4@mac.com> =?iso-8859-1?q?(Bj=F6rnke?= von Gierke's message of "Sat, 12 Jan 2002 02:17:24 +0100") References: <22A14BC2-06FA-11D6-9309-003065AD94A4@mac.com> Message-ID: <87pu4e3my4.fsf@tunes.org> Bj=F6rnke von Gierke writes: > Much snipping happening in this mail: >=20 >>> Why cant i just hit reply to answer a mail to the mailing list, is >>> it my >>> app or the server? >> As with many mailing-lists, you have to use "Group Reply" to reply >> to everyone rather than just the originator of the mail. > My app only has a "Reply to all Sender" function. It adds "Bcc: > Tunes@tunes.org" to the mail header, so the originator of the mail > will get the mail personally, AND over the Group. Very annoying... >=20 Then he or she should include a `Mail-Copies-To: never' header in their message (if I remember the header name right). If your MUA ignores that, then it's broken, and you should switch to a more standards compliant mailer, such as Gnus ;). It's not as if I were biased or anything like that ;). >>> Me thinks it's much too clumsy arranged and unintuitiv presented, maybe >>> for compatibility with CLI-Browsers? >> Compatibility with CLI-Browsers is a requirement, although if you're >> willing to write a system that adds features for other browsers without >> sacrificing compatibility *snip* > Well, thats quiet simple with an intro-page, which has a link for > text-only content (as is) and more detailed (same content framed or > within a table). One could also Use javascript to redirect every > browser to a more detailed Page. As text-only-browsers do not support > javascript, they keep on the first page anyway, and can proceed from > there manually. >=20 Why not use Apache to redirect the viewer to the appropriate page? OTOH, the more I consider WWW page design, the more I think that, with a few modifications, it is easy to make well-designed pages that are compatible with text-based browsers (NOT CLI-browsers! I've seen exactly one real CLI browser; the other text-based browsers use GUIs). >>> Faq is too detailed, shoud only give simple clue about what Tunes is. >> On the other hand, I don't know how to do without details, or else, >> the answers might betray the issue and confuse the reader. >> Maybe have a short answer in larger size and a longer answer in >> small size, for every question? > A FAQ should only give simple clue about the FAQ-ed term, IMHO. > As a reader, I would expect the FAQ to contain short info on where the > project came from, what it is, short roadmaps, targets and methods > (etc.). All very short but with links to the adequate information in > the documentation. I.E. the targets part of the FAQ could explain the > general target, the quintessence but also contain links to the > examples, the HLL-project or/and the "Why a new OS?" article... >=20 >>> Is there already a deccission made what userinterface the first version >>> will use? (I mean that 'run on top of other os' -thingie) Is It CLI, >>> GUI? >> To begin with, we'd just have a listener, that takes strings as >> input, *snip* > Listener? well ok it crunches strings... does it understand sentences? > Or do you mean string as in "long" ? There may be some detailed info > about that some where on that tunes-page-thing... >=20 > *snip* >>> Wouldn't it be funny if the logo would be a picture with a tag on it: >>> "This is not a Logo" >> Could be nice. But not before there's code. > Before code comes info, which then can be coded so that the machine > understands it... but what info? I really have to dig trough that > homepage, it MUST be hidden somewhere, as the truth lies in there... ;) >=20 > uninformed > Bj=F6rnke >=20 > PS: > "short" sentences for the OSdev page: > We don't want to make a new OS, we develop a new computing philosophy. > It has to do with selfscripting code, relational > filesystems, metatranslation of static programming languages, cool > acronyms like "Tunes" or "HLL" and much more! We even > regret the idea of a logo, so come over and dig into our project! >=20 --=20 BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From bpt@tunes.org Sun Jan 13 18:08:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Sun Jan 13 18:08:02 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> Message-ID: <874rlp1x56.fsf@tunes.org> Kyle Lahnakoski writes: > The reasons for a particular language preference appear to be lacking in > the TUNES discussions. I would like to see more detail on the benefits > of a > language that is claimed to be better than another. > > For instance, I doubt that Lisp is a superior language to Java or even > C. I would rather accept that it has certain aspects that make it > superior. The separation of a language into it's semantic aspects allow > the TUNES community to see the benefits of these aspects and be able to > construct a better language that contains them all. > If Lisp (what dialect? Common Lisp? Emacs Lisp? Dylan? Scheme? EuLisp? ISLISP? XLisp? XLisp-Stat? ...) has ``certain aspects that make it superior [to Java or C]'', then it is /ipso facto/ superior to Java or C! However, you later seem to indicate that you mean that no language is syntactically superior to another - but you fail to define `semantic'. Where does syntax end and semantics begin? By the time you mention that Lisp doesn't use traditional-style infix syntax (where a few operators are infix and function calls are prefix), but rather uses prefix syntax, does that demonstrate that Lisp isn't as strongly biased toward certain operations? When you explain that Lisp programs are not simply streams of characters, but rather print representations of objects that are read back in and evaluated, and therefore Lisp programs may be considered sequences of objects, does that imply that metaprogramming is easier with Lisp than the other languages? If you want to discuss semantic aspects of languages, then define `semantic'! > Ultimately all language aspects compete on the field of semantic > efficiency. It is important that each of these aspects are demonstrated > in a code example to show their semantic efficiency. > > For example, the difference between C and Java can be summed in three > aspects: > Java has garbage collection > Java has inheritance (limited polymorphism) > C has function pointers > > The advantages of one language over anther give clues as to the aspects > we would like to incorporate into our TUNES HLL. My comparison gives a > clue to the advantage of allowing function objects in Java "JPP - A > preprocessor for the Java language" (use Google cache). This new > advanced Java is better than either language. Now let me tackle Lisp > and it's advantages over C and Java. > > Note that I have limited experience in Lisp and Scheme (I am able to > read them, but writing is another matter). So this post will be the > beginning of a two way discussion over the advantageous aspects of Lisp > over Java and C. Here is what I have come up with. (assuming you're talking about Common Lisp here) > All compound objects are treated as lists. How do you define a compound object? Something other than a symbol, number, or character, perhaps? Then you're incorrect. > Function references, using quotation, are available. Huh? Functions are first-level objects in CL. > Lisp syntax is simple Yes > > The first advantage can be easily overcome by using library functions in > any procedural language. I have seen a comparison of Lisp (Prechelt?) > to C > and Java with respect to development time, with Lisp winning. The > positive result was a side effect of having a string intensive program > requirement. Lisp naturally handles strings, but Java and C require the > developer to make/find good string libraries to compete. > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to naturally handle sequences (lists, arrays, etc), dictionary-type objects (alists, hashtables), and functions. > The second advantage is significant compared to Java (as discussed), but > not too significant with respect to C (which has function pointers). > Many Lisp "superiority" examples compare themselves to "equivalent" C > programs, but I have yet to see one that does not use a deliberately > verbose C equivalent. > > The last, when combined with the second may be something significant. > It > allows for dynamic specification of functions. But it has been my > experience that most dynamic function specifications are simply generic > programming with partial evaluation. C does this easily (albeit > inefficiently). > I haven't yet seen lambda in C, but I may have missed some language feature that makes it possible. > The rare case of true dynamic function specification requires a compiler > to be > added to either Java or C. Java has a minor advantage over C here > because an object framework already exists that can support a dynamic > compiler. But even with a compiler, the simplicity of Lisp syntax > allows for simpler automated specification. Unfortunately, the case of > automated > function specification is so rare that I have yet to stumble across an > example that exposes a Lisp semantic advantage over C or Java. > > > SUMMARY > > I have considered these aspects and included them in my own language > specification, especially the step of simplifying the language > semantics. But my inexperience with other languages (such as Forth and > Haskell) makes me unsure if I have included all the advantageous aspects > from those languages too. I would appreciate if the "experts" in these > languages could come forward and describe the beneficial semantic > aspects, and give examples if unclear. > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From u.hobelmann@tu-bs.de Mon Jan 14 02:49:02 2002 From: u.hobelmann@tu-bs.de (Ulrich Hobelmann) Date: Mon Jan 14 02:49:02 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> Message-ID: <3C42B791.E9F8B376@tu-bs.de> Kyle Lahnakoski wrote: > For example, the difference between C and Java can be summed in three > aspects: > Java has garbage collection > Java has inheritance (limited polymorphism) > C has function pointers I'd claim that Lisp first class functions are way more powerful than C fun-pointers in that they capture an environment. Concerning Java's OO features, well, I don't like the fact that functions and types are kind of thrown together here: compare this to Haskell, where you can have arbitrary sum&product types, while limited polymorphism is handles via type classes. (BTW: can anyone tell me in what way Java's inheritance doesn't correctly model subtyping? this was hinted at in the TUNES-glossary->Inheritance ... ?) > All compound objects are treated as lists. > Function references, using quotation, are available. > Lisp syntax is simple I think the point here is that the C type system is _very_ weak, and there's no safety or GC, so writing List code is very bug-prone compared to Lisp. Also, in general, most Lisps have other types like vectors and records. Other Lambda-based languages like Haskell/ML use these other types much more than lists... > The first advantage can be easily overcome by using library functions in > any procedural language. I have seen a comparison of Lisp (Prechelt?) > to C > and Java with respect to development time, with Lisp winning. The > positive result was a side effect of having a string intensive program > requirement. Lisp naturally handles strings, but Java and C require the > developer to make/find good string libraries to compete. To me the bad point about Java is that in Lisp you can have Objects or structs, while in Java, expressing functions (via interfaces..) is sooo ugly... (Hmmm... wasn't Java developed by James Gosling and Guy Steele, two Lispers???) > The second advantage is significant compared to Java (as discussed), but > not too significant with respect to C (which has function pointers). > Many Lisp "superiority" examples compare themselves to "equivalent" C > programs, but I have yet to see one that does not use a deliberately > verbose C equivalent. Usually, when you directly translate C into Lisp, you immediately notice several points which need improvement, because C code is more bound to restictions in language comfort, which Lisp is more free-form and doesn't restrict you in any way. You can even implement your own syntax macros. > SUMMARY IMHO the only advantage of C is direct control over how data is put in memory. In all other points the language has too many unnecessary restrictions (and not even tail recursion!!). For a better done C, google for Cyclone. Java, OTOH, has _no_ single advantage to me, meaning every good point in Java is done better elsewhere... Greetings, Ulrich From kyle@arcavia.com Mon Jan 14 05:32:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Mon Jan 14 05:32:02 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> <3C42B791.E9F8B376@tu-bs.de> Message-ID: <3C42DDAC.D89B4EF@arcavia.com> Ulrich Hobelmann wrote: > > Kyle Lahnakoski wrote: > > For example, the difference between C and Java can be summed in three > > aspects: > > Java has garbage collection > > Java has inheritance (limited polymorphism) > > C has function pointers > > I'd claim that Lisp first class functions are way more powerful than C > fun-pointers in that they capture an environment. Maybe you would be so nice as to provide an example where the "powerful" aspect of first class functions shows itself by shortening code length or reducing development time. > (BTW: can anyone tell me in what way Java's inheritance doesn't > correctly > model subtyping? this was hinted at in the TUNES-glossary->Inheritance > ... ?) See my document http://www.arcavia.com/rd/document/Function%20Inheritence.htm > I think the point here is that the C type system is _very_ weak, and > there's > no safety or GC, so writing List code is very bug-prone compared to > Lisp. I will grant that C is bug prone, but in the same note I am unsure how safe Lisp is. It strikes me that Lisp lacks type information; I am able to pass anything I want to a Lisp function and it will not complain unless it runs out of symbols. I could certainly be wrong here. In any case, I think we both agree that strong typing helps reduce development time by reducing human error. > Also, in general, most Lisps have other types like vectors and records. I have only seen these implemented using lists. Maybe there are Lisp versions that implement these natively. > Other Lambda-based languages like Haskell/ML use these other types much > more than lists... So would you consider this a good thing? > To me the bad point about Java is that in Lisp you can have Objects or > structs, > while in Java, expressing functions (via interfaces..) is sooo ugly... > (Hmmm... wasn't Java developed by James Gosling and Guy Steele, two > Lispers???) Yes, certainly a deficiency in Java. > Usually, when you directly translate C into Lisp, you immediately > notice several points which need improvement, because C code is more > bound to restictions in language comfort, which Lisp is more free-form > and doesn't restrict you in any way. Maybe your direct translation of the C code is because of poorly written C code. Do you have an example? If you prefer to wait until next time you stumble cross the scenario you describe above, send it to me then. I will remember this conversation; it has bothered me for years. > You can even implement your own syntax macros. How would you say these macros are better than including a compiler library to C, if at all? I would love to deliver examples of Lisp and C to show they are very similar, but any example I come up will be disputed as contrived. An example can only prove my premise false. Unfortunately I can not think of one because I believe an example does not exist. Thanks From kyle@arcavia.com Mon Jan 14 05:32:10 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Mon Jan 14 05:32:10 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> <874rlp1x56.fsf@tunes.org> Message-ID: <3C42DDBF.2869157E@arcavia.com> Brian P Templeton wrote: > > Kyle Lahnakoski writes: > > For instance, I doubt that Lisp is a superior language to Java or even > > C. I would rather accept that it has certain aspects that make it > > superior. The separation of a language into it's semantic aspects > > allow the TUNES community to see the benefits of these aspects and be > > able to construct a better language that contains them all. > > > If Lisp (what dialect? Common Lisp? Emacs Lisp? Dylan? Scheme? EuLisp? > ISLISP? XLisp? XLisp-Stat? ...) has ``certain aspects that make it > superior [to Java or C]'', then it is /ipso facto/ superior to Java or > C! Please choose any version of Lisp you want and tell us about an aspect of it that makes it better than Java, or C, or any other language of you own choosing. > However, you later seem to indicate that you mean that no language is > syntactically superior to another - but you fail to define `semantic'. > Where does syntax end and semantics begin? By the time you mention > that Lisp doesn't use traditional-style infix syntax (where a few > operators are infix and function calls are prefix), but rather uses > prefix syntax, does that demonstrate that Lisp isn't as strongly > biased toward certain operations? When you explain that Lisp programs > are not simply streams of characters, but rather print representations > of objects that are read back in and evaluated, and therefore Lisp > programs may be considered sequences of objects, does that imply that > metaprogramming is easier with Lisp than the other languages? If you > want to discuss semantic aspects of languages, then define `semantic'! Choose your own definition and provide it here. If you believe that infix, prefix or postfix notation are in some way better then explain why. If you can provide a measurable difference between Lisp-programs-seen-as-streams-of-characters or Lisp-programs-seen-as-print-representations-of-objects then please do so. When it comes right down to it, all Turing-complete languages are identical in expressive power (e.g. implement a compiler in language A that handles language B). We only have our intuition to understand what semantics really are. Now if you believe that my compiler example is contrived, I will say that I am surprised how often some C programmers use to lexx and yacc to make small language parsers. Below I have my attempt to define semantic equivalence, but it only manages to show that all turing complete languages are semantically equivalent. > (assuming you're talking about Common Lisp here) > > All compound objects are treated as lists. > How do you define a compound object? Something other than a symbol, > number, or character, perhaps? Then you're incorrect. How am I incorrect? List of lists are still lists. A simple example would be appreciated. Records and vectors, of what I have seen, are implemented using lists. > > Function references, using quotation, are available. > Huh? Functions are first-level objects in CL. Forgive my poor nomenclature, function references, via symbol or explicit symbol list (e.g. function definition), is how Lisp is able to make functions first-level objects. > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to > naturally handle sequences (lists, arrays, etc), dictionary-type > objects (alists, hashtables), and functions. Good, take that one step further and see that strings are lists of characters. Lisp has many list manipulation functions, and therefore string manipulation functions. > > The last, when combined with the second may be something significant. > > It allows for dynamic specification of functions. But it has been my > > experience that most dynamic function specifications are simply > > generic programming with partial evaluation. C does this easily > > (albeit inefficiently). > > > I haven't yet seen lambda in C, but I may have missed some language > feature that makes it possible. Generic function specification with (apparent) partial evaluation can be done using the usual procedure definition in C. We both agree that lambda is more powerful than the C function pointer in the extreme case of pure meta-programming. But it is the simpler cases (where lambda is used more often) that C, and its function pointer, can perform as well as Lisp. My post was a request for Lisp examples contrary to my statements. I already anticipated your dismay, but abstract descriptions of language superiority are only useful between people that agree. Since I do not agree, all this high level talk is for nothing; we will never reach a consensus without something objective and measurable, namely concrete examples. It really well could be that this discussion is for naught; there is no semantic difference between languages. This would help us understand why the bulk of the programmers are sticking with C, C++, Basic or Java. It could very well be that language preference depends wholly on the number of, and quality of, tools that support that language. //MY ATTEMPT AT DEFINING SEMANTIC EQUIVALENCE We will define semantic equivalence on two programs A and B if there exists a modified PDA (call it an "IO-PDA") that can convert a program A to program B. The PDA modification is a simple addition to the transition function so it can write output. Formally, we have a definition of a IO-PDA M = (Q, S, Z, d, q0, z0, F) where Q is a finite set of states, S is a the input/output alphabet, Z is the stack alphabet, d is a transition function, q0 is the initial state (member of Q), z0 is the stack start symbol (member of Z) F is a set of final states (subset of Q). All the definitions are the same as a regular PDA except d. Let S' = union(S, {null}). Let Z' = union(Z, {null}). Let Ai be the ith symbol of input A Let Bi be the ith symbol of output B d: Q x S' x Z' -> Q x S' x Z' (q', s', z') = d(q, s, z) For any state, input symbol, and stack symbol, d defines a destination state, an output symbol and new stack symbol. The machine is "run" by passing the triple {q0, A0, z0) to d and receiving its result. The result is then used to determine the next current state (q1), the output symbol, and the symbol to be pushed on the stack. Each subsequent step will pass the current state, read the next input symbol, and pop the top symbol off the stack, to d and receiving its result, and so on. Some d-transitions do not read anything from input and look like: (q', s', z') = d(q, null, z) Some d-transitions do not pop any value off the stack and look like: (q', s', z') = d(q, s, null) Some d-transitions do not write any output and look like (q', null, z') = d(q, s, z) Some d-transitions do not push a value onto the stack and look like (q', s', null) = d(q, s, z) Because of the functional nature of the IO-PDA we can take any string A composed from alphabet S and define M(A) to be the output string, given input string A. Anyway, we can define two languages X and Y to be semantically equivalent if there exists an IO-PDA, M, such that for any program A in X there exists a program B in Y such that B=M(A). We can see that infix, prefix and postfix notations are syntactically different, but semantically equivalent. This also means that if a few library functions can improve ... and it is here that we realize all turing-complete languages are semantically equivalent under this definition. From stderr@web.de Mon Jan 14 07:25:02 2002 From: stderr@web.de (Alex Thiel) Date: Mon Jan 14 07:25:02 2002 Subject: low-level approach In-Reply-To: <3C42DDBF.2869157E@arcavia.com> References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> Message-ID: <02011415031700.11642@hilbert> On Monday 14 January 2002 14:31, Kyle Lahnakoski wrote: > Brian P Templeton wrote: > > Kyle Lahnakoski writes: > > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to > > naturally handle sequences (lists, arrays, etc), dictionary-type > > objects (alists, hashtables), and functions. > > Good, take that one step further and see that strings are lists of > characters. Lisp has many list manipulation functions, and therefore > string manipulation functions. > Maybe I got that wrong, but I think list in Lisp are objects separated by spaces. So, in that sense strings are not lists. Cheers, Alex From attila.lendvai@encorus.com Mon Jan 14 07:55:03 2002 From: attila.lendvai@encorus.com (Lendvai, Attila 101.) Date: Mon Jan 14 07:55:03 2002 Subject: low-level approach Message-ID: :: aspects and be :: > > able to construct a better language that contains them all. :: > > :: > If Lisp (what dialect? Common Lisp? Emacs Lisp? Dylan?=20 :: Scheme? EuLisp? :: > ISLISP? XLisp? XLisp-Stat? ...) has ``certain aspects that make it :: > superior [to Java or C]'', then it is /ipso facto/=20 :: superior to Java or :: > C! ::=20 :: Please choose any version of Lisp you want and tell us about=20 :: an aspect :: of it that makes it better than Java, or C, or any other=20 :: language of you :: own choosing. well, i dont consider myself a language guru and i dont really know lisp, but im sure there are zillions of examples where lisp is better because of the single fact that code=3Ddata in lisp. :: When it comes right down to it, all Turing-complete languages are :: identical in expressive power (e.g. implement a compiler in=20 :: language A :: that handles language B). We only have our intuition to=20 :: understand what :: semantics really are. Now if you believe that my compiler example is yes, but we are not talking about math proofs here... :: contrived, I will say that I am surprised how often some C=20 :: programmers :: use to lexx and yacc to make small language parsers. ::=20 :: Below I have my attempt to define semantic equivalence, but it only :: manages to show that all turing complete languages are semantically :: equivalent. ofcourse, i always say in such cases that i can do anything in assembler. (given enough resources... :) but in a better language you can do things in 10 lines that are 10 pages in c++ :: > > Function references, using quotation, are available. :: > Huh? Functions are first-level objects in CL. ::=20 :: Forgive my poor nomenclature, function references, via symbol or :: explicit symbol list (e.g. function definition), is how Lisp=20 :: is able to :: make functions first-level objects. code=3Ddata :: My post was a request for Lisp examples contrary to my statements. I :: already anticipated your dismay, but abstract descriptions=20 :: of language :: superiority are only useful between people that agree. =20 this is a good point. altough i am against c style languages in this discussion i would also be happy to see some examples. :: Since I do not :: agree, all this high level talk is for nothing; we will never reach a :: consensus without something objective and measurable,=20 :: namely concrete :: examples. ::=20 :: It really well could be that this discussion is for naught;=20 :: there is no :: semantic difference between languages. This would help us understand if you always get back to the idea that all turning equvivalent languages are the same then no, there's no difference. but it's about something else i cant put in words in a foreign language... :: why the bulk of the programmers are sticking with C, C++, Basic or :: Java. It could very well be that language preference=20 :: depends wholly on :: the number of, and quality of, tools that support that language. =20 it's about the joke that a trillion of flys can not be wrong... :) i was one of those c c++ java programmers. (in fact there was a time when i learned generic/generative programming in c++ when i tought that c++ is a superior language) but later without any friend or paper or teacher or whatever i started to lack features i later found in lisp and other languages. :: This also means that if a few library functions can improve=20 :: ... and it :: is here that we realize all turing-complete languages are=20 :: semantically :: equivalent under this definition. i think in the context i think of semantic i can not even define it! it's something more subjective then the math-like definition you gave here. (which is not bad, only different) - 101. From btanksley@hifn.com Mon Jan 14 11:00:03 2002 From: btanksley@hifn.com (Billy Tanksley) Date: Mon Jan 14 11:00:03 2002 Subject: low-level approach Message-ID: <51C7002B020CD411824E009027C469F7822452@cldxch01.hifn.com> From: Brian P Templeton [mailto:bpt@tunes.org] >If Lisp (what dialect? Common Lisp? Emacs Lisp? Dylan? Scheme? EuLisp? >ISLISP? XLisp? XLisp-Stat? ...) has ``certain aspects that make it >superior [to Java or C]'', then it is /ipso facto/ superior to Java or >C! You've missed his point! Yes, if you have to choose between Lisp and C it's clear that you have claim that one or the other is superior; however, choosing between Lisp and C isn't the goal of the Review subproject. The goal is to find the criticial features and constellations of features. And you can't do that if you're blinded by one feature of one language, and therefore ignore all the good features of all the other languages. -Billy From btanksley@hifn.com Mon Jan 14 11:19:02 2002 From: btanksley@hifn.com (Billy Tanksley) Date: Mon Jan 14 11:19:02 2002 Subject: low-level approach Message-ID: <51C7002B020CD411824E009027C469F7822454@cldxch01.hifn.com> From: Alex Thiel [mailto:stderr@web.de] >Maybe I got that wrong, but I think list in Lisp are objects >separated by >spaces. So, in that sense strings are not lists. You're confusing text (spaces) with data (objects). Objects can't be seperated by spaces; objects sit in memory, and spaces sit in a program file. Lists are sequences of objects. > Alex -Billy From mdanish@andrew.cmu.edu Mon Jan 14 17:34:01 2002 From: mdanish@andrew.cmu.edu (mdanish@andrew.cmu.edu) Date: Mon Jan 14 17:34:01 2002 Subject: low-level approach In-Reply-To: <02011415031700.11642@hilbert>; from stderr@web.de on Mon, Jan 14, 2002 at 03:03:17PM +0100 References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> Message-ID: <20020114202809.F6060@emu> On Mon, Jan 14, 2002 at 03:03:17PM +0100, Alex Thiel wrote: > On Monday 14 January 2002 14:31, Kyle Lahnakoski wrote: > > Brian P Templeton wrote: > > > Kyle Lahnakoski writes: > > > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to > > > naturally handle sequences (lists, arrays, etc), dictionary-type > > > objects (alists, hashtables), and functions. > > > > Good, take that one step further and see that strings are lists of > > characters. Lisp has many list manipulation functions, and therefore > > string manipulation functions. > > > > Maybe I got that wrong, but I think list in Lisp are objects separated by > spaces. So, in that sense strings are not lists. > You're both off. Most Lisp implementations implement strings as vectors, and they certainly do not implement vectors with lists (as Kyle stated elsewhere). Records (structs in CL) can be implemented a number of ways. Secondly, lists are not 'objects separated by spaces'. That's called the print-representation of a list and you can change that if you so desire. A more precise definition might be: lists are chains of cons cells. As for this entire sub-thread, if any modern Lisp were truely as you describe it, it would be less than useless for most practical purposes. I want arrays, structs, classes, hashtables, etc, and I want them *efficiently* implemented in native-code compilers. Of course Java/C++ and the rest of the crowd were to be compared against that extremely backwards and limited form of Lisp then they would seem to be more practical. Fortunately the designers of Common Lisp didn't think that way. If you want an example of a Lisp that is closer to what you present, see the misnamed "newLISP", http://newlisp.sf.net/ I believe. Finally: The fact that all Turing-complete languages can express each other does not lead to the conclusion that all Turing-complete languages are equally expressive, or have equal semantics. I can write a Lisp program with Turing-machine notation if I first design a Lisp interpreter/compiler in Turing-machine notation. But by the fact that I have to write an interpreter/compiler first means that Turing-machine notation does not have the same expressiveness as Lisp. It also means that the semantics are different, as I had to change them by writing the interpreter/compiler which is quite literally "a function from program to answers" (FOLDOC). Your definition of semantic equivalence doesn't fit the definition of semantics. All you've shown is that in a Turing-complete language, there is some way to express a program that was already expressed in another Turing-complete language. If a program was already expressed in a Turing-complete language then it solves something computable. And that would suit a Turing-complete language. Apologies for not responding to the grandparent post, as I wanted to address issues from the parent as well. -- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Matthew Danish email: mdanish@andrew.cmu.edu ;; ;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From bpt@tunes.org Mon Jan 14 19:18:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Mon Jan 14 19:18:02 2002 Subject: low-level approach In-Reply-To: <20020114202809.F6060@emu> (mdanish@andrew.cmu.edu's message of "Mon, 14 Jan 2002 20:28:09 -0500") References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> <20020114202809.F6060@emu> Message-ID: <87zo3g46wr.fsf@tunes.org> mdanish@andrew.cmu.edu writes: > On Mon, Jan 14, 2002 at 03:03:17PM +0100, Alex Thiel wrote: >> On Monday 14 January 2002 14:31, Kyle Lahnakoski wrote: >> > Brian P Templeton wrote: >> > > Kyle Lahnakoski writes: >> > > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to >> > > naturally handle sequences (lists, arrays, etc), dictionary-type >> > > objects (alists, hashtables), and functions. >> > >> > Good, take that one step further and see that strings are lists of >> > characters. Lisp has many list manipulation functions, and therefore >> > string manipulation functions. >> > >> >> Maybe I got that wrong, but I think list in Lisp are objects separated by >> spaces. So, in that sense strings are not lists. >> > > You're both off. Most Lisp implementations implement strings as vectors, > and they certainly do not implement vectors with lists (as Kyle stated > elsewhere). Records (structs in CL) can be implemented a number of ways. > Actually, I think that ANSI CL *requires* structs to be implemented with CLOS (as a metaclass, IIRC). > Secondly, lists are not 'objects separated by spaces'. That's called the > print-representation of a list and you can change that if you so desire. > A more precise definition might be: lists are chains of cons cells. > > As for this entire sub-thread, if any modern Lisp were truely as you > describe it, it would be less than useless for most practical purposes. > I want arrays, structs, classes, hashtables, etc, and I want them > *efficiently* implemented in native-code compilers. Of course Java/C++ > and the rest of the crowd were to be compared against that extremely > backwards and limited form of Lisp then they would seem to be more > practical. Fortunately the designers of Common Lisp didn't think that way. > If you want an example of a Lisp that is closer to what you present, > see the misnamed "newLISP", http://newlisp.sf.net/ I believe. > > Finally: The fact that all Turing-complete languages can express each other > does not lead to the conclusion that all Turing-complete languages are > equally expressive, or have equal semantics. I can write a Lisp program > with Turing-machine notation if I first design a Lisp interpreter/compiler > in Turing-machine notation. But by the fact that I have to write an > interpreter/compiler first means that Turing-machine notation does not > have the same expressiveness as Lisp. It also means that the semantics are > different, as I had to change them by writing the interpreter/compiler > which is quite literally "a function from program to answers" (FOLDOC). > Your definition of semantic equivalence doesn't fit the definition of > semantics. All you've shown is that in a Turing-complete language, > there is some way to express a program that was already expressed in > another Turing-complete language. If a program was already expressed > in a Turing-complete language then it solves something computable. And > that would suit a Turing-complete language. > > Apologies for not responding to the grandparent post, as I wanted to address > issues from the parent as well. > > -- > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;; Matthew Danish email: mdanish@andrew.cmu.edu ;; > ;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;; > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From mdanish@andrew.cmu.edu Mon Jan 14 20:07:02 2002 From: mdanish@andrew.cmu.edu (mdanish@andrew.cmu.edu) Date: Mon Jan 14 20:07:02 2002 Subject: low-level approach In-Reply-To: <87zo3g46wr.fsf@tunes.org>; from bpt@tunes.org on Mon, Jan 14, 2002 at 10:41:56PM -0500 References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> <20020114202809.F6060@emu> <87zo3g46wr.fsf@tunes.org> Message-ID: <20020114230137.I6060@emu> On Mon, Jan 14, 2002 at 10:41:56PM -0500, Brian P Templeton wrote: > Actually, I think that ANSI CL *requires* structs to be implemented > with CLOS (as a metaclass, IIRC). In fact, the representation of a struct may be chosen with the :type option. The available standard options are vector, list, and the default is as you say: a class with metaclass structure-class. -- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Matthew Danish email: mdanish@andrew.cmu.edu ;; ;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From kyle@arcavia.com Mon Jan 14 21:07:01 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Mon Jan 14 21:07:01 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> <20020114202809.F6060@emu> Message-ID: <3C43B8D1.292B8FA0@arcavia.com> mdanish@andrew.cmu.edu wrote: > As for this entire sub-thread, if any modern Lisp were truely as you > describe it, it would be less than useless for most practical purposes. > I want arrays, structs, classes, hashtables, etc, and I want them > *efficiently* implemented in native-code compilers. Of course Java/C++ > and the rest of the crowd were to be compared against that extremely > backwards and limited form of Lisp then they would seem to be more > practical. Fortunately the designers of Common Lisp didn't think that way. > If you want an example of a Lisp that is closer to what you present, > see the misnamed "newLISP", http://newlisp.sf.net/ I believe. I did not mean to imply that Lisp is not superior to C or Java. I wanted a discussion on WHY it is so. What aspects of Lisp make it a good language? Arrays, structs, classes, hashtables are all features that make a language better. I would like to know more about the aspects of the core Lisp syntax that makes it preferred over other languages. > Finally: The fact that all Turing-complete languages can express each other > does not lead to the conclusion that all Turing-complete languages are > equally expressive, or have equal semantics. The point of that post was that expressiveness appears to have no formal definition. I am having a conversation with Billy Tanksley where he suggests that expressiveness is related to minimum code length. An excellent thought, but I have trouble digesting it because it appears to make code unreadable/complex; much like trying to read/write a zipped text file. > I can write a Lisp program > with Turing-machine notation if I first design a Lisp interpreter/compiler > in Turing-machine notation. But by the fact that I have to write an > interpreter/compiler first means that Turing-machine notation does not > have the same expressiveness as Lisp. Of course not. Our intuition has something in mind. I am unsure of what expressiveness is or even if it even exists. Suppose I am given a commercial C development environment with a Lisp package. Is the resulting system as expressive as Lisp? This supposition lead me to my ranting at the end of my other post. I saw that these extra code portions could be realized as IDE features (GUI builder, lexx, yacc, Lisp interpretor, etc). Is this IDE not as expressive as Lisp? This brings up the question of why do we even need a better language when we can (in theory) build whatever we want from any turing-complete language to begin with? Of course, all these features take a lot of work to build. But to go a step further, in trying to design an HLL for Tunes we are essentially trying to make IDE features appear as beneficial language aspects. Does this mean that we are in for the same amount of work no matter if our advancements are in the form of IDE features or language aspects?. From mdanish@andrew.cmu.edu Tue Jan 15 00:04:01 2002 From: mdanish@andrew.cmu.edu (mdanish@andrew.cmu.edu) Date: Tue Jan 15 00:04:01 2002 Subject: low-level approach In-Reply-To: <3C43B8D1.292B8FA0@arcavia.com>; from kyle@arcavia.com on Tue, Jan 15, 2002 at 12:06:25AM -0500 References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> <20020114202809.F6060@emu> <3C43B8D1.292B8FA0@arcavia.com> Message-ID: <20020115025910.J6060@emu> On Tue, Jan 15, 2002 at 12:06:25AM -0500, Kyle Lahnakoski wrote: > > > mdanish@andrew.cmu.edu wrote: > > > As for this entire sub-thread, if any modern Lisp were truely as you > > describe it, it would be less than useless for most practical purposes. > > I want arrays, structs, classes, hashtables, etc, and I want them > > *efficiently* implemented in native-code compilers. Of course Java/C++ > > and the rest of the crowd were to be compared against that extremely > > backwards and limited form of Lisp then they would seem to be more > > practical. Fortunately the designers of Common Lisp didn't think that way. > > If you want an example of a Lisp that is closer to what you present, > > see the misnamed "newLISP", http://newlisp.sf.net/ I believe. > > I did not mean to imply that Lisp is not superior to C or Java. I > wanted a discussion on WHY it is so. What aspects of Lisp make it a > good language? Arrays, structs, classes, hashtables are all features > that make a language better. I would like to know more about the > aspects of the core Lisp syntax that makes it preferred over other > languages. The distinction I find about the Lisp syntax is the fact that it is simply a representation of a data structure, namely a tree with atoms at the leaves. This enables features such as Common Lisp macros which can play with that tree and transform code/data in all sorts of ways. > > > > Finally: The fact that all Turing-complete languages can express each other > > does not lead to the conclusion that all Turing-complete languages are > > equally expressive, or have equal semantics. > > The point of that post was that expressiveness appears to have no formal > definition. I am having a conversation with Billy Tanksley where he > suggests that expressiveness is related to minimum code length. An > excellent thought, but I have trouble digesting it because it appears to > make code unreadable/complex; much like trying to read/write a zipped > text file. I believe a lot of people find expressiveness to be related to the amount of effort one has to produce in order to achieve a goal. An alternate definition might be the ability to represent the meaning of a program in a vivid and lucid manner, in the language of discourse. The former requires some baseline to be measured against. How much effort does it take to write Program A in a language with special features for Program A vs a language without those special features, for example. I suppose that this should really be called "productivity" and given in terms of some goal and some baseline. In the latter sense, an ideally expressive language would never need any comments; it would be the ultimate in self-documenting code. It also suggests the usage of mechanisms such as abstraction, encapsulation, and macros. > > > > I can write a Lisp program > > with Turing-machine notation if I first design a Lisp interpreter/compiler > > in Turing-machine notation. But by the fact that I have to write an > > interpreter/compiler first means that Turing-machine notation does not > > have the same expressiveness as Lisp. > > Of course not. Our intuition has something in mind. I am unsure of > what expressiveness is or even if it even exists. > > Suppose I am given a commercial C development environment with a Lisp > package. Is the resulting system as expressive as Lisp? > > This supposition lead me to my ranting at the end of my other post. I > saw that these extra code portions could be realized as IDE features > (GUI builder, lexx, yacc, Lisp interpretor, etc). Is this IDE not as > expressive as Lisp? This brings up the question of why do we even need > a better language when we can (in theory) build whatever we want from > any turing-complete language to begin with? Of course, all these > features take a lot of work to build. But to go a step further, in > trying to design an HLL for Tunes we are essentially trying to make IDE > features appear as beneficial language aspects. Does this mean that we > are in for the same amount of work no matter if our advancements are in > the form of IDE features or language aspects?. I'm going to answer all this in one concise way: every program that you write defines a new language. Consider the C development environment by itself. In it I can create a function hello_world() that prints out the phrase "Hello, world". I have in effect created a new language that includes all of C AND my new function called hello_world(). This language has all that C has to offer, and it's more productive at printing the phrase "Hello, world" than C (it takes less effort to do). Apply the same reasoning to a lisp() function which accepts a Lisp program as argument. Of course C is not very productive when it comes to defining new languages compared to Lisp, due to macros, CLOS, functions, dynamic-typing, etc. In our C + lisp() language, however, we have the Lisp features at our disposal. Now lets say we are more interested in doing Lispy things than C things. We can create a Lisp development environment in which we have a macro named C available, as opposed to a C with a lisp(). This makes us more productive at Lispy things. So here are some premises: Everything you use builds off of previous work and in doing so defines a new language for future work. A language that is expressive is one that allows you to represent the meaning of a program clearly. A language which is productive at defining new languages is better for defining more expressive languages. Lisp is more productive at defining new languages than C. Therefore: Lisp is better for defining more expressive languages, than C is. As for IDEs vs language aspects, they are one and the same thing. C + IDE, or Lisp + IDE, either way it's a new language. Since Lisp + IDE includes Lisp, it can be substituted for Lisp in the premises above. There is one more thing which I've somewhat neglected: the relationship between expressiveness and productivity. It seems to make sense to me that a more expressive language is more productive, in the long run. But this is all speculation really, I'm interested in hearing what others think. (Hmm, now that I think about it, expressiveness needs to be defined in terms of a problem as well. I think it still fits in with everything, so long as you add "for a given task" every time you see "expressive".) -- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Matthew Danish email: mdanish@andrew.cmu.edu ;; ;; OpenPGP public key available from: 'finger mrd@db.debian.org' ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From u.hobelmann@tu-bs.de Tue Jan 15 01:28:02 2002 From: u.hobelmann@tu-bs.de (Ulrich Hobelmann) Date: Tue Jan 15 01:28:02 2002 Subject: low-level approach References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> <3C42B791.E9F8B376@tu-bs.de> <3C42DDAC.D89B4EF@arcavia.com> Message-ID: <3C43F602.B13C951A@tu-bs.de> Kyle Lahnakoski wrote: > Maybe you would be so nice as to provide an example where the "powerful" > aspect of first class functions shows itself by shortening code length > or reducing development time. Of course there's no objective measure of this, and maybe you can do well with C and I just can't ;) But then that article comparing Lisp to Java says Lisp is more productive... For instance take (define (binary-op fun) (let* ((a (stack:pop)) (b (stack:pop))) (stack:push (fun a b)))) which is imaginary code for a stack machine. With it you can just partially parametrize the function to yield other functions, like (define add (binary-op +)) (define mul (binary-op *)) The SICP book has more examples where real higher order-functions are nice. For capturing vars in an environment, take (define (add n) (lambda (x) (+ n x))) (define add-5 (add 5)) (In C you could model this as int add(int a, int b) { return a+b; } int add_5(int x) { return add(5,x); } which includes more parameter passing.) In C, where there is no lexical environment (unlike, say Pascal), you have to explicitly pass those values in a parameter or something like that, which is not strictly less powerful, but at least for hand-written programs (which C is mostly used for) it is annoying at best. > I will grant that C is bug prone, but in the same note I am unsure how > safe Lisp is. It strikes me that Lisp lacks type information; I am able > to pass anything I want to a Lisp function and it will not complain > unless it runs out of symbols. I could certainly be wrong here. I feel the same. This is probably the coolest thing about ML/Haskell dialects: "a well-typed program cannot go wrong". This isn't so in Lisp or Java, which have no compile-time, but runtime typing. In this case I prefer static languages. It also makes compilation more efficient. > > Also, in general, most Lisps have other types like vectors and records. > > I have only seen these implemented using lists. Maybe there are Lisp > versions that implement these natively. See the R5RS Scheme report on vectors. > > Other Lambda-based languages like Haskell/ML use these other types much > > more than lists... > > So would you consider this a good thing? To me it's much more readable (apart from compile-time type checking) to have, say, a tree defined as abstract type than to have just lispy constructor and selector functions around... > > You can even implement your own syntax macros. > > How would you say these macros are better than including a compiler > library to C, if at all? Maybe not, but then Lisp has more uniform syntax, which makes syntax extensions easier. But then AFAIK C++ allows at least operator overloading. It C would be more like Haskell in allowing definitions, it would be better! I haven't tried out any compiler library stuff yet... > I would love to deliver examples of Lisp and C to show they are very > similar, but any example I come up will be disputed as contrived. An > example can only prove my premise false. Unfortunately I can not think > of one because I believe an example does not exist. Right. Likewise the above Scheme code is contrived... But again I feel there's more freedom to write anything I want, unlike C... Best wishes, Ulrich From dwebb@dwebb.com Tue Jan 15 07:56:02 2002 From: dwebb@dwebb.com (Dan Webb) Date: Tue Jan 15 07:56:02 2002 Subject: low-level approach Message-ID: <20020115155544.BB5586DF@bespin.org> >This brings up the question of why do we even need >a better language when we can (in theory) build whatever we want from >any turing-complete language to begin with? Of course, all these >features take a lot of work to build. Perhaps I can shed some light on the meaning of "expressiveness". For more than 20 years I've programmed almost exclusively in imperative languages (assembly/Pascal/Fortran/C/C++), but I've been investigating the realm of functional programming for the last couple of years. Functional programming is an oasis in a sea of incomplete, redundant semantics and confusing, ambiguous syntax (I'm speaking mainly of C++ here). I've never been so productive with so little code in so little time than when I write in a functional language. It's vastly easier to write concise, precise code and factor out common elements as necessary. Try that with C++, inheritance, and virtual functions. The modularity of a language that supports a hierarchical environment with higher order functions is just amazing. It gives you the ability to factor out small, ubiquitous patterns such as map/filter/partition and reuse them everywhere, resulting in much smaller, easier to read, less buggy code. Now, I wouldn't necessarily say that CL is the best for this. I'm finding that I prefer a lazy functional language, where objects can be modeled by functions. I've got a lazy, purely function Scheme evaluator that I've been developing for a while. I'm finding that laziness is the key to saying goodbye to object-orientation and explicit state management for good. Dan Webb dwebb@dwebb.com From dwebb@dwebb.com Tue Jan 15 08:47:02 2002 From: dwebb@dwebb.com (Dan Webb) Date: Tue Jan 15 08:47:02 2002 Subject: low-level approach Message-ID: <20020115164623.07A1A704@bespin.org> >For capturing vars in an environment, take >(define (add n) (lambda (x) (+ n x))) >(define add-5 (add 5)) > >(In C you could model this as >int add(int a, int b) { return a+b; } >int add_5(int x) { return add(5,x); } >which includes more parameter passing.) But sometimes the values of a and b are available at different places in your program, in which case you have to curry the function. Currying is easy in a language with a hierarchical lexical environment and higher order functions, but in C you'd have to fake out an environment by either using a global variable or by passing an environment to all your functions. In C++ you could use a class to accomplish it (which gives you one more level of environment), which is far more tedious than in Lisp or Scheme. Dozens of lines of code compared to less than one line of code. Such a simple task being so difficult to accomplish means that it is seldom done, which results in less code reuse in C/C++ programs. Dan Webb dwebb@dwebb.com From kyle@arcavia.com Tue Jan 15 13:05:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Tue Jan 15 13:05:02 2002 Subject: [Fwd: low-level approach] Message-ID: <3C449979.5AAE5448@arcavia.com> If you didn't intend this to be private, please forward this message to the list -- I'll leave in all your context. (You replied to me rather than to the group.) I do that all the time. :-) From: Kyle Lahnakoski [mailto:kyle@arcavia.com] >Billy Tanksley wrote: >> Perhaps we're using different definitions. "Application" is >> how C, Scheme, >> Haskell, FORTRAN, and almost all existing languages call >> functions. There's >> no reason to curse about it, or if there was, it's relevant to all >> applicative languages. >My apologies. I thought applicative programming was the use of Haskell >monads. Understandable -- I had a fit working with those as well. >> >I do not see any semantic advantages in Haskell that can not be >> >found in other (simpler) languages. Haskell is an >> >excellent example of >> >a language that can be harder to read then Perl!. >> Surely you're speaking of a completely different language >> than the one I >> know! Haskell is almost bitterly clean and uncluttered. It >Monads are not simple or clean. I guess that is a subjective comment. No -- you're absolutely right. They're ugly. But monads are not Haskell! You claim that Haskell has no advantages over any other languages, when in fact Haskell merely has ONE disadvantage. There's a HUGE, critical difference there! We need to learn from Haskell. >> >Forth is much more rational, but I disagree with any stack, list or >> >"concatenative" concepts, so it may be some time before I give >> >Forth any respect. ;-) >> I hear you, but I don't understand. Stacks and >> concatenativity go together >> (I've never found a concatenative language which didn't use >> a stack as its >> main element), but lists seem unrelated. >It is all about needlessly ordered data structures. >The whole idea of order-is-bad is still unrefined in my mind, therefore >I am in the state where i believe it so, but have little empirical >evidence to convince others. The idea of names-are-bad is very clear and precise: it's presented every time you look at a language which attempts to use the lambda calculus in a functional way, and fails because computing requires imperative actions. I'll present order-is-good later. Order is good, so long as the compiler can override it after analysis. Names are bad, because they have nothing to do with the compiler; they merely add another job. Of course, I'm exaggerating. Order isn't absolutely good; I like unordered things. Names aren't absolutely bad (APL is the exception, not the rule, and it proves the rule by helping the user use names). My point is that you can't afford such a dogmatic view. >> >If you are well versed in these two languages maybe you can see some >> >aspects that are useful. My apologies, I have tried to >> >look, and I see >> >only academic novelty. I note some points you have made below. >> Forth is no academic novelty whatsoever; nor does Postscript. Yet >> Postscript is the most commonly used metaprogramming >> language anywhere; odds >> are your computer generates a custom (simple) Postscript >> program every time >> you print a page. That's not a mere academic novelty. >> If anything, the novelty is that the academics know NOTHING >> of Forth and Postscript. >I did not mean to say that meta programming, or postfix >notation, was an >academic novelty. I meant to say that Forth's particular concatenative >style appears strictly academic to me. Then why on earth isn't Forth used in any college classes? It's ONLY used by engineers, almost none of them CS people. How could you call that academic? I really am honestly confused here. >The links you referenced me to >only supported my point; the academics love combinators for >reductionist stake. That ... that wasn't the point of the paper. I don't know what to say. >I see your point that the combinators certainly have the potential to >minimize code length, but that is not expressiveness. If strict code >length defined expressiveness then zipped source code would be >considered as having superior expressiveness. For an language to be >expressive it must be able to optimize the balance between code length >and human readability. Blink. Wow. You have an AMAZING ability to miss the point. Please forgive me for saying that. Let me try to express my point... It's going to be hard, because I don't understand how you could be missing something which seems so obvious to me. First, a very short rebuttal: code length has absolutely nothing to do with this. I don't know where you got that from, since combinators by your own declaration add words to code, not subtract them (this isn't strictly true, but it's a good upper bound). What combinators _do_ is make dataflow clear, and computing is all about data flow and modification. Combinators allow the programmer to *express* that. Anyone who's ever used them recognises the feel of programming with them: ideas just flow out, and often don't need to be corrected; changes have only local effect, unless certain dangerous words are present (words with deep stack-effect), and those become obvious with a little experience or watchfulness. Compare this to naming-based code: you don't know what things any specific change is going to affect, because the effects depend on the scope of the variables affected by the change. >> >But in general this >> >concatenative property is not too useful, maybe even a >> >hindrance. For >> >example, the concatenative aspect of Forth forces the existence of >> >unusual twiddling operators, much like those found for stack based >> >machines (dup, swap, ...). These twiddlers have nothing to >> >do with the >> >work being done, and everything to do about the format the >> >program is in. >> Untrue on all points. Read about combinatory programming >If you believe that removing named variables is a good thing, then I >guess I see why you believe my statements are untrue on all points. We >are having a fundamental difference opinion: I believe in named >variables, you believe in minimal code length. I don't give a flying fig about program length. I don't know where you came up with that. I *definitely* do not "believe" in named variables; in fact, although I use them in languages where their use is required or when they make my code better, I emphatically recognise the problems they cause, both for practical modification and for program analysis. Also, your statements are untrue not because I believe they're untrue, but because the twiddling operators (I like that name, BTW) are a crucial part of the work of the program: they express the dataflow. >I believe named variables are the right thing because our human minds >are well suited to mapping names to concepts. From the human >perspective named variable require little mental force. Constant names require little force. Variable names are a HUGE concept, which take a LOT of processing. context switches, such as what happens whenever you "step in" to a function call, are even worse: all of a sudden all the variables you were used to are gone, and a totally new set takes their place. >Minimizing code length is quite the opposite, I won't harp about this again, but WOW. Straw Man. >the discipline needed to hold complex >dataflow design in the mind is much greater. I must point out that complex dataflow is complex regardless of whether it's expressed by variables or by explicit dataflow notations. And with variables, the dataflow MUST be held entirely in your mind; it's not possible to write it in the program. With dataflow, the flow only has to be thought of once, and from then on you can forget it -- dataflow modifications can be made locally. >> to see how those 'twiddlers' are significant to all programming methods, not >> just stack-based ones. >I read the pages, but I missed the part that referred to other >programming methods. Interesting. >> Once the programmer's been forced to look at the dataflow, the program will >> be written with the dataflow in mind, and the result will be a much cleaner >> program. >This statement of yours exhibits the force the human mind must endure to >build a Forth program. And yet people who write Forth programs talk about how easy and fun it is. Perhaps you misunderstood my statement, then. >> Furthermore, because the programmer is thinking about the >> dataflow, the program will be organised so that the most urgent items are at >> the top of the stack, and the less urgent items are underneath. In other >> words, the stack is sorted by urgency. From there register allocation is >> trivial: just assign the topmost stack items to registers, the next ones to >> a fast cache, the next ones to a slow cache, the next ones to memory, and >> the very lowest may be paged out (if needed). The implications for >> optimization are huge, because all this information is stored in a very >> shallow way, while it's almost impenetrable to applicative languages. >All this optimization you mention must be done by the human programmer. >This optimization should be done by the compiler. If you remove the >necessity to specify how a program will run, you are left with much less >to specify and and easier development time in general. This optimization MUST be done by the programmer: he's the only one who knows what his task will need next. The compiler can make guesses after undertaking extensive analysis, but will never better the programmer; the compiler is better used as a domain expert on the specific optimizations needed for the target machine (alignment, caching, number of registers, and so on). After all, ordering the operations is an obvious and trivial part of designing the algorithm. Some operations don't have to be ordered: but these are either exceptions, due to the structure of the algorithm (consider many of APL's array operations), and primitives can be provided which operate on arrays potentially out-of-order; or they're unordered due to dataflow and side effects, both of which are obvious in a concatenative language to even a VERY simple compiler. >> >On the other hand parse tree of any other language is just as easy >> >to split into sub tokens. Although the price of a parser is needed to >> >get that parse tree, I think it is a small price to pay for the extra >> >textual flexibility. >> Again, wrong. Even after you've done the parse you have less textual >> flexibility. You also lack dataflow information. >As above, dataflow information does not have to be specified because the >compiler can provide it. Why specify more than you must? Because the dataflow is intrinsic to your algorithm: you ALWAYS specify it, even when you're not making it explicit. You're also missing what I said above: a parse tree doesn't give you any more textual flexibility than a tokenized concatenative language naturally has (sometimes a lot less), and it's harder to get and apply. This is why it's taken so long to come out with decent refactoring tools. -Billy From kyle@arcavia.com Tue Jan 15 14:09:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Tue Jan 15 14:09:02 2002 Subject: low-level approach References: <51C7002B020CD411824E009027C469F782245C@cldxch01.hifn.com> Message-ID: <3C44A87C.CB3EC338@arcavia.com> Billy Tanksley wrote: > No -- you're absolutely right. They're ugly. But monads are not > Haskell! You claim that Haskell has no advantages over any other > languages, when in fact Haskell merely has ONE disadvantage. There's a > HUGE, critical difference there! We need to learn from Haskell. Oh yes! I did not even follow my own rule: we are only looking into the good aspects of languages. > Of course, I'm exaggerating. Order isn't absolutely good; I like > unordered things. Names aren't absolutely bad (APL is the exception, > not the rule, and it proves the rule by helping the user use names). > My point is that you can't afford such a dogmatic view. I am fine with this. > >I did not mean to say that meta programming, or postfix notation, was an > >academic novelty. I meant to say that Forth's particular concatenative > >style appears strictly academic to me. > > Then why on earth isn't Forth used in any college classes? It's ONLY used > by engineers, almost none of them CS people. How could you call that > academic? I really am honestly confused here. Just because I label a concept or thing academic, it does not mean it necessarily came from, or is used in, academia. Forth was designed from certain principals that, to me, conflict with my intuitive concept of expressive. I only label these principles academic because they do not appear to be useful. Forth used by engineers makes perfect sense! Engineers write small programs, programs built for hardware (very likely small hardware). Forth, is well suited to these types of devices. Now I can see that Fourth's principles of design are quite helpful in this area of software development; not academic at all. > >I see your point that the combinators certainly have the potential to > >minimize code length, but that is not expressiveness. If strict code > >length defined expressiveness then zipped source code would be > >considered as having superior expressiveness. For an language to be > >expressive it must be able to optimize the balance between code length > >and human readability. > What combinators _do_ is make dataflow clear, and computing is all about > data flow and modification. Combinators allow the programmer to *express* > that. Anyone who's ever used them recognises the feel of programming with > them: ideas just flow out, and often don't need to be corrected; changes > have only local effect, unless certain dangerous words are present (words > with deep stack-effect), and those become obvious with a little experience > or watchfulness. Compare this to naming-based code: you don't know what > things any specific change is going to affect, because the effects depend on > the scope of the variables affected by the change. Maybe I am missing your point. But why is clear dataflow a good thing? Whenever I think of managing dataflow I can't help but to think that I am doing more work. Maybe someone can jump in here and help me understand. I can see the functional aspect of Forth being useful (lack of side effects as you mention). I can also see linear aspects of Forth (again, a lack of side effect). I do not see how dataflow provides semantic advantage. > I must point out that complex dataflow is complex regardless of whether it's > expressed by variables or by explicit dataflow notations. And with > variables, the dataflow MUST be held entirely in your mind; it's not > possible to write it in the program. With dataflow, the flow only has to be > thought of once, and from then on you can forget it -- dataflow > modifications can be made locally. For dataflow problems, dataflow notation would certainly be a good thing. I am really concerned with problems that do not have a dataflow aspect. SQL is an example of a domain specific language that removed all dataflow specification. Every time you specify dataflow you imply a certain computation model. When that computation model changes then the program must be reversed engineered to its important results and reprogrammed in the new computation model. I am thinking of distributed and quantum computing; both highly parallel computing models. Tell me more about Forth in a parallel world. > >All this optimization you mention must be done by the human programmer. > >This optimization should be done by the compiler. If you remove the > >necessity to specify how a program will run, you are left with much less > >to specify and and easier development time in general. > > This optimization MUST be done by the programmer: he's the only one who > knows what his task will need next. The compiler can make guesses after > undertaking extensive analysis, but will never better the programmer; the > compiler is better used as a domain expert on the specific optimizations > needed for the target machine (alignment, caching, number of registers, and > so on). After all, ordering the operations is an obvious and trivial part > of designing the algorithm. We disagree on the roll and abilities of the compiler. I believe the compiler should be responsible for as much dataflow as possible. If dataflow is not part of the problem then it should not be specified. In general good compilers outperform humans. There may be a problem where a human can produce more efficient code, but then that can be taught to the compiler. The compiler is an expert in many things, one of those things should be dataflow. > You're also missing what I said above: a parse tree doesn't give you any > more textual flexibility than a tokenized concatenative language naturally > has (sometimes a lot less), and it's harder to get and apply. This is why > it's taken so long to come out with decent refactoring tools. If parse tree were so difficult to manage then Smalltalk would not have so many refactoring tools. From fare+NOSPAM@tunes.org Tue Jan 15 14:35:02 2002 From: fare+NOSPAM@tunes.org (Francois-Rene Rideau) Date: Tue Jan 15 14:35:02 2002 Subject: LISP for Concurrent Systems In-Reply-To: References: <3218955132298566@naggum.net> <3219075914130754@naggum.net> <3219086537399318@naggum.net> <%njZ7.279$iR.150960@news3.calgary.shaw.ca> <3c36fbc5_10@news.newsgroups.com> <4idg3u40ermnp682n6igc5gudp7hajkea9@4ax.com> <87n0zi0xyo.fsf@tunes.org> <87y9j0gxds.fsf@Samaris.tunes.org> Message-ID: <87hepna5ri.fsf_-_@Samaris.tunes.org> tfb@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes on comp.lang.lisp: > Francois-Rene Rideau writes: > >> they also have good features that Lisp never had: [...] >> support for building robust massively concurrent systems for Erlang. > > I certainly never had any experience with Lisp*, but I'd be surprised > if it failed here Maybe you mean *LISP, the language for the Connection Machine; but AFAIK, it wasn't exactly a LISP, just a language metaprogrammed from LISP. So it was used to build massively concurrent systems, but was very idiosyncratic with the CM, kind of SIMD, and didn't survive to the demise of Thinking Machines. I don't think it was designed for robustness, either. Other LISPs with concurrency (threads) are kind of nice, but not really built for massively concurrent systems: the global garbage-collected shared-memory model of LISP strongly limits the scalability such systems, and their robustness when faced with fault-containment problems. Also, no concurrent LISP extension correctly handles problems of synchronization of interrupted threads with application-defined invariants - see for instance the problems that Joe Marshall had with interrupted transactions. (LISP here is not worse than Java, but JOCaml and Erlang can do much better). Of course, it is possible to build distributed systems atop of LISP (just like you can atop any language), but then (just like you would have in any such setting), it means that you have a fight a multi-level programming system that imposes arbitrary constraints on your programming style and forces you to make arbitrary early low-level implementation choice as to which problem will be treated at which level. LISP's metaprogramming abilities can help you factor a lot, so you will be better with LISP than with anything else, but if you take this approach seriously, you will but end up reimplementing Erlang or JOCaml in LISP, and the idiosynchrasies of LISP systems (designed around a global namespace) will end up getting in the way, whether you try to emulate them (expensive runtime distributed coherence enforcement) or avoid them (difficult to trace inconsistent behaviour when they are mistakenly used). Erlang, on the other hand, is a generic tool for building robustp concurrent systems. It does not depend on the idiosynchrasies of any particular hardware architecture. Its model of internally pure communicating processes easily scales to building large distributed systems, while allowing for real-time behaviour (soft-real-time in practice; but nothing in theory prevents a hard-real-time implementation if needed). and provides a framework for fault-containment as well as for asynchronous interruption handling, and more. It is actually used in mission-critical telecom switch systems, in services using internet-standard protocols, etc. I don't mean that it would be impossible to design a LISP so as to be as good for concurrent programming as Erlang is. But it would require deep changes to the language and its implementations, and the end-result wouldn't quite be like Common Lisp. For instance, instead of global namespaces and am implicit global object heap, it might have something like first-class name-spaces and first-class object-spaces; the behaviour of primitives of the language in face of concurrency would have to be clarified -- maybe by introducing a linear type system. Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] How would the certainty of the near end of the world affect Ethics? From bpt@tunes.org Tue Jan 15 16:49:01 2002 From: bpt@tunes.org (Brian P Templeton) Date: Tue Jan 15 16:49:01 2002 Subject: low-level approach In-Reply-To: <3C42DDAC.D89B4EF@arcavia.com> (Kyle Lahnakoski's message of "Mon, 14 Jan 2002 08:31:24 -0500") References: <20020109131444.GA7108@hell.mine.nu> <3C40582A.7046A81F@arcavia.com> <3C42B791.E9F8B376@tu-bs.de> <3C42DDAC.D89B4EF@arcavia.com> Message-ID: <87bsfv4ytb.fsf@tunes.org> Kyle Lahnakoski writes: > Ulrich Hobelmann wrote: >> >> Kyle Lahnakoski wrote: >> > For example, the difference between C and Java can be summed in three >> > aspects: >> > Java has garbage collection >> > Java has inheritance (limited polymorphism) >> > C has function pointers >> >> I'd claim that Lisp first class functions are way more powerful than C >> fun-pointers in that they capture an environment. > > Maybe you would be so nice as to provide an example where the "powerful" > aspect of first class functions shows itself by shortening code length > or reducing development time. > > >> (BTW: can anyone tell me in what way Java's inheritance doesn't >> correctly >> model subtyping? this was hinted at in the TUNES-glossary->Inheritance >> ... ?) > > See my document > http://www.arcavia.com/rd/document/Function%20Inheritence.htm > > >> I think the point here is that the C type system is _very_ weak, and >> there's >> no safety or GC, so writing List code is very bug-prone compared to >> Lisp. > > I will grant that C is bug prone, but in the same note I am unsure how > safe Lisp is. It strikes me that Lisp lacks type information; I am able > to pass anything I want to a Lisp function and it will not complain > unless it runs out of symbols. I could certainly be wrong here. > Yes, you are, in this case. Common Lisp has, IMHO, a very useful typesystem, and by using defmethod, you can specialize generic functions on their argument types: --- lisp-mode --- ;; This could be changed to a (probably clearer in this case) ;; DEFGENERIC form. (defmethod foo ((x string)) (format t "~&Got a string~%")) (defmethod foo ((x number)) (format t "~&Got a number~%")) (defmethod foo ((x cons)) (format t "~&Got a cons~%")) ;; and later... (after you've tried those to convince yourself that it ;; does check the types) (defmethod foo ((x t)) (format t "~&I'm not sure what I got, but at least it has a type!~%")) --- end lisp-mode --- BTW, DEFMETHOD was invented to make CLOS hacking easier; however, it's useful for other purposes, too, since CLOS is fully integrated with the typesystem. Also see the standard Common Lisp CHECK-TYPE function if you don't want to define lots of generic functions. > In any case, I think we both agree that strong typing helps reduce > development time by reducing human error. > > >> Also, in general, most Lisps have other types like vectors and records. > > I have only seen these implemented using lists. Maybe there are Lisp > versions that implement these natively. > Yes, every CL implementation that I've ever heard of for vectors, and for structures (as was pointed out elsewhere in this thread) you can choose between several different implementations, the default being to use a metaclass. > >> Other Lambda-based languages like Haskell/ML use these other types much >> more than lists... > > So would you consider this a good thing? > > >> To me the bad point about Java is that in Lisp you can have Objects or >> structs, >> while in Java, expressing functions (via interfaces..) is sooo ugly... >> (Hmmm... wasn't Java developed by James Gosling and Guy Steele, two >> Lispers???) > > Yes, certainly a deficiency in Java. > > >> Usually, when you directly translate C into Lisp, you immediately >> notice several points which need improvement, because C code is more >> bound to restictions in language comfort, which Lisp is more free-form >> and doesn't restrict you in any way. > > Maybe your direct translation of the C code is because of poorly written > C code. Do you have an example? If you prefer to wait until next time > you stumble cross the scenario you describe above, send it to me then. > I will remember this conversation; it has bothered me for years. > > >> You can even implement your own syntax macros. > > How would you say these macros are better than including a compiler > library to C, if at all? > > > I would love to deliver examples of Lisp and C to show they are very > similar, but any example I come up will be disputed as contrived. An > example can only prove my premise false. Unfortunately I can not think > of one because I believe an example does not exist. > > > > Thanks > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From fare+NOSPAM@tunes.org Tue Jan 15 16:55:01 2002 From: fare+NOSPAM@tunes.org (Francois-Rene Rideau) Date: Tue Jan 15 16:55:01 2002 Subject: Static Typing in LISP? (was Re: The true faith) In-Reply-To: References: <871ygra09m.fsf@Samaris.tunes.org> Message-ID: <87wuyj869s.fsf_-_@Samaris.tunes.org> Jochen Schmidt writes on comp.lang.lisp: > I think that Common Lisp somewhat proved > that dynamic typing works for _really_ large software systems. > Oh, well, there have been huge systems in C++ or COBOL, too. So the argument should rather be one of cost/benefits (the estimation of which is indeed partly subjective): how much does it cost (in months, unit of proficiency, kloc, etc., ultimately, dollar) to achieve how much features that are worth what (in fame, brand recognition, community building, number of customers, etc., ultimately, dollar)? >> LISP usually lacks a way to turn typing on. > Your first sentence sounds as if you think Lisp is "untyped" - I know that > you know better but can you explain what you meant? > Indeed, this sentence as stated is incorrect. What I meant is that there is no (standard) way in LISP to have the system enforce any kind of rich static type system. Let me expand on that. A rich static type system is a way to attach some non-trivial invariants to the context in which some objects and functions will be used. Christopher Browne suggested that CMUCL and Stalin would be counter-examples. Stalin certainly isn't -- as far as I know, it won't enforce any kind of user-supplied type declaration; it will infer a "type" for every program; any invariant enforced as to the context of use of a given object is trivial. CMUCL comes much closer, since it is possible to declare types, and have the system enforce them, although it requires quite some familiarity with the system so as to understand how to use declarations to *statically* enforce invariants -- which implies filtering the CMUCL warnings to detect whether any inconsistency was detected. In addition to such usability issues, the richness of type-system enforceable by CMUCL its a far cry from that of the simplest ML variant. >> Also, SEXP feels like >> quite a suboptimal syntax for specialized sublanguages like the type >> language, or the language of objects of a given type. > > Furthermode you lost me on why SEXPs are a suboptimal syntax for > sublanguages like the type language or the language of objects of a given > type. I don't see any fundamental problems in using an SEXP syntax for a > type sublanguage. > It's indeed not a "fundamental" problem, but an important usability problem. As an exercise, just try to write ML programs with a SEXP syntax, which Macro Antoniotti suggested in a mail would have made *ML better languages. It's definitely possible - and actually, the original ML interpreter and the first ML compilers were written in LISP, and there was a internal LISP representation for terms. But there's a reason why ML users did not just stick to such internal representation. Not only do you end up using noticeably more characters, but the result is rather unwieldy, unless you are writing deep macros, as with camlp4. Note that I'm not claiming that a SEXP syntax be dropped altogether (as was the case with Dylan), but that there are times when a specialized syntax is preferrable (which I presume is precisely the reason why CL has reader-macros). As for the CL syntax (declare (type Tfoo bar)), defended by Christopher Browne, apart from its not having a semantic of system-enforcement (a variant certainly could), it has the syntactical disadvantage of not being at point of declaration of the declared variable bar. A syntax as practical as ML would be to have something like (the Tfoo bar) in lambda lists as well as in positive terms, although once again with semantics of a system-enforcement rather than user-enforcement. My conclusion would be that the lack of rich strong static typing in LISP is certainly a disadvantage, and that though extending LISP with such typing is at least conceivable, for practical reasons it would probably lead to a language that, while hopefully retaining enough of the distinctive characteristics of LISP that we like to still be called a LISP, would probably also be noticeably different from existing LISPs, and largely incompatible too, both semantically and syntactically. Would such a beast be desirable? I think it would be worth a try, and I intend to try, one of these days. Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking about what we are doing. The precise opposite is the case. Civilization advances by extending the numbers of important operations which we can perform without thinking about them. Operations of thought are like cavalry charges in battle -- they are strictly limited in number, they require fresh horses, and must only be made at decisive moments. -- Alfred North Whitehead From btanksley@hifn.com Tue Jan 15 17:10:03 2002 From: btanksley@hifn.com (Billy Tanksley) Date: Tue Jan 15 17:10:03 2002 Subject: low-level approach Message-ID: <51C7002B020CD411824E009027C469F7822464@cldxch01.hifn.com> From: Kyle Lahnakoski [mailto:kyle@arcavia.com] >Just because I label a concept or thing academic, it does not mean it >necessarily came from, or is used in, academia. Forth was >designed from >certain principals that, to me, conflict with my intuitive concept of >expressive. I only label these principles academic because they do not >appear to be useful. Okay, that's cool. So "academic", to you, means "useless to me". I've heard that before. >Forth used by engineers makes perfect sense! Engineers write small >programs, programs built for hardware (very likely small hardware). >Forth, is well suited to these types of devices. Now I can see that >Fourth's principles of design are quite helpful in this area >of software development; not academic at all. Right. Nor useless. Let me add, though, that Forth has also been used to solve some very large problems. It's true that the resulting Forth program is small, but that doesn't mean that the problem was small -- a C consulting company bidding on the UPS software asked for about four times more than what the Forth company which did it billed. I was also surprised to see talk about Forth being academic because one interesting thing about Forth and concatenative languages in general is that there is almost zero research on them. This is one of the reasons I'm studying them; not because they're a silver bullet perfect language (they aren't), but because they're unexplored territory. >> What combinators _do_ is make dataflow clear, and computing >> is all about >> data flow and modification. Combinators allow the >Maybe I am missing your point. But why is clear dataflow a >good thing? >Whenever I think of managing dataflow I can't help but to think that I >am doing more work. Maybe someone can jump in here and help me >understand. Because computing is all about data flow and modification. One of the harder parts of programming is managing dataflow, and being able to manage dataflow is crucial to programming. A language which ignores dataflow forces you to keep the dataflow in your head or in a seperate, unchecked document; a language which forces you to make the dataflow explicit also allows later modifiers to realise what impact their changes will have. Now, it might take a bit of thought to make the dataflow explicit; but I guarantee you that you've already done the hardest work, generating the dataflow in the first case. So Forth doesn't really add much challenge in this respect. There's one other thing Forth forces the programmer to do which DOES add a challenge: the programmer has to arrange sources and uses of the data so that it's on the stack for the minimum amount of time, and so that it's on top of stack when it has to be used. This /is/ a challenge, and takes some getting used to -- but it's also a critical part of any computational task, and provides useful data to optimising compilers which they could not otherwise get. >I can see the functional aspect of Forth being useful (lack of side >effects as you mention). I can also see linear aspects of >Forth (again, a lack of side effect). I'm glad you like them, but they have nothing to do with lack of side effect -- on the contrary, both aspects of Forth operate with or without side effects. >> I must point out that complex dataflow is complex regardless >> of whether it's >> expressed by variables or by explicit dataflow notations. And with >> variables, the dataflow MUST be held entirely in your mind; it's not >> possible to write it in the program. With dataflow, the >> flow only has to be >> thought of once, and from then on you can forget it -- dataflow >> modifications can be made locally. >For dataflow problems, dataflow notation would certainly be a good >thing. All problems involve dataflow. >I am really concerned with problems that do not have a dataflow >aspect. SQL is an example of a domain specific language that removed >all dataflow specification. It's a slow, special-purpose language. Look at ksql -- it's SQL plus dataflow. /Much/ faster, and much smaller than any SQL implementation I've seen. >Every time you specify dataflow you imply a certain computation model. >When that computation model changes then the program must be reversed >engineered to its important results and reprogrammed in the new >computation model. I am thinking of distributed and quantum computing; >both highly parallel computing models. Tell me more about Forth in a >parallel world. I can't speak about quantum computing; I know nothing of it. Parallel computing, though, I've considered. There are three major ways to accomplish parallel computing: 1. Allowing the compiler to parallelize your serial program. This works very poorly in any language, but better when the dataflow is known to the programmer and thus available for hand-optimization. 2. Writing problems which use primitives that can be parallel, as in APL's array operations. This can be done as easily in Forth as it was in APL. 3. Writing your programs to execute as seperate, hand-coded processes. This, of course, can be done just as easily in Forth as any other language. Only solution #1 could cause any problems at ALL with specified dataflow; and in reality, the problems are there in all code, whether the dataflow is specified or not. With specified dataflow, the programmer can /see/ why the compiler's having a problem. >> >All this optimization you mention must be done by the human >> >programmer. >> >This optimization should be done by the compiler. If you remove the >> >necessity to specify how a program will run, you are left >> >with much less to specify and and easier development time in general. >> This optimization MUST be done by the programmer: he's the >> only one who >> knows what his task will need next. The compiler can make >> guesses after >> undertaking extensive analysis, but will never better the >> programmer; the >> compiler is better used as a domain expert on the specific >> optimizations >> needed for the target machine (alignment, caching, number of >> registers, and >> so on). After all, ordering the operations is an obvious >> and trivial part >> of designing the algorithm. >We disagree on the roll and abilities of the compiler. Clearly. >I believe the >compiler should be responsible for as much dataflow as possible. >If dataflow is not part of the problem then it should not be specified. The dataflow is ALWAYS part of the problem and the solution, so it must be specified. The question isn't whether or not it's going to be specified; the only question is how hard it's going to be to figure out. Variables are like magical teleporters: they make it look like data gets used, then teleports to the next place it's needed. Well, in reality that doesn't happen. The data has to sit somewhere. Explicit dataflow simply makes that sitting process explicit, and the way Forth does it also lets the compiler (or anyone who cares to know) see how urgent the data's going to be, in case the compiler has to choose between more and less speedy memories (and it almost always has to). The compiler isn't, and CAN'T be, responsible for the dataflow. The algorithm specifies the dataflow, and the concrete implementation makes it certain. We KNOW, thanks to the algorithm, that data gets generated _here_, then used _here_, then used again _here_, and then never looked at again. That's the dataflow. >In general good compilers outperform humans. There may be a problem >where a human can produce more efficient code, but then that can be >taught to the compiler. Not true. In EVERY case, the programmer is completely responsible for the speed of his code. He must choose the algorithm, thus generally specifying the dataflow; then he has to implement the algorithm, thus EXACTLY specifying the dataflow. The compiler should be responsible for machine-dependant details and microoptimizations at this point; it's very good at those bookkeeping details. It CAN'T choose a better algorithm, nor can it reimplement the algorithm the programmer chose to make a better implementation. >The compiler is an expert in many things, one >of those things should be dataflow. I don't have a real problem with that. The compiler is obviously responsible for allocating resources for the specified dataflows, no matter what languages you're using. But when you're using a dataflow language, the programmer can tell the compiler how important a given dataflow edge is to the program, and the compiler can allocate it immediately, and spend its time optimizing something else. It's fine when the compiler acts as an expert, but it's not fine when it's forced to act as a programmer -- then we have to implement an expert system and accept mediocre results. >> You're also missing what I said above: a parse tree doesn't >> give you any >> more textual flexibility than a tokenized concatenative >> language naturally >> has (sometimes a lot less), and it's harder to get and >> apply. This is why >> it's taken so long to come out with decent refactoring tools. >If parse tree were so difficult to manage then Smalltalk would not have >so many refactoring tools. It's not exactly "so difficult"; it's merely *harder*. It took Smalltalk a lot of time to get those browsers, and Smalltalk is a simple language. Compare Java, a much more complicated language with a LOT more effort behind it -- its refactoring browsers are only beginning to get off the ground, some 3 years after publication of the Refactoring book made it very popular. -Billy From Francois-Rene Rideau Tue Jan 15 18:04:01 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Tue Jan 15 18:04:01 2002 Subject: low-level approach In-Reply-To: <51C7002B020CD411824E009027C469F7822464@cldxch01.hifn.com> References: <51C7002B020CD411824E009027C469F7822464@cldxch01.hifn.com> Message-ID: <20020116020305.GA10661@hell.mine.nu> I appreciate what Billy Tanksley writes about the benefits of using combinators and eliciting variables so as to make dataflow explicit, and how it can be a great tool when designing algorithms. As for combinator languages in academia, let me just remind our readers that combinators were very much studied ever since the beginning of CS. The SKI combinators were already used by Schoefinkel in the 1920's, before the lambda-calculus was even born. Haskell Curry studied them a lot - see Curry and Feys' "Combinatory Logic", volume 1 published in 1958 (btw, "combinatory logic" is about *computation* with combinators, although Curry was also after a way to do reasoning without variables: "illative combinatory logic"). Combinators are very much studied by in computer science theory, by functional language designers and implementers, semanticians, logicists, graph theorists. They are often the basis of the programming models used as targets by compilers for functional languages: There are lots of papers about graph-reduction models with combinators for pure functional languages (Haskell, Clean), and the whole idea behind CAML was to compile functional programs to some special kind of a stack machine implementing categorical combinators. In conclusion, combinators are a very useful conceptual tool, that are both studied by scientists, and put to good use by implementers. However, there is a good reason why they are not so much exposed to the public at the outer layers of programming languages, but only used in the lower-levels of compilers: they are very low-level, in their own way. Programming *only* with combinators can be very tedious and obfuscating - witness unlambda (based on SKI combinators), or finitary lambda calculi. Combinators certainly DO help express and handle data-flow constraints, and when optimizing them is what is meant, they are a great paradigm. But when these constraints do not matter, or when you want the system to handle them for you (and YES, there are cases when you do), then expliciting them gets in the way, and so do combinators. Ideally, you'd have a system that would allow you to dynamically change your point of view on the same program; this is what refactoring is about, although refactoring is often used in as destructive rather than as explorative. I'm sure combinators are studied a lot by people doing refactoring for functional programming languages (has anyone contacted Claus Reinke about that?). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] "The society which scorns excellence in plumbing as a humble activity and tolerates shoddiness in philosophy because it is an exaulted activity will have neither good plumbing nor good philosophy. Neither its pipes nor its theories will hold water." From Francois-Rene Rideau Tue Jan 15 20:28:01 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Tue Jan 15 20:28:01 2002 Subject: Expressiveness (was Re: low-level approach) In-Reply-To: <3C43B8D1.292B8FA0@arcavia.com> References: <20020109131444.GA7108@hell.mine.nu> <874rlp1x56.fsf@tunes.org> <3C42DDBF.2869157E@arcavia.com> <02011415031700.11642@hilbert> <20020114202809.F6060@emu> <3C43B8D1.292B8FA0@arcavia.com> Message-ID: <20020116042658.GA10280@hell.mine.nu> On Tue, Jan 15, 2002 at 12:06:25AM -0500, Kyle Lahnakoski wrote: > I did not mean to imply that Lisp is not superior to C or Java. I > wanted a discussion on WHY it is so. What aspects of Lisp make it a > good language? Arrays, structs, classes, hashtables are all features > that make a language better. I would like to know more about the > aspects of the core Lisp syntax that makes it preferred over other > languages. I didn't reply to your original message (yet), but it is because I think it was right on the spot and deserved a good answer. Actually, I reserved part of my thesis for the notion of expressiveness. I don't have all the answers yet, but I have many elements, and will try to present them in a coherent way in a next email. Yours freely, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] Nobody seems more obsessed by diet than our antimaterialist, otherworldly, New Age, spiritual types. But if the material world is merely illusion, an honest guru should as content with Budweiser and bratwurst as with raw carrot juice, tofu, and seaweed slime. -- Edward Abbey From schizophonic@tiscali.it Wed Jan 16 02:45:01 2002 From: schizophonic@tiscali.it (PB) Date: Wed Jan 16 02:45:01 2002 Subject: [OT] Be Message-ID: <002f01c19e7b$575d8fc0$2410af83@elet.polimi.it> For whom might care: Be Incorporated, the society which produced the famous BeOS, has sold all its assets and its intellectual property to Palm and is being dissolved. Their site now reports only financial information, with the operating system and all the resources unavailable, and a indicative black ribbon on the Be logo. Somehow paradigmatic of how a good software project can be hindered by its proprietary nature - think at all the people who wrote software for that os, or that just used it. Pietro -- Computer Science is not about computers, any more than astronomy is about telescopes. (Edsger Wybe Dijkstra) From israel@lith.com Wed Jan 16 10:17:01 2002 From: israel@lith.com (Israel Evans) Date: Wed Jan 16 10:17:01 2002 Subject: New to Tunes... Message-ID: Hello everyone. I've been browsing around the web and stumbled across the Tunes Project and was very attracted to it's philosophy and to the theories and viewpoints outlined in many of the papers on the site. Though I am quite the newcomer to programming in general I am very interested in becoming involved with this project in some way. At the very least, I'll be keeping up with the latest developments and lurking on the mailing lists. I would like to say that it is extremely refreshing to hear such interesting and educated debate on the fairly wide array of topics that Tunes naturally encompasses. Curiously yours, Israel C. Evans. From BRice@vinson.navy.mil Fri Jan 18 22:32:01 2002 From: BRice@vinson.navy.mil (RE01 Rice Brian T. EM2) Date: Fri Jan 18 22:32:01 2002 Subject: I will be home within the week Message-ID: <44EB12A3E6F7D5119AF80020486435BF017AF9EA@CVN70UEX02> Hello all, I've been following the discussions as I can on the web interfaces to the mailing lists and such, and it's certainly nice to see some activity. However, obviously I haven't made the effort to add to the discussions myself: my time is fairly sparse, basically. I haven't really had time for my own programming exercises as well. So when I return, expect the release of the final bug fixes and rounding-out of features for the initial semantics of my Arrow code, which is the Binary Relational Algebra plus some extensions. The coding that was done aside from that is very dis-organized and doesn't really reflect any concepts better than the sources I tried to emulate (e.g. Maude, Lisp, etc.), so it won't be released yet. I'm going to go talk to some professors and graduate students at the University of Washington nearby to see if I can develop some useful relationship and discussions with solving this in mind. However, I have been studying different matters which relate to the system, and I have some ideas which solve problems individually (collecting these ideas into a continuous system is another matter :/). One of the most interesting sources of food for thought I've found has been the collected works of Martin Heidegger, the German philosopher. I've also taken the time to practice up on C and OCAML for my own edification. Here's some preliminary feedback about some of the things presented recently: TUNES website / review: This is perennially useful in itself and also controversial. This also may be the first time in a while where I could devote quite a lot of time to writing and editing, but as I'm not familiar with web/cgi/php programming, someone needs to step forward to take care of what's needed. I believe Tril had some intentions on this, and there are new volunteers obviously, but whoever does it needs to follow through and take it on as their *own* (imho) to avoid the idea that someone would be interfering. Corey Reece wanted to do this with the Diktuon and I had put some content into it, but he no longer has the time for anything like it now. Questions about LISP or its status with respect to TUNES plans: Lisp is an excellent philosopher's stone for us because it has the longest history of interesting languages, and also has had some of the most relevant developments. The critical feature that characterizes any discussion about the various LISPs is the syntactic abstraction feature that it provides, which some researchers have actually suggested can be surpassed (foregoing cons-based representation with ADTs) but no one has really followed through on using this idea integrally. A *great* many features may be added or deleted from a language with this central feature and still be the object of a LISP discussion. Perhaps it would be more beneficial to frame these talks in terms of the features instead, or to propose ways that new and interesting features fit or do not fit into the current set of major semantic elements of what we commonly call LISP (e.g. applicative semantics, eval-quote relation, standardized quotation mechanism, ...). One major example that comes to mind is pattern-matching, which some LISPs in the 1960s even tried to incorporate (Planner and others, I believe. The name 'Scheme' itself is a pun on that tradition.). *As a side note, I do recommend following the Lambda the Ultimate Programming Language Weblog (http://lambda.weblogs.com), which has been a nice source of pointers and opinions of good programmers for me on my low-bandwidth connection out here. Questions about Maude or its status with respect to TUNES plans: As for Maude, I'll just explain the interesting aspects as quickly as I can. Maude is a specification language (like Z or OBJ) based on the replacement of (sub-)terms ('term-rewrite'). It has a basic self-hosted evaluator and quotation mechanism which are highly useful in specializing the language in interesting ways. Of course, it's *executable*: it's a logic that relates very neatly to concurrent computations and their models. I should add that the syntax is pretty bad as is; I find it fairly hard to use myself. Everything else about Maude is just the formal details. It is a research project after all. It's relevance to TUNES has to do with the TUNES idea of simple formal proofs being directly available for software and providing the security aspects we normally get through manual checking. (It took me a while to understand Fare's stance on this.) The security checks are just quick ways to say where you can optimize, and the big win (we predict) is that a good logic allows for many more *automatic* optimizations than we can get otherwise. Maude *is* just another language, but its semantics are at a very interesting point for us in the continuum of languages. If you like, edit these as you see fit and add them to explanation pages on the Wiki. When I get back, I'll need to take some time off and also to work on the company I consult for, but otherwise I'll be developing a lot of things for you, and will be very available for questions. I should be available well enough on IRC/ICQ as well, and apparently Squeak's groupware tools have also gotten a lot better. I certainly have enjoyed doing demos across the internet for Arrow and Squeak, so this will probably just improve. Thanks guys, ~ From bpt@tunes.org Sat Jan 19 11:56:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Sat Jan 19 11:56:02 2002 Subject: MOX Message-ID: <87bsfr6r78.fsf@tunes.org> I have begun preliminary work on a system called MOX. (``MOX'' stands for ``MOX Obviates Xanadu'', since it was originally going to be a hypertext system; `mox' is also a Latin word for `soon', with allusions to the common phrase `RSN'.) It is centered around a datastructure called an arrow, in honour of Brian Rice's Arrow system - I don't yet understand Arrow, but after attempting to read the Arrow papers one more time, I thought of locatives and how an ``arrow'' might be something like a locative (though I knew that that is not what an Arrow arrow is). An arrow acts as a pointer into a 'verse (short for ???verse). A 'verse, the allusion being to poetry and rhyme, acts as an environment in other languages, except that instead of being a mapping between symbols and objects, it is simply a collection of objects, internally identified by a tumbler (a word borrowed from Xanadu) - though I may change `tumbler' to something else, since I don't really know what would be like in Xanadu other than being of the form 0.x.y.z (I could probably do some research on it, though). [Those who've listened to me promise to post to the TUNES list on IRC, besides having learned how good I am at procrastination :), may notice that I've generalized from a huge Xanadu-like ``Objectuverse'' to smaller 'verses. I think that this was a good design decision, but I may reverse it if necessary. The worlds thread from a few years ago, Alan Grime's Sphere project, and other ideas were influential here.] An `object' in MOX is simply something that has a tumbler, some slots (well, zero or more slots, probably), and hints. (The name `hints' will probably change to `annotations' later on, as it appears that Fare came up with this idea a long time before I did.) I am not quite sure how the slots will work yet. [After considering recent ideas I've had concerning protocols/interfaces, specification languages, etc, I may change the semantics of objects completely, but then again, I may not. MOX doesn't yet exist and so /ipso facto/ doesn't even have ten users, so unlike the designer of `make' I don't even have a *bad* excuse :).] In MOX, source code is merely a sequence of arrows, possibly, e.g. using the Lisp tradition of using lists to represent function applications. However, there are *no symbols*. It will likely be possible to attach a default label to an object, through hints, but there is no particular reason why one must use labeled objects at all. In fact, using hints, someone could implement, say, a system where objects were identified by color (yes, that's probably a really stupid idea, but there are most likely some interesting variations on it). Some interesting things appear to be possible with arrows; for example, if MOX were to adopt the Lispish convention of making source code simply a series of sexps, then MOX could implement Arc's ``name-munging'' (I have no idea what the real name of the ``feature'' is) cleanly. (In Arc, (eqcar x y) === (eq (car x) y) but in MOX, something like (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|)) with `|...|' denoting an arrow to the object whose canonical name is `...', could be cleanly implemented, I think.) - Synopsis - MOX is based on a datastructure called an arrow (in honor of Brian Rice's excellent Arrow system, which it seems that no one other than he understands :)). Source is just a sequence of arrows ``pointing'' to an object in a 'verse, which can orthogonally or non-orthogonally make objects persistant, and [FIXME: is this a good idea? - probably not] the same arrow will always point to the same object, unless, perhaps, a hint is provided to the contrary. A 'verse is a collection of objects. There are no symbols in MOX, though they can be emulated. MOX combines development and hypertext in a somewhat novel way. This post is poorly organized and incomplete, but it will hopefully give you some idea of the basic concepts of MOX. All questions are gladly answered and I would very much appreciate any feedback at all. Thanks in advance, -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From bpt@tunes.org Sat Jan 19 12:07:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Sat Jan 19 12:07:02 2002 Subject: MOX In-Reply-To: <87bsfr6r78.fsf@tunes.org> (Brian P Templeton's message of "Fri, 18 Jan 2002 20:54:19 -0500") References: <87bsfr6r78.fsf@tunes.org> Message-ID: <87lmeukrqm.fsf@tunes.org> Brian P Templeton writes: > I have begun preliminary work on a system called MOX. (``MOX'' stands > for ``MOX Obviates Xanadu'', since it was originally going to be a > hypertext system; `mox' is also a Latin word for `soon', with > allusions to the common phrase `RSN'.) > > It is centered around a datastructure called an arrow, in honour of > Brian Rice's Arrow system - I don't yet understand Arrow, but after > attempting to read the Arrow papers one more time, I thought of > locatives and how an ``arrow'' might be something like a locative > (though I knew that that is not what an Arrow arrow is). > > An arrow acts as a pointer into a 'verse (short for ???verse). A > 'verse, the allusion being to poetry and rhyme, acts as an environment > in other languages, except that instead of being a mapping between > symbols and objects, it is simply a collection of objects, internally > identified by a tumbler (a word borrowed from Xanadu) - though I may > change `tumbler' to something else, since I don't really know what > would be like in Xanadu other than being of the form 0.x.y.z (I could s/what would be like/what they would be like/ > probably do some research on it, though). > > [Those who've listened to me promise to post to the TUNES list on IRC, > besides having learned how good I am at procrastination :), may notice > that I've generalized from a huge Xanadu-like ``Objectuverse'' to > smaller 'verses. I think that this was a good design decision, but I > may reverse it if necessary. The worlds thread from a few years ago, > Alan Grime's Sphere project, and other ideas were influential here.] ^^^^^^^^^^^^ Alan Grimes' > > An `object' in MOX is simply something that has a tumbler, some slots > (well, zero or more slots, probably), and hints. (The name `hints' > will probably change to `annotations' later on, as it appears that > Fare came up with this idea a long time before I did.) I am not quite > sure how the slots will work yet. > > [After considering recent ideas I've had concerning > protocols/interfaces, specification languages, etc, I may change the > semantics of objects completely, but then again, I may not. MOX > doesn't yet exist and so /ipso facto/ doesn't even have ten users, so > unlike the designer of `make' I don't even have a *bad* excuse :).] > > In MOX, source code is merely a sequence of arrows, possibly, e.g. > using the Lisp tradition of using lists to represent function > applications. However, there are *no symbols*. It will likely be > possible to attach a default label to an object, through hints, but > there is no particular reason why one must use labeled objects at all. > In fact, using hints, someone could implement, say, a system where > objects were identified by color (yes, that's probably a really stupid > idea, but there are most likely some interesting variations on it). > > Some interesting things appear to be possible with arrows; for > example, if MOX were to adopt the Lispish convention of making source > code simply a series of sexps, then MOX could implement Arc's > ``name-munging'' (I have no idea what the real name of the ``feature'' > is) cleanly. (In Arc, > (eqcar x y) === (eq (car x) y) > but in MOX, something like > (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|)) > with `|...|' denoting an arrow to the object whose canonical name is > `...', could be cleanly implemented, I think.) > Oops. I forgot to mention that this would probably rely on a sort of arrow called a multi-arrow, which could also be used for multiple values. > - Synopsis - > MOX is based on a datastructure called an arrow (in honor of Brian > Rice's excellent Arrow system, which it seems that no one other than > he understands :)). Source is just a sequence of arrows ``pointing'' > to an object in a 'verse, which can orthogonally or non-orthogonally > make objects persistant, and [FIXME: is this a good idea? - probably > not] the same arrow will always point to the same object, unless, > perhaps, a hint is provided to the contrary. A 'verse is a collection > of objects. There are no symbols in MOX, though they can be emulated. > MOX combines development and hypertext in a somewhat novel way. > > This post is poorly organized and incomplete, but it will hopefully > give you some idea of the basic concepts of MOX. All questions are > gladly answered and I would very much appreciate any feedback at all. > > Thanks in advance, > -- > BPT /"\ ASCII Ribbon Campaign > backronym for Linux: \ / No HTML or RTF in mail > Linux Is Not Unix X No MS-Word in mail > Meme plague ;) ---------> / \ Respect Open Standards > BTW, water, if you read this, am I correct in predicting that you'll arrive in San Diego, CA soon? (You probably can't answer that :).) Best regards, -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From BRice@vinson.navy.mil Sat Jan 19 21:56:01 2002 From: BRice@vinson.navy.mil (RE01 Rice Brian T. EM2) Date: Sat Jan 19 21:56:01 2002 Subject: MOX Message-ID: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> Hi, it's nice to have time to talk again. Brian P Templeton writes: > I have begun preliminary work on a system called MOX. (``MOX'' stands > for ``MOX Obviates Xanadu'', since it was originally going to be a > hypertext system; `mox' is also a Latin word for `soon', with > allusions to the common phrase `RSN'.) Interesting reference. Actually in recent times I've considered renaming Arrow to one of a few terms in ancient Greek, to honor some of the philosophical ideas I think it relates to. 'logos' and 'aletheia' are at the top of the list, and there are a few others. > It is centered around a datastructure called an arrow, in honour of > Brian Rice's Arrow system - I don't yet understand Arrow, but after > attempting to read the Arrow papers one more time, I thought of > locatives and how an ``arrow'' might be something like a locative > (though I knew that that is not what an Arrow arrow is). > An arrow acts as a pointer into a 'verse (short for ???verse). A > 'verse, the allusion being to poetry and rhyme, acts as an environment > in other languages, except that instead of being a mapping between > symbols and objects, it is simply a collection of objects, internally > identified by a tumbler (a word borrowed from Xanadu) - though I may > change `tumbler' to something else, since I don't really know what > would be like in Xanadu other than being of the form 0.x.y.z (I could s/what would be like/what they would be like/ > probably do some research on it, though). That sounds like what I was intending (though I didn't properly document) with the Slate language system. Eventually the idea was to use arbitrary quoted objects as identifiers (annotations for path elements) to obtain/denote the available objects in the system. Still, I can't think of a good term for it either, except perhaps 'name'. Remember that if you consider '.' in an algebraic sense, it's an associative, non-commutative operator, probably using an (quoted?) empty string as its identity element (i.e. "''.foo" = "foo"); so you can describe it programmatically. It happens to have the same semantics as character- or string-catenation into strings, although at a separated level of abstraction. > [Those who've listened to me promise to post to the TUNES list on IRC, > besides having learned how good I am at procrastination :), may notice > that I've generalized from a huge Xanadu-like ``Objectuverse'' to > smaller 'verses. I think that this was a good design decision, but I > may reverse it if necessary. The worlds thread from a few years ago, > Alan Grime's Sphere project, and other ideas were influential here.] I'll have to look back at that. > An `object' in MOX is simply something that has a tumbler, some slots > (well, zero or more slots, probably), and hints. (The name `hints' > will probably change to `annotations' later on, as it appears that > Fare came up with this idea a long time before I did.) I am not quite > sure how the slots will work yet. This is what makes me think of the Slate system the most. Within that system I was using different aspects of the proposed MetaObject protocol as the place for hints, so that they were meta-objects in the generic sense that the CLOS MOP considers things. Objects were sets of slots in the most generic logical sense. I have to say that I haven't overcome all of the problems that arose when trying to meld this idea into the TUNES ideal. > [After considering recent ideas I've had concerning > protocols/interfaces, specification languages, etc, I may change the > semantics of objects completely, but then again, I may not. MOX > doesn't yet exist and so /ipso facto/ doesn't even have ten users, so > unlike the designer of `make' I don't even have a *bad* excuse :).] Well, I may have some time now to implement the ideas I completed for Slate once I get back. It'll probably be in Lisp first instead of in Arrow as I intended, mostly due to my difficulties in trying to make an architecture within Arrow that would allow for those things (I think these problems are not insurmountable; I just need to talk these ideas out a little to refine my decisions). > In MOX, source code is merely a sequence of arrows, possibly, e.g. > using the Lisp tradition of using lists to represent function > applications. However, there are *no symbols*. It will likely be > possible to attach a default label to an object, through hints, but > there is no particular reason why one must use labeled objects at all. > In fact, using hints, someone could implement, say, a system where > objects were identified by color (yes, that's probably a really stupid > idea, but there are most likely some interesting variations on it). Interesting. It sounds similar to what I mentioned above, and there's certainly space in the Slate type-system to allow for the various color types, obviously the larger system needs mappings from these color objects to objectively-defined (e.g. scientific) measurements in order to be useful. Taken from your self-reply: > > Some interesting things appear to be possible with arrows; for > > example, if MOX were to adopt the Lispish convention of making source > > code simply a series of sexps, then MOX could implement Arc's > > ``name-munging'' (I have no idea what the real name of the ``feature'' > > is) cleanly. (In Arc, > > (eqcar x y) === (eq (car x) y) > > but in MOX, something like > > (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|)) > > with `|...|' denoting an arrow to the object whose canonical name is > > `...', could be cleanly implemented, I think.) > > > Oops. I forgot to mention that this would probably rely on a sort of > arrow called a multi-arrow, which could also be used for multiple > values. I interpret this `|...|' operator as the reification of the reference (as an arrow), which seems like boxing (Fare has used this term several times; this refers to the Eval/Quote and modal S4 logic papers by Giraud). Boxing is similar to quote except for quote's relation to eval; it's similar also to ML's referencing operator, which is what allows for state in ML. As for the 'real name' of the name-munging idea, it sounds like an extension of the DWIM features that InterLisp had in the 70's for letting the listener guess what a user means when an environment lookup fails. I'm just referring to the fact that it was non-deterministic semantically. With your || operator, you're introducing the meta-level type of string that is an extension (level 2) of the distinction I made earlier between '.' (level 1) and string-concatenation (level 0 abstracted from strings). > - Synopsis - > MOX is based on a datastructure called an arrow (in honor of Brian > Rice's excellent Arrow system, which it seems that no one other than > he understands :)). Source is just a sequence of arrows ``pointing'' > to an object in a 'verse, which can orthogonally or non-orthogonally > make objects persistant, and [FIXME: is this a good idea? - probably > not] the same arrow will always point to the same object, unless, > perhaps, a hint is provided to the contrary. A 'verse is a collection > of objects. There are no symbols in MOX, though they can be emulated. > MOX combines development and hypertext in a somewhat novel way. As for the notion of source you use, it'd be useful to give an explanation of the reason for using sequences as your code shape; perhaps by explaining what the sequencing is supposed to mean semantically, you (we) could arrive at a better understanding. As for persistency, I am reminded of the Linear Naming paper by Alan Bawden, where a name being linear corresponds to trading your reference to it with a reference to something else, which breaks an implicit 'return link' back to you; it resolves to manual GC in a simplified form. Other systems use this in a linear typing sense; you annotate an object as being allocated linearly, and it is deleted from the system heap right when you lose the reference to it. This works usually by just holding it on the stack and requiring multiple references to only use heap-allocated objects (here we pretend that the linearly-allocated objects are in the heap semantically). About multi-arrows, I'm not sure what kind of reference this would be, perhaps you just need a collection primitive, and this is your intent. Am I off? > This post is poorly organized and incomplete, but it will hopefully > give you some idea of the basic concepts of MOX. All questions are > gladly answered and I would very much appreciate any feedback at all. Not too bad an explanation. Of course I'd like to hear more at some point. Perhaps an IRC (i.e. real-time) meeting would be best. > BTW, water, if you read this, am I correct in predicting that you'll > arrive in San Diego, CA soon? (You probably can't answer that :).) I'm on the ship at the pier right now, but I'm in the middle of dealing with a pretty bad flu. So I'll not be in town this time. I only had 16 hours of time off anyway. It's pretty likely, though, that I'll be around again while doing software work. Thanks, ~ From kholmes@localhost.localdomain Sun Jan 20 13:31:02 2002 From: kholmes@localhost.localdomain (Kevin Holmes) Date: Sun Jan 20 13:31:02 2002 Subject: (no subject) Message-ID: <200201192244.g0JMilH01856@localhost.localdomain> From: Kevin Holmes To: tunes@tunes.org Subject: Re: Mox Reply-To: kholmes@sedona.net Brian P Templeton bpt@tunes.org wrote: > environment in other languages, except that instead of being a > mapping between symbols and objects, it is simply a collection of > objects, internally identified by a tumbler (a word borrowed from > Xanadu) - though I may change `tumbler' to something else, since I > don't really know what would be like in Xanadu other than being of > the form 0.x.y.z (I could probably do some research on it, though). Can you provide a link or explanation on what a tumbler is? > In MOX, source code is merely a sequence of arrows, possibly, e.g. > using the Lisp tradition of using lists to represent function > applications. However, there are *no symbols*. It will likely be > possible to attach a default label to an object, through hints, but > there is no particular reason why one must use labeled objects at all. > In fact, using hints, someone could implement, say, a system where > objects were identified by color (yes, that's probably a really stupid > idea, but there are most likely some interesting variations on it). Can you give more examples on how to reference an object without a symbol? > - Synopsis - MOX is based on a datastructure called an arrow (in > honor of Brian Rice's excellent Arrow system, which it seems that no > one other than he understands :)). Source is just a sequence of > arrows ``pointing'' to an object in a 'verse, which can orthogonally > or non-orthogonally make objects persistant, and [FIXME: is this a > good idea? - probably not] the same arrow will always point to the > same object, unless, perhaps, a hint is provided to the contrary. A > 'verse is a collection of objects. There are no symbols in MOX, > though they can be emulated. MOX combines development and hypertext > in a somewhat novel way. Could you explain what a hint is and how it would be used? And how is hypertext involved? Best Regards, Kevin Holmes From bpt@tunes.org Mon Jan 21 18:13:01 2002 From: bpt@tunes.org (Brian P Templeton) Date: Mon Jan 21 18:13:01 2002 Subject: (no subject) In-Reply-To: <200201192244.g0JMilH01856@localhost.localdomain> (Kevin Holmes's message of "Sat, 19 Jan 2002 15:44:47 -0700") References: <200201192244.g0JMilH01856@localhost.localdomain> Message-ID: <877kqbjy3r.fsf@tunes.org> Kevin Holmes writes: > From: Kevin Holmes > To: tunes@tunes.org > Subject: Re: Mox > Reply-To: kholmes@sedona.net >=20 > Brian P Templeton bpt@tunes.org wrote: >=20 >=20 >> environment in other languages, except that instead of being a >> mapping between symbols and objects, it is simply a collection of >> objects, internally identified by a tumbler (a word borrowed from >> Xanadu) - though I may change `tumbler' to something else, since I >> don't really know what would be like in Xanadu other than being of >> the form 0.x.y.z (I could probably do some research on it, though). >=20 > Can you provide a link or explanation on what a tumbler is? >=20 Hmm. I think may have some information, and you can probably google for something like "Xanadu tumbler" to get some information. (Of course, the Xanadu books (_Literary Machines_ and the out-of-print _Computer Lib_, both by Ted Nelson) should have some information, but I haven't read them yet, so I'm not sure.) >> In MOX, source code is merely a sequence of arrows, possibly, e.g. >> using the Lisp tradition of using lists to represent function >> applications. However, there are *no symbols*. It will likely be >> possible to attach a default label to an object, through hints, but >> there is no particular reason why one must use labeled objects at all. >> In fact, using hints, someone could implement, say, a system where >> objects were identified by color (yes, that's probably a really stupid >> idea, but there are most likely some interesting variations on it). >=20 > Can you give more examples on how to reference an object without a symbol? >=20 Quite simply, you use a reference (sort of like a locative)! Although I am not sure what the exact semantics of 'verses and arrows are (for example, how could something like `fluid-let' be implemented?), here's a possible example: 'verse 0: [...] 99: function object: concat 100: string object: "abc" 101: string object: "def" [...] source code: [...] (# # #) [...] Note that the #<...> parts, the function name, parentheses, double-quotes, etc are ONLY to make the example easier to read. >> - Synopsis - MOX is based on a datastructure called an arrow (in >> honor of Brian Rice's excellent Arrow system, which it seems that no >> one other than he understands :)). Source is just a sequence of >> arrows ``pointing'' to an object in a 'verse, which can orthogonally >> or non-orthogonally make objects persistant, and [FIXME: is this a >> good idea? - probably not] the same arrow will always point to the >> same object, unless, perhaps, a hint is provided to the contrary. A >> 'verse is a collection of objects. There are no symbols in MOX, >> though they can be emulated. MOX combines development and hypertext >> in a somewhat novel way. >=20 > Could you explain what a hint is and how it would be used? And how is > hypertext involved? >=20 Hints are sort of like Far=E9's annotations or CL's declarations. Although I'm not sure whether they would store type information or not (objects might turn out to be immutable with a versioning system), one possible use would be to specify the canonical name of an object for editors to display, etc. The connection to hypertext is a very tangled one. First of all, a few months ago (perhaps early last fall) I read ``As We May Think'' by Vannevar Bush, leading me to re-investigate hypertext. Then I learned about the Lisp Machines, and heard `locatives' mentioned a few times, but with no explanations. I planned to write a system called eMUmex that would be a sort of an implementation of Bush's memex device. Directly following that I found out about LyX, and envisioned a similar, but much better, system (in Emacs, actually) that would simply convert LaTeX objects into widgets for editing them, and then convert back when the buffer was saved. After that I learned about Xanadu (well, I had read a bit about it a few years prior, but never read much about it), and came up with a scheme where a hypertext document would merely be a series of objects that would have editing and viewing widgets provided by various environments (e.g. Emacs-like, billowing, environments for blind users, etc), with associated hints for, e.g., a pseudo-environment for hardcopy output to restrict the width of a particular object to, say, 3 cm. Then I re-read the Arrow papers (I don't really know much at all about category theory yet), and learned what a locative was. Finally, I realized that, instead of having reference/transclusion/... objects in hypertext documents, and locatives in programs, why not combine the two into generalized arrows (imagining a locative as simply being a conceptual `arrow' to somewhere else was helpful here)? Lately, I've also realized that my new activation/deactivation scheme (analogous to quotation/evaluation in some ways) would /not only/ allow one to discard the concept of source code separate from objects altogether and facilitate metaprogramming, but *also* allow both transclusions and hyperlinks in hypertext documents, very easily!! *whew* That was a long explanation, and I may have left out a part, so please inform me if I've skipped anything. > Best Regards, > Kevin Holmes >=20 Regards, --=20 BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From bpt@tunes.org Mon Jan 21 18:13:06 2002 From: bpt@tunes.org (Brian P Templeton) Date: Mon Jan 21 18:13:06 2002 Subject: MOX In-Reply-To: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> ("RE01 Rice Brian T. EM2"'s message of "Sat, 19 Jan 2002 21:54:59 -0800") References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> Message-ID: <873d0zjwt0.fsf@tunes.org> "RE01 Rice Brian T. EM2" writes: > Hi, it's nice to have time to talk again. > > Brian P Templeton writes: > >> I have begun preliminary work on a system called MOX. (``MOX'' stands >> for ``MOX Obviates Xanadu'', since it was originally going to be a >> hypertext system; `mox' is also a Latin word for `soon', with >> allusions to the common phrase `RSN'.) > > Interesting reference. Actually in recent times I've considered renaming > Arrow to one of a few terms in ancient Greek, to honor some of the > philosophical ideas I think it relates to. 'logos' and 'aletheia' are at the > top of the list, and there are a few others. > Sorry, but I don't (yet) know Greek, though I've been planning to try to learn it (but don't have enough time ATM): what do `logos' and `aletheia' mean? >> It is centered around a datastructure called an arrow, in honour of >> Brian Rice's Arrow system - I don't yet understand Arrow, but after >> attempting to read the Arrow papers one more time, I thought of >> locatives and how an ``arrow'' might be something like a locative >> (though I knew that that is not what an Arrow arrow is). > >> An arrow acts as a pointer into a 'verse (short for ???verse). A >> 'verse, the allusion being to poetry and rhyme, acts as an environment >> in other languages, except that instead of being a mapping between >> symbols and objects, it is simply a collection of objects, internally >> identified by a tumbler (a word borrowed from Xanadu) - though I may >> change `tumbler' to something else, since I don't really know what >> would be like in Xanadu other than being of the form 0.x.y.z (I could > s/what would be like/what they would be like/ >> probably do some research on it, though). > > That sounds like what I was intending (though I didn't properly document) > with the Slate language system. Eventually the idea was to use arbitrary > quoted objects as identifiers (annotations for path elements) to > obtain/denote the available objects in the system. Still, I can't think of a > good term for it either, except perhaps 'name'. Remember that if you > consider '.' in an algebraic sense, it's an associative, non-commutative > operator, probably using an (quoted?) empty string as its identity element > (i.e. "''.foo" = "foo"); so you can describe it programmatically. It happens > to have the same semantics as character- or string-catenation into strings, > although at a separated level of abstraction. > Tumblers are not really visible to programmers in MOX, normally - they are just a detail of how objects are uniquely idenfied. No programmer (except a MOX developer) will care what an object's tumbler is, as long as they can produce a valid arrow to the object. >> [Those who've listened to me promise to post to the TUNES list on IRC, >> besides having learned how good I am at procrastination :), may notice >> that I've generalized from a huge Xanadu-like ``Objectuverse'' to >> smaller 'verses. I think that this was a good design decision, but I >> may reverse it if necessary. The worlds thread from a few years ago, >> Alan Grime's Sphere project, and other ideas were influential here.] > > I'll have to look back at that. > Worlds and spheres are getting more influential by the moment! I just had an excellent idea concerning source code and 'verses, I think, but I'm not sure how to write it yet. >> An `object' in MOX is simply something that has a tumbler, some slots >> (well, zero or more slots, probably), and hints. (The name `hints' >> will probably change to `annotations' later on, as it appears that >> Fare came up with this idea a long time before I did.) I am not quite >> sure how the slots will work yet. > > This is what makes me think of the Slate system the most. Within that system > I was using different aspects of the proposed MetaObject protocol as the > place for hints, so that they were meta-objects in the generic sense that > the CLOS MOP considers things. Objects were sets of slots in the most > generic logical sense. I have to say that I haven't overcome all of the > problems that arose when trying to meld this idea into the TUNES ideal. > >> [After considering recent ideas I've had concerning >> protocols/interfaces, specification languages, etc, I may change the >> semantics of objects completely, but then again, I may not. MOX >> doesn't yet exist and so /ipso facto/ doesn't even have ten users, so >> unlike the designer of `make' I don't even have a *bad* excuse :).] > > Well, I may have some time now to implement the ideas I completed for Slate > once I get back. It'll probably be in Lisp first instead of in Arrow as I > intended, mostly due to my difficulties in trying to make an architecture > within Arrow that would allow for those things (I think these problems are > not insurmountable; I just need to talk these ideas out a little to refine > my decisions). > What Lisp will it be in: CL, Scheme, or some other Lisp? I'd like to test it, but most non-trivial Scheme programs are not portable between implementations :(. >> In MOX, source code is merely a sequence of arrows, possibly, e.g. >> using the Lisp tradition of using lists to represent function >> applications. However, there are *no symbols*. It will likely be >> possible to attach a default label to an object, through hints, but >> there is no particular reason why one must use labeled objects at all. >> In fact, using hints, someone could implement, say, a system where >> objects were identified by color (yes, that's probably a really stupid >> idea, but there are most likely some interesting variations on it). > > Interesting. It sounds similar to what I mentioned above, and there's > certainly space in the Slate type-system to allow for the various color > types, obviously the larger system needs mappings from these color objects > to objectively-defined (e.g. scientific) measurements in order to be useful. > Well, no, the names or the colors have no relation to how the object is identified; sorry for that ambiguity. Basically, labels and colors are conveniences for developers. > Taken from your self-reply: > >> > Some interesting things appear to be possible with arrows; for >> > example, if MOX were to adopt the Lispish convention of making source >> > code simply a series of sexps, then MOX could implement Arc's >> > ``name-munging'' (I have no idea what the real name of the ``feature'' >> > is) cleanly. (In Arc, >> > (eqcar x y) === (eq (car x) y) >> > but in MOX, something like >> > (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|)) >> > with `|...|' denoting an arrow to the object whose canonical name is >> > `...', could be cleanly implemented, I think.) >> > >> Oops. I forgot to mention that this would probably rely on a sort of >> arrow called a multi-arrow, which could also be used for multiple >> values. > > I interpret this `|...|' operator as the reification of the reference (as an > arrow), which seems like boxing (Fare has used this term several times; this > refers to the Eval/Quote and modal S4 logic papers by Giraud). Boxing is > similar to quote except for quote's relation to eval; it's similar also to > ML's referencing operator, which is what allows for state in ML. > I'm not familiar with `boxing'. `|...|' is *not* an operator; it is just to make the example easier to understand. However, as for quoting, this seems like a good time to introduce activation/dectivation. Here are some examples: - An active application object (see below) would, when reference, return its evaluation; an inactive application object could be used as a thunk. (Well, I'm certainly not sure about this one.) - An active arrow, when referenced, returns the evaluation of the object that it points to; an inactive arrow is self-evaluating. - An active multi-arrow, when referenced, returns the evaluation of the object that the first branch points to; an inactive multi-arrow is self-evaluating. After writing these examples, I am surprised to find that active versus inactive seems to simply mean self-evaluating versus non-self-evaluating!! > As for the 'real name' of the name-munging idea, it sounds like an extension > of the DWIM features that InterLisp had in the 70's for letting the listener > guess what a user means when an environment lookup fails. I'm just referring > to the fact that it was non-deterministic semantically. With your || > operator, you're introducing the meta-level type of string that is an > extension (level 2) of the distinction I made earlier between '.' (level 1) > and string-concatenation (level 0 abstracted from strings). > No, the `|...|' operator is simply a notational convenience. >> - Synopsis - >> MOX is based on a datastructure called an arrow (in honor of Brian >> Rice's excellent Arrow system, which it seems that no one other than >> he understands :)). Source is just a sequence of arrows ``pointing'' >> to an object in a 'verse, which can orthogonally or non-orthogonally >> make objects persistant, and [FIXME: is this a good idea? - probably >> not] the same arrow will always point to the same object, unless, >> perhaps, a hint is provided to the contrary. A 'verse is a collection >> of objects. There are no symbols in MOX, though they can be emulated. >> MOX combines development and hypertext in a somewhat novel way. > > As for the notion of source you use, it'd be useful to give an explanation > of the reason for using sequences as your code shape; perhaps by explaining > what the sequencing is supposed to mean semantically, you (we) could arrive > at a better understanding. > I no longer think that sequences are necessary, and I didn't at the time of this posting; I have now, however, decided that something like an application object would be best. I now have an idea about source code that may make metaprogramming and persistance easier. > As for persistency, I am reminded of the Linear Naming paper by Alan Bawden, > where a name being linear corresponds to trading your reference to it with a > reference to something else, which breaks an implicit 'return link' back to > you; it resolves to manual GC in a simplified form. Other systems use this > in a linear typing sense; you annotate an object as being allocated > linearly, and it is deleted from the system heap right when you lose the > reference to it. This works usually by just holding it on the stack and > requiring multiple references to only use heap-allocated objects (here we > pretend that the linearly-allocated objects are in the heap semantically). > > About multi-arrows, I'm not sure what kind of reference this would be, > perhaps you just need a collection primitive, and this is your intent. Am I > off? > A multi-arrow is conceptually something like this: x y z ^ ^ ^ \ | / 0 1 2 \ | / --- | where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in some 'verse. When the multi-arrow is active, it is considered to point to only the object at the end of the first branch - in this case, x - and when inactive, well, it is a complete multi-arrow, not pointing to anything, but just there. They will probably be used to implement multiple values. You are off; multi-arrows are *not* collection primitives. They are intended to be used as multiple values of sorts. >> This post is poorly organized and incomplete, but it will hopefully >> give you some idea of the basic concepts of MOX. All questions are >> gladly answered and I would very much appreciate any feedback at all. > > Not too bad an explanation. Of course I'd like to hear more at some point. > Perhaps an IRC (i.e. real-time) meeting would be best. > Yes, I think so. I'm usually IRCing somewhere between 8:00 to 10:00 PM EST. >> BTW, water, if you read this, am I correct in predicting that you'll >> arrive in San Diego, CA soon? (You probably can't answer that :).) > > I'm on the ship at the pier right now, but I'm in the middle of dealing with > a pretty bad flu. So I'll not be in town this time. I only had 16 hours of > time off anyway. > I hope you are well again soon. > It's pretty likely, though, that I'll be around again while doing software > work. > > Thanks, > ~ > Best regards, -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From BRice@vinson.navy.mil Mon Jan 21 22:12:02 2002 From: BRice@vinson.navy.mil (RE01 Rice Brian T. EM2) Date: Mon Jan 21 22:12:02 2002 Subject: MOX Message-ID: <44EB12A3E6F7D5119AF80020486435BF017AF9EF@CVN70UEX02> Once more into the fray... > > Brian P Templeton writes: > > > >> I have begun preliminary work on a system called MOX. > (``MOX'' stands > >> for ``MOX Obviates Xanadu'', since it was originally going to be a > >> hypertext system; `mox' is also a Latin word for `soon', with > >> allusions to the common phrase `RSN'.) > > > > Interesting reference. Actually in recent times I've > considered renaming > > Arrow to one of a few terms in ancient Greek, to honor some of the > > philosophical ideas I think it relates to. 'logos' and > 'aletheia' are at the > > top of the list, and there are a few others. > > > Sorry, but I don't (yet) know Greek, though I've been planning to try > to learn it (but don't have enough time ATM): what do `logos' and > `aletheia' mean? Logos is traditionally translated as 'the literal word' or 'word denotation' referring to the objective meaning or definition of words, sometimes more specifically as nouns. But this only came after Aristotle and contemporaries. Before this it apparently meant something more like 'the connected consensus of words' or '... of knowledge', and the former description arose after it and replaced it. Aletheia means the unconcealment (appearing) of things in general into the world (or at least that's how Heidegger puts it ;). This relates a lot to the ideas I wanted for my ontology system within Arrow. Perhaps the word is most appropriate for the ontology system (and just sounds pretty rather than academic, after all no one cares if the Eidos game company is named after the greek word for 'mask' or 'idea' or 'icon' =). Conventional translations for the word usually just reduce it to 'truth' or 'beauty'. As always, I recommend a Google search for strange words that happen to be talked about in important literature. > >> It is centered around a datastructure called an arrow, in honour of > >> Brian Rice's Arrow system - I don't yet understand Arrow, but after > >> attempting to read the Arrow papers one more time, I thought of > >> locatives and how an ``arrow'' might be something like a locative > >> (though I knew that that is not what an Arrow arrow is). > > > >> An arrow acts as a pointer into a 'verse (short for ???verse). A > >> 'verse, the allusion being to poetry and rhyme, acts as an > environment > >> in other languages, except that instead of being a mapping between > >> symbols and objects, it is simply a collection of objects, > internally > >> identified by a tumbler (a word borrowed from Xanadu) - > though I may > >> change `tumbler' to something else, since I don't really know what > >> would be like in Xanadu other than being of the form > 0.x.y.z (I could > > s/what would be like/what they would be like/ > >> probably do some research on it, though). > > > > That sounds like what I was intending (though I didn't > properly document) > > with the Slate language system. Eventually the idea was to > use arbitrary > > quoted objects as identifiers (annotations for path elements) to > > obtain/denote the available objects in the system. Still, I > can't think of a > > good term for it either, except perhaps 'name'. Remember that if you > > consider '.' in an algebraic sense, it's an associative, > non-commutative > > operator, probably using an (quoted?) empty string as its > identity element > > (i.e. "''.foo" = "foo"); so you can describe it > programmatically. It happens > > to have the same semantics as character- or > string-catenation into strings, > > although at a separated level of abstraction. > > > Tumblers are not really visible to programmers in MOX, normally - they > are just a detail of how objects are uniquely idenfied. No programmer > (except a MOX developer) will care what an object's tumbler is, as > long as they can produce a valid arrow to the object. Okay, this kind of explanation (and others below) helps give me an idea of what MOX means in the TUNES conception of things. I'll try to explain what I understand it to be below. > >> An `object' in MOX is simply something that has a tumbler, some slots > >> (well, zero or more slots, probably), and hints. (The name `hints' > >> will probably change to `annotations' later on, as it appears that > >> Fare came up with this idea a long time before I did.) I am not quite > >> sure how the slots will work yet. I just re-read this and now have questions about it, just to clarify: you mentioned above that the tumbler is invisible, but is still required for MOX object existence. Basically you consider it your underlying unique identifier (ugh, I hate conversations about those) but you consider the names or hints to not be part of the meaning of the object. On the other hand, I may just be confusing your slot concept with your annotation concept, which I treat fairly similarly in my Slate concepts. But then again you seem just as unsure as I am. Can you clarify what you want for MOX? > > Well, I may have some time now to implement the ideas I > completed for Slate > > once I get back. It'll probably be in Lisp first instead of > in Arrow as I > > intended, mostly due to my difficulties in trying to make > an architecture > > within Arrow that would allow for those things (I think > these problems are > > not insurmountable; I just need to talk these ideas out a > little to refine > > my decisions). > > > What Lisp will it be in: CL, Scheme, or some other Lisp? I'd like to > test it, but most non-trivial Scheme programs are not portable between > implementations :(. Common Lisp... it has the most useful features, full macros, CLOS (good enough for me), and optional and keyword arguments. > >> In MOX, source code is merely a sequence of arrows, possibly, e.g. > >> using the Lisp tradition of using lists to represent function > >> applications. However, there are *no symbols*. It will likely be > >> possible to attach a default label to an object, through hints, but > >> there is no particular reason why one must use labeled > objects at all. > >> In fact, using hints, someone could implement, say, a system where > >> objects were identified by color (yes, that's probably a > really stupid > >> idea, but there are most likely some interesting variations on it). > > > > Interesting. It sounds similar to what I mentioned above, > and there's > > certainly space in the Slate type-system to allow for the > various color > > types, obviously the larger system needs mappings from > these color objects > > to objectively-defined (e.g. scientific) measurements in > order to be useful. > > > Well, no, the names or the colors have no relation to how the object > is identified; sorry for that ambiguity. Basically, labels and colors > are conveniences for developers. Now I am really confused :). What exactly is the status of your identifiers in MOX? May I use arbitrary-type objects or no? Before you answer, I also offer you a third option: do you mean to create two separate MOX languages/interfaces, one for average users and a seperate, more powerful one for developers? If this is so, how strongly would you be dividing the two? As a contrast, I consider the weakest division between base-level and meta-level access for a common language is that for Lisp and/or Smalltalk: you simply have access to 'eval' + hooks and the environment (in Smalltalk's case, you hack the bytecode-compiler or meta-classes). I suppose as long as I've asked all these questions, I'll tack on one more: do the tumblers fit in at the 'developer' (~meta) level? > > Taken from your self-reply: > > > >> > Some interesting things appear to be possible with arrows; for > >> > example, if MOX were to adopt the Lispish convention of > making source > >> > code simply a series of sexps, then MOX could implement Arc's > >> > ``name-munging'' (I have no idea what the real name of > the ``feature'' > >> > is) cleanly. (In Arc, > >> > (eqcar x y) === (eq (car x) y) > >> > but in MOX, something like > >> > (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|)) > >> > with `|...|' denoting an arrow to the object whose > canonical name is > >> > `...', could be cleanly implemented, I think.) > >> > > >> Oops. I forgot to mention that this would probably rely on > a sort of > >> arrow called a multi-arrow, which could also be used for multiple > >> values. > > > > I interpret this `|...|' operator as the reification of the > reference (as an > > arrow), which seems like boxing (Fare has used this term > several times; this > > refers to the Eval/Quote and modal S4 logic papers by > Giraud). Boxing is > > similar to quote except for quote's relation to eval; it's > similar also to > > ML's referencing operator, which is what allows for state in ML. > > > I'm not familiar with `boxing'. `|...|' is *not* an operator; it is > just to make the example easier to understand. Well I didn't mean it would be a MOX operator (which you clarified), but it still is an operator in the generic sense. (This is pedantic, though.) > However, as for quoting, this seems like a good time to introduce > activation/dectivation. Here are some examples: > > - An active application object (see below) would, when reference, > return its evaluation; an inactive application object could be used > as a thunk. (Well, I'm certainly not sure about this one.) > > - An active arrow, when referenced, returns the evaluation of the > object that it points to; an inactive arrow is self-evaluating. > > - An active multi-arrow, when referenced, returns the evaluation of > the object that the first branch points to; an inactive multi-arrow > is self-evaluating. > > After writing these examples, I am surprised to find that active > versus inactive seems to simply mean self-evaluating versus > non-self-evaluating!! Sure, and one of the primary differences between Lisp and Slate, Fare and I found, was that Lisp auto-evaluates its forms and Slate denotes objects to obtain (which sometimes require evaluating a thunk but not usually, and basically needs to be forced). However, the multi-arrow is a little confusing. If I were to relate it to some lambda-calculus style ideas, I'd say that referencing active multi-arrows would return the evaluation of the first branch object *and* a "continuation" multi-arrow. http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?continuation+passing+style explains basically what I mean by a continuation. You could also just have the 'rest' part be a similar thunk instead of a continuation, which is less confusing. Either way, though, I still don't understand what a multi-arrow as you describe it is supposed to mean. How does it fit into the MOX style of thinking? Come to think of it, what IS the MOX style of thinking? :) > > As for the 'real name' of the name-munging idea, it sounds > like an extension > > of the DWIM features that InterLisp had in the 70's for > letting the listener > > guess what a user means when an environment lookup fails. > I'm just referring > > to the fact that it was non-deterministic semantically. With your || > > operator, you're introducing the meta-level type of string > that is an > > extension (level 2) of the distinction I made earlier > between '.' (level 1) > > and string-concatenation (level 0 abstracted from strings). > > > No, the `|...|' operator is simply a notational convenience. Again, just a mis-understanding. I was describing the relationship between types as I would in a specification. But I should add that every 'notational convenience' in some language eventually has some kind of real semantics in some real context, even if you don't consider the context relevant. So I assume this means you don't care about this with respect to MOX. (i.e. it would be part of the larger TUNES system but not visible in MOX) > >> - Synopsis - > >> MOX is based on a datastructure called an arrow (in honor of Brian > >> Rice's excellent Arrow system, which it seems that no one > other than > >> he understands :)). Source is just a sequence of arrows > ``pointing'' > >> to an object in a 'verse, which can orthogonally or > non-orthogonally > >> make objects persistant, and [FIXME: is this a good idea? > - probably > >> not] the same arrow will always point to the same object, unless, > >> perhaps, a hint is provided to the contrary. A 'verse is a > collection > >> of objects. There are no symbols in MOX, though they can > be emulated. > >> MOX combines development and hypertext in a somewhat novel way. > > > > As for the notion of source you use, it'd be useful to give > an explanation > > of the reason for using sequences as your code shape; > perhaps by explaining > > what the sequencing is supposed to mean semantically, you > (we) could arrive > > at a better understanding. > > > I no longer think that sequences are necessary, and I didn't at the > time of this posting; I have now, however, decided that something like > an application object would be best. I now have an idea about source > code that may make metaprogramming and persistance easier. 'Application object'? This word connotes for me CORBA and COM and all sorts of business logic, which I suppose is unfair :). So do you mean an object representing the application of a function? This could be useful but applicative programming is not a magic bullet per se. [Snipped stuff about persistency.] > > About multi-arrows, I'm not sure what kind of reference > this would be, > > perhaps you just need a collection primitive, and this is > your intent. Am I > > off? > > > A multi-arrow is conceptually something like this: > > x y z > ^ ^ ^ > \ | / > 0 1 2 > \ | / > --- > | > > where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in > some 'verse. When the multi-arrow is active, it is considered to point > to only the object at the end of the first branch - in this case, x - > and when inactive, well, it is a complete multi-arrow, not pointing to > anything, but just there. They will probably be used to implement > multiple values. Okay, the basic idea in the diagram is simple, and I didn't mis-interpret that. But multiple values? I take it you mean that successive 'evaluations' of the multi-arrow return the values successively? If that is so, then it would be equivalent to a stream ADT. > You are off; multi-arrows are *not* collection primitives. They are > intended to be used as multiple values of sorts. Unfortunately, the multiple values idea only seems to come across as the same thing that most programmers call streams. Am I wrong? Well, overall it seems you're mostly interested in re-interpreting and clarifying what Ted Nelson's Xanadu was trying to do. Just keep working on the concepts and try to relate them to whatever existing abstractions you can. If you can manage to clarify and solidify what Fare's written about meta-text systems, you are welcome to revise the documents there. :) (I grok them well enough myself, but I am not so concerned about that aspect of TUNES personally.) Keep at it... ~ From bpt@tunes.org Fri Jan 25 14:37:01 2002 From: bpt@tunes.org (Brian P Templeton) Date: Fri Jan 25 14:37:01 2002 Subject: MOX In-Reply-To: <44EB12A3E6F7D5119AF80020486435BF017AF9EF@CVN70UEX02> ("RE01 Rice Brian T. EM2"'s message of "Mon, 21 Jan 2002 20:32:24 -0800") References: <44EB12A3E6F7D5119AF80020486435BF017AF9EF@CVN70UEX02> Message-ID: <873d0xzgnh.fsf@tunes.org> "RE01 Rice Brian T. EM2" writes: > Once more into the fray... >=20 >> > Brian P Templeton writes: >> >=20 >> >> I have begun preliminary work on a system called MOX.=20 >> (``MOX'' stands >> >> for ``MOX Obviates Xanadu'', since it was originally going to be a >> >> hypertext system; `mox' is also a Latin word for `soon', with >> >> allusions to the common phrase `RSN'.) >> >=20 >> > Interesting reference. Actually in recent times I've=20 >> considered renaming >> > Arrow to one of a few terms in ancient Greek, to honor some of the >> > philosophical ideas I think it relates to. 'logos' and=20 >> 'aletheia' are at the >> > top of the list, and there are a few others. >> >=20 >> Sorry, but I don't (yet) know Greek, though I've been planning to try >> to learn it (but don't have enough time ATM): what do `logos' and >> `aletheia' mean? >=20 [...good explanation snipped...] >=20 >> >> It is centered around a datastructure called an arrow, in honour of >> >> Brian Rice's Arrow system - I don't yet understand Arrow, but after >> >> attempting to read the Arrow papers one more time, I thought of >> >> locatives and how an ``arrow'' might be something like a locative >> >> (though I knew that that is not what an Arrow arrow is). >> >=20 >> >> An arrow acts as a pointer into a 'verse (short for ???verse). A >> >> 'verse, the allusion being to poetry and rhyme, acts as an=20 >> environment >> >> in other languages, except that instead of being a mapping between >> >> symbols and objects, it is simply a collection of objects,=20 >> internally >> >> identified by a tumbler (a word borrowed from Xanadu) -=20 >> though I may >> >> change `tumbler' to something else, since I don't really know what >> >> would be like in Xanadu other than being of the form=20 >> 0.x.y.z (I could >> > s/what would be like/what they would be like/ >> >> probably do some research on it, though). >> >=20 >> > That sounds like what I was intending (though I didn't=20 >> properly document) >> > with the Slate language system. Eventually the idea was to=20 >> use arbitrary >> > quoted objects as identifiers (annotations for path elements) to >> > obtain/denote the available objects in the system. Still, I=20 >> can't think of a >> > good term for it either, except perhaps 'name'. Remember that if you >> > consider '.' in an algebraic sense, it's an associative,=20 >> non-commutative >> > operator, probably using an (quoted?) empty string as its=20 >> identity element >> > (i.e. "''.foo" =3D "foo"); so you can describe it=20 >> programmatically. It happens >> > to have the same semantics as character- or=20 >> string-catenation into strings, >> > although at a separated level of abstraction. >> >=20 >> Tumblers are not really visible to programmers in MOX, normally - they >> are just a detail of how objects are uniquely idenfied. No programmer >> (except a MOX developer) will care what an object's tumbler is, as >> long as they can produce a valid arrow to the object. >=20 > Okay, this kind of explanation (and others below) helps give me an idea of > what MOX means in the TUNES conception of things. I'll try to explain wha= t I > understand it to be below. >=20 >> >> An `object' in MOX is simply something that has a tumbler, some slots >> >> (well, zero or more slots, probably), and hints. (The name `hints' >> >> will probably change to `annotations' later on, as it appears that >> >> Fare came up with this idea a long time before I did.) I am not quite >> >> sure how the slots will work yet. >=20 > I just re-read this and now have questions about it, just to clarify: you > mentioned above that the tumbler is invisible, but is still required for = MOX > object existence. Basically you consider it your underlying unique > identifier (ugh, I hate conversations about those) but you consider the > names or hints to not be part of the meaning of the object. On the other > hand, I may just be confusing your slot concept with your annotation > concept, which I treat fairly similarly in my Slate concepts. But then ag= ain > you seem just as unsure as I am. Can you clarify what you want for MOX? >=20 >> > Well, I may have some time now to implement the ideas I=20 >> completed for Slate >> > once I get back. It'll probably be in Lisp first instead of=20 >> in Arrow as I >> > intended, mostly due to my difficulties in trying to make=20 >> an architecture >> > within Arrow that would allow for those things (I think=20 >> these problems are >> > not insurmountable; I just need to talk these ideas out a=20 >> little to refine >> > my decisions). >> >=20 >> What Lisp will it be in: CL, Scheme, or some other Lisp? I'd like to >> test it, but most non-trivial Scheme programs are not portable between >> implementations :(. >=20 > Common Lisp... it has the most useful features, full macros, CLOS (good > enough for me), and optional and keyword arguments. >=20 Excellent... for some reason I thought I had heard that you strongly disliked CL, but I'm probably misremembering. >> >> In MOX, source code is merely a sequence of arrows, possibly, e.g. >> >> using the Lisp tradition of using lists to represent function >> >> applications. However, there are *no symbols*. It will likely be >> >> possible to attach a default label to an object, through hints, but >> >> there is no particular reason why one must use labeled=20 >> objects at all. >> >> In fact, using hints, someone could implement, say, a system where >> >> objects were identified by color (yes, that's probably a=20 >> really stupid >> >> idea, but there are most likely some interesting variations on it). >> >=20 >> > Interesting. It sounds similar to what I mentioned above,=20 >> and there's >> > certainly space in the Slate type-system to allow for the=20 >> various color >> > types, obviously the larger system needs mappings from=20 >> these color objects >> > to objectively-defined (e.g. scientific) measurements in=20 >> order to be useful. >> >=20 >> Well, no, the names or the colors have no relation to how the object >> is identified; sorry for that ambiguity. Basically, labels and colors >> are conveniences for developers. >=20 > Now I am really confused :). What exactly is the status of your identifie= rs > in MOX? May I use arbitrary-type objects or no? >=20 ``Identifiers'' are meaningless. Objects are referenced simply by providing an arrow to it; an arrow just contains the tumbler of the object. So, I guess, the real identifier of an object is the tumbler. Any hints specifying a name, color, graphic, noise, or any other convenient identifier exist just for convenience. Hrm... it seems to me that a tumbler is roughly isomorphic to a symbol in Lisp, in that it is supposed to represent a single object at all times but can change... something more permanent seems necessary, too. I had an interesting idea related to this based on thinking of a 'verse as a set of points, each point representing an object (reminiscent of the `Timeless Theory' bag in _The End of Time_...). Instead of simply having points identify object locations, objects are located by following a vector from the current location (I just began reading _The End of Time_ today, and already it's seeming to have some similarities to MOX ideas!...probably not coincidental). Therefore, if you follow an arrow -- a vector -- from a different location, it could very well end up pointing to a different object. > Before you answer, I also offer you a third option: do you mean to create > two separate MOX languages/interfaces, one for average users and a sepera= te, > more powerful one for developers? If this is so, how strongly would you be > dividing the two? As a contrast, I consider the weakest division between > base-level and meta-level access for a common language is that for Lisp > and/or Smalltalk: you simply have access to 'eval' + hooks and the > environment (in Smalltalk's case, you hack the bytecode-compiler or > meta-classes). I suppose as long as I've asked all these questions, I'll > tack on one more: do the tumblers fit in at the 'developer' (~meta) level? >=20 No. >> > Taken from your self-reply: >> >=20 >> >> > Some interesting things appear to be possible with arrows; for >> >> > example, if MOX were to adopt the Lispish convention of=20 >> making source >> >> > code simply a series of sexps, then MOX could implement Arc's >> >> > ``name-munging'' (I have no idea what the real name of=20 >> the ``feature'' >> >> > is) cleanly. (In Arc, >> >> > (eqcar x y) =3D=3D=3D (eq (car x) y) >> >> > but in MOX, something like >> >> > (|eq||car| |x| |y|) =3D=3D=3D (|eq| (|car| |x|) (|car| |y|)) >> >> > with `|...|' denoting an arrow to the object whose=20 >> canonical name is >> >> > `...', could be cleanly implemented, I think.) >> >> >=20 >> >> Oops. I forgot to mention that this would probably rely on=20 >> a sort of >> >> arrow called a multi-arrow, which could also be used for multiple >> >> values. >> >=20 >> > I interpret this `|...|' operator as the reification of the=20 >> reference (as an >> > arrow), which seems like boxing (Fare has used this term=20 >> several times; this >> > refers to the Eval/Quote and modal S4 logic papers by=20 >> Giraud). Boxing is >> > similar to quote except for quote's relation to eval; it's=20 >> similar also to >> > ML's referencing operator, which is what allows for state in ML. >> >=20 >> I'm not familiar with `boxing'. `|...|' is *not* an operator; it is >> just to make the example easier to understand. >=20 > Well I didn't mean it would be a MOX operator (which you clarified), but = it > still is an operator in the generic sense. (This is pedantic, though.) >=20 >> However, as for quoting, this seems like a good time to introduce >> activation/dectivation. Here are some examples: >>=20 >> - An active application object (see below) would, when reference, >> return its evaluation; an inactive application object could be used >> as a thunk. (Well, I'm certainly not sure about this one.) >>=20 >> - An active arrow, when referenced, returns the evaluation of the >> object that it points to; an inactive arrow is self-evaluating. >>=20 >> - An active multi-arrow, when referenced, returns the evaluation of >> the object that the first branch points to; an inactive multi-arrow >> is self-evaluating. >>=20 >> After writing these examples, I am surprised to find that active >> versus inactive seems to simply mean self-evaluating versus >> non-self-evaluating!! >=20 > Sure, and one of the primary differences between Lisp and Slate, Fare and= I > found, was that Lisp auto-evaluates its forms and Slate denotes objects to > obtain (which sometimes require evaluating a thunk but not usually, and > basically needs to be forced). >=20 > However, the multi-arrow is a little confusing. If I were to relate it to > some lambda-calculus style ideas, I'd say that referencing active > multi-arrows would return the evaluation of the first branch object *and*= a > "continuation" multi-arrow. > http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?continuation+passing+style > explains basically what I mean by a continuation. You could also just have > the 'rest' part be a similar thunk instead of a continuation, which is le= ss > confusing. >=20 > Either way, though, I still don't understand what a multi-arrow as you > describe it is supposed to mean. How does it fit into the MOX style of > thinking? Come to think of it, what IS the MOX style of thinking? :) >=20 For more information on the MOX style of thinking, please locate memory 0.340.704.205.7194. If that turns out to be a reference to another memory, then please locate *that* memory. If *that* turns out to be a reference to another memory, then please locate /that/ memory. If /that/ turns out to be a reference to another memory. then ... >> > As for the 'real name' of the name-munging idea, it sounds=20 >> like an extension >> > of the DWIM features that InterLisp had in the 70's for=20 >> letting the listener >> > guess what a user means when an environment lookup fails.=20 >> I'm just referring >> > to the fact that it was non-deterministic semantically. With your || >> > operator, you're introducing the meta-level type of string=20 >> that is an >> > extension (level 2) of the distinction I made earlier=20 >> between '.' (level 1) >> > and string-concatenation (level 0 abstracted from strings). >> >=20 >> No, the `|...|' operator is simply a notational convenience. >=20 > Again, just a mis-understanding. I was describing the relationship between > types as I would in a specification. But I should add that every 'notatio= nal > convenience' in some language eventually has some kind of real semantics = in > some real context, even if you don't consider the context relevant. So I > assume this means you don't care about this with respect to MOX. (i.e. it > would be part of the larger TUNES system but not visible in MOX) >=20 In a good editor for MOX, I imagine that source might be displayed like this: ([myfunction] [arg1] [arg2]) where [...] is colored in some way and `...' is the contents of the `name' hint of the object. IOW, even names are just notational conveniences, and do not affect the ``pure'' semantics of the system, although developers will probably think in terms of names. >> >> - Synopsis - >> >> MOX is based on a datastructure called an arrow (in honor of Brian >> >> Rice's excellent Arrow system, which it seems that no one=20 >> other than >> >> he understands :)). Source is just a sequence of arrows=20 >> ``pointing'' >> >> to an object in a 'verse, which can orthogonally or=20 >> non-orthogonally >> >> make objects persistant, and [FIXME: is this a good idea?=20 >> - probably >> >> not] the same arrow will always point to the same object, unless, >> >> perhaps, a hint is provided to the contrary. A 'verse is a=20 >> collection >> >> of objects. There are no symbols in MOX, though they can=20 >> be emulated. >> >> MOX combines development and hypertext in a somewhat novel way. >> >=20 >> > As for the notion of source you use, it'd be useful to give=20 >> an explanation >> > of the reason for using sequences as your code shape;=20 >> perhaps by explaining >> > what the sequencing is supposed to mean semantically, you=20 >> (we) could arrive >> > at a better understanding. >> >=20 >> I no longer think that sequences are necessary, and I didn't at the >> time of this posting; I have now, however, decided that something like >> an application object would be best. I now have an idea about source >> code that may make metaprogramming and persistance easier. >=20 > 'Application object'? This word connotes for me CORBA and COM and all sor= ts > of business logic, which I suppose is unfair :). So do you mean an object > representing the application of a function? This could be useful but > applicative programming is not a magic bullet per se. >=20 The application of a function or a macro to arguments. I'm considering using PyLisp's ingenious method of getting first-class macros: functions are just macros that evaluate their arguments early. > [Snipped stuff about persistency.] >=20 >> > About multi-arrows, I'm not sure what kind of reference=20 >> this would be, >> > perhaps you just need a collection primitive, and this is=20 >> your intent. Am I >> > off? >> >=20 >> A multi-arrow is conceptually something like this: >>=20 >> x y z >> ^ ^ ^ >> \ | / >> 0 1 2 >> \ | / >> --- >> | >>=20 >> where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in >> some 'verse. When the multi-arrow is active, it is considered to point >> to only the object at the end of the first branch - in this case, x - >> and when inactive, well, it is a complete multi-arrow, not pointing to >> anything, but just there. They will probably be used to implement >> multiple values. >=20 > Okay, the basic idea in the diagram is simple, and I didn't mis-interpret > that. But multiple values? I take it you mean that successive 'evaluation= s' > of the multi-arrow return the values successively? If that is so, then it > would be equivalent to a stream ADT. >=20 No. Evaluating it returns the first value; using some kind of macro could allow one to extract what it points to as a list, etc. >> You are off; multi-arrows are *not* collection primitives. They are >> intended to be used as multiple values of sorts. >=20 > Unfortunately, the multiple values idea only seems to come across as the > same thing that most programmers call streams. Am I wrong? >=20 I think so; the idea is that a function can return a multiple value (sic), and, if necessary, programmers can extract all values out of a multiple value, but otherwise only get the first one. > Well, overall it seems you're mostly interested in re-interpreting and > clarifying what Ted Nelson's Xanadu was trying to do. Not anymore. Now I'm much more interested in figuring out the semantics of arrows. Hypertext is easy and simple; arrows and 'verses are difficult. > Just keep working on the concepts and try to relate them to whatever > existing abstractions you can. The problem is that there is, for the most part, *no* existing abstraction other than a locative in ZetaLisp or a pointer in C. The only other thing that is even comparable is Lisp's continual emphasis on object identity. > If you can manage to clarify and solidify what Fare's written about > meta-text systems, you are welcome to revise the documents there. :) > (I grok them well enough myself, but I am not so concerned about > that aspect of TUNES personally.) >=20 [looks around] What has Far=E9 written about meta-text systems? Where can I get the papers? Googling for metatext a few weeks ago (Far=E9 had mentioned it) didn't find much... > Keep at it... > ~ >=20 --=20 BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From btanksley@hifn.com Fri Jan 25 14:50:02 2002 From: btanksley@hifn.com (Billy Tanksley) Date: Fri Jan 25 14:50:02 2002 Subject: MOX Message-ID: <51C7002B020CD411824E009027C469F78224BF@cldxch01.hifn.com> From: Brian P Templeton [mailto:bpt@tunes.org] >Hrm... it seems to me that a tumbler is roughly isomorphic to a symbol >in Lisp, in that it is supposed to represent a single object at all >times but can change... something more permanent seems necessary, too. No. A tumbler in Xanadu is permanent and refers only to the one object, EVER. -Billy From bpt@tunes.org Fri Jan 25 15:07:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Fri Jan 25 15:07:02 2002 Subject: MOX In-Reply-To: <51C7002B020CD411824E009027C469F78224BF@cldxch01.hifn.com> (Billy Tanksley's message of "Fri, 25 Jan 2002 14:48:21 -0800") References: <51C7002B020CD411824E009027C469F78224BF@cldxch01.hifn.com> Message-ID: <87g04ugg92.fsf@tunes.org> Billy Tanksley writes: > From: Brian P Templeton [mailto:bpt@tunes.org] >>Hrm... it seems to me that a tumbler is roughly isomorphic to a symbol >>in Lisp, in that it is supposed to represent a single object at all >>times but can change... something more permanent seems necessary, too. > > No. A tumbler in Xanadu is permanent and refers only to the one object, > EVER. > Right, but this is in MOX. I'll change the term when I think of another one. A lot of stuff is changing quickly now, but could just as easily change back, I hope. > -Billy > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From kyle@arcavia.com Sat Jan 26 06:02:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Sat Jan 26 06:02:02 2002 Subject: MOX References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> Message-ID: <3C52B640.DFC18924@arcavia.com> Brian P Templeton wrote: > A multi-arrow is conceptually something like this: > > x y z > ^ ^ ^ > \ | / > 0 1 2 > \ | / > --- > | > > where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in > some 'verse. When the multi-arrow is active, it is considered to point > to only the object at the end of the first branch - in this case, x - > and when inactive, well, it is a complete multi-arrow, not pointing to > anything, but just there. They will probably be used to implement > multiple values. With respect to the multi-arrow, as shown, is it important that the multi-arrow have three parameters (0, 1, 2). Does the multi-arrow have an identifier beyond these ?three? parameters? Thanks From sayke@gmx.net Sat Jan 26 16:09:02 2002 From: sayke@gmx.net (sayke) Date: Sat Jan 26 16:09:02 2002 Subject: MOX In-Reply-To: <3C52B640.DFC18924@arcavia.com> References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> Message-ID: <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> At 08:59 AM 1/26/2002 -0500, someone with the password to kyle@arcavia.com wrote: >Brian P Templeton wrote: > > > A multi-arrow is conceptually something like this: > > > > x y z > > ^ ^ ^ > > \ | / > > 0 1 2 > > \ | / > > --- > > | > > > > where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in > > some 'verse. When the multi-arrow is active, it is considered to point > > to only the object at the end of the first branch - in this case, x - > > and when inactive, well, it is a complete multi-arrow, not pointing to > > anything, but just there. They will probably be used to implement > > multiple values. > >With respect to the multi-arrow, as shown, is it important that the >multi-arrow have three parameters (0, 1, 2). Does the multi-arrow have >an identifier beyond these ?three? parameters? and what, pray tell, is the difference between this and a standard tree/or list of lists? sayke, v2.3.2 From tapselj0@cs.man.ac.uk Sat Jan 26 22:42:02 2002 From: tapselj0@cs.man.ac.uk (John Tapsell) Date: Sat Jan 26 22:42:02 2002 Subject: Similiar project Message-ID: Hi there, I've been working on a similar project, but with a different angle - namely trying to get the current gnu tools (binutils, fileutils etc etc) to work together much more. I've been trying various different ways, from XML to Lisp to COM, and discussed many ideas over irc, when someone pointed to your site. I was wondering how things were going with you lot at the moment, whether you are still active, and whether you can think of a way I can rewrite the fileutils/netutils in a way that would benefit you most. Thanks for your time, JohnFlux From kyle@arcavia.com Mon Jan 28 18:48:02 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Mon Jan 28 18:48:02 2002 Subject: MOX References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> Message-ID: <3C560CC5.B06425F@arcavia.com> sayke wrote: > > At 08:59 AM 1/26/2002 -0500, someone with the password to kyle@arcavia.com > wrote: > >Brian P Templeton wrote: > > > > > A multi-arrow is conceptually something like this: > > > > > > x y z > > > ^ ^ ^ > > > \ | / > > > 0 1 2 > > > \ | / > > > --- > > > | > > > > > > where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in > > > some 'verse. When the multi-arrow is active, it is considered to point > > > to only the object at the end of the first branch - in this case, x - > > > and when inactive, well, it is a complete multi-arrow, not pointing to > > > anything, but just there. They will probably be used to implement > > > multiple values. > > > >With respect to the multi-arrow, as shown, is it important that the > >multi-arrow have three parameters (0, 1, 2). Does the multi-arrow have > >an identifier beyond these ?three? parameters? > > and what, pray tell, is the difference between this and a standard > tree/or list of lists? I am certain that the described structure can be used to implement trees/lists and trees/lists can be used to implement the above structure, but what are you getting at? :/ >From a conceptual point-of-view I believe that the ordered triple datastrucure (as above) is the minimum structure needed to describe all describable structures. This is my own conclusion, and I am certainly willing to explore this more. (Note: I have a dangerously unfinished page exploring the idea of references, and the conclusion that ordered triples are necessary at... http://www.arcavia.com/rd/document/References.htm). A convincing argument that triples are important: both Brian's arrow (ID, head, tail) and in Lisp cons cells (ID, car, cdr) are triples. The "ID" encapsulates the ability to reference (or point to) the arrow or cons cell respectively. From Francois-Rene Rideau Tue Jan 29 04:44:02 2002 From: Francois-Rene Rideau (Francois-Rene Rideau) Date: Tue Jan 29 04:44:02 2002 Subject: MOX In-Reply-To: <3C560CC5.B06425F@arcavia.com> References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> <3C560CC5.B06425F@arcavia.com> Message-ID: <20020129124315.GA2260@hell.mine.nu> > A convincing argument that triples are important: both Brian's arrow > (ID, head, tail) and in Lisp cons cells (ID, car, cdr) are triples. The > "ID" encapsulates the ability to reference (or point to) the arrow or > cons cell respectively. However, CONS-as-triples, as opposed to triple-knowledge-bases such as used expert systems like SNARK and its successors, verify an additional invariant that an ID can be used but once in head position. All in all, important questions are "what information do you want to encode?" (the inductive types approach), and dually "what are the operations to be performed on this information?" (coinductive types). Continuation-based techniques allow to go from one to the other in higher-order languages. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] First Person: "Why are you snapping your fingers?" Second Person: "To keep the tigers away." First Person: "But, there are no tigers in this area!" Second Person: "You see: it's working." From kyle@arcavia.com Tue Jan 29 08:35:01 2002 From: kyle@arcavia.com (Kyle Lahnakoski) Date: Tue Jan 29 08:35:01 2002 Subject: MOX References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> <3C560CC5.B06425F@arcavia.com> <20020129124315.GA2260@hell.mine.nu> Message-ID: <3C56CE8B.F984DCC2@arcavia.com> Francois-Rene Rideau wrote: > > > A convincing argument that triples are important: both Brian's arrow > > (ID, head, tail) and in Lisp cons cells (ID, car, cdr) are triples. The > > "ID" encapsulates the ability to reference (or point to) the arrow or > > cons cell respectively. > However, CONS-as-triples, as opposed to triple-knowledge-bases such as > used expert systems like SNARK and its successors, verify an additional > invariant that an ID can be used but once in head position. Are you saying that a triple-knowledge-base ("base" as in "basis" as opposed to "database") is a more general structure and therefore more expressive? I would agree with that. But I would prefer to find a structure with the most restrictions on its coordinates. > All in all, important questions are "what information do you want to encode?" > (the inductive types approach), and dually "what are the operations to be > performed on this information?" (coinductive types). Continuation-based > techniques allow to go from one to the other in higher-order languages. I would like to hear more about this role of continuations. I think I know what you mean here; the two questions are important for determining how to encode information. Even an arrow-like system has had to answer these questions, but those questions were not explored consciously (at least not in my mind). I guess, then, I should search for the (desirable) properties that demand an arrow-like system of information representation. Here is my attempt: 1) Information must be encoded without the use of symbol sequences. Things such as strings, or blocks of bits are not allowed. Being a person that denies any form of series or sequences, when possible, enjoys the existence of this requirement. 2) ?is that all? The triple I suggest above can be seen as a reduction of sequences to their basic building block (cons cell). But even this triple need not be an ordered triple as long as we name the parameters. For example, a particular triple can be stated as {ID=A, head=B, tail=C}. From bpt@tunes.org Wed Jan 30 18:15:02 2002 From: bpt@tunes.org (Brian P Templeton) Date: Wed Jan 30 18:15:02 2002 Subject: MOX In-Reply-To: <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> (sayke's message of "Sat, 26 Jan 2002 16:07:55 -0800") References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> <5.1.0.14.2.20020126160653.01f5fd68@pop.gmx.net> Message-ID: <87aduz897m.fsf@tunes.org> Hi, sayke, sayke writes: > At 08:59 AM 1/26/2002 -0500, someone with the password to > kyle@arcavia.com wrote: >>Brian P Templeton wrote: >> >> > A multi-arrow is conceptually something like this: >> > >> > x y z >> > ^ ^ ^ >> > \ | / >> > 0 1 2 >> > \ | / >> > --- >> > | >> > >> > where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in >> > some 'verse. When the multi-arrow is active, it is considered to point >> > to only the object at the end of the first branch - in this case, x - >> > and when inactive, well, it is a complete multi-arrow, not pointing to >> > anything, but just there. They will probably be used to implement >> > multiple values. >> >>With respect to the multi-arrow, as shown, is it important that the >>multi-arrow have three parameters (0, 1, 2). Does the multi-arrow have >>an identifier beyond these ?three? parameters? > > and what, pray tell, is the difference between this and a > standard tree/or list of lists? > The difference is that, when activated (evaluated), it only returns the object pointed to by the first branch. In order to get the values of other branches, you have to pass around inactive (somewhat like `quoted') multi-arrows. > sayke, v2.3.2 > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards From bpt@tunes.org Wed Jan 30 18:15:07 2002 From: bpt@tunes.org (Brian P Templeton) Date: Wed Jan 30 18:15:07 2002 Subject: MOX In-Reply-To: <3C52B640.DFC18924@arcavia.com> (Kyle Lahnakoski's message of "Sat, 26 Jan 2002 08:59:28 -0500") References: <44EB12A3E6F7D5119AF80020486435BF017AF9EB@CVN70UEX02> <873d0zjwt0.fsf@tunes.org> <3C52B640.DFC18924@arcavia.com> Message-ID: <87665n896c.fsf@tunes.org> Kyle Lahnakoski writes: > Brian P Templeton wrote: > >> A multi-arrow is conceptually something like this: >> >> x y z >> ^ ^ ^ >> \ | / >> 0 1 2 >> \ | / >> --- >> | >> >> where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in >> some 'verse. When the multi-arrow is active, it is considered to point >> to only the object at the end of the first branch - in this case, x - >> and when inactive, well, it is a complete multi-arrow, not pointing to >> anything, but just there. They will probably be used to implement >> multiple values. > > With respect to the multi-arrow, as shown, is it important that the > multi-arrow have three parameters (0, 1, 2). Does the multi-arrow have > an identifier beyond these ?three? parameters? > No! They're intended to be used for much the same purpose as multiple values in Common Lisp. (That's why they're called multi-arrows :).) > Thanks > -- BPT /"\ ASCII Ribbon Campaign backronym for Linux: \ / No HTML or RTF in mail Linux Is Not Unix X No MS-Word in mail Meme plague ;) ---------> / \ Respect Open Standards