Re: [perl #41237] [TODO] PMC Class name IDs will require a dot in front
Matt Diephouse wrote: Allison Randal via RT <[EMAIL PROTECTED]> wrote: > PMC Class name IDs ... will require a dot in front My preference is to eliminate the dot in classname IDs. Lodge your objections now, before it's made fact in 0.4.9. Allison I actually prefer the dot. I don't like the possible ambiguity between types and local variables: .local string MyClass MyClass = '...' $P0 = new MyClass # is this a type or a string? Capitalized variable names may be rare and/or bad practice, but it's bound to happen. There was talk on #parrot about how this still conflicts with macros, but those are rarer than variables. Also, if we decide that anything starting with a dot that doesn't have parens is a type, I could write: $I0 = typeof $P0 if $I0 == .Foo goto bar I know we're not optimizing PIR for human readability, but I've written a lot of it, so I appreciate the little things. :) A dot also indicates that this is not pure PASM, but rather PIR. The dot implies the token is pre-processed by IMCC (the type is looked up during parsing, IIRC), which is, IMHO, more consistent with the other dot-prefixed tokens from PIR. One could also think about it like this: the dot indicates the difference between a variable having a value during compile time or runtime, or, in other words, a dot-prefixed name is a variable during compile-time, and no-dot-prefixed name is a runtime variable. So: compile time: .local pmc p p = new .Hash # dot indicates ".Hash" is looked up during compile time by IMCC runtime: .local pmc p .local int hash_type hash_type = find_type "Hash" p = new hash_type # no dot means "hash_type" gets a value during runtime (the previous statement in this case, but usually it may not be as clear as this simple example) Just a thought, klaas-jan
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jan 15 14:00:04 2007 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 76 new + 375 open = 451 Created this week: 34 Closed this week: 25 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 41201 [TODO] Remove temporary conf hack in Configure.pl 41185 [BUG]: examples/shootout/regexdna.pir.input: Persistently failing test 41168 graceful "no compiler" error message? 2 - 3 weeks old 3 - 4 weeks old 4 - 5 weeks old 41097 Segfault in malformed get_results 5 - 6 weeks old 6 - 7 weeks old 41035 [BUG] Parrot segfaults in perl6 08-regex.t (GC/pointer bug?) 41031 bad links in docs/ROADMAP.pod 7 - 8 weeks old 40990 [BUG] Parrot segfaults in perl6 08-regex.t (GC/pointer bug?) 40972 Iterator over Env under Win32 8 - 9 weeks old 40923 test errors 9 - 10 weeks old 40830 [PATCH] Man-Chicken's awesome hackathon throw-away patches... 40826 Mac OS X and Dylib Funcs 40822 Pg NCI Test Makes Unportable Connection 40804 -j fails: Stack alignment of x86 JIT on Mac 10 - 11 weeks old 11 - 12 weeks old 40599 [NEW] Coding standards test of return statements 12 - 13 weeks old 13 - 14 weeks old 40490 Flat/Slurpy Named Parameter Passing Errors 14 - 15 weeks old 15 - 16 weeks old 16 - 17 weeks old 17 - 18 weeks old 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues Platform Severity Tag Lang aix 0abandoned 05005threads 0 Amber0 All 2fatal 3bounce0 BASIC0 bsdos 0High 1Bug 40 bc 0 cygwin6low 1compiler 0 befunge 0 cygwin_nt 0medium0configure 0 bf 0 darwin0none 0core 0 cola 0 dec_osf 0Normal1dailybuild0 forth0 dgux 0unknown 0docs 0 jako 0 dos 0Wishlist 3duplicate 0 Lisp 0 dynixptx 0 install 1 m4 0 freebsd 1 library 0 ook 0 generic 0 notabug 0 perl60 gnu 0 notok 0 plot 0 HPUX 0 ok0 punie0 irix 0 Patch21 python 0 irix640 regex 0 ruby 0 Linux 0 sendToCPAN0 scheme 0 lynxos0 Todo266 tcl 91 mac 0 unknown 0 urm 0 machten 0 utilities 0 Zcode0 macos 0 wontfix 0 MacOS X 0 mswin32 0 netbsd1 next 0 openbsd 1 os2 0 os390 0 other 0 powerux 0 qnx 0 riscos0 sco 0 Solaris 1 sunos 0 svr4 0 svr5 0 sysv 0 unicos0 unicosmk 0 unix 0 unknown 0 uts 0 vms 0 VOS 0 Win32 3 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 70 Will Coleda 56 [EMAIL PROTECTED] 46 jerry gay 34 Joshua Hoblitt 30 Matt Diephouse 28 Leopold Toetsch 26 Jerry Gay 25 Chip Salzenberg 22 Patrick R. Michaud 13 --- * Total Issues * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- This page is CPU intensive to create, it will be updated only once every 5 minutes
Re: [perl #41237] [TODO] PMC Class name IDs will require a dot in front
On Sun, Jan 14, 2007 at 11:58:10PM -0500, Matt Diephouse wrote: > Allison Randal via RT <[EMAIL PROTECTED]> wrote: > >> PMC Class name IDs ... will require a dot in front > > > >My preference is to eliminate the dot in classname IDs. Lodge your > >objections now, before it's made fact in 0.4.9. > > > >Allison > > I actually prefer the dot. I don't like the possible ambiguity between > types and local variables: > >.local string MyClass >MyClass = '...' >$P0 = new MyClass # is this a type or a string? Just to add my vote, I prefer the dot as well. Pm
[perl #41269] [PATCH] fix some failed test in F
On Sun Jan 14 00:09:35 2007, [EMAIL PROTECTED] wrote: > Attached patch fix some failed tests in F > when run C: > > [...] Could you verify that the bug exists in the latest revision? I'm not seeing the error when I run the tge tests (and I think this particular bug was fixed in r16520). Thanks! Pm
Re: Numeric Semantics
HaloO, Mark J. Reed wrote: I believe mod should be defined in the conventional way: x mod y = x - floor(x/y) * y, which does yield 0.8 for 3.2 mod 2.4. However, for 3.2 mod - 2.4 it yields -1.6. To get 0.8 you would have to round toward zero instead of taking the floor, and that complicates any computation that crosses zero. So, you are opting for the F-definition. Could you give examples where the E-definition makes problems when crossing zero? Looks like we need a host of division function pairs: fdiv fmodflooring division ediv emodeuclidean division rdiv rmodrounding division tdiv tmodtruncating division cdiv cmodceiling division Note that the div functions have signature :(Num, Num --> Int) and the mod functions have signature :(Num ::T --> T). When called with Ints the mod funtions also return an Int. There should be a pair of operators div and % that is aliased to one of the above according to a pragma. The F-definition seems to be the default by popular demand. The / operator always returns a Num or perhaps has signature :(Num --> Num ^ Int) such that 8 / 2 == 4 gives an Int result. Even 1.6 / 0.4 == 4 might return an Int. But this means that / has to run a divisibility test and rounding errors might spoil this. E.g. (4/3) / (1/3) == 4.03 is just almost an Int. The R-definition has the funny effect of returning a negative remainder even for positiv dividend and divisor. E.g. 8 rdiv 3 == 3 and 8 rmod 3 == -1. But this definition is used in the complex case of the Gaussian Integers. E.g. (12 + 5i) div (3 + 4i) == round(2.24 - 1.32i) == 2 - i and (12 + 5i) % (3 + 4i) == 2 BTW, we should define that the family of rounding functions floor, ceil, round and trunc all take a positiv modulus as their optional second argument that defines the jump width and height. The default is of course 1. E.g floor(1.3, 0.25) == 1.25 and floor(-2.7, 1.3) == -3.9. We could actually make these two optional positional parameters for width and height separately with the height the same as the width if not given and width defaulting to 1, as before. Regards, TSa. --
Re: Numeric Semantics
HaloO, I wrote: I cannot give an algorithm how to calculate the remainder. Even less do I know how to generalize it to full Complex. Since one wants the absolute value of the remainder less than the absolute value of the divisor the float result is *rounded* in the real and imaginary components separately. That is the rmod definition as outlined in my other mail in this thread. The fact that a remainder is negative for positive dividend and divisor is moot for complex numbers with their continuous "sign" in the range 0..2*pi in the polar representation. Regards, TSa. --
Re: Numeric Semantics
TSa writes: > Looks like we need a host of division function pairs: > > fdiv fmodflooring division > ediv emodeuclidean division > rdiv rmodrounding division > tdiv tmodtruncating division > cdiv cmodceiling division That depends on exactly what you mean by "we" and "need". I think it would be terrible to that many div and mod functions as a core part of the Perl language. Most people would rarely use any of them, and merely having them there at all slightly raises the barrier of entry to Perl, making the documentation just a little bit fatter. By all means have them available as modules. Presumably people who need this stuff in Perl 5 have already created Cpan modules providing them, and the same will happen in Perl 6. Smylers
