On Tue, May 11, 2004 at 10:49:46AM -0400, Judson, Ross wrote:
> Hi Scott...I see that in the SISC trunk you've got some neat new stuff
> for doing optimizations on expressions that don't require further
> function calls or evaluation.
>
> It's been a hell of a busy month (for both of us, I suspect). You
> mentioned that you were going to think over the vector-based stuff in
> the email below...had any time to think it over? It's probably just
> lost in the shuffle... :)
Yeah, I did get busy and then forgot about it. Sorry.
>
> Recent discussion on the scheme newsgroup has mentioned declaring types
> as a possible extension to scheme. I don't particularly like that; I'd
> rather see Scheme move in the direction of type inferencing. With a
> fast type-capable dispatch mechanism, it's possible (defining the +
> function to operate on various forms of arguments). With type
> inferencing we can defer type-based dispatch to the last possible
> moment. I think the combination of a dynamic environment and type
> inferencing can potentially be extremely interesting. In Java, we can
> write very fast primitives that can do things like add two double
> vectors; if the interpreter can rapidly select between type-specific
> primitives, we are in a good spot.
Well, the discussion around Scheme and types is rooted in the desire to
correct the lack of user defined ones as a shortcoming of the language.
Dispatch based on those types is the next step, but probably won't
become part of the Scheme standard. We already have the capability to
dispatch on operators based on type in SISC's generic function library.
It obviously needs some improvement in the performance department to be
suitable for more general programming frameworks such as what you
describe, but the basis is there.
I don't necessarily like the idea of extending type based dispatch
pervasively, as it makes it more difficult to reason about programs and
increases the complexity overall. On the other hand, as has been done
with the type and object system already in SISC, it would be really cool
to see a fairly seemless library implementation of those ideas. Part of
the non-technical problem is to allow SISC to be useful to all sorts of
people, from the more Scheme purists to the ML folks yearning for
stronger typing.
Scott
PS. Some quick comments where I didn't have to delve in too deeply.
>
> A quick example: When we add two numbers (+ 2 4) we get a result, 6. We
> can form a vector like this: '#(1 2 3), but we can't do this (+ 2 '#(1 2
> 3)). If Scheme had vector processing capability, the answer would be
> #3(3 4 5). Similarly, if we do (+ '#(1 2 3) '#(4 5 6)) the answer would
> be #3(5 7 9).
You can pull this off already:
(import generic-procedures)
(import type-system)
(define native-+ +)
(define-generic +)
; This can be done even more easily with SRFI-45
(define-method (+ (<number> scalar) (<vector> vector))
(do ([i 0 (+ i 1)]
[ov (make-vector (vector-length vector))])
((>= i (vector-length vector)) ov)
(vector-set! ov i (+ scalar (vector-ref vector i)))))
(define-method (+ . others)
(apply native-+ others))
>
> Switching to K for a second, we can do this: (1;2;3)+(4;5;6), which
> results in 5 7 9. K has _adverbs_, which modify what the base verbs (in
> our case +), do. So in K we can also write (1;2;3) +\: (4;5;6), which
> modifies + with "each-left", and results in: (5 6 7 6 7 8 7 8 9)
>
> The \: following the + symbol is the EACHLEFT adverb; it tells K to call
> the + function with each member of the left operand and the entire right
> operand.
This seems to be essentially a syntactic definition. K is using
abbreviated syntax (much like perl) where Scheme prefers verbosity. I
would translate the above as you do, roughly into:
(each-left + '#(1 2 3) '#(4 5 6))
I think the interesting endeavour would be to define a library of the
adverbs from K, and a set of generic procedures to bring most of the
power over to Scheme while retaining a more schemely interface.
> It become more difficult when we want to give a programmer the ability
> to write vector-capable functions. We can clearly write functions that
> check types at runtime with is-vector-XXX?. This is what the primitives
> do on the inside; they check the types of their arguments and select an
> appropriate method of calculation. There's clearly some crossover with
> generic procedures, though. If we wanted to code our own + procedure,
> we might want a syntax that would allow us to declare various forms of
> it (+ int double) (+ float float), and have the "right" one called.
This is where there is some disconnect, as our types currently are
fairly coarse in the numerics department. Thats largely because Scheme
doesn't concern itself with the low level representation of numbers, but
rather leaves it to the implementation. Behind the scenes we do that
sort of thing for efficiency. I'm not sure how useful more granularity
would be.
>
> If is-a tests can be made very efficiently, generic procedures might not
> be necessary. The K system gains its speed by handling as atomic vector
> operations many computations that would require extensive iteration in
> other languages.
I would also point out that if raw speed is the concern, then SISC
probably isn't the best platform for a production system of this sort.
Scott
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
|
