From: Michael Lenaghan <[email protected]> Subject: Re: [r6rs-discuss] What's under the hood? Date: Thu, 24 Sep 2009 09:52:20 -0400
> >> (define-vector-type <name> <type>) > > > > Could you specify a bit more about what information <type> > > should carry? > > > > I suspect that, to give enough information to allow "a smart > > compiler" to work with this definition, you need a structured > > way to define and construct types, including specifying allowed > > value ranges and possible coercion rules. > > It is interesting path to go, but I think resulting language > > would be much more type-centric than existing Scheme. > First, let's imagine that each type has a "container?" predicate; if > "container?" returns #t then the garbage collector has to walk > instances of the type and if it returns #f it doesn't. Right off the > bat the vector type inherits the same predicate--the same value. An > implementation can use that information to make memory management > and/or garbage collection much more efficient. For programs that deal > with, say, large vectors of numbers that would seem to be an easy and > very important win. > > Second, let's say that each type knows whether or not the value can be > unboxed to a native representation. The interface might be > "unboxable?", "unbox", "box", "make-unboxed-vector", "unboxed-length", > "unboxed-ref", "unboxed-set!". Then if "unboxable?" is true: > > (make-<type>-vector n): (make-unboxed-vector <unboxed-type> n) > (<type>-length v): (unboxed-length v) > (<type>-ref v i): (box (unboxed-ref v i)) > (<type>-set! v i x): (unboxed-set! v i (unbox x)) (I assume unboxed-length, box, unbox, etc are generic function that dispatch by the argument type. I also asuume that the returned value of 'unboxed-ref' and 'unbox' are, by definition, some kind of unboxed value that is only allowed in arguments of specific functions such as 'box' and 'unboxed-set!', right?) This is what I tried to mean by "type-centric"; specification of behavior is largely described as an attribute of types, rather than a bundle of functions that work on the types. Note that either one is no more better than the other. The latter way tend to duplicate similar functions, as you see in srfi-4, which is nuisance. However, with the former way you still have to specify lots of things per each type, and to set the appropriate level of detail as a language specification doesn't seem trivial---you can be easily overspecified or underspecified. It is OK for each *implemenation* to take this approach; they know exactly how much details should be specified. But as a language *specification* you want to leave room for implementations to wiggle with. I strongly suspect that if you complete this approach the specification ends up no simpler than the current approach of Scheme. This is my hunch (but I did implement part of my implementation using this type of abstraction, so it's not completely ouf of air). If you argue otherwise, I'd like to see more concrete details. > > Besides, the similarity of strings and vectors are superficial; > > both are fixed length and has -ref and -set! in RnRS, but > > the usage pattern and the nature of their elements are very > > different, so their implementations tend to differ a lot. > > How do you express those difference in define-vector-type? > > If you don't, then again, define-vector-type is useless > > for any implementation that wants to be a bit smarter than > > naive implementation where it just uses a ucs4 array as a string. > > I think the opposite is true. If the compiler knows that it can use a > more efficient representation and implementation for "vectors of char" > then define-vector-type allows it to do so. Indeed, that's the very > point of the abstraction! > > But perhaps you meant something else? Imagine you specify whole bunch of <char>-type specification in order to define <string> as a vector of <char>. An implementation that uses utf8 string won't use that information *at all*. It will look at the higher-level API such as string-ref and implement its semantics, and do not care whether char is unboxale or not. Then what's the point to have <char>-type specificaion in the standard? Here I think the type-centric approach got overspecified. --shiro _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
