Subject: Re: Back to character set implementation thinking From: Erik Naggum <erik@naggum.net> Date: Mon, 01 Apr 2002 11:11:04 GMT Newsgroups: comp.lang.lisp Message-ID: <3226648279194697@naggum.net> * Brian Spilsbury | It's possible, but you have provided no reasoning or references. I generally do not consider it my job to unconfuse peoplw who make claims that something untrue is true. In fact, I take part in a discussion with the premise that those I talk to have done their own homework. If they have not and are not inclined to do it upon request, there can be no discussion. | The definition of an array is such that you could implement an array | via a hash-bucket which accepted only integers in the specified range. > Random access _means_ O(1). | No, random access means that the interface allows access to elements in a | random order. OK, so our terminology problem has just been compounded with stubbornness. | This does not necessarily imply an O(1) access characteristic, although | this might be commonly expected. If an implementation offers arrays that have anything other than O(1) access characteristics, it will be so resoundingly trashed that even inventing such silly interpretations indicates that you come here to quibble, not understand anything. | What is ad-hoc is that loop is a nice baroque flow-control language which | happens to have some support for iterating sequences in certain | circumstances. (incf *troll-indicator*) > Well, we just appear to have different tolerance of necessities | This depends on how easily annoyed you are. Really? > An example of a stateful encoding with an annoyingly large amount of > state would be useful so I know where the amount becomes annoyingly > large. | The example of the SCS encoding is one that I would consider to have a | relatively large amount of state carried between elements. SCS is nice and small by all standards. | I can imagine some cases in which it would be desirable to sacrifice | speed for reduced consing, although they would be unusual. Huh? Why would anyone sacrifice speed for reduced consing? Are you sure you know what you are talking about here? Do you think using more memory leads to _slower_ code? It is usually the opposite that is true. | Yes, that is what I'm advocating. So you are just agreeing with me by arguing against what I suggest? | > | I think that a lot of state is the exception rather than the rule. | > | > You are actually wrong about this. [] | | I may be wrong about this, but you would need to provide statistics to | demonstrate that a lot of state is the rule rather than the exception. How about you cough up some statistics to support your own claim!? (incf *troll-indicator*) | > | I also think that as shown above, we can externalise that state into | > | points, at an acceptable cost for reasonable encodings. | > | > I truly wonder how you could have thought that anyone would want to | > store the iteration state in the object iterated over. [] | | Probably because of a reference to Emacs and mark/point. OK, I see that this simile/analogy/metaphor thing is too complex for communication with you. I shall adjust accordingly. | I'm not sure how display control sequences and MIME processing relate | to string encoding. Just think about it. This kind of statefulness is also found in input editing, which may occur at different times. But I think you are a literate troll, and will probably not respond if you do not do any work on your own and only demand work of others when they doubt your statements. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.