Subject: Re: Problems with EQUALP hash tables and Arrays
From: Erik Naggum <erik@naggum.no>
Date: 1999/05/29
Newsgroups: comp.lang.lisp
Message-ID: <3136956702725490@naggum.no>

* Lieven Marchand <mal@bewoner.dma.be>
| I think it would make more sense for the standard to demand of
| implementors to document the expected performance of their implementation.

* Erik Naggum <erik@naggum.no>
| this would mean that no implementation would ever be conforming to the
| standard, and reasonable people would shrug off that requirement, because
| it is actually an unreasonable thing to request people to do.

* Lieven Marchand <mal@bewoner.dma.be>
| Why?  It seems more reasonable than demanding a certain performance
| requirement.

  I have tried, but I do not understand what you are trying to say.  are
  people "demanding a certain performance requirement" (whatever this
  means) today?  or is it an example of something much less reasonable than
  your already unreasonable request that you are kindly offering us because
  you actually have the much more unreasonable request in mind?

  in case you missed my point entirely, language standards are not the
  place to require performance statistics from implementations.  it doesn't
  matter how much you think you need it or how useful you think it might
  be.  it's incredibly stupid to put such requirements in a standard.  

| Personally, I have nothing against commercial vendors but this issue
| seems orthogonal to the discussion.  Besides, it would make sense for the
| vendors to document things like that when it gets asked frequently.  That
| is why a lot of vendors put (a sanitized version of) their support
| knowledge base online.

  and what?  are you unhappy with the current support offerings?  it looks
  like you don't have anything actually constructive in mind.

| I think I do understand.

  you wrote:

||... but since the implementation is not required to support objects or
||arrays above a certain size any vendor can claim O(1) performance of
||everything by choosing a suitably large constant.

  and this indicates that you have very little understanding of what the
  big-O notation is supposed to express and use it in a very sloppy fashion
  that I would expect from newspaper hacks.  I certainly do not expect any
  vendor to be equally devoid of understanding or willing to compromise his
  credibility with users who actually knows what you suggest they say means.

| That's why I don't think such requirements are useful in a standard.

  so the standard should not include them, but you think it's smart to
  demand such data of every conforming implementations, even though you
  think that by jacking up the constant, you can get away with grossly
  misleading numbers?

  but never mind -- programmers who can't write stuff they need on their
  own should be doing something else entirely.

#:Erik
-- 
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century