Thanks for any help,

Károly Ladvánszky

In a vague sense, symbols will feel like an enum type except there are an
infinite number of them and you don't have to declare them.  You just type
their name and they're there.

  (setq person1 'fred)
  => FRED

All expressions will return a value.  An assignment returns the value
assigned.

  person1
  => FRED

This assigns the variable person1 a value which is the symbol FRED.
That would take more work in C++ already, requiring declarations, etc.
In Lisp, the type is in the object, not in the variable.  And many datatypes
have a type-in/print-out notation such that you can just name them and they
will exist.  If you want a list of things, you can do that, too.

  (setf (get 'fred 'favorite-sports) '(boxing tennis archery))
  => (BOXING TENNIS ARCHERY)

You can write a function to inquire whether something is in such a list:

  (defun likes? (person sport)
    (if (member sport (get person sport))
        'yes 'no))
  => LIKES?

Then you can ask

  (likes? person1 'boxing)
  => YES

Another common thing is to associate one symbol with another in a list.
For example:

  (setf (get 'acme 'jobs)
        '((sally president)
          (mark vice-president)
          (fred secretary)))
  => ((SALLY PRESIDENT) (MARK VICE-PRESIDENT) (FRED SECRETARY))

Then you can say:

  (defun role-in (company person)
    (let ((all-jobs (get company 'jobs)))     ; get list of company jobs
      (let ((entry (assoc person all-jobs)))  ; get person's entry in jobs
        (if entry                             ; when entry exists
            (second entry)                    ;  return the second element
            'customer))))                     ;  otherwise, return CUSTOMER
  => ROLE-IN

  (role-in 'acme 'mark)
  => VICE-PRESIDENT

  (role-in 'acme person1)  ; PERSON1 is a variable we assigned earlier
  => SECRETARY

  (role-in 'acme 'arthur)
  => CUSTOMER

You can also write things to find out other things from the same data.
Consider:

  (defun jobs-in (company)
    (mapcar #'second               ; make a list of the first elements from
            (get company 'jobs)))  ;  the jobs list for the company
  => ROLES-IN

  (jobs-in 'acme)
  => (PRESIDENT VICE-PRESIDENT SECRETARY)

  (defun employees-of (company)
    (mapcar #'first                ; make a list of the first elements from
            (get company 'jobs)))  ;  the jobs list for the company
  => EMPLOYEES-OF

  (employees-of 'acme)
  => (SALLY MARK FRED)

Cheers

- access to the reader (parser) and evaluator from within the program.
- treatment of code as data and vice versa
- tree-transforming macros for implementing new sublanguages and other uses
- programmer control over evaluation
- Lisp program can customize the behavior of Lisp's lexical analyzer
  (read tables which classify input characters, and reader macros,
  can be altered programmatically).
- dynamic typing (values have type, not objects or
  expressions)---you can't effectively emulate a dynamic language like
  Lisp within a static language like C++ without writing an interpreter.
- built in support for rational numbers and bignum integers
- dynamically scoped variables
- lexical closures---objects can can be called like functions, which
  capture (close over) the variables and bindings of the lexical
  environment in which they were created.
- automatic garbage collection---necessary to support all kinds of
  powerful programming techniques whose usefulness would be drowned by
  the complexity of explicit storage management. (There are garbage
  collectors for C++ implementations, but they don't do a complete enough
  job to be trustworthy, because they have to make conservative guesses
  about the meaning of raw, untyped memory).
- dynamic loading, redefinition of functions (done only in clumsy,
  fragile, operating-systems-specific ways in C++, like shared libraries
  on UNIX).

In the object system:

- multiple dispatch
- auxiliary methods (before/around/after)
- basic types (strings, integers, etc) *are* classes and participate
  in dynamic polymorphism. In C++ you can't even do *static* polymorphism
  on non-class types.
- changing class of object at run time
- overridable data members (called slots in CLOS terminology)
  (Only functions in C++ classes can be overriden via the virtual
  function mechanism).
- static members (``:allocation class'' slots) inherited properly
  (In C++, static class members are not inherited).
- Class slot in derived class can override instance slot in
  base and vice versa.
- meta object protocol (called MOP, supported by some CLOS implementations)
  to subtly or radically customize the behavior of the class system.

Primitive HTML tools

http://www.cadvision.com/humeniuw/primitive-html.lisp

and an example of using Primitive HTML Report Generation

http://www.cadvision.com/humeniuw/html-report.lisp

Wade

  You seem to be a Microsoft user.  I am not.  Could you show me a few
  short examples that demonstrate the power of the Windows environment?

| I'm especially interested about the symbol manipulation features. Are
| there 'magic' constructs native to Lisp, constructs that would need a lot
| more coding in languages like C++?

  There are two kinds of constructs in a Common Lisp vs C++ comparison:

1 Those for which C++ uses one- or two-character prefix, infix, and postfix
  notation, where C++ excels in compactness and expressibility, which leads
  many people to think that C++ is somehow compact and easy to write and
  express yourself in, even while the bulk of your code is not using these
  small and elegant syntactic sugarcubes.

2 Those for which Common Lisp use the same syntax as everything else, where
  Common Lisp excels in overall compactness and expressibility because of a
  _much_ higher level of abstraction and much lower number of minor details
  that needs expressing, meaning that the value of a super-compact syntax
  for the simplest operators is correspondingly lower.

  It should be fairly obvious that comparisons have to be performed at two
  different levels at once and thus will produce no useful results if you
  do not already understand what you just compared on their own merits.

This isn't exactly the kind of response that is likely to convert
someone who is new to Lisp to using it, as it conveys no useful
information whatsoever. At the very least you need to say what a
multimethod is, give a toy example and say why you can't achieve it
with C++ templates.

"Erik Naggum" <e...@naggum.net> az alábbiakat írta a következo üzenetben:
news:3211824385979077@naggum.net...

I'd say other people have answered the questions raised.

Cheers

Anyway, the commercial CL implementations running on Windows offer
integration with COM.  Franz Inc. ACL is the one I have used and I have to say
(to Franz Inc.'s merit) it is easy to use.  I have not used LW or
Corman Lisp in this capacity, so I cannot comment on them.

Cheers

Károly

"Kent M Pitman" <pit...@world.std.com> az alábbiakat írta a következõ
üzenetben: news:sfwvghm1o5r.fsf@world.std.com...

  http://lisa.sourceforge.net

Thanks

Anything that wants to call a COM DLL, or behave like one, has to
emulate C++ virtual function calls, to do which it has to understand
vtable layout, and the Visual C++ calling conventions for passing
parameters and returning values. That is not only language-dependent,
but downright compiler-dependent.

DCOM is also language bound, because the kinds of data types
passed through its remote calling interface are based on the C language.
DCE was written in C and designed primarily for C programming.
The protocol itself uses inflexible binary representations on the wire.

Microsoft took the RPC library from DCE, turned it into Microsoft RPC
(embrace and extend, like everything else) then added some hacks whereby
DCE services become interfaces, represented by C++ objects. The 128 bit
GUID of a DCE service is renamed an interface ID and so forth.

If you wanted to use DCOM for, say, communicating between two Lisp
components, you'd have to design a way to represent Lisp's types from
the ground up.  Atoms, cons cells, Lists, bignums, vectors, dynamic type
information, you name it. You'd most likely just pass raw character
data and parse it on the other side with Lisp's built in reader, using
the DCOM connection as a dumb pipe.

Anything that wants to call a COM DLL, or behave like one, has to
emulate C++ virtual function calls, to do which it has to understand
vtable layout, and the Visual C++ calling conventions for passing
parameters and returning values. That is not only language-dependent,
but downright compiler-dependent.

DCOM is also language bound, because the kinds of data types
passed through its remote calling interface are based on the C language.
DCE was written in C and designed primarily for C programming.
The protocol itself uses inflexible binary representations on the wire.

Microsoft took the RPC library from DCE, turned it into Microsoft RPC
(embrace and extend, like everything else) then added some hacks whereby
DCE services become interfaces, represented by C++ objects. The 128 bit
GUID of a DCE service is renamed an interface ID and so forth.

If you wanted to use DCOM for, say, communicating between two Lisp
components, you'd have to design a way to represent Lisp's types from
the ground up.  Atoms, cons cells, Lists, bignums, vectors, dynamic type
information, you name it. You'd most likely just pass raw character
data and parse it on the other side with Lisp's built in reader, using
the DCOM connection as a dumb pipe.

  Special variables leaps to mind as the obvious first choice, more obvious
  than closures, the Lisp object reader and writer, the type hierarchy and
  dynamic types, the entire condition system, macros, compiler-macros, etc,
  which I just mention in no particular order.  Of course, if your point is
  to gripe about the choice of "much", you will never be satisifed with any
  answer I could give you, anyway, so either you accept this or you do not.
  And if you had had a real argument, it would have been expressed properly,
  so I am inclined to believe you are just trolling and will not respond to
  any further trolling-like responses you choose to post, but please feel
  free to argue your case if you have one.

Rolf Wester

  Then you deserve a better answer.

| I'm not very familiar with CL but I'm fascinated by it's capabilities as
| far as I recognized them.  As I mostly programmed in Fortran/C++/Java
| it's not so obvious for me to see in what respect Lisps level of
| abstraction is much higher compared to other languages.

  This is actually a serious problem for Common Lisp, and you are far from
  alone in experiencing its effects.  For instance, take special variables.
  People who do now know how they work, tend to dismiss them as some old
  Lisp concept that should not have survived.  Then they write code that
  uses some global variables and they _set_ their values, they get yelled
  at for using global variables whose values are hard to track, and they
  think that global state is a bad thing.  However, the bad thing about
  global variables is that they do _not_ have the infrstructure offered by
  special binding in Common Lisp.  A function may legitimately desire to
  change the global state for a carefully controlled duration, but in order
  to do so, you have to guarantee that the old state is restored.  This is
  truly hard if the language does not support it.  Exceptions and other
  non-local control transfers intervene.  Storing the variable in some
  local variable is not always trivial -- you need to replicate an object
  with the same type as the global variable, and the language does not give
  you that obvious operation, either -- and then you need to ensure that
  the stored value is put back into the global variable before you return,
  which can be foiled by the kind of unconscious programmers that are
  likely to mess with our code.  So C++ people tend to think that special
  variables are useless, but in fact, they solve a very serious problem
  that C++ programmers do not generally try to solve because it is too hard
  and generally too painful in their language.  Sticking to the convenient,
  they use semi-global state variables and are nervous.  The abstraction
  offered by special variables is thus hard to grasp for the programmer who
  does not even perform the concrete operations the abstraction automates
  and hides.  Even Common Lisp programmers are generally unaware of the
  concrete mechanisms underlying the abstraction.  The impact on threads,
  for instance, is not quite obvious: One variable may be so global that it
  should affect all threads, while another may have a thread-local global
  value.  This means that implementationally, a thread context switch needs
  to re-bind special variables if they share a Lisp image, and involve IPC
  and shared memory between threads if the variable is thread-global.  This
  is so hairy stuff that even good programmers would shy away from thinking
  about using such things if they had to do it manually.  To a Common Lisp
  programmer, it is a natural extension to special variables, even though
  conceptually much more advanced.  Other forms of context switches may
  also be desirable, so it makes sense to expose the control mechanism for
  rebinding special variables, but this could now be done separately from
  the bindings because the infrastructure for bindings is already there.
  Thus the abstraction offered by special binding in Common Lisp spans an
  enormous amount of otherwise manual work, and they are not only "global
  variables", which is how some think of them, it is also a mechanism that
  can be used for variables that are _not_ global, but require the support
  of binding and unbinding of variables that can be shared only among a few
  functions that know about them.  Therefore, there is a local declaration
  to request special binding of an otherwise lexical variable in addition
  to the global declaration to request it of all bindings of a symbols, and
  the global declaration applies to the symbol regardless of its context,
  because specialness of a symbol must be pervasive to work at all.  This
  means that the mechanism behind the special binding is very different
  from the global variable in many other languages, which may be shadowed
  by a lexical binding (except they do not call it that).

| P.S.: My mother language is not English so misunderstandings may arise
| because I can't express myself in English as precisely as I could do in
| German.

  It is probably OK to include the German if you are uncertain about an
  expression -- even if people here write in English, the language skills
  of the community is pretty amazing, and you could get tips and hints that
  would not get anywhere else.  For instance, "Muttersprache" and "mother
  tongue" and "langue maternelle" have the common Latin etymology "lingua
  materna", but still it does not really work all that well to translate
  directly between them in any direction...

I'd put a somewhat different emphasis on them.

lexical closures and functional programming:
  Functions are first class objects. You can make code or functions
  which generate function values. There are lots of library functions
  which accept function values as arguments and do powerful things
  with them.
    (DEFUN CUTOFF-FUN (X)
      "Return a function which tests whether its argument exceeds X."
      (LAMBDA (Y) (> Y X)))
    (DEFVAR *CUTOFF-FUN-1* (CUTOFF-FUN 1))
    (DEFVAR *CUTOFF-FUN-4* (CUTOFF-FUN 4))
    (SOME *CUTOFF-FUN-1* '(1 2 3)) => T
    (SOME *CUTOFF-FUN-4* '(1 2 3)) => NIL
    (SOME (LAMBDA (Y) (> Y 2)) '(1 2 3)) => T
    (FIND-IF #'EVENP '(1 2 3)) => 2
  This is shared with other functional programming languages (notably
  the ML family and Haskell) and some scripting languages, but lots
  of languages have either weak or no support for it.

garbage collection:
  This is a nice thing in general, and in particular, functional
  programming tends to get unreasonably messy if you don't have it.

extremely general, powerful macros:
  A macro in Lisp is a Lisp program which generates code. Because of
  this, and the way that the syntax of Lisp makes it trivial to
  manipulate Lisp source code as Lisp data, there are few unnecessary
  obstacles to adding complex new behavior to Lisp. (There's only the
  *necessary* obstacle that this is fairly tricky to think about.)
  It's hard to give a convincing tiny example of this, especially
  since typical macro syntax isn't self-explanatory. So I'll refer
  you to a small example and a medium-sized example instead:
  writing an object-oriented programming system from scratch (as
  a demonstration only, since the existing CLOS system is fine)
  in Paul Graham's book _ANSI Common Lisp_, or adding nondeterminism
  (choose and fail) to the language, in the free library Screamer. Both
  of these are nontrivial changes to the language, and adding them to
  almost any other language would be a major project. In Lisp this
  kind of thing is relatively routine.

integrated compiler, interpreter, and debugger:
  This isn't unique to Lisp, of course: many other languages,
  especially scripting languages and functional languages, have it.
  But for me C++ is one of the strongest competitors to Lisp, and
  the lack of this is a major reason why I don't use C++. When I
  write a complicated program in C++, and I'm trying to understand
  its behavior -- not just bugs, but e.g. performance problems
  in a complex problem with no single optimum algorithm -- I end
  up writing a lot of code to inspect the program. In Lisp I write
  a lot less of this because it's already there.

good compiled performance:
  It depends on the compiler, of course, but it's possible to
  compile Common Lisp efficiently. This isn't unique to Common Lisp,
  of course, but it's an important distinction from some scripting
  languages (e.g. tcl has some real problems with being compiled
  efficiently). Also, reasonably efficient implementations do exist,
  which distinguishes it from various nifty but too-small-a-niche
  languages.

smaller but still significant advantages:
  * a powerful object system (CLOS), including multiple inheritance and
    multiple dispatch. Multiple dispatch is an unusual feature, and
    sometimes you don't need it, but sometimes you really want it. If
    you're from a C++ background, check out Scott Meyers' _More
    Effective C++_ for a discussion of ways you can sort of mock
    it up in C++.
  * powerful support for object identity and i/o, with things like
    reader/writer support for circular data structures and the
    MAKE-LOAD-FORM stuff to give you the hooks you need to set up
    object identity correctly at load time

features which can be either advantages and disadvantages, depending:
  * A Common Lisp program is itself a dynamic object, and there are
    many standard ways to change it radically while it's running.
    This can be useful, but it makes it a lot harder to write various
    kinds of software which depends on understanding the build
    process of your program, e.g. to do the kind of incremental
    rebuilding done by Unix "make".
  * Common Lisp uses dynamic typing by default. This helps a lot when
    writing some kinds of code. But more typically, it lets you write
    normal code concisely and quickly, but the compiler can't understand
    it well enough to perform some basic sanity checks or make some
    useful optimizations. (You can override this to a large extent by
    adding type declarations, which are supported, just not required.)

Here's a trivial implementation of memoization
in Common Lisp. You can use it to memoize any function that's not too
bizarre (so e.g. the function should return only one value, and EQUAL
should be an appropriate test for equality of the function's
arguments).
  ;; private, bare memoization function
  (defun %memoized (fun)
    (let ((memos (make-hash-table :test #'equal)))
      (lambda (&rest rest)
        (multiple-value-bind (value foundp) (gethash rest memos)
          (if foundp
              value
              (setf (gethash rest memos)
                    (apply fun rest)))))))
  ;; public version: Make all attempts to memoize the same FUN share
  ;; the same closed-over hash table.
  (setf (symbol-function 'memoized) (%memoized #'%memoized))
Hopefully this will illustrate the point that it's simpler to
express this abstraction in Lisp than in most other languages.
Unfortunately, I'm too hurried to test it right now, so if you
need something which actually works, see the comparably simple
example on p. 65 of Paul Graham's _On Lisp_, which is what this
is loosely based on.

This implementation is nice and simple because it uses lexical
closures and dynamic typing. So I think you could do it in modern
Perl, since it's supposed to do lexical closures. And you could
maybe sorta kinda in Java, since I've heard that Java sorta
kinda supports dynamic typing. In C++ you might be able to do
something with templates and the STL map classes, although I'd be
surprised if it'd be nearly as simple and usable as this.
In the other languages I'm familiar with it might be impossible
to express this abstraction at all. (You can express a memoized
function in any reasonable language, of course, but can you
express "memoize this function" in the language?)

  http://ww.telent.net/cliki/Ask%20Uncle%20Peter