Re: More tests.
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 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? conversion.t The int -> bit conversion doesn't actually convert anything...pehaps you meant bit instead of int? If you, in fact, did mean bit instead of int, then shouldn't -2 become 1 instead of 0...I would imagine that anything non-zero would go to 1? Also, same applies with num -> bit...no conversions were made. interpolation.t The Interpolation of Hash as Expressions You have %hash.keys interpolating as item, two I would imagine it would interpolate the same way as an array (i.e. item two) Also, you test array with non-interpolation, but you don't hash. In the $() test, you define x but never use it. Also, in the unimplemented & test, I didn't think & was special in a string. Instead, I thought we should use $() such that print "&(noret)" should be print "$(noret)"; Is this correct? Anyway, it looks good...keep up the good work. Tanton - Original Message - From: "Joseph F. Ryan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 23, 2002 4:58 AM Subject: More tests. > I've added a slew of new tests to the p6-literals test-suite, including: > > - Error tests. > - Bit-type. > - Subscripted variable interpolation. > - Variable method interpolation. > - Many conversion tests. > > I was a bit unsure (read: possibly rong as wrabbits) on some of the error > and conversion tests, so let me know if you find any errors or > discrepancies. > > Find them at: > http://jryan.perlmonk.org/images/literals.tar.gz > > >
Re: long double error
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, which explains why it wasn't caught in config/auto/pack.pl.
> perldoc for pack shows no way to pack a native NV. Should assemble.pl be
> using packout.c via XS/Inline? If this is decided to be the way to go then
> I'd be glad to work on a patch to do it.
'D' will pack long doubles on perl 5.8.0 (and later) if the perl is built
with NVs as long doubles. (ie -Duselongdouble at Configure time)
The long vaunted plan to actually make everything that outputs bytecode use
one C library (with a perl interface) might be a better way to properly
solve this.
Nicholas Clark
Re: C#/Parrot Status
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 to add features. YOu just send
us patches which do them :-)
Nov 25 03:09:38And I'm serious. If you want a dotnet.ops file,
go for it.
.
I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ...
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 ..
Gopal
--
The difference between insanity and genius is measured by success
/*
** dotgnu.ops
*/
#include "parrot/method_util.h"
VERSION = PARROT_VERSION;
=head1 NAME
dotgnu.ops
=cut
=head1 DESCRIPTION
Additional opcodes for C# compilation needed by cscc PM codegen
=cut
inline op conv_i1(inout INT) {
$1= (int)((char)($1));
goto NEXT();
}
inline op conv_i1_ovf(inout INT) {
if($1 >= -128 && $1 <= 127) {
$1= (int)((char)($1));
}
else {
internal_exception(1, "Overflow exception for conv_i1_ovf\n");
}
goto NEXT();
}
inline op conv_u1(inout INT) {
$1= (int)((unsigned char)($1));
goto NEXT();
}
inline op conv_u1_ovf(inout INT) {
if($1 >= 0 && $1 <= 256 ) {
$1= (int)((unsigned char)($1));
}
else {
internal_exception(1, "Overflow exception for conv_u1_ovf\n");
}
goto NEXT();
}
inline op conv_i2(inout INT) {
$1= (int)((short)($1));
goto NEXT();
}
inline op conv_i2_ovf(inout INT) {
if($1 >= -32768 && $1 <= 32767 ) {
$1= (int)((short)($1));
}
else
{
internal_exception(1, "Overflow exception for conv_i2_ovf\n");
}
goto NEXT();
}
inline op conv_u2(inout INT) {
$1= (int)((unsigned short)($1));
goto NEXT();
}
inline op conv_u2_ovf(inout INT) {
if($1 >= 0 && $1 <= 65535) {
$1= (int)((unsigned short)($1));
}
else
{
internal_exception(1, "Overflow exception for conv_u2_ovf\n");
}
goto NEXT();
}
inline op conv_i4(out INT, in NUM) {
$1= (int)($2);
goto NEXT();
}
inline op conv_i4(out INT, in PMC) {
$1= (int)($2->vtable->get_integer(interpreter, $2));
goto NEXT();
}
inline op conv_u4(out INT, in NUM) {
$1= (unsigned int)($2);
goto NEXT();
}
inline op conv_u4(out INT, in PMC) {
$1= (unsigned int) ($2->vtable->get_integer(interpreter, $2));
goto NEXT();
}
inline op conv_i8(out PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1,$2);
goto NEXT();
}
inline op conv_i8(out PMC, in PMC) {
$1->vtable->set_integer_same(interpreter, $1,$2);
goto NEXT();
}
inline op conv_i8(out PMC, in NUM) {
$1->vtable->set_integer_native(interpreter, $1,(int)$2);
goto NEXT();
}
inline op conv_r4(out NUM, in INT) {
$1= (FLOATVAL)($1);
goto NEXT();
}
inline op conv_r4(out NUM, in PMC) {
$1= (FLOATVAL) ($2->vtable->get_number(interpreter, $2));
goto NEXT();
}
Re: C#/Parrot Status
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 typos, which a *test* would have catched
;-) hint, hint t/op/*.t ...
Ok, here we go.
inline op conv_i1(inout INT) {
$1= (int)((char)($1));
$1 = (INTVAL)((char)($1));
The INTVAL could be a "long long".
inline op conv_i2(inout INT) {
$1= (int)((short)($1));
$1 = (INTVAL)((Parrot_int2)($1));
Parrot_Int2 will be generated by a test in config/auto/somewhere and
will be "short".
inline op conv_i8(out PMC, in INT) {
inline op conv_i8(inout PMC, in INT) {
"inout", because the PMC has to exist in advance, and isn't emerging new
here, like an int or num.
inline op conv_i8(out PMC, in NUM) {
$1->vtable->set_integer_native(interpreter, $1,(int)$2);
$1->vtable->set_integer_native(interpreter, $1, $2);
The vtable function has to do the conversion.
inline op conv_r4(out NUM, in INT) {
$1= (FLOATVAL)($1);
inline op conv_r4(out NUM, in INT) {
$1 = (FLOATVAL)(float)($2);
^^
leo
Re: C#/Parrot Status
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 out to me ..
Pretty well done, modulo minor typos, which a *test* would have
catched ;-) hint, hint t/op/*.t ...
Ok, here we go.
inline op conv_i1(inout INT) {
$1= (int)((char)($1));
$1 = (INTVAL)((char)($1));
The INTVAL could be a "long long".
That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
inline op conv_i2(inout INT) {
$1= (int)((short)($1));
$1 = (INTVAL)((Parrot_int2)($1));
Parrot_Int2 will be generated by a test in config/auto/somewhere and
will be "short".
Same here. shorts may not be 16 bits.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: C#/Parrot Status
Gopal V wrote: /* ** dotgnu.ops */ Thanks applied, leo PS please run "perl Configure.pl" after applying.
Re: C#/Parrot Status
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. 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, so is a conditional compile to chose between the two worth it? Nicholas Clark
Re: C#/Parrot Status
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. shorts may not be 16 bits. Test for this is in. leo
Re: C#/Parrot Status
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 of a char might be different though. Alas not. That'd be too easy. :( -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
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 expected output, and auto-generating parrot code. 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, so is a conditional compile to chose between the two worth it? The bitmask doesn't sign-extend where the casting will, which could be an issue. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
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
> representation of a char might be different though.
The standard only requires CHAR_BIT ("number of bits for smallest object
that is not a bit-field (byte)") to be at least 8 (5.2.4.2.1). sizeof(char)
is 1 by definition (6.5.3.4.3).
Dave
Isa. 40:31
Re: C#/Parrot Status
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 to do that latter to make it work on Crays anyway, so is > >a conditional compile to chose between the two worth it? > > The bitmask doesn't sign-extend where the casting will, which could > be an issue. That still lets us halve our conditional code. :-) (do all the unsigned with masks) 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 other OSes on S/390 processors?] 3: not 2s complement [no examples] Nicholas Clark
Re: C#/Parrot Status
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 parrot
code.
Writing a few explicit tests is faster ;-)
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]
?
gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
This is listed to take 3 cycles which "and mem" needs too. Inkluding
sign extension would be slower then.
We're going to have to do that latter to make it work on Crays anyway, so is
a conditional compile to chose between the two worth it?
My Cray is currently out of order ;-) What is special with it?
Nicholas Clark
leo
Re: C#/Parrot Status
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 other OSes on S/390 processors?] > 3: not 2s complement [no examples] oops. forgot one: 4: nasal demons (Irix64) (doing stuff on out of range signed values is undefined behaviour, IIRC) Nicholas Clark
Re: C#/Parrot Status
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 tests is faster ;-)
Good answer.
When I have tuits (little white things made of ice, commonly found in hell)
I'll re-write your tests as autogenerated from a table of pathological cases.
> > 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]
> > ?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
> This is listed to take 3 cycles which "and mem" needs too. Inkluding
> sign extension would be slower then.
and gcc's optimiser is not clever enough to spot bit & cases that are not
equivalent to this? :-(
> > We're going to have to do that latter to make it work on Crays anyway, so is
> > a conditional compile to chose between the two worth it?
>
>
> My Cray is currently out of order ;-) What is special with it?
sizeof(short) == 8
[sizeof (int) == 8 for that matter, and the elements of a sockaddr_in
structure are bitfields, so you can't take the address of them.]
Nicholas Clark
Re: C#/Parrot Status
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 test in config/auto/somewhere and > will be "short". I asked the IRC room Nov 25 16:23:21 on a related note .. does parrot size types ? Nov 25 16:23:33 sort of like a Int8 I could cast to ? Nov 25 16:24:19 I just write the summaries. Nov 25 16:24:52 :-) . Sure, made note of Parrot_Int2 for future use ... > "inout", because the PMC has to exist in advance, and isn't emerging new > here, like an int or num. OK .. > The vtable function has to do the conversion. Yes.. especially if I have to use it for Float to Int64 ... Thanks for correcting my errors, Gopal -- The difference between insanity and genius is measured by success
What dotgnu.ops does (Re: C#/Parrot Status)
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_ovf
-
Truncate to between (-128 and 127) so 128 converted to -128 ... 0 to 0
and the basic sign extensions of `char' apply here . 'ovf' suffix
instruction throws an OverFlowException message if the value is not
between -128 and 127. (TODO: throw catchable exceptions)
conv_u1 & conv_u1_ovf
-
To between 0 and 255 ... ovf throws the OverFlowException if value not
in range. Original post bugs out for 256 ... See attached patch
conv_i2 & conv_i2_ovf
-
To between -32768 and 32767 .. ovf for out of range
conv_u2 & conv_u2_ovf
-
To between 0 & 65535 ... ovf for out of range
conv_i4
---
NUM to int : 3.1415 to 3 , -3.1415 to 3
PMC to int (until csint64.pmc is done...try testing with perlint please ..)
conv_u4
---
NUM to unsigned int: 3.1415 to 3, -3.1415 is not 3
PMC to int (when csint64.pmc is done ...)
conv_i8
---
(int to csint64.pmc , NUM to csint64.pmc ...)
conv_r4
---
(PMC to floatval) ... to be implemented as csint64.pmc
test 3 to 3.000 ... (not much of a test , eh ?)
I'll try to catch up on PMC writing at leisure ..
Gopal
--
The difference between insanity and genius is measured by success
--- /tmp/dotgnu.ops Mon Nov 25 21:26:31 2002
+++ dotgnu.ops Mon Nov 25 21:27:02 2002
@@ -38,7 +38,7 @@
}
inline op conv_u1_ovf(inout INT) {
- if($1 >= 0 && $1 <= 256 ) {
+ if($1 >= 0 && $1 <= 255 ) {
$1= (int)((unsigned char)($1));
}
else {
Re: Dynamic scoping (take 2)
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 )
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
1...
#alias %MY to topic so that it can be fetched from sub_a by "is given"
$_ ::= \%MY ;
sub_a ;
2...
}
sub sub_a (;$x is yours,
$y is yours ) is given($CALLER_SYMB)
{
#alias variables from $CALLER_SYMB to the local variables if
#requested
$SUB_SYMB ::= \%MY ;
for $SUB_SYMB.keys {
if $SUB_SYMB{$_}.yours
and $CALLER_SYMB{$_}.yours
{
$SUB_SYMB{$_} ::= $CALLER_SYMB{$_} ;
}
} ;
$CALLER_SYMB = undef ; #but better if this happens at compile time
# -- probably this have to be forced with
#BEGIN
3...
} ;
arcadi
Re: Numeric Literals (Summary 4)
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 form, and the colon-form digit 253254255 cannot exist in base 256. AND since underscores can only separate digits, underscores are not allowed at all in coloned form, no matter what the base. (Umm... what's a better name than "coloned form"? That term sounds really... um... bad.) MikeL
Re: Numeric Literals (Summary 2)
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 in hex in C99). However this clearly cannot generalise for all bases <= 36... 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 design team to add it to the language. It certainly wouldn't be missed by 99.999% of the population. It will be easy enough to add as a grammar munge later, for the elite set of sixteen-fingered people who find working in base 10 floating-point disdainful. :-) (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 !) MikeL
Re: Numeric Literals (Summary 4)
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 > underscores can only separate digits, underscores are not allowed at > all in coloned form, no matter what the base. > > (Umm... what's a better name than "coloned form"? That term sounds > really... um... bad.) I would say colon form sounds fine. Although to be honest, I think Prefer CSD (Colon Separated Digits). andrew -- Libra: (Sept. 23 - Oct. 23) Someday, you'll look back on all of this and laugh very, very bitterly. msg24670/pgp0.pgp Description: PGP signature
Numeric Literals (Summary 5)
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 notation is _not_, due to ambiguities with 'E'.
--- Numeric Literals ---
decimal notation:
123 # int 123
0123 # int 123 (not octal!)
123.0 # num 123.0
-123 # int -123 (but - is operator, not part of num)
0_1.2_3 # ok
_01.23 # WRONG
01.23_ # WRONG
01_._23# WRONG
1__2# WRONG
0.1 # ok
0.1.1 # WRONG, can have only one decimal point
.1 # WRONG; looks like method call on $_
-.1 # WRONG, looks like method call on $_
exponential notation:
-1.23e4 # num
-1.23E4 # num (identical)
1.23_e_4# WRONG (underscore only between digits)
1e4 # ok
0e4 # ok, == 0
0e0 # ok, == 0
1e0 # ok, == 1
e4 # WRONG, looks like func
.e4 # WRONG, looks like method
bin/oct/hex notation:
0d6789 # decimal
0b0110 # bin
0o0123 # oct
0x00ff # hex
0x00fF # hex, == 0x00ff
0x00FF # hex, == 0x00ff
-0xff # ok
-0x00ff # ok
0x-ff # WRONG, - is an operator, not part of the literal
0xf_f # ok
0x_ff # WRONG, underscore only between digits
0x0 # ok, == 0
0x0.0 # ok
0x.0# ok
0d1.1E5 # WRONG, exp not allowed in shorthand radix
0B0110 # WRONG, should be 0b0110
0O0123 # WRONG, should be 0o0123
0X00FF # WRONG, should be 0x00FF
explicit radix:
(radix 2-36)
20#1gj # base 20
20#1GJ # base 20 (identical)
20#1:G:J # base 20 (identical)
20#1_G_J # base 20 (identical)
20#1:16:19 # base 20 (identical)
20#1_16_19 # NOT identical, == 20:11619
20#1:1_6:19 # WRONG: colon form may not have underlines
20#0:0:1 # base 20
20#0:1 # base 20 (identical)
20#:1# base 20 (identical) (leading : is ok)
:1 # WRONG, need radix specifier
20# # WRONG, need at least an '0'
1#0 # WRONG, radix must be >= 2
20#1_G.J # ok, radix point (e.g. float) allowed
20#1:16.19 # ok, radix point (e.g. float) allowed
10#1.1E5 # WRONG, no exp notation in explicit radix
-20#1GJ # base 20 (negative)
-20#1:16:19 # base 20 (negative)
20#-1GJ # WRONG, - is an operator, not part of the literal
(radix 37-RADIX_MAX)
256#0:253:254:255 # base 256
256#:253:254:255# base 256 (identical)
256#0_253_254_255 # WRONG, digit 253254255 doesn't
# exist in base 256.
Other issues w/ literals:
- radix <= 36, alpha digits may be upper or lowercase
- radix > 36, only colon form is allowed, not alpha digits
- underlines may appear ONLY between digits
- colon form may therefore not have underlines
- radix < 2 throws error
- negative sign goes before radix, e.g. -20#1GJ.
- need to specify RADIX_MAX (platform dependent?)
- explicit radix form may have radix point, '.',
but cannot use exponential notation ('e')
- can't have runtime radix, e.g. 2**8#10, because # binds tighter.
- can't say (2**8)#10, because not a literal.
MikeL
Re: Numeric Literals (Summary 2)
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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Status Summary; next steps
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" section from the docs we have, find any remaining holes, etc. I'll post next week for comments/revisions. The next Big Deals are: (1) String Interpolation. This was pretty well spelled out by A2, so there shouldn't be much to do except write it up, unless we want to make any additional requests. There's some issues that need to be finalized wrt Unicode, escaped chars, etc. (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". (3) Context. How to determine it, how to force it. Hypothesis: There is a one-to-one relationship between Type and Context, such that there is a context that matches every type, and a type that matches every context (except void). (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. Generic typecasting rules: how to define user classes that can typecast to/from str, int, bool, etc. This gets into Perl6 OO, but we may need to request some preliminary decisions before then, because the implications are substantial. Let's open these for discussion. Questions/proposals/issues, anyone? MikeL
Re: Dynamic scoping (take 2)
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 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.
: 2. C is a conditional C; it only
:restores a variable's value if, on exit
:from the enclosing block, the block is
:somehow considered to have "failed". It
:can be applied to a global or lexical.
At the moment, it doesn't apply to either. It applies only to the
current regex's variables. It is a bit of an inconsistency that
in the current model, regex variables are lexically scoped but not
actually declared. This may be a mistake.
: The above two features are basically sugar
: for what would otherwise be achieved with
: paired FIRST/LAST/UNDO blocks.
Well, there's no UNDO defined for regex backtracking unless we define
some kind of BACK block, but conceptually you're basically right.
: Both must be applied to an existing variable.
Not strictly true. if you say
/foo bar { let $baz = 2 } /
the $baz is creating a new variable within the scope of the surrounding regex.
: Next, I want to do a better job of stating
: a problem I wonder about:
:
: Consider "environmental" values such as
: "screen sizes, graphics contexts, file
: handles, environment variables, and
: foreign interface environment handles." [1]
:
: Consider a sub One that is going to call
: a 10 deep stack of subs such that sub Ten
: needs to access one of these environmental
: values. How do you pass the data?
:
: A. Globals. Bad. Disastrous in threads.
:
: B. Passed as args to all intervening subs.
:Verbose. Sometimes incredibly verbose.
:
: C. Aggregate info into objects. But then
:you still have to do either 1 or 2 above
:with the object references. And it's a
:shame to be forced to the object paradigm
:unnecessarily.
:
: D. Use $CALLERS::. Relatively succinct, but
:definitely error-prone and ugly.
But you haven't mentioned what's really going on with package
variables:
E. Passed via thread-local storage. Under I-threads, package variables
are *not* shared by default among threads, so they can be scoped
dynamically without the threading problems of A. Package variables
are global only if you squint really hard.
: Given what I understand of Perl 6 syntax,
: Parrot, and Perl philosophy, I suspect P6
: should, and could fairly easily, provide a
: good solution to the problem outlined above.
:
: Does anyone agree the problem I've outlined
: is inadequately addressed by $CALLERS::?
The real question is, do I agree. :-)
: In previous emails I've suggested:
:
: 1. The notion of something like attaching
:a C property on variables, and
:picking appropriate defaults for its
:args (not/ro/rw), to allow the writer
:of a sub to easily strictly limit what
:a called sub can access.
I think the granularity is wrong on this. Trying to mesh the
namespaces of caller and callee is a big problem as soon as you
have multiple callees with different ideas. In other words, I think
it's probably a mistake to try to generalize implicit $_ passing to
any name.
: 2. The notion of args that are explicitly
:defined in a sub's sig but implicitly
:passed. This kills most of the verbosity
:of B above, while, in combination with
:the previous point, being otherwise just
:as safe as passing args explicitly all
:the way down the call stack.
We already have currying, and I think that notion should be extended to
handle any caller-instituted defaulting. The granularity can be controlled
on a sub-by-sub or on a class-by-class basis.
# curry sub
my $DBhandle = mumble();
my &shortcut ::= &longcut.assuming(handle => $DBhandle);
# curry all methods of a class
use Dog.assuming(tail => "cut_short", ears => "cut_long");
my $little_dog = Dog.where_oh_where();
or some such. If there are early-binding/late-binding issues we
should address those as part of the currying design. For instance,
it's not clear above whether $DBhandle is evaluated at compile time
or run time. I think we have to say that it's a binding, which means
the value of handle depends on the *current* value of $DBhandle each
time the shortcut is called.
Basically, the parameter list of the subroutine is already providing a
limited namespace to be shared by caller and callee. If the caller really
wants to bind to a variable of the same name, they can always say
my $bar;
&foo.assuming(bar => $bar)
But I think it would be wrong for the callee to start forcing its
namespace into the namespace of the caller beyond what we already do
with named parameter syntax (and $_).
Larry
Re: Dynamic scoping (take 2)
[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: In 1793 the french king was executed. MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
Re: Dynamic scoping (take 2)
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 callee.
> ...
> But I think it would be wrong for the callee to
> start forcing its namespace into the namespace
> of the caller beyond what we already do with
> named parameter syntax (and $_).
Yes. I was following the same principles.
But I much prefer your route, that is, to use
assuming (a suggested perl lingo replacement
for currying) which so clearly fits the bill.
I love (natural) brevity, so perhaps one could
have .assuming map passed arg values that are
variables (rather than pairs) to a target arg
of same name:
my $tail = "cut_short";
my $ears = "cut_long";
Dog.assuming($tail, $ears);
What's the briefest way to say:
for [Dog, Devil] { use .assuming($tail, $ears) };
Presumably this won't work:
use (Dog&Devil).assuming($tail, $ears);
--
ralph
Re: Status Summary; next steps
"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 needing to create a template specialization for the void type, because I cannot declare/assign-to void variables in C++. Even if Perl won't have templates, we still tend to be quite dynamic with the code (code generators, eval, etc.). The ability to declare a variable of type-Void could be helpful to avoid special casing it in the generators. Dave.
Re: Status Summary; next steps
> 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/null. > > An example, from another language, is C++ templates. Its amazing > how often I find myself needing to create a template specialization > for the void type, because I cannot declare/assign-to void variables > in C++. Even if Perl won't have templates, we still tend to be > quite dynamic with the code (code generators, eval, etc.). The > ability to declare a variable of type-Void could be helpful to > avoid special casing it in the generators. 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? my void $false_var = void but false; I'm just speculating. But I do see a use for it. Luke
Re: Numeric Literals (Summary 2)
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 design team to add it to the language. It certainly wouldn't be missed by 99.999% of the population. It will be easy enough to add as a grammar munge later, for the elite set of sixteen-fingered people who find working in base 10 floating-point disdainful. :-) 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; how often does it happen in perl5?), you'll have to write the code so that compiler knows how to handle it. While not overly hard, I think its a little much for something that should be provided in the core. I think the design team should at least account for the fact that someone will want to do this, even if it is uncommon. If floating point radii doesn't make its way in the core language, I think it should at least be possible through a pragma. (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 !) Now even I think that is *Just Plain Wrong* :) Joseph F. Ryan [EMAIL PROTECTED]
Re: Status Summary; next steps
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 assemble a full "Numerics" section from the docs we have, find any remaining holes, etc. I'll post next week for comments/revisions. The next Big Deals are: (1) String Interpolation. This was pretty well spelled out by A2, so there shouldn't be much to do except write it up, unless we want to make any additional requests. There's some issues that need to be finalized wrt Unicode, escaped chars, etc. As far as this goes, here are a few known issues: 1.) How do references stringify? 2.) How do hashes stringify? 3.) How do objects stringify by default (i.e., without "" being overloaded) 4.) As far as I know, escaping is the same as perl5, and most of that is dealt with by parrot. (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". (3) Context. How to determine it, how to force it. Hypothesis: There is a one-to-one relationship between Type and Context, such that there is a context that matches every type, and a type that matches every context (except void). (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. Generic typecasting rules: how to define user classes that can typecast to/from str, int, bool, etc. This gets into Perl6 OO, but we may need to request some preliminary decisions before then, because the implications are substantial I was really confused about this when writing the tests for it :) Joseph F. Ryan [EMAIL PROTECTED]
Re: Numeric Literals (Summary 2)
> 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 the novice. But that's why there's modules. > how often does it happen in perl5?), Never. Because you can't. Perl 6 has the advantage that it's possible. > you'll have to write the code so that compiler knows how to handle > it. While not overly hard, I think its a little much for something > that should be provided in the core. I think the design team should > at least account for the fact that someone will want to do this, > even if it is uncommon. If floating point radii doesn't make its > way in the core language, I think it should at least be possible > through a pragma. Once again, or a module. We don't want the Perl 6 core to be minimal. We don't want it to be maximal either; that's CPAN's job. It seems to me (as Simon has pointed out many a-time) that too much is going into the core. I guess a lot of this stuff that's being talked about is going to be in modules anyway... so I'm less worried than when I started writing this paragraph :). Luke
RE: Status Summary; next steps
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? > > my void $false_var = void but false; > > I'm just speculating. But I do see a use for it. I see the Void type as being truely void: foo($bar); Void $baz = foo($bar); should be synonymous. But the Void type can crop up in a number of places. The most obvious is as the return type of a function. But it could also be useful in any place where a value might be unwittingly preserved. Its greatest uses are probably for the C builtin (or whatever the souped-up C is); and for generated code (whether on-the-fly evaled; or the output of a real code generator). It could also be used as a a hack to create non-existant attributes on a class. I would hope that, if you did attach properties to a void value, then they would go straight to the same bit-bucket as the value itself. (compile-time C properties are a different matter). Dave.
Re: Status Summary; next steps
> (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 you get the bool from $x.
$x.getBool()
$x.isTrue()
if( $x ) {
}
See the section on typecasting for more info...
> (3) Context. How to determine it, how to force it. Hypothesis: There
> is a one-to-one relationship between Type and Context, such that there
> is a context that matches every type, and a type that matches every
> context (except void).
This is not true in Perl5 as you only have scalar/list/void context. I can
see this changing or remaining the same depending on how well your lunch
digested:
my int $x = 2.2; # this either 1.) casts 2.2 to int context
# or 2.) 2.2 remains in scalar context, $x's
assignment operator does a trunc
I personally prefer 2. I would rather keep things simple and just allow
scalar/list/void context...perhaps also array and hash context now.
> (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc.
> Generic typecasting rules: how to define user classes that can typecast
> to/from str, int, bool, etc. This gets into Perl6 OO, but we may need
> to request some preliminary decisions before then, because the
> implications are substantial.
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. However, runtime
properties give me problems with this
my int $x = (0 but true);
if( $x or false ) {
}
Does the or evaluate to true or false? What if we want to compare the
numeric portion of $x.
if( int($x) or false ) {
}
Now is it false?
In the general case, I can't really see a need for typecasts. It is only
when paired with
runtime properties that they have some benefit. However, if there were ways
to easily
access the value vs. the property, then we could eliminate them completely.
Tanton
Re: C#/Parrot Status
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.
Re: Dynamic scoping (take 2)
> "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 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Status Summary; next steps
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 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 either a scalar or list "type", but only if it isn't that
type already.
So by Perl6 "casting", I mean the transformation of one type to
another, whether automatic:
my num $i = 5.0;
my str $s = $i; # cast $i to 'str'
or explicit:
my $i = str 5.0; # cast the literal number 5.0 to a str
Casting and context are closely related, and both are required (I would
hope) for multimethods. If you have a multimethod:
sub foo (int $var);
sub foo (str $var);
and you call it like this:
&foo($myval);
the multimethod dispatcher needs to know if $myval is closer to an
int, or a str, or something that can be easily/trivially cast to an int
or str. If I make a subclass of C called C, the &foo
dispatcher should know that a MyString is a str, and call the str-based
multimethod variant:
my MyString $mystring = MyString.new('hello');
&foo($mystring); # knows to call foo(str), not foo(int)
My hope is that there is little difference between builtin and
user-defined types/classes, such that both use the same syntax and have
the same features wrt context and casting:
my str $s = $var; # evaluate $var in str context
my MyClass $s = $var; # evaluate $var in MyClass context
my $s = str $var; # cast $var to str
my $s = MyClass $var; # cast $var to MyClass
my MyClass $myclass = MyClass.new;
my str $as_string = $myclass; # cast $myclass to string
my int $as_int= $myclass; # cast $myclass to integer
this implies that the want() function can identify context as
narrowly or as broadly as is needed:
# class str is scalar;
# class MyString is str;
my MyString $s = &foo('bar'); # in C context
such that within &foo:
want scalar; # TRUE
want str; # TRUE
want MyString; # TRUE
want hash; # FALSE
MikeL
Re: Status Summary; next steps
> 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 either a scalar or list "type", but only if it isn't that
> type already.
I would argue that these are not typecasts, but instead are context casts.
>
>
> Casting and context are closely related, and both are required (I would
> hope) for multimethods. If you have a multimethod:
>
> sub foo (int $var);
> sub foo (str $var);
>
> and you call it like this:
>
> &foo($myval);
>
> the multimethod dispatcher needs to know if $myval is closer to an
> int, or a str, or something that can be easily/trivially cast to an int
> or str. If I make a subclass of C called C, the &foo
> dispatcher should know that a MyString is a str, and call the str-based
> multimethod variant:
>
> my MyString $mystring = MyString.new('hello');
> &foo($mystring); # knows to call foo(str), not foo(int)
Yes, but this relies on compile time types, not typecasting. It was my
understanding
that the dispatcher would always operate on compile time types.
> My hope is that there is little difference between builtin and
> user-defined types/classes, such that both use the same syntax and have
> the same features wrt context and casting:
>
> my str $s = $var; # evaluate $var in str context
> my MyClass $s = $var; # evaluate $var in MyClass context
>
> my $s = str $var; # cast $var to str
> my $s = MyClass $var; # cast $var to MyClass
>
> my MyClass $myclass = MyClass.new;
> my str $as_string = $myclass; # cast $myclass to string
> my int $as_int= $myclass; # cast $myclass to integer
Ok, I think I was confused the way you phrased typecast. We are actually
talking
about constructors. I don't have a problem with constructing a new value
from
a previously existing value when possible though the use of constructors.
However,
that is not what I consider a typecast mechanism where you can cast any type
to
any other type all willy nilly.
Tanton
Re: Status Summary; next steps
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 something to argue over? :) (i.e., a first draft of these sections)
Re: Numeric Literals (Summary 5)
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 # WRONG, should be 0b0110
> 0O0123 # WRONG, should be 0o0123
> 0X00FF # WRONG, should be 0x00FF
>
> explicit radix:
>
> (radix 2-36)
>
> 20#1gj # base 20
> 20#1GJ # base 20 (identical)
> 20#1:G:J # base 20 (identical)
> 20#1_G_J # base 20 (identical)
> 20#1:16:19 # base 20 (identical)
> 20#1_16_19 # NOT identical, == 20:11619
> 20#1:1_6:19 # WRONG: colon form may not have underlines
>
> 20#0:0:1 # base 20
> 20#0:1 # base 20 (identical)
> 20#:1# base 20 (identical) (leading : is ok)
> :1 # WRONG, need radix specifier
> 20# # WRONG, need at least an '0'
> 1#0 # WRONG, radix must be >= 2
>
> 20#1_G.J # ok, radix point (e.g. float) allowed
> 20#1:16.19 # ok, radix point (e.g. float) allowed
> 10#1.1E5 # WRONG, no exp notation in explicit radix
>
> -20#1GJ # base 20 (negative)
> -20#1:16:19 # base 20 (negative)
> 20#-1GJ # WRONG, - is an operator, not part of the literal
>
>(radix 37-RADIX_MAX)
>
>256#0:253:254:255 # base 256
>256#:253:254:255# base 256 (identical)
>256#0_253_254_255 # WRONG, digit 253254255 doesn't
># exist in base 256.
>
>
> Other issues w/ literals:
>
> - radix <= 36, alpha digits may be upper or lowercase
> - radix > 36, only colon form is allowed, not alpha digits
> - underlines may appear ONLY between digits
> - colon form may therefore not have underlines
No 'therefore'. Your examples give such an example.
> - radix < 2 throws error
Is there a maximum?
> - negative sign goes before radix, e.g. -20#1GJ.
> - need to specify RADIX_MAX (platform dependent?)
I guess so. :-) May want to group those two.
> - explicit radix form may have radix point, '.',
> but cannot use exponential notation ('e')
>
> - can't have runtime radix, e.g. 2**8#10, because # binds tighter.
> - can't say (2**8)#10, because not a literal.
>
The examples are good and extrapolate nicely, but has the grammar been
defined somewhere (in one form or another)?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Re: More tests.
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 ;) conversion.t The int -> bit conversion doesn't actually convert anything...pehaps you meant bit instead of int? If you, in fact, did mean bit instead of int, then shouldn't -2 become 1 instead of 0...I would imagine that anything non-zero would go to 1? Also, same applies with num -> bit...no conversions were made. Right, those are mistakes. Woops :) Also, in the unimplemented & test, I didn't think & was special in a string. Instead, I thought we should use $() such that print "&(noret)" should be print "$(noret)"; Is this correct? Anyway, it looks good...keep up the good work. You're right, there is no &(); I'm not even sure how I came up with that... I fixed all of the other mistakes you found, thanks.
Re: Status Summary; next steps
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 work (lexically), you shouldn't be discussing it on p6d. Kicked back to p6l. The efficiency of storage isn't of your concern. Tackle the linguistical questions first: Should an explicit bool type be part of the language? If so, how should it work? C storing only a truth property but no value makes little sense in the context of the larger language. So does handling truth as something other than a property. > (3) Context. How to determine it, how to force it. Hypothesis: There > is a one-to-one relationship between Type and Context, such that there > is a context that matches every type, and a type that matches every > context (except void). Again... > > (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. > Generic typecasting rules: how to define user classes that can typecast > to/from str, int, bool, etc. This gets into Perl6 OO, but we may need > to request some preliminary decisions before then, because the > implications are substantial. and again... > > 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? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Status Summary; next steps
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)
NCI stuff (mostly) done
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 past horrendous, but it does work. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
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. Warnock bwarnock@(gtemail.net|raba.com)
Re: NCI stuff (even more mostly) done
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 from strings, fetches from PMCs and stores to PMCs now work. This should be enough to get most external interfaces working. Note that to add in signatures involves editing call_list.txt. I considered just permuting the hell out of the possibilities, but that got really big really fast. Plus from what I can see, 99% of them'd never get used anyway. As we come across libraries that we don't have a signature for, we should add them to call_list.txt. (At least until we can build the call headers ourselves) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Adding new function signatures to parrot's NCI call list
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 in a full library) as we'd rather not have nci.o get *too* big... If I've got things set properly, nci.c should get rebuilt if either call_types.txt or build_nativecall.pl change, but do feel free to add in other checks, just to make sure. I'd hate to have too much stale stuff hanging around. Also, at the moment I can't test this. (The dynaloading on Darwin only works on .bundle files not .dylib files (I think I know how to fix this), and my linux box's headers are all screwed up somehow) So if someone wants to pick a target library and try it out, well, that'd be fine with me. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dynamic scoping (take 2)
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 ;
> 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 )
>
> {
> my $x is yours ;
> my $y is yours ;
> my $z is yours ;
>
> 1...
>
> #alias %MY to topic so that it can be fetched from sub_a by "is given"
> $_ ::= \%MY ;
> sub_a ;
>
> 2...
>
> }
>
> sub sub_a (;$x is yours,
> $y is yours ) is given($CALLER_SYMB)
> {
> #alias variables from $CALLER_SYMB to the local variables if
> #requested
> $SUB_SYMB ::= \%MY ;
> for $SUB_SYMB.keys {
> if $SUB_SYMB{$_}.yours
> and $CALLER_SYMB{$_}.yours
>{
> $SUB_SYMB{$_} ::= $CALLER_SYMB{$_} ;
>}
> } ;
> $CALLER_SYMB = undef ; #but better if this happens at compile time
> # -- probably this have to be forced with
> #BEGIN
> 3...
>
> } ;
>
>
>
>
> arcadi
--
ralph
Re: Status Summary; next steps
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 assemble a full "Numerics" section from the docs we have, find any remaining holes, etc. I'll post next week for comments/revisions. The next Big Deals are: (1) String Interpolation. This was pretty well spelled out by A2, so there shouldn't be much to do except write it up, unless we want to make any additional requests. There's some issues that need to be finalized wrt Unicode, escaped chars, etc. I'm pretty familiar with all of the new string interpolation semantics, so I'll write this section up, unless someone else wants to do it (or is already doing it).
