Re: compare function return values

[bear <bear@xxxxxxxxx>]

On Mon, 6 Jun 2005, Panu Kalliokoski wrote:

>On Sat, Jun 04, 2005 at 11:07:15AM -0700, bear wrote:

>> First, symbols, from an implementation POV, are a *lot* heavier
>> than small integer numbers.  There are table lookups to do, and
>> guarantees to make about symbols being eq? and hash functions to
>> call and store the result of, etc.  Depending on the implementation,

> I'm surprised to see so much misunderstanding about symbols in the
> Scheme community... since symbols are _atomic_, their comparison by eq?
> is a pointer comparison in all implementations I know of.  The only time
> one needs to find a symbol by its string representation is when it is
> being (read).  For builtin functions, all symbols are already in their
> "pointer" form, that is, they're already references to the Unique Symbol
> With That Name.

Yes, their comparison by eq? is a simple pointer compare.  That's not the
problem.  But producing them means going to the symbol table to see if
they already exist and returning an eq pointer to point at the existing
one if so, and allocating them and inserting a reference to them in the
global symbol table otherwise.  And at every GC, unless you simply don't
reap symbols, which a lot of implementations don't, you're iterating over
that table and eliminating symbols that are not currently bound to values
in any scope nor referenced from anywhere in the program, which is a
moderately expensive operation because it has to involve weak pointers.

Now, I'm talking about my own toy scheme system here; and this is a
good argument for creating a class of static symbols specifically for
function-return constants, that somehow shortcut the garbage collection
process.  So, yea, with a different implementation strategy most of the
costs I'm worried about could be avoided.

> Symbols that are used by builtins are statically allocated.  In an
> average implementation, this means an overhead of something like 8 bytes
> in addition to the storage usage of the string representation of the
> symbol.

Hooboy.  Is this an actual scheme implementation?  I haven't looked at
others, but I can't store the overhead involved with a symbol (scopes,
locations, lexical contours, contexts, variable values, weak references,
etc) in less than 64 bytes.  Am I just doing something horribly wrong?

> The great thing about symbols is exactly that they show that symbolic
> (descriptive) expressions _are_ as efficient to process as their
> non-expressive counterparts (like numeric tags).

Perhaps you can recommend a good book on handling symbols and
symbol tables in lispy languages?  'Cause clearly, I'm not currently
getting these benefits from symbols, and I'd like to know how.

> Now, I understand if people think that the long matured custom of
> mathematics to use (-1, 0, 1) is better.  But I think the original
> motivation for this codomain of signum was more likely the reluctance of
> adding new data types to mathematics than any real benefit these numbers
> convey.

>> Second, small integers are useful in indexing arrays, and indexing
>> arrays is a natural use of comparison results.  Indexing arrays with

> (Just to make sure: did you understand that preventing explicit indexing
> of arrays with comparison results was one of my original intentions in
> the proposal of using symbols?)

Sorry if you find this offensive, but I'd really rather not have
someone preventing me from doing something because without having
ever seen my problem or application, they've decided ex cathedra
that it's always and forever a bad idea.  The point of a good
programming language is to make good code possible and natural.
Preventing something you think is "bad code" contributes nothing
to this goal. Don't make the bad stuff harder; make the good stuff
easier.  If people want to index arrays with comparison results,
and you think this is bad code because it blurs the semantics of
comparison results, it's incumbent on you to provide a way to do
it that doesn't blur the semantics of comparison results, rather
than to put comparison results in a form that doesn't allow it.

I agree that the numbers don't express the values you actually mean
here, and I dislike that semantic untidiness.  To say "-1" when I
mean "increasing" is as irritating as saying "27" when I mean "escape"
or 'a' when I mean "43" or "0" when I mean "false."  The only reason
to put up with this semantic blurring, IMO, is because you can use
numbers to index arrays or in further computations, and because doing
so is the most straightforward and useful way to use those results.

You're addressing the problem of further computation by providing
additional functions to do most of the things that can be done with
the numeric representations.  I don't know why you've skipped
such functions for array creation and reference; they are just as
important a part of the functionality as what you've provided.

Honestly, I think the "right thing to do" here is to provide arrays
with typed indices, so they can be indexed by *any* scalar without
semantic blurring.  That would solve both this problem and many
others, including indexing by characters and booleans. But this is
a larger issue, and not properly within the scope of your proposal.

>> Third, the limitation of array indexes to exact nonnegative integers
>> only, and the requirement of starting at zero, is a problem that ought
>> to be addressed first.  If arrays could be indexed by an arbitrary

> Aiee!  Maybe.  But I never found Scheme the language to do "nifty
> tricks" in, like indexing arrays with comparison results.  I think
> Scheme should remain simple, clean, powerful (in terms of tools it
> provides, not weird expressions it enables the programmer to use), and
> elegant.

This isn't a "trick."  It's an "idiom," and a damned useful one.  If
you disallow it or make it hard, without providing an equivalent that's
as easy to use, you are making things worse, not better.

				Bear