Michael Lazzaro wrote:
I think we've covered everything about nums that we're able to for the
moment. There are still issues with types/overflow/exception
handling. Internals is talking about them; let's revisit the issue
after they've figured out some of the preliminaries.
I'll attempt to
Larry's earlier response means this 'yours'
idea is history, but for closure, yes, this
seems to be headed in the right direction,
at least in theory. It may have even been
practical to implement it thru the standard
property mechanism.
> so these two are equivalent ???
>
> {
> my $x is yours ;
>
Pretty straightforward. Edit call_types.txt. First parameter's the
return type, the rest are the parameter types. Use "p" for any
generic "i've stuffed a struct pointer into a PMC" type. Do please
only add in signatures for functions you're actually going to call
(or are adding if you're adding
At 7:55 PM -0500 11/25/02, Dan Sugalski wrote:
Okay, I've finished the framework for the NCI stuff. The code to
make storing into PMCs, and using strings, needs finishing, but the
rest is in there. (Something went awry with the checkin, so it might
not have been noted properly)
Okay, fetches f
On Mon, 2002-11-25 at 11:04, Nicholas Clark wrote:
> Is there any speed advantage in truncating by casting via a C type
> [eg a = (int)(short) b]
> rather than and on a bitmask
> [eg a = b & 0x]
> ?
>
> We're going to have to do that latter to make it work on Crays anyway
Why?
--
Bryan C.
On Mon, 2002-11-25 at 20:00, Joseph F. Ryan wrote:
> I agree; perhaps before the argument begins, we should have something to
> argue over? :) (i.e., a first draft of these sections)
Sure. On perl6-language. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Tanton Gibbs wrote
radii.t
This isn't your fault, but I have to say that 0o0777 looks really bad in my
font...i.e.
looks like 000777. Perhaps the powers that be may eliminate octal (who uses
it?)
or change it to c? t? or l?
Hmmm, maybe, but 0o00 would be so great in halloween-based JAPHs ;)
On Mon, 2002-11-25 at 13:06, Michael Lazzaro wrote:
> 0x0 # ok, == 0
> 0x0.0 # ok
> 0x.0# ok
Given that .1 is wrong (from above), I would disallow it here simply for
consistency sakes.
> 0d1.1E5 # WRONG, exp not allowed in shorthand radix
>
> 0B0110
Bryan C. Warnock wrote:
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
Let's open these for discussion. Questions/proposals/issues, anyone?
and again... what's the scope of p6d, and how does it differ from p6l?
I agree; perhaps before the argument begins, we should have somethi
Okay, I've finished the framework for the NCI stuff. The code to make
storing into PMCs, and using strings, needs finishing, but the rest
is in there. (Something went awry with the checkin, so it might not
have been noted properly)
Please be aware that the code in build_nativecall.pl is well pa
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
> (2) The behavior of an explicit bool type, _if_ one exists, that stores
> "truth", not "value". Such that C stores
> true, not 0, and does so in "the most efficient way".
If you don't already know whether it exists, or how it will roughly wo
> Well... Perl5 didn't have typecasts primarily because it didn't have
> types. To the extent it _does_ have types, it has casting, too: it
> just is extremely limited.
>
> my $s = scalar ;
> my $s = list ;
>
> The above can be construed as typecasting: converting an expression
> to eit
On Monday, November 25, 2002, at 12:27 PM, Tanton Gibbs wrote:
Perl 5 did not have typecasts...probably for good reason. The quip in
the camel book says that no one likes to be typecast, anyway. I would
rather not have typecasts in Perl6 if we can get by without them.
Well... Perl5 didn't h
> "Simon" == Simon Cozens <[EMAIL PROTECTED]> writes:
Simon> What were the good reasons for not allowing localized lexicals in Perl 5?
Nobody could explain it in 50 words or less.
"What the hell is 'local my $foo = 35'?"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503
> (2) The behavior of an explicit bool type, _if_ one exists, that stores
> "truth", not "value". Such that C stores
> true, not 0, and does so in "the most efficient way".
I think before we can answer this question, we have to know how to extract
truth.
my int $x = (0 but true);
Now, how do yo
Luke Palmer wrote [reply to my Void type suggestion]
> It could also behave as our bool type. Something that you can attach
> properties to but doesn't need a value seems that it could be useful
> every once in a while.
>
> Just... what does a void literal look like? Perhaps just the word
> C?
>
> Date: Mon, 25 Nov 2002 14:49:25 -0500
> From: "Joseph F. Ryan" <[EMAIL PROTECTED]>
>
> I think "easy enough with a grammar munge" gets tossed around way too
> often; don't forget, in addition to having to know how to hack the core
> grammer (which I assume won't be for the novice;
It's not for t
Michael Lazzaro wrote:
I think we've covered everything about nums that we're able to for the
moment. There are still issues with types/overflow/exception
handling. Internals is talking about them; let's revisit the issue
after they've figured out some of the preliminaries.
I'll attempt to
Thanks for the clear answers.
Larry:
> I think that currying should be extended to
> handle any caller-instituted defaulting.
Argh. So obvious! (So of course I missed it.)
> Basically, the parameter list of the subroutine
> is already providing a limited namespace to be
> shared by caller and c
Michael Lazzaro wrote:
Hmm, that's not overpoweringly ugly. Looks nice, even. The fact that
it doesn't generalize is a little awkward.
I'm still thinking that, unless someone comes up with a really
compelling real-world reason to *have* floats in bases other than 10,
we shouldn't ask the
> From: "Dave Whipp" <[EMAIL PROTECTED]>
> Date: Mon, 25 Nov 2002 11:35:40 -0800
>
> "Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> > [...] and a type that matches every
> > context (except void).
>
> Actually, it might be nice to have a void type. It might seem useless:
> but then, so does /dev/n
Nicholas Clark <[EMAIL PROTECTED]> writes:
> (doing stuff on out of range signed values is undefined behaviour, IIRC)
Yes, that's right. Some GCC optimizations rely on the fact that
signed integer calculations can never overflow.
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> [...] and a type that matches every
> context (except void).
Actually, it might be nice to have a void type. It might seem useless:
but then, so does /dev/null.
An example, from another language, is C++ templates. Its amazing
how often I find myself
I think we've covered everything about nums that we're able to for the
moment. There are still issues with types/overflow/exception handling.
Internals is talking about them; let's revisit the issue after they've
figured out some of the preliminaries.
I'll attempt to assemble a full "Numerics
On Mon, Nov 25, 2002 at 09:25:32AM -0800, Michael Lazzaro wrote:
> (Ooooh, there's another idea we _SHOULDN'T_ pursue... adding postfix
> '%' to mean 'percent', but in any radix. So 0x80% of 0x10 would be
> 0x08 !)
And here you give the PERFECT example as to why this idea shouldn't be
pursued.
[EMAIL PROTECTED] (Larry Wall) writes:
> :It can also make sense if it is lexical.
> :Is the latter currently allowed?
>
> I'm planning to allow it unless someone can come up with a good reason not to.
What were the good reasons for not allowing localized lexicals in Perl 5?
--
User:
On Sat, Nov 23, 2002 at 08:46:03PM -0600, Me wrote:
: First, I'd like to confirm I've understood
: C and C right:
:
: 1. C dynamically scopes changes to a
:variable's value to the enclosing block.
:It does not dynamically scope the name.
:The variable can obviously be a global.
:It
With clarifications, and additional syntactic edge cases.
The last remaining known "numeric literals" issue is whether we want to
allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
disallow it as being Way Too Creepy. This version assumes that '.' is
allowed, but exponential not
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote:
>>> 256#0_253_254_255 # base 256, NOT identical!
>>
>> is actually not allowed, no?
>
> Correct. It's an error, because radix > 36 mandates coloned form, and
> the colon-form digit 253254255 cannot exist in base 256. AND since
On Sunday, November 24, 2002, at 04:16 AM, Richard J Cox wrote:
We could adopt the C99 version and use "p" or "P" for hex decimal
values (this, reportedly, allows certain values not expressible in
decimal for floats to be specified).
Thus
0x.4Ap10
0xA.BCDp-15
(The exponent cannot be i
If memory serves me right, Gopal V wrote:
> I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ...
On nicholas' advice I'm writing out the expected results for all
these opcodes... in the hope that someone more well versed in writing
..t files than me can help ..
conv_i1 & conv_i1
I guess I have more to learn about writing opcodes for parrot ... But
all I can say is you people make it almost too easy :-)
If memory serves me right, Leopold Toetsch wrote:
> The INTVAL could be a "long long".
Ok ... /me sort of needs an Int32 there ...
> Parrot_Int2 will be generated by a t
On Friday, November 22, 2002, at 03:31 AM, Anton Berezin wrote:
This:
- radix > 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Correct. It's an error, because radix > 36 mandates coloned
On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> > I'm surprised that you did your regression tests longhand, rather than having
> > a data table in perl of input and expected output, and auto-generating parrot
> > code.
>
>
> Writing a few explicit test
On Mon, Nov 25, 2002 at 04:39:23PM +, Nicholas Clark wrote:
> And we ought to make a generic "safe" version of the code for signed
> truncation that works for platforms that are any or all of the following
> holds
>
> 1: no type of that size (eg Crays)
> 2: signed integer truncation (UTS) [and
Nicholas Clark wrote:
On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote:
Gopal V wrote:
/*
** dotgnu.ops
*/
Thanks applied,
I'm surprised that you did your regression tests longhand, rather than having
a data table in perl of input and expected output, and auto-generating
On Mon, Nov 25, 2002 at 11:29:01AM -0500, Dan Sugalski wrote:
> At 4:04 PM + 11/25/02, Nicholas Clark wrote:
> >Is there any speed advantage in truncating by casting via a C type
> >[eg a = (int)(short) b]
> >rather than and on a bitmask
> >[eg a = b & 0x]
> >?
> >
> >We're going to have
On Mon, 25 Nov 2002, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> >> $1 = (INTVAL)((char)($1));
> >> The INTVAL could be a "long long".
> >
> > That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
>
> AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
> repr
At 4:04 PM + 11/25/02, Nicholas Clark wrote:
On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote:
Gopal V wrote:
> /*
> ** dotgnu.ops
> */
Thanks applied,
I'm surprised that you did your regression tests longhand, rather than having
a data table in perl of input and expec
At 5:01 PM +0100 11/25/02, Leopold Toetsch wrote:
Dan Sugalski wrote:
$1 = (INTVAL)((char)($1));
The INTVAL could be a "long long".
That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
representation o
Dan Sugalski wrote:
$1 = (INTVAL)((char)($1));
The INTVAL could be a "long long".
That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
representation of a char might be different though.
Same here. s
On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote:
> Gopal V wrote:
>
> > /*
> > ** dotgnu.ops
> > */
>
> Thanks applied,
I'm surprised that you did your regression tests longhand, rather than having
a data table in perl of input and expected output, and auto-generating parrot
code
Gopal V wrote:
/*
** dotgnu.ops
*/
Thanks applied,
leo
PS please run "perl Configure.pl" after applying.
At 3:58 PM +0100 11/25/02, Leopold Toetsch wrote:
Gopal V wrote:
Thanks for the patch. I'll add some config methods and apply it
after polishing.
DISCLAIMER: I don't know anything about how parrot opcodes should be
written .. So all errors are accidental and I would like somebody to
point them
so these two are equivalent ???
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
1...
sub_a ;
2...
}
sub sub_a ( ; $x is yours, $y is yours ) { ...3... } ;
- same as -
# ( here no special meaning for "is yours" -- just another property )
Gopal V wrote:
Thanks for the patch. I'll add some config methods and apply it after polishing.
DISCLAIMER: I don't know anything about how parrot opcodes should be
written .. So all errors are accidental and I would like somebody to
point them out to me ..
Pretty well done, modulo minor typ
If memory serves me right, Rhys Weatherley wrote:
> on 32-bit, 64-bit, and native-sized integer types (8-bit
> types don't need it).
Hmm... maybe there's only one way to stop this lng thread ...
Oct 18 20:31:20 no, no, you have it wrong. you don't
*ask* us t
On Sun, Nov 24, 2002 at 07:02:11PM -0500, David Robins wrote:
> Actually it looks like the problem is in assemble.pl's sub constant_table;
> even though $PConfig{numvalsize} is 12, $PConfig{packtype_n} is 'd' and
> pack('d',$n) uses 8 bytes. This is after hacking NUMVAL_SIZE to 12,
> though, whic
numbers.t
comment is wrong
the first
#negative big float
should be
#negative big int
string.t
reverse paired delim qq actually tests reverse paired delim q
in other words, change
q)hi(; to qq)hi(; for that test.
radii.t
This isn't your fault, but I have to say that 0o0777 looks really bad in my
49 matches
Mail list logo
