Anybody willing to decipher Forth program
in [Lisp]
|
From: joswig on 14 Mar 2010 06:27 On 14 Mrz., 02:57, Eli Barzilay <e...(a)barzilay.org> wrote: > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > On 14 Mrz., 00:18, Eli Barzilay <e...(a)barzilay.org> wrote: > >> "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > >> > On 13 Mrz., 23:27, Eli Barzilay <e...(a)barzilay.org> wrote: > >> >> As other[s] said, PLT Scheme is far from being a small language -- > >> >> it's overall much bigger than CL (and probably on the same scale of > >> >> any "real" language, including actual CL implementations). But the > >> >> organization of code *and* language into separate modules tend to > >> >> make it easier to learn. > > >> > Than what? > > >> Than a monolithic language like CL. > > >> > Common Lisp code is organized around separate packages and systems. > > >> Right, and the CL package system is much weaker than the PLT module > >> system in terms of expressiveness. > > > There are lots of things in CL that are 'weaker' than what some > > Scheme offers - but more practical. > > This is inflammatory nonsense. I'm talking about a more expressive > system -- ones that makes it possible to write better code. In > practice. You are talking about it, but you haven't brought any evidence for that. In practice. > > >> (That also applies to a number of > >> Scheme module systems that are very weak, some being close to > >> something like CL packages.) As a purely anecdotal example, I have > >> not seen any practical example of a CL program that defines a new > >> language for some purpose, > > > This is so wrong, it really hurts. > > Feel free to produce concrete pointers. No, you were claiming that PLT Scheme is easier to learn due to language and code in modules. You have failed to bring any evidence for that, instead you jump to the next topic and let me bring the pointers. > > >> whereas this is quite common in PLT, to the > >> point of defining a new language that is used in a few files and > > > That's already a problem. You learn to think in files. > > That's more inflammatory nonsense. I write code in files, so that's > what I used. In PLT, I usually put one module in one file, just like > in CL I usually put one package in one file. It's possible in both > systems to have more than one module/package in one file, and it's > possible in both to spread a module/package across more than one file > (and due to the package system being less expressive, the latter is > more common in CL). I fail to see the connection. > (Or maybe you're trying to bait me into some talk > about the mythical repl as the single place where you write your code, > something that is so unpractical it's not even funny.) More claims... The REPL is just a TOOL for incremental and interactive software development. There are others. That files may have packages etc. is just an organizing principle. I'm not thinking about organizing packages/modules over files. That's again just a tool to help me. I'm possibly more concerned how the thing is organized when it RUNS and how I can interact with it to evolve it. How many packages per file or how many files per package I use does not interest me that much. (...) > > > There are like a million examples where CL programs define new > > languages for some purpose. > > Note that I'm not talking about some DSL *extension* of CL that is > achieved via a macro. I'm talking about having different languages > with different semantics for the same names and forms. Me too. But I fail to see how different semantics for the same names and forms make things easier to learn. > > > Every implementation already does. CL-USER, the default user package > > is already different language in each implementation. Each > > implementation uses different packages for CL-USER, but includes the > > base CL package. > > And I'm also not talking about having a few more bindings as the way > to get a "new" language. That would be as vacuously interesting as > saying that each an every definition produce a new language than the > one that existed before that definition. I did not talk about that either. > > Just looking at my old Lisp Machine I get the following > > USER packages: > > > Command: (remove-if-not (lambda (x) (search "USER" x)) (mapcar > > 'package-name (list-all-packages))) > > ("ZETALISP-USER" "USER" "FUTURE-COMMON-LISP-USER" "CLTL-USER" "CLIM- > > USER" "PSTATICE-USER" "HTTP-USER") > > > There is ZetaLisp, three CL dialects, a dialect for programming UIs, > > a dialect for the database, and another one for the web server. I > > could load in more stuff which provides some kind of Prolog, a rule > > language, etc. > > The problem with trying to use these things as "different languages" > is that either they're really just different extensions of the same > basic language (for example, `if' and `defun' would be the same), > which is not what I'm talking about. ZetaLisp, in ZETALISP-USER: (if predicate-form then-form else-form*) CL in some CL package: (if predicate-form then-form else-form) A very typical thing is to create a new package, import stuff from some Common Lisp package and shadow some stuff. Like DEFUN. Then provide a new/changed DEFUN in that package. DEFMETHOD is a really common example. Various extensions to Common Lisp provide their own extended/different defmethod. In my example above one dialect may use CLOS and CLOS:DEFMETHOD and another one may use FLAVORS:DEFMETHOD and define flavors with that. One is then a Lisp with Flavors integrated and another one is with CLOS integrated. Others may use an extended version of CLOS, where new dispatch capabilities need an extended version of DEFMETHOD. Often one sees also the strategy that a portable software defines their own language and implements it on the various implementation by either reusing/modifying existing stuff or providing it's own version to implement it. In my example above CLIM-USER is such a package. It is thought for developing user interfaces and it comes with its streams, processes, etc - thus you have a CL variant, where the I/O streams may work differently from the rest of the system. > Alternatively, they would > provide you with different languages by providing different names -- > but that leaves you with no easy way of combinig them in a single > application without littering your code with explicit package > qualifiers. No, I can build packages and important names, shadow names, etc. > > >> But this subjective and getting close to drowning this thread in > >> flames -- I'm sure you're very happy with CL packages. > > > Definitely more happy than with anything that R6RS provides. > > I didn't say anything about R6RS in the current context. > > And now that this went all the way into subjective redundantism, I'll > plonk this thread. You may want to think about how much you just contributed. Not much, I'd say. You make a few claims ('easier to learn', 'more expressive', ...') and walk away when you have to provide backup for your claims.
From: Nicolas Neuss on 14 Mar 2010 06:31 Eli Barzilay <eli(a)barzilay.org> writes: > (FWIW, I tried to have a quick and naive translation of the CL code to > PLT, and on a 64 bit machine with that input file it takes about 19 > seconds. But I'm not posting any code since I know nothing about it > or what it should produces... (What I got was some random text which > looked like the output on a different post but also had a bunch of > junk characters.)) That junk output was probably OK (the text was too short for finding the correct unique solution by this decryption technique). I also checked only that my optimized version produced the same output as Helmut's original CL version (and I was quite confident that Helmut did check the output against the original Forth program). 19 seconds sounds quite reasonable. I would be really interested in how that code and the procedure to compile and call it looks like. >> [...] By switching to Common Lisp though, I might be jumping out of >> the frying pan and into the fire! :-) PLT Scheme seems to be a >> purposefully thin language though, so that might be more Forth-like. > > As other said, PLT Scheme is far from being a small language -- it's > overall much bigger than CL (and probably on the same scale of any > "real" language, including actual CL implementations). But the > organization of code *and* language into separate modules tend to make > it easier to learn. Nicolas
From: Eli Barzilay on 14 Mar 2010 06:54 Tamas K Papp <tkpapp(a)gmail.com> writes: > On Sat, 13 Mar 2010 18:18:01 -0500, Eli Barzilay wrote: > >> practical example of a CL program that defines a new language for >> some purpose, whereas this is quite common in PLT, to the point of >> defining a new language that is used in a few files and nowhere >> else. > > I would be interested in learning more about this. Can you provide > some links to examples? http://tmp.barzilay.org/tutorial.txt This is the DEFUN tutorial that we did last summer. It's showing things from very basic to medium level (and will be extended in the future to a full language writing guide; the most obvious thing that is missing is how to make a language with its own non-sexpr-ish parser). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Eli Barzilay on 14 Mar 2010 06:58 Nicolas Neuss <lastname(a)kit.edu> writes: > Eli Barzilay <eli(a)barzilay.org> writes: > >> (FWIW, I tried to have a quick and naive translation of the CL code >> to PLT, and on a 64 bit machine with that input file it takes about >> 19 seconds. But I'm not posting any code since I know nothing >> about it or what it should produces... (What I got was some random >> text which looked like the output on a different post but also had >> a bunch of junk characters.)) > > That junk output was probably OK (the text was too short for finding > the correct unique solution by this decryption technique). I also > checked only that my optimized version produced the same output as > Helmut's original CL version (and I was quite confident that Helmut > did check the output against the original Forth program). > > 19 seconds sounds quite reasonable. I would be really interested in > how that code and the procedure to compile and call it looks like. I've put the code at http://tmp.barzilay.org/x (but again, this was just a quick translation). You don't need to compile, just save that somewhere and run `mzscheme the-file'. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Rainer Joswig on 14 Mar 2010 07:47
In article <978067d6-b3ec-4a37-afde-3cd87280c3d0(a)q15g2000yqj.googlegroups.com>, "joswig(a)corporate-world.lisp.de" <joswig(a)lisp.de> wrote: > > >> �(That also applies to a number of > > >> Scheme module systems that are very weak, some being close to > > >> something like CL packages.) �As a purely anecdotal example, I have > > >> not seen any practical example of a CL program that defines a new > > >> language for some purpose, > > > > > This is so wrong, it really hurts. > > > > Feel free to produce concrete pointers. Some CL applications use Scheme for scripting. CL-USER 278 > (lisp-implementation-type) "LispWorks" CL-USER 279 > (in-package "SCHEME") #<The SCHEME package, 750/1024 internal, 0/16 external> SCHEME 280 > (define (foo x) (x 1 2)) FOO defined. SCHEME 281 > (foo list) (1 2) -- http://lispm.dyndns.org/ |