[plt-scheme] More PLT Scheme as an Alternative to Matlab

My philosophy at the moment is to provide the semantics we want to the user
- for example, logical immutability, if that's what we want. So a user
facing view with a reference implementation (that is useful) for the moment.
Then, we'll work with the compile guys with a view towards efficiency. If
the immutability is what we think will get us to that ultimate goal, then
that's what the user view should encompass.

There are other places (for example my inference collection rewrite) where
I'm focusing on immutability with the hope of getting multicore benefits
some time in the future.

Doug

On Fri, Aug 14, 2009 at 7:32 AM, Noel Welsh <noelwelsh at gmail.com> wrote:

> Certainly there has to be mutation at some level. Immutability at the
> user's level means no arrays can alias. Given this a compiler can
> reorder array traversals to take advantage of the cache and multiple
> cores. This is, AFAIK, the key to high performance on modern machines,
> and the key optimisation SAC does on its comprehensions. OTOH it does
> require quite some compiler machinery to exploit.
>
> N.
>
> On Fri, Aug 14, 2009 at 1:54 PM, Doug
> Williams<m.douglas.williams at gmail.com> wrote:
> > You give me more credit for forward thinking than I deserve. I was
> planning
> > on having array-set!. I'm not sure how to avoid it at the primitive level
> -
> > I just won't have enough information at the time I create the underlying
> > vectors to make them immutable (and there are no immutable SRFI vectors
> that
> > I'm aware of). Of course, that doesn't mean I have to expose the
> underlying
> > vectors or array-set! in the interface. That would make them logically
> > immutable, but not in a manner than helps the GC system, for example.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090814/9187bbd4/attachment.html>