Bryan C. Warnock wrote:
> I use direct, raw access in prototyping when dipping back into C for
> "heavy" data manipulations - bit stream analysis, signals processing, etc.
> Since I'm usually doing a lot of buffer manipulations, I don't want all
> the scalar overhead that comes into play.
> > >My reason for asking is that the more of the perl core that relies on
> > >specific representations of data, the more complexity there is in porting to
> > >other architectures.
> >
> > Fair enough. It may turn out to be unnecessary, in which case we'll toss
> > it, or if not we'll just make sure to force some reasonable requirements on
> > it so porting's easier.
> I think, through line disciplines or string tags or what-have-you, that
> some data should be allowed to be tagged as raw - perhaps to prevent any
> automatic promotion, for instance - but actually needing that raw data
> underneath is rather incestuous. If something relies on that data so
> much, it knows where to find it.
I agree! I see nothing wrong with programmers who understand a bit about
perl6guts using the raw data in any way they see fit for the task at hand
(as Bryan does). After all, we want to make the impossible jobs, possible.
:)
However, if someone was using the raw data in this fashion, they shouldn't
(at least, I hope they wouldn't ;) expect for something like the JVM port to
support what they are doing out of the box. My concern is just that _other
parts of the core_ treat these vtable interfaces as a firewall, and do not
"reach in" past them.
If we find out they have to "reach in" later for performance, I see no
problem with that. I just don't want the design to depend on "reaching in".
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
