Reviews for lisp implementations 
Author Message
 Reviews for lisp implementations

Hi,
    Could someone recommend any good, independent
sites for the above?  In particular, I'm looking
for product comparisons between Harlequin's end
Franz's implementations.  I had tried the ALU site
(and the rest of the web) for a few hours without
any success.  Thanks in advance.

Best regards,
Peter



Sun, 30 Sep 2001 03:00:00 GMT  
 Reviews for lisp implementations


Quote:
> In particular, I'm looking for product comparisons between
> Harlequin's and Franz's implementations.  I had tried the ALU site
> (and the rest of the web) for a few hours without
> any success.  

Apart from Usenet snippets, the only product comparison I'm aware of
is by David Lamkins (http://www.teleport.com/~dlamkins). Unfortunately,
it's probably too old to be of any use.

I've waited two days for people with more experience to shed some
light here. But, apparently, nobody is willing to burn his fingers
on a comparison between Harlequin and Franz. So here's my (very
personal and very subjective) impression, based on about 1000 hours
of working with Harlequin's Lispworks, 50 hours of experiments with
Franz' previous version (don't remember version number) for Windows
and about 5 hours of playing with Franz' current version. All of this
on Windows 95/98.

* Price
  Franz is a lot more expensive than Harlequin (at least a few thousand
vs. less than one thousand dollars). Also, Franz wants royalties for
programs that you distribute; Harlequin doesn't (unless you use their
Enterprise Edition).
  For personal use, both companies have a free version.

* Conformance to standards.
  My impression is that both companies are pretty good at conforming
to the ANSI spec, but that Harlequin takes it a bit more seriously
than Franz. Harlequin seems to be much better at supporting Unicode
and other character sets. Franz still seems to think that 256 characters
is more than enough (just like Bill Gates thought that 640K is more
than anyone would ever need).

* Integration with underlying platform
  My impression is that Franz puts more effort into this than Harlequin.
For Windows, Franz seems to support more platform-specific stuff
(e.g. multimedia extensions, tree views). Also, their development
environment has a more 'natural' feel.

* Performance
  I haven't run any benchmarks, but Lispworks feels a bit more
sluggish (both in space and speed) than Allegro CL.

If money didn't matter, I would use Allegro for platform-dependent
stuff and Lispworks for everything else. Personally, I can't afford
Allegro and I've settled for Lispworks. I've never regretted buying
it.

I'll be happy to have my impressions corrected by people who know
better.

Arthur Lemmens



Mon, 01 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

| I've waited two days for people with more experience to shed some
| light here.  But, apparently, nobody is willing to burn his fingers
| on a comparison between Harlequin and Franz.

  that's because this is the kind of stuff lawsuits are made of.  you need
  a protective wrapper of serious legal quality to dive into this matter of
  comparing products in general.  not that I think Franz or Harlequin will
  sue anyone, but most professionals are aware of the problems of comparing
  products, and consequently avoid it, at least in public.

| So here's my (very personal and very subjective) impression, based on
| about 1000 hours of working with Harlequin's Lispworks, 50 hours of
| experiments with Franz' previous version (don't remember version number)
| for Windows and about 5 hours of playing with Franz' current version.
| All of this on Windows 95/98.

  although extremely important to inform your readers of (thanks), this
  makes your comparison "weak".  (I wouldn't be able to provide a stronger
  comparison, by the way.)

| * Price

  price comparisons are more dangerous than any other comparisons.

| * Conformance to standards.

  this comparison should be performed by someone very familiar with the
  standard and its semantics, because impressions of non-conformance may
  actually be within the bounds of conformance, and some non-conformances
  may be insignificant and easily fixed if the vendor is alerted to them.

| My impression is that both companies are pretty good at conforming to the
| ANSI spec, but that Harlequin takes it a bit more seriously than Franz.

  this is _very_ difficult to establish from watching the products, as it
  refers to intentions and future, not to the past.  it _is_ fair to say
  that Harlequin's LispWorks conforms better to the specification in some
  areas than Franz's Allegro CL does, but it has to be an area-by-area
  comparison to be fair, and the severity of the non-conformance is also
  important for a fair comparison.  e.g., _my_ impression is that Allegro
  CL has a weaker safe mode (not all errors signal errors as they should)
  than one could hope for, but this is not an area where I need it, so it
  may or may not matter to a particular programmer.  (incidentally, I know
  that Franz Inc _is_ taking conformance seriously and I'm working with
  them to help us all get there.)

| Harlequin seems to be much better at supporting Unicode and other
| character sets.

  although very valuable for a user, this is not about conformance to the
  ANSI Common Lisp standard.  it is therefore important to state what you
  expect from a product.

| Franz still seems to think that 256 characters is more than enough (just
| like Bill Gates thought that 640K is more than anyone would ever need).

  such parenthetical remarks, however, make your "comparison" nigh useless.

  incidentally, Franz Inc has an "international" (= Japanese) version that
  covers the need of most present non-Latin speakers.  (I have had to do a
  little home-brewing to get ISO 8859-1 working as I want it to in Allegro
  CL, but I don't know whether LispWorks is any better.)

| * Integration with underlying platform

  this is a valuable comment to a user.

| * Performance

  comparisons here are fraught with danger and should be performed with
  published code and all sorts of things.  e.g., some property that makes
  it feel "sluggish" could be extremely easy to fix, and other properties
  can be very hard to change because they are pandemic to the design.  I
  think performance comparisons are _generally_ unfair, because after you
  have decided on a product, you learn how to make it faster.

| I'll be happy to have my impressions corrected by people who know
| better.

  I don't want to snap at you, but it's a _lot_ safer to talk to the person
  requesting a comparison and let it be a personal exchange, rather than
  post impressions and request correction; it usually requires a huge
  effort to correct simple misimpressions.  this is why comparisons often
  produce a tremendous amount of noise on the newsgroups.  also, most user
  impressions are exceedingly hard to quantify, and a lot of factors come
  into play.

  incidentally, I haven't had the opportunity to compare Allegro CL with
  much anything else.  (I went from CMUCL 17f to Allegro CL 4.3 and it was
  a world of difference, so I don't even consider CMUCL possible to compare
  in the area I think matters the most: the development environment.)  I
  get the performance I need, and I get the support I need from Franz Inc
  whenever I wonder about something or find a problem, and I see no reason
  to go look for a competing product.  now, this is more an accident of
  history than anything else, so it does in no way preclude similar
  experiences with Harlequin -- it just didn't happen to me.  my guess is
  that this is how most user impressions are formed: luck and good timing.

#:Erik
--
environmentalists are much too concerned with planet earth.  their geocentric
attitude prevents them from seeing the greater picture -- lots of planets are
much worse off than earth is.



Mon, 01 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

> I've waited two days for people with more experience to shed some
> light here. But, apparently, nobody is willing to burn his fingers
> on a comparison between Harlequin and Franz. So here's my (very

OK. I've used both Allegro (up to 4.2) and Harlequin (upto 1995),
and I must say, FFI issues aside, that I would go with Allegro. I just
feel safer (some might argue that Harlequin's other businesses make it
safer,
but for me it gives a feeling (just an impression, but that's what marketing

is all about) of lack of commitment.
Maybe more importantly, I never `got' the Harlequin way. I'm not a fan
of IDEs. The primitive (but then, you have those cool menus) Xemacs
interface of
Allegro feels good. I've never used ACL for Windows but it looks pretty
neat,
so maybe it's just that I don't like _this_ Harlequin IDE.

I'd really like a Genera for SGI to play around. I have no use for it right
now, but I'd gladly pay my own $800 for the manuals (upgradeable to a
commercial license).

--
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

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html



Mon, 01 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

>   price comparisons are more dangerous than any other comparisons.

Would you care to explain?
I would think that price is just about the only thing you can
compare without the risk of giving "misimpressions".

Quote:
>   this comparison should be performed by someone very familiar with the
>   standard and its semantics
>   [...]
>   but it has to be an area-by-area comparison to be fair, and the
>   severity of the non-conformance is also important for a fair comparison.

I can't disagree with this, of course.
But I tried to make it clear that I was giving my personal impression
and not attempting to make a fair comparison. (I couldn't possibly find
the time for a fair comparison, but I didn't want to leave the original
question unanswered.)

Quote:
> | Franz still seems to think that 256 characters is more than enough (just
> | like Bill Gates thought that 640K is more than anyone would ever need).

>   such parenthetical remarks, however, make your "comparison" nigh useless.

Sorry, I shouldn't have said that.
This wasn't the right place to vent my frustration about the slow
acceptance of a decent international character set.

Quote:
>  (I have had to do a little home-brewing to get ISO 8859-1 working
>  as I want it to in Allegro CL, but I don't know whether LispWorks
>  is any better.)

I'm so glad that I only need to type
  (code-char #x41A)
to actually get a Russian K that I've forgiven Lispworks for
returning NIL when I ask
  (alpha-char-p *)

But it  _does_ know something about Latin 1:

CL-USER 17 > (code-char #xF0)
#\e

CL-USER 18 > (char-upcase *)
#\D

Quote:
>   it's a _lot_ safer to talk to the person requesting a comparison
>   and let it be a personal exchange, rather than post impressions
>   and request correction;

Thanks for the advice. I don't know if I will actually follow it,
though. Having a public discussion increases the chance that _I_ can
learn something as well. E.g., if I had sent my remarks privately,
I wouldn't have learnt from you that Franz has an international
version of Allegro CL.

Quote:
>  (I went from CMUCL 17f to Allegro CL 4.3 and it was a world of
>   difference, so I don't even consider CMUCL possible to compare
>   in the area I think matters the most: the development environment.)

Let's hope the CMUCL maintainers won't sue you for this remark ;-)

Arthur Lemmens



Mon, 01 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

| Would you care to explain?  I would think that price is just about the
| only thing you can  compare without the risk of giving "misimpressions".

  there are all sorts of pricing policies around, depending on who you are
  (student, commercial, educational), where you are (United States, Europe,
  Asia), how much you want to buy (trial, student, professional, enterprise
  edition), etc, etc.  it's actually difficult to compare the price that
  you would have to pay unless you're the person buying something and in
  position to weigh alternatives.  for instance, one might find that some
  add-on product is not worth the price from one vendor and roll your own,
  while from another vendor the price is acceptable.  the result may be
  that the former costs less from the vendor than the latter, but more
  after life-cycle costs for the new code are accounted for, but not with
  the initial prices, only.  stuff like this is why large companies have
  acquisitions departments who work like hell to get good package deals.

| But it  _does_ know something about Latin 1:
|
| CL-USER 17 > (code-char #xF0)
| #\e
|
| CL-USER 18 > (char-upcase *)
| #\D

  good.  Allegro CL does this correctly only with my personal fixes.
  (which, incidentally, supports the entire ISO 8859 family, one by one,
  once properly invoked.)

| E.g., if I had sent my remarks privately, I wouldn't have learnt from
| you that Franz has an international version of Allegro CL.

  valid point.  however, it would have been prudent to ask Franz Inc if you
  tried to write a fair comparison.

#:Erik
--
environmentalists are much too concerned with planet earth.  their geocentric
attitude prevents them from seeing the greater picture -- lots of planets are
much worse off than earth is.



Mon, 01 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

> Off-topic.

Yes.

Quote:
> By the way, I am not aware of another alphabet besides the
> contemporary Russian version of Cyrillics where the number
> of letters is a power of 2 (2^5).

[mumbling the alphabet]... hmm, last time I checked - it was 33. :-)

You probably forgot cyrillic-letter-io, which is rarely used in
printed Russian (mostly in texts for children and foreigners and in
ambiguous cases) and is substituted with cyrillic-letter-ie.  Still
it's part of the alphabet/orthography.

SY, Uwe
--

http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen



Tue, 02 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

> I'm so glad that I only need to type
>   (code-char #x41A)
> to actually get a Russian K

Vassil Nikolov replied:

Quote:
> Cyrillic K, please.  There are a number of nations besides the
> Russians, including Byelorussians, Macedonians, Serbs, Ukrainians,
> as well as Bulgarians, who use (different versions of) this alphabet.

Uhm, yes. Sorry. In my situation, (code-char #x41A) is usually a
Russian K. But next time I'll call it Cyrillic. I sometimes forget
I'm not the only Cyrillic speaking (;-) Lisp programmer on Usenet.

Quote:
> I am too lazy to look it up, but I believe the ISO 10646 name of
> this character is CYRILLIC CAPITAL LETTER KA or something.

I looked it up. You're right.

Quote:
> I'd rather have had the above as

>   (char-code (char-upcase (code-char #xF0)))

> instead of, or in addition to, the above, which makes little
> apparent sense on my Macintosh with a Cyrillic font selected.

Before sending, I verified that the content-type header included
"charset=iso8859-1" to increase the probability of readers seeing
what I meant.

Arthur Lemmens



Tue, 02 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

> >  (I have had to do a little home-brewing to get ISO 8859-1 working
> >  as I want it to in Allegro CL, but I don't know whether LispWorks
> >  is any better.)

LispWorks uses ISO 8859-1 for files by default. Currently users need
to do some configuration to use other encodings for files.

The internal encoding of LispWorks 4.x is Unicode. It has just one
executable.

Quote:
> I'm so glad that I only need to type
>   (code-char #x41A)
> to actually get a Russian K that I've forgiven Lispworks for
> returning NIL when I ask
>   (alpha-char-p *)

> But it  _does_ know something about Latin 1:

> CL-USER 17 > (code-char #xF0)
> #\e

> CL-USER 18 > (char-upcase *)
> #\D

Yes, in LispWorks we added the alphabetic property and case-pairs
(beyond those required by the ANSI standard) for Latin-1 only. I
should admit that this is rather half-baked, but allow me to
explain one of the technical problems...

Recall that BASE-STRINGs contain only BASE-CHARs. LispWorks provides
also a 16bit string type (TEXT-STRING) which can contain all of
Unicode.

There is a particular difficulty (for LispWorks at least) with U+00FF
LATIN SMALL LETTER Y DIARESIS which is a BASE-CHAR in LispWorks yet
its uppercase pair (as defined by Unicode) is an EXTENDED-CHAR. Thus
if we were to make these particular characters BOTH-CASE-P then
STRING-UPCASE etc. could not be relied upon to preserve string
types. That might be acceptable by the ANSI standard (though
potentially dangerous to users whose code used specialized accessors)
but the real killer was NSTRING-UPCASE.

I suppose we could have defined a larger set of alphabetic characters
without such problems, but we didn't. Sorry!

There was some attempt to define extended character case (and other)
functions in the JEIDA Common Lisp Guideline. I don't know if anyone
actually implemented that.

LispWorks users needing case converters beyond Latin-1 should exploit
the fact that the internal encoding is Unicode to write their own
functions using range checks.  

--

Harlequin Ltd, Barrington Hall,           Tel:   +44 1223 873879
Barrington, Cambridge CB2 5RG, England.   Fax:   +44 1223 873873
These opinions are not necessarily those of Harlequin.



Tue, 02 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

* David Fox
|
| There is a particular difficulty (for LispWorks at least) with
| U+00FF LATIN SMALL LETTER Y DIARESIS which is a BASE-CHAR in
| LispWorks yet its uppercase pair (as defined by Unicode) is an
| EXTENDED-CHAR.

This problem is solved in the recently-approved ISO 8859-15, so
providing that as an alternative to 8859-1 may make sense.

--Lars M.



Tue, 02 Oct 2001 03:00:00 GMT  
 Reviews for lisp implementations

Quote:

>Yes, in LispWorks we added the alphabetic property and case-pairs
>(beyond those required by the ANSI standard) for Latin-1 only. I
>should admit that this is rather half-baked, ...

If you need the case pairs for some other codepages,
you can grab those. It's not the full set but you get the idea.
I haven't found them on the net anywhere so I had to calculate them by
my own. I wrote it for AutoLISP, in CL you maybe could use vectors
instead.

I post this also (instead of linking to it) to let you see how weird
some codepages had been designed, considering case predicates and case
conversions. I guess most OS do it by precalculating the tables, wasting
a lot of bytes.

Note: the third element <islower> of each triple is the numeric
difference from the uppercase to the lowercase char.
so (65 90 32) means that there are 36 uppercase chars from 60 to 95
with the lower brothers 32 above (65+32 up to 90+32)

;;; Hardcoded charset capital letter ranges per codepage,
;;; kind of LC_CTYPE info. Format: list of: (<from> <to> <tolower>)
;;; Found the differences in toupper, tolower, isupper, islower
;;; by scanning the descriptive character names for upper and lower,
;;; unified the pairs into groups and came up with redefinitions
;;; of the upper/lower predicates and conversions.
(setq std:cp-cap-ascii     '((65 90 32)))       ; this is simple
                           ;; there's a hole at 215
(setq std:cp-cap-iso8859-1 '((65 90 32)(192 214 32)(216 223 32)))
(setq std:cp-cap-iso8859-2 '((65 90 32)(192 214 32)(216 223 32)
                             (161 161 16)(163 163 16)
                             (165 166 16)(169 172 16)(174 175 16)
                             ))
(setq std:cp-cap-iso8859-3 '((65 90 32)(192 214 32)(216 223 32)
                             (161 161 16)(166 166 16)
                             (169 172 16)(175 175 16)
                             ; 0xAE, 0xBE seem to missing
                             ))

;;; A really weird charset (by ibm), very old.
;;; thanksfully the system provided strcase should handle this most
;;; of the time (by static table loopkup)
(setq std:cp-cap-dos850    '((65 90 32)
        (128 128 7)(142 142 -10)(143 143 -9)(144 144 -14)
        (146 146 -1) (153 153 -5) (154 154 -25) (157 157 -2)
        (165 165 -1) (181 181 -21) (182 182 -51) (183 183 -50)
        (185 185 -5) (186 186 -7)
        (188 188 29) (199 199 -1) (209 209 -1)
        (210 212 -74)(214 214 -53) (215 215 -75) (216 216 -77)
        (222 222 -81)
        (224 224 -62) (226 226 -79) (227 227 -78) (229 229 -1)
        (231 231 1)
        (233 233 -70) (234 235 -84) (237 237 -1)))
(setq std:cp-cap-iso8859-4 '((65 90 32) (192 214 32)(216 222 32)
                        (152 152 71) (161 161 16)
                        (163 163 16) (165 166 16)
                        (169 172 16) (174 174 16) (189 189 2)
                        ;; not tested
                        ))
(setq std:cp-cap-koi-8r    '((65 90 32)
                             (179 179 -16)(224 255 -32)))
;; the weirdest charset ever (by microsoft), ignoring cp866,
;; iso-8859-5 and koi8-r
(setq std:cp-cap-cp1251    '((65 90 32)(192 223 32)
                             (128 128 16)(129 129 2)
                             (138 138 16)(140 143 16)
                             (161 161 1)(163 163 25)(165 165 15)
                             (168 168 16)(170 170 16)(175 175 16)
                             (178 178 1)(189 189 1)
                             ))
(setq std:cp-cap-dos866    '((65 90 32)
                             (128 144 32)(145 159 80)
                             (240 240 1)(242 242 1)
                             (244 244 1)(246 246 1)
                             ))

;; Beware: Dynamic Autolisp code, just to get the idea.
;; you really should store the pairs in bitfield for the
;; predicates and vectors for the converters.
(defun STD-ISUPPER (_i)
  (if (stringp _i)
    (setq _i (ascii _i)))
  (apply 'or
         (mapcar
           (function (lambda (l)
             (<= (car l) _i (cadr l))))
           std:actual-cp-cap)))

(defun STD-TOUPPER (i / cp x)
  (setq x (car (setq cp std:actual-cp-cap)))
  (while x
    (if (<= (+ (caddr x) (car x)) i (+ (caddr x) (cadr x)))
      (setq i (- i (caddr x))
            x nil)
      (setq cp (cdr cp) x (car cp))
    )
  )
  i
)

this is from http://xarch.tu-graz.ac.at/autocad/stdlib/STDLOCAL.LSP
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html



Tue, 02 Oct 2001 03:00:00 GMT  
 
 [ 40 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Reviews and pointers to reviews about implementation

2. Regular expression code implementation review between Tcl vs Python

3. Common Lisp is a dpANS in Public Review

4. X3 announces second public review for Common Lisp

5. Common Lisp public review deadline approaching

6. Common Lisp is a dpANS in Public Review

7. Please review proposed Common Lisp CORBA mapping...

8. Updated Macintosh Common Lisp review pointer

9. X3 announces second public review for Common Lisp

10. Common Lisp public review deadline approaching

11. Common Lisp is a dpANS in Public Review

12. Book review: "Lisp Style and Design"

 

 
Powered by phpBB® Forum Software