This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.
On Mon, Jun 06, 2005 at 03:55:36PM -0700, bear wrote:
> > I'm surprised to see so much misunderstanding about symbols in the
> > Scheme community... since symbols are _atomic_, their comparison by eq?
(By the way, I'm sorry if I sounded disdainful or something...)
> 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
Yes, but they are "produced" when the code is (read), not when it is run
/ (eval)'d. Your point about GC is valid, though -- it requires some
care to handle "static" symbols specifically. Similar considerations
apply to nil, #t, #f of course.
> > 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
Of course, there's no upper limit on implementation-specific stuff you
can put into your symbol structure; symbols are unique, so this does not
incur much overhead. But for example in tinyscheme, symbols take 8
bytes (plus the string).
> 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?
Probably not, but I don't have the foggiest idea what those things do in
the _symbol_. This is probably not the right place to discuss that,
though.
> > (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
You don't sound offensive, but I think that's what Scheme is like. For
example, destructive operations like (set!) could have their values
defined, but they do not, partly because of backward compatibility, but
mostly because there is a tendency to discourage code that mixes
side-effects with functional style.
I challenge you to produce an example case where comparison return
values make a useful and clean idiom when used as indices.
> 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
Good that we soon hopefully have hash tables :)
> 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.
(if3)?
On Mon, Jun 06, 2005 at 04:59:37PM -0700, Per Bothner wrote:
> >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.
>
> Well, using {-1, 0, 1} is fairly conventional in other languages
> (including C, C++, and Java), and there is the mathematical signum
> function. There is something to be said for stick with what works.
> Plus using a symbol is awkward because it is hard to avoid it
> being human-langauge-specific - unless you use '<, '=, and '> I guess.
>
> Let's stick with {-1, 0, 1}.
I have two objections to the rationale presented here:
(1) in C, C++, and Java, the reason {-1, 0, 1} is used might well be the
lack of the symbol type (or any real enumeration type at all). Or it
might be an adoption of the mathematical custom. In mathematics, the
reason for {-1, 0, 1} might also be the lack of a symbol type.
(2) do you realise that an expression like (compare a b) is
human-language-specific? More specifically, it includes an English
verb.
Panu
--
personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369
work contact: pkalliok@xxxxxxxxxxxxxxxx, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/