Re: A question (confusion) about closure

Didier Verna <didier@xxxxxxxxxxxxx> writes:

"John Thingstad" <jpthing@xxxxxxxxx> wrote:

emacs is a evolved system that worked the whole time while they added
code. If you had 'designed' it with the current features I doubt if it
would ever have worked in the first place.

If not in the first place, emacs lisp code could have evolved if elisp
itself had; but that didn't really happen. At some point (I mean right
now), perhaps starting from scratch again would be better than
refactoring.


Another question is if OO design would have made it 'better' or just
more 'familiar'.

Right. Not all parts would necessarily benefit from object
orientation, but some definitely would. What's more (at least in the
case of XEmacs), some parts already *are* object-oriented; just not in
an OO language which is a real PITA. Refactoring those parts with a
more modern tool underneath would not be difficult, because the design
is already there.

I don't see what's the problem. Lisp is a programmable programming
language. There's nothing easier than to define an OO system in Lisp.
Do Xemacs hackers need to learn about defmacro?

If you already have implemented some OO patterns manually, it would be
quite easy to just define the macros to formalize these patterns, and
progressively replace manual patterns with macro calls. When it'll be
all done, you will be able to change the implementation of these
macros if needed.

--
__Pascal Bourguignon__
.

Relevant Pages

  • Re: macro for shorter array syntax
    ... macros for that are not of the "let's fix the array syntax" variety. ... I've only been writing Lisp code for two years and in a purely ... expression of dependent patterns. ...
    (comp.lang.lisp)
  • Re: Reflections on a classic Lisp Paper
    ... relative to other mechanisms as the rather different macros ... of a functioning fexpr-based lisp. ... Fexprs is that they're applicable and have first-class runtime ... the rest of their design decisions. ...
    (comp.lang.lisp)
  • Re: Design Patterns and Functional programming
    ... patterns in the GoF book are "invisible or simpler" in Lisp ... than existing independently of the solution domain, many design ... the language used for implementation. ...
    (comp.object)
  • Re: Lisp Design Patterns
    ... variable capture vs anaphoric macros ...). ... I have for instance looked at patterns for concurrency which might well be implemented in Lisp. ... For some other patterns like the factory pattern, well Lisp has first class functions wich do the same job with less fuss. ...
    (comp.lang.lisp)
  • Re: Concentration in OCaml
    ... OCaml (and probably Lisp too). ... Regarding the well known design patterns from the GoF: ... OCaml offer both much better mechanisms to express most of these design ...
    (comp.lang.lisp)
Loading