On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote:
>
> =head1 Compact structs
>
> A class whose attributes are all low-level types can behave as
> a struct.
"all low-level types" or "all low-level *sized* types"?
(I'm wondering about char arrays, string and pointers.)
I presume a char[
On Fri, 20 Aug 2004, Luke Palmer wrote:
> Austin Hastings writes:
> > Larry Wall wrote:
> > >Hmm. Gotta decided if S$foo.bar() is too ugly to live though...
> >
> > It is.
>
> Agreed.
Though IMHO Perl has a long history of syntax allowances too ugly to live,
and yet, as long as they are not *
On Fri, 3 Sep 2004 11:41:05 +0100, Tim Bunce <[EMAIL PROTECTED]> wrote:
> Is there some syntax to express if the struct is packed or
> needs alignment? (Perhaps that would be needed per element.)
Why am I suddenly thinking about unions ?
The C opcode and vtable is in CVS. The Complex PMC has a
reference implementation (modulo some error checking[1]) and there are
some tests using the new opcode as well as the function call syntax.
I'd be glad if people could implement the C vtable method
for other PMCs too.
Some PMCs have a si
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
>>
>>Pclass = getclass, "Foo"
>>Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument
>>
>>and that be special-cased to call VTABLE_new according to calling
>>conventions.
> Still don't like __n
The BigInt PMC has a lot of unimplemented MMD and vtable functions. Some
are denoted with internal_exception ... "unimp", some are probably just
missing.
So it'll be great if some folks could complete that.
A second job what be to take a start at an internal implemenation of the
BigInt / BigNum
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 02, 2004 8:41 PM
> To: Perl6
> Subject: Re: Reverse .. operator
>
> On Thu, Sep 02, 2004 at 08:34:22PM -0400, Joe Gottman wrote:
> : Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I
[ resent ]
Date: Thu, 26 Aug 2004 09:17:52 +0200
Subject: Integer PMCs
Fog around integer PMC semantics is lifting, so we should start bringing
classes/*.pmc into shape.
Currently PerlInt is the most complete implementation of the proposed
semantics. Some vtable methods like C still need work, t
On Thu, 19 Aug 2004 19:45:37 -0700, Larry Wall wrote:
> To process two arrays in parallel, use either the zip function:
>
> for zip(@a,@b) -> $a, $b { print "[$a, $b]\n" }
>
> or the "zipper" operator to interleave them:
>
> for @a ¥ @b ¥ @c -> $a, $b, $c { print "[$a, $b, $c]\n" }
n-ary z
According to [EMAIL PROTECTED] (Dan Sugalski):
>*) extract substring
Rather than that, wouldn't you prefer to make "substring of target
string" the actual target of all these?
>*) exact string compare
>*) find string in string
>*) find first character of class X in string
>*) find first character
On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote:
> my ref[Array] @ragged2d;
What is a "ref" type exactly? Is it like a pointer in C? If so, and
based on the parameterization above, I assume that there will also be
the appropriate pointer arithmetic such that if $fido is declared as
Jonathan Scott Duff wrote:
Maybe it's just my BASIC upbringing, but "shape" doesn't seem like the
right word. Words like "dimension" and "cardinal" fit better in my
head, but I'd want them shorter and "dim" and "card" don't quite work
either ;-)
But "shape" makes me want to do something like this:
On Fri, Sep 03, 2004 at 02:56:48PM +0100, Peter Haworth wrote:
: n-ary zip() is simple enough, but the infix ? makes zipping more than
: two lists somewhat entertaining. Without iterators doesn't work well:
:
: @a ? @b produces (@a[0],@b[0],@a[1],@b[1],...)
:
: which is what we wanted, but
:
:
On Fri, Sep 03, 2004 at 10:00:24AM -0500, Jonathan Scott Duff wrote:
: On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote:
: > my ref[Array] @ragged2d;
:
: What is a "ref" type exactly? Is it like a pointer in C?
It's exactly like a reference in Perl 5. Declaring a compact array of
"
At 2:44 PM + 9/3/04, Chip Salzenberg wrote:
According to [EMAIL PROTECTED] (Dan Sugalski):
*) extract substring
Rather than that, wouldn't you prefer to make "substring of target
string" the actual target of all these?
Only if the resulting substring'd be used in the match. Otherwise
you're be
At 12:55 PM -0400 9/3/04, Chip Salzenberg wrote:
According to Dan Sugalski:
At 2:44 PM + 9/3/04, Chip Salzenberg wrote:
>According to [EMAIL PROTECTED] (Dan Sugalski):
>>*) extract substring
>
>Rather than that, wouldn't you prefer to make "substring of target
>string" the actual target o
On Fri, Sep 03, 2004 at 09:29:36AM -0700, Larry Wall wrote:
> : If so, and
> : based on the parameterization above, I assume that there will also be
> : the appropriate pointer arithmetic such that if $fido is declared as a
> : ref[Dog] and pointed at an array of Dogs, then $fido++ will move to the
I am getting ready to release a new version of DBD::Mock and all seemed
fine until I tried running 'make test' and I got a bunch of warnings,
which when I ran it with 'prove -b t/*.t' I did not get.
I have tried to debug the issue based on the DBI line number. But (as
far as I can tell) what
On Fri, Sep 03, 2004 at 12:25:37PM -0500, Jonathan Scott Duff wrote:
: If "my int @foo" makes a compact array of ints, is there a way to make a
: compact array of Dog? (Does it even make sense?) And if so, does it look
: like "my Dog @foo" or must there be some other syntax to declare it?
It's jus
On Fri, Sep 03, 2004 at 11:41:05AM +0100, Tim Bunce wrote:
: On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote:
: >
: > =head1 Compact structs
: >
: > A class whose attributes are all low-level types can behave as
: > a struct.
:
: "all low-level types" or "all low-level *sized* types"?
On Thu, 2 Sep 2004, Clayton O'Neill wrote:
> On 2 Sep 2004 15:22:39 -, Andy Dougherty via RT
> <[EMAIL PROTECTED]> wrote:
> > I'm not quite sure if I understand you correctly, since you don't want c++
> > if Configure.pl chooses gcc. Perhaps you meant icu's configure would find
> > gcc? Or p
I seem to have fixed the issue, it had something to do with the scope
of some of the DBD specific variables. Basically, I had repleaced
several use vars (...) with our $variable not realizing the variables
were then being file scoped and not package scoped. Once I got the
variables into the
Synopsis 4 says:
"PRE and POST must return boolean values that are evaluated according to the
usual Design by Contract rules."
Do "the usual Design by Contract rules" include the ability to "turn off"
(i.e. remove from program flow) PRE and POST blocks for performance reasons
in production, or is
On Fri, Sep 03, 2004 at 04:02:39PM -0400, stevan little wrote:
> I seem to have fixed the issue, it had something to do with the scope
> of some of the DBD specific variables. Basically, I had repleaced
> several use vars (...) with our $variable not realizing the variables
> were then being
On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote:
: Synopsis 4 says:
:
: "PRE and POST must return boolean values that are evaluated according to the
: usual Design by Contract rules."
:
: Do "the usual Design by Contract rules" include the ability to "turn off"
: (i.e. remove from p
On 9/3/04 6:03 PM, Larry Wall wrote:
> On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote:
> : Synopsis 4 says:
> :
> : "PRE and POST must return boolean values that are evaluated according to the
> : usual Design by Contract rules."
> :
> : Do "the usual Design by Contract rules" incl
John Siracusa wrote:
I don't see how we could prevent someone from clobbering the global
definitions of PRE and POST to be no-ops if they wanted to. Seems to
me that the whole point of putting the program in charge of its own
compilation is to let it be in charge of its own compilation, n'est pa?
On 9/3/04 6:45 PM, Damian Conway wrote:
> John Siracusa wrote:
>>> I don't see how we could prevent someone from clobbering the global
>>> definitions of PRE and POST to be no-ops if they wanted to. Seems to
>>> me that the whole point of putting the program in charge of its own
>>> compilation is
On Thu, 2 Sep 2004, Larry Wall wrote:
> The argument to a shape specification is a semicolon list, just like
> the inside of a multidimensional subscript. Ranges are also allowed,
> so you can pretend you're programming in Fortran, or awk:
>
> my int @ints is shape(1..4;1..2); # two dimension
On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote:
: On Thu, 2 Sep 2004, Larry Wall wrote:
:
: > The argument to a shape specification is a semicolon list, just like
: > the inside of a multidimensional subscript. Ranges are also allowed,
: > so you can pretend you're programming in F
On Thu, 2 Sep 2004, Larry Wall wrote:
> A multidimensional array is indexed by a semicolon list, which is really
> a list of lists in disguise. Each sublist is a slice of one particular
> dimension. So
>
> @array[0..10; 42; @x]
>
> is really short for
>
> @array.postcircumfix:[]( <== [0..
Larry Wall wrote:
On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote:
: What happens when the Pascal programmer declares
:
: my int @ints is shape(-10..10);
:
: Does it blow up?
No.
: If not, does @ints[-1] mean the element with index -1 or the last element?
The element with ind
John Williams writes:
> On Thu, 2 Sep 2004, Larry Wall wrote:
> > A multidimensional array is indexed by a semicolon list, which is really
> > a list of lists in disguise. Each sublist is a slice of one particular
> > dimension. So
> >
> > @array[0..10; 42; @x]
> >
> > is really short for
> >
Larry Wall wrote:
> Arrays with explicit ranges don't use the minus notation to count from
> the end. We probably need to come up with some other notation for the
> beginning and end indexes. But it'd be nice if that were a little
> shorter than:
>
> @ints.shape[0].beg
> @ints.shape[0
On Fri, Sep 03, 2004 at 07:42:53PM -0500, Rod Adams wrote:
(B: What jumps to my mind is that inside an array subscript could be
(B: (sub)?context of it's own. Then one could do:
(B:
(B: @ints[.beg .. .end ; .beg + 3 .. .end];
(B
(BAwful dotty...
(B
(B: Where the .beg and .end would relate
On Fri, Sep 03, 2004 at 06:31:49PM -0700, Jonathan Lang wrote:
: I wonder if this notion of contextualizing a method's signature could be
: generalized... I could see a case for treating most methods as if the
: expressions in each parameter were being evaluated within the caller's
: class:
:
:
> I think we just need something really short and unconfusing for the
> commonest cases,
@a[ 42 ; -1 but last ]
That reads pretty well, no?
Maybe the other end isn't quite as good:
@a[ 1 but first .. -2 but last ]
Hmm. Should "-1 but last" or "0 but last" be the last element?
~ John Wil
On Fri, Sep 03, 2004 at 08:19:11PM -0600, John Williams wrote:
: > I think we just need something really short and unconfusing for the
: > commonest cases,
:
:@a[ 42 ; -1 but last ]
:
: That reads pretty well, no?
:
: Maybe the other end isn't quite as good:
:
: @a[ 1 but first .. -2 but
Larry Wall wrote:
> On Fri, Sep 03, 2004 at 06:31:49PM -0700, Jonathan Lang wrote:
> : I wonder if this notion of contextualizing a method's signature could
> : be generalized... I could see a case for treating most methods as if
> : the expressions in each parameter were being evaluated within th
Larry Wall wrote:
I'm still thinking A is the first one and Z is the last one. Someone
talk me out of it quick.
I had thought about A and Z before my previous post. I dismissed it for
two reasons:
1) Using Alphas as an index for something that should be numeric can be
very confusing. Especially
> If you insist on using A and Z, at least make them \A and \Z, to give a
> stronger visual cue that something different is happening.
I think I'd prefer alpha and omega.
Or maybe turn my previous suggestion around and make first and last
special constants. Then say:
@a[ first .. last but 1 ]
On Fri, Sep 03, 2004 at 11:03:03PM -0500, Rod Adams wrote:
> If you insist on using A and Z, at least make them \A and \Z, to give a
> stronger visual cue that something different is happening.
Some other ideas ...
^A..^Z Too confusing with $^A and $^Z ?
^A..^? Well, if control
42 matches
Mail list logo
