[EMAIL PROTECTED] (Simon Cozens) writes:
> =head2 C
>
> This field is, as its name suggests, unused; however, it can be used to
> hold a pointer to the correct vtable for foreign strings.
Wouldn't it be better to put a vtable * directly inside struct
parrot_string instead of the 'encoding' enum
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
> But "platform build tool" is going to be 'make' - the alternative is
> that we maintain and ship every flavou
If you think the ideas expressed in my previous post are sensible, I
can go through my "MakeMake" and put together a design document, about
what to seek and what to avoid, as far as I can tell.
Additional issues (not mentioned in my post) would be:
* usage of the front-end
* dire
[EMAIL PROTECTED] (B Vlad) writes:
> ps. have to figure how to get the WinCVS thing work...
> can't seem to be able to access cvs.perl.org. I've used
> the following set up:
>
> CVSROOT = :pserver:[EMAIL PROTECTED]:/home/perlcvs
> Authentication = passwd file on the remote host.
>
> any suggest
Filipe Brandenburger wrote:
[...]
> struct sv {
> vtable_sv * ptr_to_vtable;
> void * ptr_to_data;
> void * gc_data;
> };
[...]
> I don't think I can get further from here. Note that, in all examples,
> I didn't write the `this' pointer that every funct
Matthew Cline wrote:
>
> We might want to have a member/method by which we can tell what type of
> variable we're dealing with, so that a function can be passed an arbitrary
> XV, and treat it differently if it's an SV, AV, and so on.
>
> For SVs, we might want to have a method to determine what
Might this be madness? (BRAINSTORMS AHEAD!):
The API of the Perl data types could be specified
in the following way:
*) a class hierarchy (hopefully not a deep one).
eg.
AnyV (XV?)
|
-
| | | |
SV
Dan Sugalski wrote:
>
> At 05:02 PM 2/3/2001 +0100, Edwin Steiner wrote:
> >Might this be madness? (BRAINSTORMS AHEAD!):
>
> Generally, yes. :)
>
> The vtable stuff won't be exposed outside the core. This means embedding
> programs and extensions will *not*
Branden wrote:
[...]
>
> I also don't see how it wouldn't bang badly if we get an incorrect PMC. How
> would we extract the 5th element of a scalar? And how would we read one line
> out of an array? Sum two hashes? I think having only one vtable for all
> would only put a burden on who implements
Branden wrote:
>
> Edwin Steiner wrote:
> > Branden wrote:
> > [...]
> > >
> > > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
> How
> > > would we extract the 5th element of a scalar? And how would we read
Branden wrote:
[...]
> Edwin Steiner wrote:
[...]
> > Different pointer types also make coding harder when there is no
> > need to make a difference between object types. (When you just pass
> > something on, for example.)
> >
>
> I actually see it as strong t
Dan Sugalski wrote:
[snip]
> That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> the martian death flu, along with too much blood in my caffeine stream) The
> example
>
> $foo{bar} = $baz + $xyzzy[42];
>
> turns into
>
>baz->vtable->add[NATIVE](foo, baz, xyzzy, key)
Edwin Steiner wrote:
>
> Dan Sugalski wrote:
> [snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> >
Dan Sugalski wrote:
> At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > >Please see my previous post on the subject. As I pointed there,
> > implementing
> > > >|| and && like that breaks short-circuits.
> > >
> > > No, it doesn't. Just because you pass in two PMCs doesn't mean that they
>
Dan Sugalski wrote:
>
> At 11:57 AM 2/8/2001 +0100, Edwin Steiner wrote:
> >Dan Sugalski wrote:
> > > At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > > > >Please see my previous post on the subject. As I pointed there,
> > > > imple
15 matches
Mail list logo
