geez.  just tell me what you did, and I might approve, but this is just
  getting silly.  if you think you can argue based on keeping stuff secret
  until you think you can win an argument by disclosing it in a way that
  implies that somebody ought to have known what you kept secret, you're
  sadly mistaken and less constructive that I suspected to begin with.

| I wouldn't have to take this out in public if others weren't hinting
| people to make their own decisions based on a single criterion.

  as far as I can see, nobody is doing that, and anyone who bases their
  decisions on a single criterion aren't worth spending time on, anyway,
  since you are _very_ unlikely to be the next single criterion and are
  probably not going to multiply the criteria, either.

| A final note: immediately after their Lucid acquisition, Harlequin had
| maybe even more Top Gun talent than Franz.

  which might imply that Franz Inc is the "underdog" in some people's view,
  and that it is just as silly to base your decisions on which product to
  buy on a single criterion as to choose which is the "underdog" on a single
  criterion.  (it seems to me as if "underdog" is your criterion of choice.)

| Your comments may sometimes give someone the impression that their
| technology is not good, and unless you've also seen their source code (I
| know you've seen Franz's), I believe a bit more of tact is in order.

  I fail to see how you could possibly conclude that I think or imply or
  even want to communicate that their TECHNOLOGY is not good.  Harlequin
  has made some technical decisions that I don't approve of, and Franz Inc
  has made some of their own, which should come as no surprise to anyone --
  neither I nor any company can be expected never to make mistakes or even
  dumb decisions for which "do not approve" is the only viable sentiment
  either way -- but these are usually _survivable_ differences, especially
  in a language as good as Common Lisp.  that I don't like IDEs has been a
  motivation for me to urge Franz Inc to keep Emacs for the Windows port of
  Allegro CL (I was worried they would scuttle it from all the hype about
  the IDE for Windows), but I'm open to learning what IDEs can offer and I
  try them out every once in a while to see whether they suffer from the
  typical GUI illness: anti-scalability of functionality.

  however, Harlequin has made several _political_ and _financial_ decisions
  that I don't like at all, and Franz Inc hasn't made any such decisions.
  on the contrary, both their free and commercial Linux (and FreeBSD) ports
  were decisions I approved of very strongly, and they do other stuff that
  is concurs with my sentiments.  I have also been worried at times, such
  as when 5.0 took a _long_ time to come out, and I'm always afraid that
  people who flirt with the Evil Empire and begin to depend on their APIs
  will wind up killed in the insane rush to keep up with whatever the Evil
  Empire decides to break between releases and fixes.  however, they have
  _not_ wasted enormous amounts of energy on failing endeavors that nearly
  killed them, and that, to me, is quite important.  fiscal responsibility
  is important.  that Harlequin laid off a bunch of excellent people in a
  pretty rash move and nearly croaked soon thereafter is _not_ something I
  consider beneficial when deciding whether to trust somebody, and I'm not
  going to pity them with an "underdog" label, either.  trust in companies
  is a really big deal to me -- it's why I don't ever want to use anything
  that comes out of Microsoft, for instance.

  your "underdog" may be in a position right now to make a lot of easy
  money from products whose costs are no longer a part of the company
  budgeting because of the acquisition.  I'm very critical of the process
  wherein a company badly run ends up having their creditors (not their
  investors and customers) pay for development projects that can then be
  priced way below any competitor's ability to compete without going
  through a reorganization of their own to scuttle their debts.  I am not
  privy to the exact process that Harlequin went through, but I have seen
  companies that sell stuff too cheaply cut their costs through deliberate
  reorganization sufficiently often and the attendant ramifications for
  their competitors are so grim that I'm not at all pleased with the point
  of view that such people are also worthy "underdogs" because they got
  their creditors to bail them out.  I am very happy that they survived
  this ordeal intact, but they should be prepared to prove that they did
  learn from the experience and are now fiscally responsible and ensure
  that they get enough income from their sales so as not to have to repeat
  the same stunt later.  going for too low prices is not reassuring to me.

  I'd be much happier with a more level playing field than this talk about
  "underdogs" and the negative attitudes towards policies that _haven't_
  caused anybody financial problems.

  also, as I have said before and might as well repeat: I don't think Lisp
  can win by competing with unprofessional languages.  Common Lisp is a
  language you mature into, after you've fought a bunch of other languages
  and come to understand something much more complex and lasting than how
  to make individual functions run fast with machine integers and addresses
  (which is a valuable thing, of course, but like potty training, you don't
  stop there).  as a "graduate" language, I don't want it to be something
  you choose out of low entry costs.  students of the language should be
  able to pick it up for free, essentially, but should also realize what
  they have got their hands on and be willing to share their productivity
  gains and the values they create because of this superior tool with the
  tool-maker.  it's when the tool is essentially a commodity on its own
  that it makes sense to demand no royalties or cooperation with the tool
  vendor, and Lisp doesn't stand a chance of becoming a commodity language,
  so it's counter-productive in the extreme to attempt to jump-start the
  process by removing the means of ensuring cooperative success between
  system and application vendor.

  this obviously doesn't mean that I think people shouldn't make small Lisp
  applications and find ways to sell them at a rewarding profit -- after
  all, I have grown up in a country with >50% tax on reasonable incomes,
  28% corporate tax, and a 23% sales tax, so I'm not going to suggest that
  any companies adopt similar measure to kill their future -- but it is
  entirely appropriate to set the expectations at sharing, since small Lisp
  applications haven't been the norm so far, and that's _not_ because of
  the royalties policies, like some would have you believe.

The essence of a commodity language is that it works with
a commodity operating system and has similar pricing and
support.  Corman Lisp is too new to know how it's going to
do, but I would not be surprised to see it skyrocket to
become the leader in a few years.

  please identify yourself and then re-post your opinion.  thank you.

You also get automatic separation of environment and application, like a
conventional language: so delivery of applications is straightforward. But at
the same time you still get a listener and interactive development.

I'm not saying Dylan is better than Common Lisp: I'm simply pointing out that
issue of raw performance isn't over and it wasn't the only reason for doing
Dylan.

This newsgroup isn't the intended constituency for Dylan anyway. In a sense,
Dylan is like CL boiled down and given a sugar frosting to make it more
palatable to the masses. It's hardly likely to appeal to people who like
organic food and more fibre in their diet. Ironically, however, (ex-)Lispers
are some of the people best placed to appreciate Dylan's flavour.

Biggest benefits:

- uniformity
- extensibility
- introspection

obvious candidates: functions, streams, pathnames, hashtables, arrays,
sequences, readtables, ...

So while you can't dispatch on (integer 0 7), which is a type-spec (as
is (satisfies evenp), or (member 0.0 7 a)), you can dispatch on
integer, ratio, rational, float, real, complex, number, character,
sequence, vector, array, string, etc.

typecase is a macro that let's you dispatch on types (described via
type-specs), but that is orthogonal to CLOS' ability to dispatch on
classes.

Here are the definitions of types and classes from the HyperSpec:

type n. 1. a set of objects, usually with common structure, behavior, or
purpose. (Note that the expression ``X is of type Sa'' naturally implies that
``X is of type Sb'' if Sa is a subtype of Sb.) 2. (immediately following the
name of a type) a subtype of that type. ``The type vector is an array type.''

type specifier n. an expression that denotes a type. ``The symbol
random-state, the list (integer 3 5), the list (and list (not null)), and the
class named standard-class are type specifiers.''

class n. 1. an object that uniquely determines the structure and behavior of a
set of other objects called its direct instances, that contributes structure
and behavior to a set of other objects called its indirect instances, and that
acts as a type specifier for a set of objects called its generalized
instances. ``The class integer is a subclass of the class number.'' (Note that
the phrase ``the class foo'' is often substituted for the more precise phrase
``the class named foo''---in both cases, a class object (not a symbol) is
denoted.) 2. (of an object) the uniquely determined class of which the object
is a direct instance. See the function class-of. ``The class of the object
returned by gensym is symbol.'' (Note that with this usage a phrase such as
``its class is foo'' is often substituted for the more precise phrase ``its
class is the class named foo''---in both cases, a class object (not a symbol)
is denoted.)

class designator n. a designator for a class; that is, an object that denotes
a class and that is one of: a symbol (denoting the class named by that symbol;
see the function find-class) or a class (denoting itself).

Regs, Pierre.

  yes, but we name them accurately "system classes".  a _type_ is a set of
  values of a given class.  some languages don't have any means to express
  this, so conflate "type" with "class".  some languages don't have type
  hierarchies and think "primitive type" is a good idea to make different
  from all other types.  this is an issue of forcing the user to be acutely
  aware of implementational considerations on the hardware, so the types
  should be more accurately be called "hardware types" and "software types"
  in such languages.

| I mean, can or can't you write a method for, e.g., numbers that get
| dynamically dispatched?

  yes, NUMBER is a system class.  so are its two disjoint subtypes REAL and
  COMPLEX, the two disjoint subtypes RATIONAL and FLOAT of REAL, and the
  two disjoint subtypes INTEGER and RATIO of RATIONAL, but the subtypes
  FIXNUM and BIGNUM of INTEGER and {SHORT,SINGLE,DOUBLE,LONG}-FLOAT are not
  system classes.  you can still dynamically dispatch on them in most CLOS
  implementations, however, because they form implementation classes.

| What's the deal with the typecase macro?

  it is to TYPEP what EQL is to CASE.  (I don't think this answered your
  question, but it is not a very answerable question -- it seems to say,
  because of the preceding tone, that you disapprove of it because it isn't
  OO, which is a silly reason.  I can't make you approve of something you
  don't yet understand, and won't waste my time to help you understand when
  approval precedes understanding.  back up a bit and desire to understand
  before you want to approve or disapprove, and this might change.)

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

Perodically, I wish object-orientation was shot a bit more into the core

of lisp.  Of course, there are speed issues, so it'd want it to be
optional.

This is convenient for high-volume products with fairly predictable high
demand.  For low-volume products, the accounting is not much of an issue.

In all cases, customers balk (understandably) at royalties and will only pay
them if they feel the technology they are acquiring is indispensable and
cannot be gotten elsewhere or written by the customer.  It always creates
some amount of hard feeling by the customer.

This is unfortunate to some degree.  When you think about it, if you embed
lots of complicated code in your application that was written by somebody
else, it's reasonable to pay a per-piece fee as you would pay a supplier of
hardware components.  On the other hand, the marginal cost of software
copying is so low that it's easy to see why one would feel ripped off for
having to pay royalties that end up being more-or-less pure profit for the
vendor.

In the end, it's all a question of supply and demand.  If a vendor can get
away with charging a large annuity stream rather than a one time payment,
they will.  If they can't, they won't.

A quick small survey over previous posters came up with this solution:

- e...@nospam.net from <3817c18b.1435913...@news.earthlink.net> and also
<3815fe44.1385922...@news.earthlink.net> has the same posting host and
software as <3825c1e6.854123...@news.earthlink.net>. he never showed up
again in all three threads.