Anybody willing to decipher Forth program
in [Lisp]
|
From: Hugh Aguilar on 23 Mar 2010 19:02 On Mar 23, 2:06 pm, "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> wrote: > AMOP is really great, but it is not for beginners and not even > for average Lisp programmers. I'm not an average Forth programmer, so I wouldn't expect to be an average Lisp programmer either. :-) > To learn CLOS and GUI programming any of Allegro CL and LispWorks > is fine. Both have most of their libraries CLOS-based. > > A bit more complicated, but interesting, would be something > like McCLIM + SBCL. But that requires quite a bit > understanding of CLOS. I'll take a look at these in regard to GUI --- thanks for the tip.
From: Eli Barzilay on 24 Mar 2010 23:00 Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > 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." [...] Here's an alternative suggestion which might be more suitable if you're comfortable with code: start with tiny-clos (it's easy to find), and just learn how it works. IMO, AMOP does a very good job in making you appreciate the MOP, but following an implementation is doing that even more effectively. Note that it is in Scheme, but doesn't use anything sophisticated, and would probably be effective for just reading through, even if you don't try to actually run it. Also note that it's much simpler than CLOS, but has all the clever ideas in -- so if you follow that, then understanding CLOS would be significantly easier. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Pascal Costanza on 25 Mar 2010 06:44 On 25/03/2010 04:00, Eli Barzilay wrote: > Hugh Aguilar<hughaguilar96(a)yahoo.com> writes: > >> 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." [...] > > Here's an alternative suggestion which might be more suitable if > you're comfortable with code: start with tiny-clos (it's easy to > find), and just learn how it works. IMO, AMOP does a very good job in > making you appreciate the MOP, but following an implementation is > doing that even more effectively. > > Note that it is in Scheme, but doesn't use anything sophisticated, and > would probably be effective for just reading through, even if you > don't try to actually run it. Also note that it's much simpler than > CLOS, but has all the clever ideas in -- so if you follow that, then > understanding CLOS would be significantly easier. There are actually two versions of tiny clos, one in Scheme and one in Common Lisp. You can find the Scheme version at ftp://ftp.parc.xerox.com/pub/mops/tiny/ and the Common Lisp version at ftp://ftp.parc.xerox.com/pub/mops/oopsla93-tutorial 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 25 Mar 2010 06:50 On 25/03/2010 07:51, Kazimir Majorinc wrote: > On 14.3.2010 20:11, Eli Barzilay wrote: > > Excellent post, Eli. However, I'm interested > in this part: > >> One point that can help getting some enlightenment is that hygiene is >> a crucial aspect of these kind of language games -- and I'm talking >> about both sides of it: both the part that you solve in CL with a >> gensym, and the part that cannot be solved by a macro (where you want >> to avoid names in the result of macros from being captured by names >> that happen to be bound in the call site). The latter is usually >> dismissed by CLers as not being too important, yet it is IME even more >> important than the first one when you're dealing with creating a new >> language. > > It is not obvious to me that this second part > of hygiene, i.e. macros that use the values > of the symbols from macro definition environment, > not environment of use, is impossible in CL > macro systems without some package or namespaces. > > Why do you claim that, Eli? If answer is not simple, > do you have any reference with more detailed > discussion? > > Do CL-ers agree with Eli? What Eli says is correct, but only relevant when you use local macro definitions. A canonical example is this: (let ((x 1)) (macrolet ((foo () 'x)) (let ((x 2)) (foo)))) You have two variable bindings for x, and the expansion of foo will refer to the inner one, so this form will yield 2. If you want to keep the name x for both variable bindings, there is no way in Common Lisp to reliably rewrite the macro foo such that it unambiguously refers to the outer x, without adding some serious heavy machinery on top of Common Lisp. Of course, you could decide to rename one of the two variable bindings. For global macro definitions, packages are sufficient to protect you from such problems. (You still need to be careful, of course.) 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 25 Mar 2010 10:11
On 25.3.2010 11:50, Pascal Costanza wrote: > Of course, you could decide to rename one of the two variable bindings. OK. But isn't it possible to change macrolet definition: (let((x 1)) (macrolet-with-gensyms ((foo () 'x)) '(x); 'variables to be replaced with gensyms (let ((x 2)) (foo)))) == expands to ==> (let((x 1)) (let ((G3197 x)) (macrolet((foo () 'G3197)) (first (list (let ((x 2)) (foo)))) (setf x G3197)))) ;==>1 With real gensyms, these are manual equivalents. Both outer and inner bindings are here, which part of the problem is left? |