[plt-scheme] Tagging primitive types?

From: Erich Rast (erich at snafu.de)
Date: Thu Dec 1 15:00:16 EST 2005

> I don't understand why you need this.  This is such a special-case
> solution - limited in both power and scope - and you can solve it so
> easily by doing
> (define a VALUE)
> (define a-tags TAGS)
> that I don't understand why you need to build this "automatic
> association".

Well, after some thinking about it I completely agree with you. I don't 
really need this any longer.

My original motivation was this: I'm dealing with lots of labelled 
values---numbers, lists, and symbols. Now most of the code just does 
the usual stuff with those values without considering any labels. For 
example, map, append, car, cdr, maptree, etc. applied to a nested list 
that has a label and whose elements might also have labels. Most of the 
time, labels are only needed for some side effects, like displaying 
them. So my idea was that I would like to use existing functions 
without having to define tagged-map, tagged-append, tagged-car, 
tagged-cdr, tagged-maptree, and so on for everything that has ever been 
implemented for primitive datatypes.

So I could for example write

(map (lambda (x) (+ x 1)) a)

and get [TAG1 TAG2 TAG3]__(2 3 4) as result if the value of a was the 
list (1 2 3) and its tags were [TAG1 TAG2 TAG3], or I could write 
(define b 20) ... (tag b 'hello-world) ... (/ b 10) ==> 
[hello-world]__2, i.e. the tagged number 2.

The problem and conceptual flaw of this weird idea is that there 
doesn't seem to be any sensible and generic way in which tagged and 
untagged values ought to be combined when something is done with them, 
how tags should be "inherited" or combined during computation, and 
furthermore, that in order for this to make sense a tag would have to 
be somehow magically attached to expressions, as in (/ (tag 10 'hi) 2) 
==> [hi]__5. I can't see how this would work. So I guess it was a 
rather bad idea...

Best regards,


Posted on the users mailing list.