Anybody willing to decipher Forth program
in [Lisp]
|
From: Hugh Aguilar on 22 Mar 2010 15:35 On Mar 20, 8:06 am, Nicolas Neuss <lastn...(a)kit.edu> wrote: > Thanks for this report. It looks as if both PLT and CL have still some > way to go until they reach my "Limit Lisp" above. Which one is nearer > at the moment depends very much on which metric is used. For me, CL > feels nearest, especially because I like CLOS and I do not want to make > much compromises with respect to performant code (I did already when > choosing Lisp:-). But I can imagine that for others (putting, say, the > emphasis more on hygienic macros or call/cc) PLT is the right choice. Largely the reason why I am interested in learning Lisp is because I tried learning Factor but found that some of the concepts and terminology were unknown to me. Most of my confusion has to do with dynamic OOP. The terminology seems to be borrowed from CLOS, so I hoped to learn it in the context of Lisp and then go back to Factor when I am better prepared. Does it matter much whether I tackle PLT Scheme or CL in regard to learning the concepts of dynamic OOP? I am now starting in on PLT Scheme because of the practical reason that it provides better support for writing GUI software. I've never written a GUI program in my life, so this is something else that I need to learn about. Factor provides support for GUI software, but the documentation is a reference and assumes that the programmer already knows the concepts. Terms like "widget" are unknown to me. I don't even like *using* GUI software, but GUI seems to be what the world wants, so I suppose I should bite the bullet and learn how to write it. I'm already familiar with static OOP from having worked as a C++ programmer. I've also seen implementations of static OOP in Forth (SwiftForth and FICL). I know what the virtual method table (VMT) is. I've even heard of static OOP done without a VMT (Oberon). I think I could implement a static OOP system myself, and I likely will later on when I get that far in my PIC24 Forth system. What I don't get is all the computer-sciency terminology associated with dynamic OOP. For example, what is the difference between a "tuple" and an old-fashioned record (or "struct" in the C world)? Another funky word is "curry." This seems to refer to nothing more than providing default values for input parameters, which has always been available in C++. Is there more to it than that? Why does this old and not-very-exciting concept warrant a fancy new word? These are the kinds of questions that I hope to get answered in my study of Lisp or Scheme or whatever. Also, btw, why does so much of your terminology come from the food world? Did the concept of curried input values get invented over lunch at an Indian restaurant? What does "fry" mean in the context of dynamic OOP? If I went to a Lisp convention, would I discover that everybody there is overweight? Your minds seem to be pretty focused on food! :-)
From: Tim Bradshaw on 22 Mar 2010 16:16 On 2010-03-22 19:35:08 +0000, Hugh Aguilar said: > Also, btw, why does so much of your terminology come from the food > world? Did the concept of curried input values get invented over lunch > at an Indian restaurant? What does "fry" mean in the context of > dynamic OOP? If I went to a Lisp convention, would I discover that > everybody there is overweight? Your minds seem to be pretty focused on > food! :-) Currying comes from Haskall Curry who (re-)invented the technique so is not food related. In the Lisp (as opposed to Scheme) world there was a historoclly-important object system some of whose terminology ("vanilla", "mixin") came from ice-cream flavours, which was called called "flavors" and then later "new flavors".
From: Nicolas Neuss on 22 Mar 2010 16:43 Eli Barzilay <eli(a)barzilay.org> writes: > Nicolas Neuss <lastname(a)kit.edu> writes: > >> Yes, but IMO all these are really desirable features, and for every >> single feature there are already reference implementations. So I >> think we can be quite sure that they also will be contained in the >> feature list of "Limit Lisp". > > Some of your points are far off because of deeper problems. For > example, yes there are theorem provers that can prove code correct, > but they're usually not things that the average programmer can deal > with and they're not useful for average project sizes and they still > require a proper language specification. Another example is your > mention of "(optional)" for types -- sound type systems are *very* > different from those that allow optional type declarations (mostly for > optimizations), and in addition it's unclear whether this can be dealt > with when you have something as dynamic as CLOS. Given such problems, > the meaning of your "Limit Lisp" is questionable. You are probably right - it is not as simple as I have put it above. OTOH, this is also a boon - it means that 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. Concerning the dynamicity of CLOS, I have sketched some time ago that I would be quite satisfied with a solution that would warn at compilation time if the class hierarchy would not fit its use (but otherwise let it pass, because the hierarchy might be changed at runtime). Nicolas
From: Nicolas Neuss on 22 Mar 2010 16:53 Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > On Mar 20, 8:06 am, Nicolas Neuss <lastn...(a)kit.edu> wrote: >> Thanks for this report. It looks as if both PLT and CL have still some >> way to go until they reach my "Limit Lisp" above. Which one is nearer >> at the moment depends very much on which metric is used. For me, CL >> feels nearest, especially because I like CLOS and I do not want to make >> much compromises with respect to performant code (I did already when >> choosing Lisp:-). But I can imagine that for others (putting, say, the >> emphasis more on hygienic macros or call/cc) PLT is the right choice. > > Largely the reason why I am interested in learning Lisp is because I > tried learning Factor but found that some of the concepts and > terminology were unknown to me. Most of my confusion has to do with > dynamic OOP. The terminology seems to be borrowed from CLOS, so I > hoped to learn it in the context of Lisp and then go back to Factor > when I am better prepared. Does it matter much whether I tackle PLT > Scheme or CL in regard to learning the concepts of dynamic OOP? When I learned the Lisp/CLOS way of OO (first using a Scheme version of it), I was amazed about its beauty, simplicity, and power, especially compared with OO as it is known from C++. I guess you will see these points in CLOS as well as in Swindle, but I cannot give a reasonable comparison, because I did only play with the latter ten years ago. > I am now starting in on PLT Scheme because of the practical reason > that it provides better support for writing GUI software. I've never > written a GUI program in my life, so this is something else that I > need to learn about. Factor provides support for GUI software, but the > documentation is a reference and assumes that the programmer already > knows the concepts. Terms like "widget" are unknown to me. I don't > even like *using* GUI software, but GUI seems to be what the world > wants, so I suppose I should bite the bullet and learn how to write > it. > > I'm already familiar with static OOP from having worked as a C++ > programmer. I've also seen implementations of static OOP in Forth > (SwiftForth and FICL). I know what the virtual method table (VMT) is. > I've even heard of static OOP done without a VMT (Oberon). I think I > could implement a static OOP system myself, and I likely will later on > when I get that far in my PIC24 Forth system. Fortunately, in CLOS you do not have to know what the VMT is. (It is there in a more general form, but) Things simply work as you expect. > What I don't get is all the computer-sciency terminology associated > with dynamic OOP. For example, what is the difference between a > "tuple" and an old-fashioned record (or "struct" in the C world)? > Another funky word is "curry." This seems to refer to nothing more > than providing default values for input parameters, which has always > been available in C++. Is there more to it than that? Why does this > old and not-very-exciting concept warrant a fancy new word? These are > the kinds of questions that I hope to get answered in my study of Lisp > or Scheme or whatever. > > Also, btw, why does so much of your terminology come from the food > world? Did the concept of curried input values get invented over lunch > at an Indian restaurant? What does "fry" mean in the context of > dynamic OOP? If I went to a Lisp convention, would I discover that > everybody there is overweight? Your minds seem to be pretty focused on > food! :-) I admit that I never heard "fry". And "curry" comes from FP, not OO. Nicolas
From: Hugh Aguilar on 22 Mar 2010 18:07
On Mar 22, 2:53 pm, Nicolas Neuss <lastn...(a)kit.edu> wrote: > Fortunately, in CLOS you do not have to know what the VMT is. (It is > there in a more general form, but) Things simply work as you expect. If I don't know what is going on under the hood, how do I know what to expect? I remember back in the late 1980s when OOP was first becoming popular that I was seriously confused. I really despaired of understanding it. I wondered if I might be *dumb*, as everybody else seemed to *intuitively* grasp the subject. The problem was that none of the terminology was being defined. We had words like "polymorphism" and "inheritance" that were tossed around, but they were never defined except with very vague analogies (involving the platypus, of all things!). Finally I decided to try reading a book on compiler-writing for OOP languages. This was pretty ambitious considering that I had yet to even write an application using OOP and I hadn't the slightest idea what OOP was. When I read about the VMT however, all of a sudden everything made sense. I realized that OOP was pretty similar to what I had already done in assembly language, with records being appended onto each other. The difference is that I had just put the vectors (pointers to functions) inside of the records as fields, whereas the VMT is a single field that points to an array of vectors. The VMT saves memory in the records, and it also saves time in initializing the vectors which are the same every time anyway. The cost is an extra level of indirection, which can be slow especially on processors that don't have very many registers. Other than the introduction of the VMT however, OOP was just same-old same-old. It wasn't that complicated! I'm really a low-level type of guy. If I don't know what is going on at the level of assembly language, then I don't claim to know what is going on at all. I tend to get very annoyed when people use undefined terminology and then tell me that it is "intuitive" and that "Things simply work as you expect." > I admit that I never heard "fry". And "curry" comes from FP, not OO. Maybe "fry" is Factor-specific. As for functional programming (FP), what is the definition of that? My understanding is that this just means that functions work with data that is passed into them, and they return data, but they don't muck around with global data. If that is what FP is, then I am in favor of it. Forth philosophy emphasizes doing this as it makes testing the functions much easier. There are a finite number of possible inputs, and they can be tested pretty thoroughly. Also, once a function is tested, you can expect it to continue working forever. It just does what it does, and it is unaffected by any kind of context around it. That is the Forth way! |