Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:05 PM 12/12/00 +, David Mitchell wrote:
> >Also, some of the standard perumations would also need to do some
> >re-invoking, eg
> >($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would
> >just fall
> >through to Num->sub[INT](
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I was under the impression that ANSI C required that a void * be large
> enough to store any pointer type in it. Whether that's true or not's
> irrelevant at the moment, though we can work something out at some poi
At 02:36 PM 12/13/00 +, Nicholas Clark wrote:
>Ah. Digest system tells me some messages for me bounced.
>
> > From: Damien Neil <[EMAIL PROTECTED]>
> > On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
> > >int perl6_parse(PerlInterp *interp,
> > >void *sour
At 06:05 PM 12/12/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following external types: byte (
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> That is a Language and not an internals issue - Larry will tell us.
> But I suspect the answer is that it should "work" without any special
> stuff for simple perl5-ish types - because you need to be able to
> translate 98% of 98% of perl5 programs.
On Thu, Nov 30, 2000 at 06:43:35PM +, David Mitchell wrote:
> * do values ever get demoted - eg an expression inolving bigints that evaluates
> to 0: should this be returned as an int or a bigint?
[I may have mailed this already]
Experimentation on perl5 says yes.
Making the sv_setuv actuall
Ah. Digest system tells me some messages for me bounced.
> From: Damien Neil <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: The external interface for the parser piece
> Message-ID: <[EMAIL PROTECTED]>
> Mime-Version: 1.0
> Content-Type: text/plain; cha
On Tue, Dec 12, 2000 at 06:05:30PM +, David Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following externa
David Mitchell <[EMAIL PROTECTED]> writes:
>
>I think this this boils down to 2 important questions, and I'd be interested in
>hearing people's opinions of them.
>
>1. Does the Perl 6 language require some explicit syntax and/or semnatics to
>handle multiple and user-defined numeric types?
>Eg "my
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > If we assume that ints and nums are perl builtins, and that some people
> > have implemented the following external types: byte (eg as implemented
> > as a specialised array type), bigre
On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> If we assume that ints and nums are perl builtins, and that some people
> have implemented the following external types: byte (eg as implemented
> as a specialised array type), bigreal, complex, bigcomplex, bigrat,
> quaternian; the
On Thu, 07 Dec 2000, Dan Sugalski <[EMAIL PROTECTED]> mused:
> >My original suggestion was that scalar types provide a method that says
> >how 'big' it is (so complex > bigreal > real > int etc),
> >and pp_add(), pp_sub() etc use these values to call the method associated
> >with the biggest oper
At 02:01 PM 12/7/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > > All the math is easy if the scalars are of known types. Addition and
> > > > mul
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > > All the math is easy if the scalars are of known types. Addition and
> > > multiplication are easy if only one of the scalars involved i
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > All the math is easy if the scalars are of known types. Addition and
> > multiplication are easy if only one of the scalars involved is of known
> > type. Math with both of unknown type
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Is all that really necessary? Why not a non-vtbl function that knows how
>> to add numeric types?
DS> Which numeric types? Int? BigInt? Num? BigNum? Complex numbers? One of the
DS> reasons to go with the vtable stuff is to allow for smal
At 11:24 AM 12/1/00 +, David Mitchell wrote:
>and Buddha Buck <[EMAIL PROTECTED]> wrote:
>
> > I seem to remember a suggestion made a long time ago that would have the
> > vtable include methods to convert to the "standard types", so that if the
> > calls were b->vtable->add(b,a) (and both ope
At 03:02 PM 11/30/00 -0500, Buddha Buck wrote:
>At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>>> > (Moved over to -internals, since it's not really a parser API thing)
>>> >
>>
At 04:05 PM 11/30/00 -0500, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> The "add" op would, in C code, do something like:
> >>
> >> void add() {
> >> P6Scaler *addend;
> >> P6Scaler *adder;
> >>
> >> addend = pop(); adder = pop();
> >> push addend->vtable-
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I would have wanted to limit the vtbl to self manipulation functions.
> Set, get, convert, etc. Cross object operations would/should be
> outside the realm of the object. (It seems like trying to lift yourself
> by the bootstraps.)
There is a certainly
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> The "add" op would, in C code, do something like:
>>
>> void add() {
>> P6Scaler *addend;
>> P6Scaler *adder;
>>
>> addend = pop(); adder = pop();
>> push addend->vtable->add(addend, adder);
>> }
>>
>> it would be up to the addend->vta
At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>> > (Moved over to -internals, since it's not really a parser API thing)
>> >
>> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wro
At 01:51 PM 11/30/00 -0500, Buddha Buck wrote:
>At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>
>(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>
>>$a=1; $b =3; $c = $a + $b
>>
>>
>> > If they don't exist already, th
At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> > (Moved over to -internals, since it's not really a parser API thing)
> >
> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >Presumably. But why are you then still talkin
At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>$a=1; $b =3; $c = $a + $b
>
>
> > If they don't exist already, then something like:
> >
> > newscalar a, n
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> It looks to me like add needs to be polymorphic and work out the best
> compromise for the type of scalar to create based on the integer/num/
> complex/oddball types of its two operands.
>
> [Oh. but I'm blinkered in this because I'm attempting to make
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On a related note: a wrapper not completely unlike
JH> union sv_any_aligned_s {
JH> IV iv;
JH> NV iv;
JH> PV pv;
JH> void *vp;
JH> int (*dummy)(void) *fp;
JH> /* any others? */
JH> };
JH> should be used aroun
On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> (Moved over to -internals, since it's not really a parser API thing)
>
> At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >Presumably. But why are you then still talking about "the IV slot in
> >a scalar"...? I'm slow today.
(Moved over to -internals, since it's not really a parser API thing)
At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>Presumably. But why are you then still talking about "the IV slot in
>a scalar"...? I'm slow today. Show me how
>
> $a = 1.2; $b = 3; $c = $a + $b;
>
>is going to
On Thu, Nov 30, 2000 at 04:15:24PM +, Nick Ing-Simmons wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> >
> >We're trying to make this an easy embedding API.
>
> Yes, and we are in danger of "premature optimization" of the _interface_.
Amen.
Tim.
> > > Huh? You're not talking about using this union around, say, the IV slot in
> > > a scalar, I hope...
> >
> >You hope in vain :-) If we still want to in perl6 to do (disgusting)
> >things like (we do in perl5)
> >
> > - "intercast" pointers and integers
> > - "intercast" integ
At 10:54 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> > At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > > On a related note: a wrapper not completely u
On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > On a related note: a wrapper not completely unlike
> > >
> > > union sv_any_aligned_s {
> > > IV iv
At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > On a related note: a wrapper not completely unlike
> >
> > union sv_any_aligned_s {
> > IV iv;
> > NV iv;
> > PV pv;
> > void *vp;
> > int (*du
On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> On a related note: a wrapper not completely unlike
>
> union sv_any_aligned_s {
> IV iv;
> NV iv;
> PV pv;
> void *vp;
> int (*dummy)(void) *fp;
> /* any others? */
> };
>
> should be used ar
Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>We're trying to make this an easy embedding API.
Yes, and we are in danger of "premature optimization" of the _interface_.
What we need to start with is a list of "what we need to know" - they may
as well be separate parameters at this point - the
Nicholas Clark <[EMAIL PROTECTED]> writes:
>> Counted strings should probably just have either a platform-native int in
>> front, or a 32-bit int in network format, both of which should be doable on
>> any platform that perl deals with.
>
>I agree it's do-able.
>What seems to me a good idea not
On a related note: a wrapper not completely unlike
union sv_any_aligned_s {
IV iv;
NV iv;
PV pv;
void *vp;
int (*dummy)(void) *fp;
/* any others? */
};
should be used around SVs to ascertain that everything fits everywhere.
--
$jhi++; # http://ww
On Tue, Nov 28, 2000 at 04:47:42PM -0500, Dan Sugalski wrote:
> At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
Not sure:
Dan:
> is treated as if it points to a stream of bytes, where the first four are
> the length o
At 07:29 AM 11/30/00 -0800, Dave Storrs wrote:
>On Wed, 29 Nov 2000, Dan Sugalski wrote:
>
> > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> > >I have a feeling this is a stupid question, but I have to ask anyway.
> > >
> > >Do we really need to pass in a PerlInterp pointer? Or can perl6_par
On Wed, 29 Nov 2000, Dan Sugalski wrote:
> At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> >I have a feeling this is a stupid question, but I have to ask anyway.
> >
> >Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
> >just create one for itself if/when it needs one? I
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Count me in with the people who prefer:
int perl6_parse(PerlInterp *interp, Perl
At 02:49 PM 11/29/00 +, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski wrote:
> > At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> > >FILE * is not a good idea. PerlIO * is fine.
> >
> > The problem with that is we're potentially getting the filehandle fro
On Wed, Nov 29, 2000 at 09:51:07AM -0800, Dave Storrs wrote:
> I have a feeling this is a stupid question, but I have to ask anyway.
> Do we really need to pass in a PerlInterp pointer?
Yes. Threads. There's a reason for all the PERL_EXPLICIT_CONTEXT anxiety.
--
Old Japanese proverb:
T
At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
>I have a feeling this is a stupid question, but I have to ask anyway.
>
>Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
>just create one for itself if/when it needs one? If created, it could of
>course be kept around so that
I have a feeling this is a stupid question, but I have to ask anyway.
Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
just create one for itself if/when it needs one? If created, it could of
course be kept around so that it didn't need to be re-created later.
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> But on the other hand I also liked Simon Cozen's argument that it should
NC> be easy to embed somewhere else, in which case why do we want to make
NC> the parser have a dependency on the IO library?
I can't see anyway that the dependen
Tom Hughes <[EMAIL PROTECTED]> writes:
>In message <[EMAIL PROTECTED]>
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>>
>> >FILE * is not a good idea. PerlIO * is fine.
>>
>> The problem with that is we're potentially getting the filehan
On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski wrote:
> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
> >FILE * is not a good idea. PerlIO * is fine.
>
> The problem with that is we're potentially getting the filehandle from
> something that isn't perl. Or so my thinking went at t
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> >FILE * is not a good idea. PerlIO * is fine.
>
> The problem with that is we're potentially getting the filehandle from
> something that isn't perl. Or so my
At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 07:03 PM 11/28/00 +, Tom Hughes wrote:
> >>In message <[EMAIL PROTECTED]>
> >> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>
> >> > The third parameter is the flags parameter, and it's
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>>In message <[EMAIL PROTECTED]>
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>> > The third parameter is the flags parameter, and it's optional. If omitted
>> > or set to PERL_CHAR_SOURCE, the secon
On Tue, 28 Nov 2000, Dan Sugalski wrote:
> >I also like the suggestion that rather than supply flags, we should
> >follow the lead and supply a Perl* something that would return an
> >appropriate bunch of text to the parser.
>
> I'd really rather not, since that would place the burden of knowing
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, and I called my abstract stream "void *source". :)
It isn't really abstract though as it only understand types of streams
that the parser author had thought of. An abstract stream would have a
vtable or som
Dan Sugalski wrote:
>
> Sure. Suggestions?
int perl6_parse(PerlInterp* interp, PerlIO* input);
PerlIO* make_memory_stream(char* buf, ssize_t length); // length=-1 for
nul-terminated
int close_stream(PerlIO* stream);
then if you read further, you'll eventually see:
PerlIO* make_callback_stream(
At 04:23 PM 11/28/00 -0500, Chaim Frenkel wrote:
>Err, this seems a little too Swiss Army Knife.
>
>This reads like a utility function. (i.e. A function that handles the
>most common scenerio.)
What it's supposed to be is the highest-level interface to the parser, and
so it's supposed to handle
At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > > is treated as if it points to a stream of bytes, where the first
> four are
>
>
>I spy magic number.
At 03:15 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software design problem
On Tue, Nov 28, 2000 at 03:15:35PM -0600, Jarkko Hietaniemi wrote:
> On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software
Err, this seems a little too Swiss Army Knife.
This reads like a utility function. (i.e. A function that handles the
most common scenerio.)
Shouldn't a set of lower level visible API be visible? One that seems
to pop out at me is some way of actually parsing a piece of code and
ending up with a
On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > Applying the maxim that any software design problem can be solved
> > > with sufficient levels of abstraction I'
On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > is treated as if it points to a stream of bytes, where the first four are
I spy magic number.
> > > the length of the source to be read followed by the
At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > Applying the maxim that any software design problem can be solved
> > with sufficient levels of abstraction I'd suggest that passing some
>
>A related warning sign is trying to cra
At 09:10 AM 11/28/00 -1000, Tim Jenness wrote:
>On Mon, 27 Nov 2000, Dan Sugalski wrote:
>
> > ---
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
> >
>
> > The third para
At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> > null-t
On Mon, 27 Nov 2000, Dan Sugalski wrote:
> ---
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
>
> The third parameter is the flags parameter, and it's optional. If omitted
> o
On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a sta
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The third parameter is the flags parameter, and it's optional. If omitted
> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> null-terminated string. If set to PERL_COUNTED_SOURCE, the sec
--- Steve Fink <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
>
> Given that other things may want to be streamable in
> similar f
At 09:48 AM 11/28/00 -0800, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
>
>Given that other things may want to be streamable in similar fash
Dan Sugalski wrote:
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Given that other things may want to be streamable in similar fashion (eg
the regular expression engine), why not have a Per
72 matches
Mail list logo
