Anybody willing to decipher Forth program
in [Lisp]
|
From: joswig on 23 Mar 2010 09:13 On 23 Mrz., 13:52, Eli Barzilay <e...(a)barzilay.org> wrote: > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > On 23 Mrz., 11:48, Eli Barzilay <e...(a)barzilay.org> wrote: > > >> "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > >> > He says 'extension', but shows redefinition. His example is > >> > 'nonsense'. > > >> That depends on your definition of "definition". If it means > >> creating a binding, then there is no redefinition happening > >> there. If it means determining what a specific function does -- or > >> more generally changing what value a variable contains -- then yes > >> this is redefinition, just like any other (incf *foo*). The wart > >> that I'm referring to is exactly this side effect -- and that (and > >> consequences like order-of-loading dependencies) remains whatever > >> your definitions are. > > > Just disallow REDEFINITION of methods. Done. > > *sigh* > > > But then in CLOS and CL in general, side effects are everywhere, and > > are not 'warts'. > > Yes, side effects are everywhere -- in all practical languages. Even > in Haskell. But side effects are >>> IN MY OPINION <<< warts > regardless of the language -- and *I* consider it an even bigger wart > if you have side effects that lead to dependencies on the order of > loading code. Because of this, *I* consider it a problem when an > object system forces me to get into this swamp (barring non-solutions > like "Just disallow individual definitions of methods"). This does > *not* mean that if I'd design a language from scratch I'd try to > remove side effects, but it does mean that *I* try to avoid such > dependencies, and that *I* believe that avoiding such dependencies > *if* possible and practical makes *MY* code more robust. *sigh* Above is all vague and fuzzy. > But of course *YOUR* opinion is different. I can agree with that.
From: Pascal Costanza on 23 Mar 2010 09:58 On 23/03/2010 02:39, Eli Barzilay wrote: > Nicolas Neuss<lastname(a)kit.edu> writes: > >> 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. > > Yes, that's been a very active area for probably more than the past > decade. > > >> 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. > > (It does have a strong academic background -- but "a lot of funding" > in academic terms is usually an order of magnitude less than an > average commercial company.) > > >> 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). > > The reason I pointed at CLOS as being a potential problem is related > to types, but goes beyond that: it is the fact that generic functions > are being extended via side-effects which complicates both having it > live in peace with a typechecker as well as other components. To get > a feeling of the general problem, consider the fact that if you have > this > > (defmethod foo ((x string)) 'x) > > in one file, and this > > (defmethod foo ((x string)) 'y) > > in another, then the order in which you load the two files becomes > important. IMO, this is the single biggest wart that I didn't address > in Swindle. (And I don't know of a way to address it.) 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. What could happen after startup time 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. A problem could arise from the fact that the static type checker may not work well when analyzing independently developed modules in isolation. Maybe some of the informal Common Lisp coding conventions could be reused to solve this, notably the one that recommends that you only define methods where at least one specializer applies on instances of "your own" classes. This could maybe be formalized into requiring that the methods in a compilation unit must specialize on at least one class that is defined in the same compilation unit. Just guessing, don't know if that could work well enough. 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: Pillsy on 23 Mar 2010 10:39 On Mar 22, 6:07 pm, Hugh Aguilar <hughaguila...(a)yahoo.com> wrote: [...] > 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. That's one major element of it, but it also includes the idea that you have functions as first-class values---they can be passed as arguments to functions, and returned as values *by* functions. Functions are just another type of data. For example, you can have a function called "compose" which takes two functions of one argument as arguments and returns a different function of one argument, so that compose(f, g)(x) = f (g (x)) where f(x) is the usual notation for function application. First-class functions seem to be really catching on these days, much more so thaneschewing side-effects. Cheers, Pillsy
From: Eli Barzilay on 23 Mar 2010 10:41 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). > 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.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Hugh Aguilar on 23 Mar 2010 13:24
On Mar 22, 4:37 pm, refun <re...(a)nospam.gmx.com> wrote: > Using basic CLOS features is rather intuitive, but if you want all the details, > read AMOP and inspect a live CL system which comes with source code, that way > you'll understand both what it's supposed to do, and how it does it, but keep > in mind that implementations are given a certain degree of freedom on how > things are implemented, so you can't expect things which are not documented(in > the ANSI CL standard and the MOP) to stay the same in each implementation. I actually have the AMOP book, but have never read it. Is PLT Scheme different enough that reading AMOP would mess me up? Should I wait until later on when I have graduated/downgraded to CL before I read AMOP? |