Anybody willing to decipher Forth program
in [Lisp]
|
From: Pascal Costanza on 26 Mar 2010 04:30 On 25/03/2010 22:25, Kazimir Majorinc wrote: > On 25.3.2010 19:42, Pascal Costanza wrote: > >> (let ((x 1)) >> (macrolet ((foo () 'x)) >> (let ((x 47)) >> (incf (foo))) >> (+ x x))) >> >> How do I make sure that it has the same result as the following, but >> without renaming any of the x bindings? >> >> (let ((x 1)) >> (macrolet ((foo () 'x)) >> (let ((y 47)) >> (incf (foo))) >> (+ x x))) > > I don't know whether one can be sure, but it looks to me > that it could work. That's why I ask. > > ; (let ((x 1)) > ; (macrolet-with-gensyms ((foo () 'x)) '(x) > ; (let ((x 47)) > ; (incf (foo))) > ; (+ x x))) > ; > ; should expand to (I added progn) > > (let ((x 1)) > (let ((G3197 x)) > (macrolet((foo () 'G3197)) > (first (list (progn (let ((x 47)) > (incf (foo))) > (+ x x)) ; outer x used > (setf x G3197)))))) ;==>2 > > ; (let ((x 1)) > ; (macrolet-with-gensyms ((foo () 'x)) '(x) > ; (let ((y 47)) > ; (incf (foo))) > ; (+ x x))) > ; > ; should expand to > > (let ((x 1)) > (let ((G3197 x)) > (macrolet((foo () 'G3197)) > (first (list (progn (let ((y 47)) > (incf (foo))) > (+ x x)) ; outer x used > (setf x G3197)))))) ;==>2 The last expression in my original form is (+ x x), so the result should be 4, not 2. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Kazimir Majorinc on 26 Mar 2010 07:53 Ah, OK, there is no easy way out.
From: Pascal Costanza on 26 Mar 2010 09:56 On 23/03/2010 15:41, Eli Barzilay wrote: > Pascal Costanza<pc(a)p-cos.net> writes: > >> A static type checker can only make safe assumptions about the code >> it sees, not about code that may be defined and/or loaded later. So >> you could place the restriction that no two methods may have the >> same qualifiers and specializers in the code that the static type >> checker sees. That should be enough, as far as I can tell. > > There's no need for that -- since `defmethod' is basically an > assignment, it could work in the same way that this works in ocaml: > > let g_fun = ref None ;; > let set_g_fun f = g_fun := Some f ;; > let g x = match !g_fun with Some f -> f x > | None -> raise (Failure "uninitialized") ;; > set_g_fun (fun x -> x+1) ;; > g 4 ;; > set_g_fun (fun x -> x-1) ;; > g 4 ;; > > So one bit that is required is to either pre-determine a single result > type for a generic function, or somehow include the type as another > specializer (which is probably close to what Haskell can do). > > >> What could happen after startup time > > If there's anything that can happen after type-checking, then this is > no longer a "strongly typed" language (which is a fuzzy term, but I'm > talking about a type checker that guarantees no type errors at > runtime). You don't consider languages like Java, where you can load new classes after a program was started, to be strongly typed? >> is this: (a) A new method could be added for a new class that the >> static type checker did not see; (b) a new method could be added for >> a class that the static type checker did see; (c) an existing method >> could be replaced by a new one. >> >> (a) should have no impact because the code the static type checker >> analyzed doesn't mention the new class anyway. >> (b) should have no impact because it just rejected programs that are now >> valid (but static type checkers are typically conservative anyway). >> (c) should have no impact because it doesn't change the set of methods >> that was know to the static type checker. > > I don't follow your (b), (c) is not a problem since any attempts to > set a new value mean that the type checker verified that the new > method has the same type. But (a) is a problem in that it raises the > question of how can a new type be added dynamically to code that is > checked statically. Another problem with a type system for CLOS would > be a type for `standard-class' and the usual fun that a type of all > types implies. (I'm not saying that all of this is impossible, just > that it'll need some serious work.) I also didn't want to imply that this is all easy. I just don't see why it should not be possible. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza on 26 Mar 2010 09:56 On 23/03/2010 21:16, joswig(a)corporate-world.lisp.de wrote: > On 23 Mrz., 21:06, "jos...(a)corporate-world.lisp.de"<jos...(a)lisp.de> > wrote: >> On 23 Mrz., 20:08, Hugh Aguilar<hughaguila...(a)yahoo.com> wrote: >> >>> On Mar 23, 12:07 pm, Eli Barzilay<e...(a)barzilay.org> wrote: >> >>>> ... if your >>>> ultimate goal *is* clos, then it's probably better to go with CL right >>>> from the start. >> >>> My ultimate goal is still CLOS. I've had AMOP on my bookshelf for >>> quite a few years. Every time I walk past I think: "I should read that >>> book before I die." I feel the same way about the Spanish version of >>> "Don Quixote," but AMOP is somewhat more of a realistic goal. :-) >> >> If you want to LEARN CLOS or Common Lisp, >> I don't think AMOP is a good book for that. >> >> AMOP is really great, but it is not for beginners and not even >> for average Lisp programmers. It is an advanced text and >> the topic is not CLOS, but CLOS in CLOS. I would read it > > Just to mention it, because most people won't know it > (especially since it is written in German), for those > who understand German and are interested in AMOP topics, > there is the excellent book by Harry Bretthauer: > > Entwurf und Implementierung effizienter Objektsysteme > f�r funktionale und imperative Programmiersprachen am > Beispiel von Lisp > > Available as PDF: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.7416&rep=rep1&type=pdf Nett! :) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal J. Bourguignon on 26 Mar 2010 18:09
Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > On Mar 22, 2:43 pm, Nicolas Neuss <lastn...(a)kit.edu> wrote: >> ... there is research to be done >> for finding e.g. a "continuous" passage between dynamic and static >> typing. And as I understand it, one of the strengths of PLT is its >> academic background with a lot of funding because of such basic >> research. > > One reason why I have put off learning CL or (especially) Scheme is > because of the academic background. I don't have any college > education. If a job were available, *every* job applicant except > myself would have college degree, possibly even from MIT. No matter > how much I learn about Lisp/Scheme, I would never be qualified for any > job due to my lack of education. > > I have worked as a programmer. Typically I write assembly language. > Programmers with education will refuse to program in assembly language > because they hate it, and (more importantly) because it is a dead-end > career wise. The assembly language work gets dumped on bottom-feeders > such as myself. There is not much assembly language work available, > and less now than previously, thanks to Moore's Law. This is why I > mostly just work as a cab driver, and only occasionally find work as a > programmer. Programming is mostly just a hobby for me; I write > programs for my own use (the poker analysis program) or give them away > for free (the slide-rule gcode program). I won't comment on your professionnal choices, you're the best placed to make the best choices. But since you program mainly as a hobby, you could choose a pleasurable programming language and environment. I mean Lisp! Sure, assembler is fun too, but to write bigger than trivial programs, it's more fun to use lisp than assembler. -- __Pascal Bourguignon__ |