Re: Time::Local
On Wed, 17 Aug 2005, Sam Vilain wrote: Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact It's hardly short sighted to want leap seconds to be abandoned (not in Perl but world wide). The few people who _really_ care about syncing to midnight can still have them, but the rest of the world would be just fine with a leap hour every couple hundred years. synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Great, so now code that works in one environment throws a cannot find an up-to-date leap seconds table exception in another? Eek! -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Test::Code
On 8/11/05, Ovid [EMAIL PROTECTED] wrote:
X-Posted to Perlmonks (http://perlmonks.org/index.pl?node_id=483100)
I frequently write code that generates anonymous functions on the fly.
However, I often want to verify that these functions are correct
without executing them. To this end, I've started writing Test::Code.
Here's the start of my test suite (more or less):
BEGIN { use_ok 'Test::Code' or die }
ok defined *::is_code{CODE},
'is_code should be exported to our namespace';
is_code sub { 1 }, sub { 1 },
'Basic subs should match';
is_code sub { 2 }, sub { 1+1 },
'... even if the exact text is not the same';
is_code
sub { print((3 * 4) + shift) },
sub { print 3 * 4 + shift },
'... and parens that do not affect the meaning should work';
ok defined *::isnt_code{CODE},
'isnt_code should be exported to our namespace';
# How many people would spot the following bug, eh? It's something
# I know I've fallen victim to ...
isnt_code
sub { print (3 * 4) + shift },
sub { print 3 * 4 + shift },
'... and parens that do affect the meaning should fail';
isnt_code
sub { print for 1 .. 4 },
sub { for (1 .. 4) { print } },
'Subtle lexical issues should cause the match to fail (darn it)';
The last example really bugs me. I'd like for that to work, but it
doesn't. Also, variables with different names will fail, even if the
code is functionally identical. I'm currently using B::Deparse to
handle this, but in the long run, I'd really prefer to be able to use
PPI::Normal and fail back to B::Deparse.
Right now, this test module is not as useful as I would like due to
caveats listed above. Suggestions welcome.
One idea might be to try using Data::Dump::Streamer for your tests. It
will serialize the lexical context that the subroutine was compiled
with (including bound anonymous subroutines and their lexical
context).
A small hack (that i would be happy to work with you to put into the
next release) might allow you to rename the vars the in the sub as you
wanted. IE, it could normalize all vars that are lexical bound to the
subroutine so that comparisons would be easier. Of course by default
DDS wouldnt consider the subs the same unless the values of said vars
were the same too...
Yves
/me goes off to read about PPI.
--
perl -Mre=debug -e /just|another|perl|hacker/
Re: Ambiguity of parsing numbers with underscores/methods
Luke Palmer wrote: On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, 1_234; # surely 1234 1e23; # surely 1 * 10**23 1._5; # call of method _5 on 1? 1._foo; # call of method _foo on 1? 1.e5; # 1.0 * 10**5? 1.efoo; # call of method efoo on 1? 1.e_foo;# call of method e_foo on 1? 0xFF.dead; # call of method dead on 0xFF? I think we should go with the method call semantics in all of the ambiguous forms, mostly because no such method: Int::e5 is clearer than silently succeeding and the error coming up somewhere else. Luke 1.e5# all of these... 1._e5 # 1._0e5 # 1.e_0_5_# == 1 * 10^5? The longest-possible-token metarule, common among languages, would want all of these to be numbers. I see that perl5's lexer has this rule (3rd edition, p49); is not perl6's specced to have it as well? Likewise, if hex numbers allow fractions, 0xDE_AD.BE_EF # 57005.7458343505859375 ? 0xde_ad.be_ef # same should be taken as a number. (Naturally 'e' as exponent marker is here problematic.) If one wants to call a method on a number, surely one may follow the usual advise and write 1 ._5 1 ._foo 1 .efoo 1 .e_foo 0xFF .dead ? -- Roger Hale
Re: GC API from discussion
On Tue, 16 Aug 2005 20:14:43 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] Let's define some terms: These are all very good and I'm going to incorprate them in the API docs. scope/origin - where objects are created I would refine this one. origin scope - The lexical scope where an object was created. current scope - The lexicial scope where this thread is currently executing. [...] timelyness - the property of an object such that it's finalization subroutine is called the moment it becomes unreachable. This is important for objects using finalizers for resource management, especially when an unreleased resource could cause deadlock. This should be changed, timelyness will not prevent deadlock. However it will prevent resource starvation aka livelock. [...] The aspects of control we need: scope - which objects get cleaned up priority - what performance tradeoffs we want to make delay - whether or not the normal program flow will ever be paused when it is known that no timely objects need to be destroyed. Also possibly the maximum amount of time (in milliseconds?) that a GC iteration may take. timelyness - whether all objects, some objects (That are marked using 'but' or by their class), or no objects should be checked for timely destruction finalization - whether objects should be cleaned up at all Looks good, I would also add to this optimisation - giving infomation to the GC to allow it to work more effectivly. Actually, since to my naive eyes it looks like the GC is a first class object the problem can probably be solver better by adding your own. I'm not sure that replacing the GC is going to be easy, I expect thats going to involve heavy magic. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote:
On 8/16/05, Tim Bunce [EMAIL PROTECTED] wrote:
I was a little dissapointed that there wasn't greater focus on using
Perl6 features - especially as it would have helped kick-start my own
understanding of Perl6 topics that I expect to be significant (such as
Roles and Pairs, to pick two at random). Perhaps the community of
Perl6+DBI users is too small at this point.
I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes
feel like DBI1 fell into: the curse of being designed before the idioms and
Best Practices of API design in the language have been established.
I think it'll take years, and much actual production experience building
Perl 6 modules before the community learns what works and what doesn't for a
Perl 6 API (let alone implementation). So trying to pin down a properly
Perl-6-ish API before Perl 6 is even through the language design process
strikes me as a Very Bad Idea.
I remember the early years of Perl 5 development, when a new feature was
added there'd be a period of over-zealous use followed by a hangover as
all the problems and edge-cases became apparent.
With Perl 6 there's going to be some almighty hangovers :)
That could explain why there were so few Perl 6 related suggestions: no one
knows how to design a good Perl 6 API yet, and any guess is very likely to
be wrong. Instead, suggestions have focused on what we do know: DBI in Perl
5 and Perl 5 API design. In that spirit, here's my suggestion: no more
configuration through magic/tied hashes. (e.g., $dbh-{'AutoCommit'} = 1)
(Probably goes without saying, but I wanted to make sure someone said it ;)
Hey, it seemed like a good idea at the time :)
(Actually it's still a good idea in many ways, especially in relation to
its behaviour for unknown driver-private attributes and DBI version skew.
But it does need rethinking for DBI2.)
Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999
after that. Basically, get one or two willing DBD authors who will help you
to test and then throw away the first two attempts at a Perl 6 DBI API.
Then at least you'll have some confidence when you commit to a DBI 2.0
API...which will be several years after Perl 6 is released, I hope.
It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but
it'll be DBI 2.0.00xxx for quite a while :)
Of course, *someone* has to go first so we can all learn what works best
in Perl 6. I'm just saying that maybe DBI, which took the bullet in Perl 5
to some degree, is under no obligation to do so again. (This assumes that
we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of
course...)
I'm in no great rush as one of my core assumptions is that DBI v1 will
be available in Perl 6 via either Ponie or direct embedding of libperl5.so.
Tim.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 01:16:19PM -0700, Darren Duncan wrote: At 4:04 PM +0100 8/16/05, Tim Bunce wrote: I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Perhaps the community of Perl6+DBI users is too small at this point. One way that the Perl 6 thought process can be started is in considering the design principles laid out in Damian's new Best Practices book. I said to Damian at OSCON that I thought the practices he was putting forward were intended to get people thinking now in Perl 5 about ways of doing things that will be the natural way of doing them in Perl 6; he said something along the lines that I had good insight. So these practices are probably some good things to keep in mind as we move forward. Yeap. I'm awaiting delivery of that one, plus several others including MJDs Higher Order Perl. Now, speaking specifically in Perl 6 terms ... I suggest that DBI v2 has a more formal separation between interface and implementation. The parts of DBI can be grouped into these categories: 1. Role definitions for the public behaviour/API that DBI-using apps see. 2. Role definitions for the behaviour/API that DBI drivers/engines must have. 3. Class definitions that implement #1 and invoke #2. 4. Class definitions having a generic implementation of #2 or parts thereof, which a driver/engine can complete or override. 5. Basic utility classes that exist to the side of the above, which such as DBI drivers can optionally use to do some common things without rolling their own. 6. A basic test suite. I agree entirely - except for the word basic in item 6 :) One of the key things missing from DBI 1 was a test suite that could be reused to test/validate different drivers. Note that what you've described is essentially just what JDBC is. Only JDBC has a comprehensive driver test/validate suite. At the moment I'm thinking in terms of a Parrot-level DBDI modeled on JDBC, with a thin Perl6-specific DBI layered on top. Other languages targeting Parrot would have their own thin language adaption layers. I also recommend expelling some parts of the DBI distro into their own distros and/or leaving them to third parties. A prime example is the proxy server/client stuff; that should be a separate project. I'd like to see someone do a stateless proxy sometime (as I've outlined previously) and I'll be ensuring there's a serializable RowSet object available - but, yes, such things should be separate. Tim.
Re: Parrot - Java integration
On Tue, Aug 16, 2005 at 04:39:06PM +0200, Nattfodd wrote: Tim Bunce wrote: Anyone given any thought to Parrot - Java integration? Possible? Practical? How much would would be involved? Tim. If I'm not mistaken, it's even one of the summer of code projects (see http://www.perlfoundation.org/gc/grants/2005-googlesoc.html and http://www.perlfoundation.org/news/2005/socperljavaintegration.html). I'd looked at that and it's certainly interesting, but it's focused on Perl 5, like Inline::Java. May be should you drag David Rusek to p6i :) I've CC David, and also Patrick LeBoutillier, author of Inline::Java. Hi Dave. Any news on progress? (The last blog update was several weeks ago and the code repository's isn't available yet.) Hello Patrick. Would you be interested in working on Parrot - Java integration? Tim.
Re: GC API from discussion
On Wed, Aug 17, 2005 at 00:59:52 +0100, Adrian Howard wrote: Sorry - I don't understand. If I do: call_to_external_c_library_foo( $foo ); call_to_external_c_library_bar( $bar ); Then how does the compiler know that $foo is only used temporarily and can be moved around, while $bar is cached in the external library and shouldn't be moved by any heap de-fragmentation that the garbage collector might do? $foo points to the object structure, which also has a static handle, that is allocated in a static arena (something that isn't defragmented or copied by the GC). this handle is simply a pointer that points back to the object structure (and is updated as this object moves). The object has it's address, and it has the object's address. When an object is given to a foreign function, that function gets the handle to the object (the address of the staticly located pointer to the dynamically located object). When the compiler is sure that an object is never ever given to an external function, it can omit the code that keeps handles to the objects. This is just a small solution for a GC scheme that copies or defragments - I personally doubt that this will be the case any time in the forseeable future, but it's runtime and GC dependant, and there are other solutions, this is just one. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgpx98dfxTWat.pgp Description: PGP signature
Re: GC API from discussion
On Tue, 16 Aug 2005 19:46:29 +0300, Yuval Kogman [EMAIL PROTECTED] wrote:
[...]
On Tue, Aug 16, 2005 at 05:32:50 -, David Formosa (aka ? the Platypus) =
wrote:
This is getting me thinking though:
=20
$*RUNTIME.Memory.GarbageCollector.dispose($object); # force it,
# even if it should be alive
=20
Isn't that what we have undefine(...) for?
No:
my Dog $spot .=3D new;
my $spot_II =3D $spot; # another reference
$*RUNTIME.Memory.GarbageCollector.dispose($spot);
In the GC API this would be
sub GC::dispose (Any $thing is rw,+Bool $recursive=Bool::false -- Int) {...}
And also thinking about it.
sub GC::size (Any $thing,+Bool $recursive=Bool::false -- Int) {...}
Use the GC to sweep accross an object and tell you the size of the object in
memory.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 12:12:02PM -0700, Dean Arnold wrote: Tim Bunce wrote: And nobody mentioned JDBC as a potential model. Odd that. I was sorely tempted to do so (and did mention it a few times in my posts, along w/ ODBC and ADO.NET), but there are some things about JDBC which rub me the wrong way (e.g., explicit set/get methods for every data type no true binding support; the lame bulk interface; etc.). I'm not crazy about all the DataSource business, either. I think all those are fixable for Perl/Parrot. Same for the painful need for try catch every few lines. But the threading support, the Factory pattern presented by Statement classes, the nice separation of metadata from statements/resultsets/connections, and XA would certainly be nice models to follow. That's what I'm thinking. Not only nice but also well proven and widely understood. One area of concern I have is the ability to subclass. I've been struggling w/ trying to subclass+extend JDBC the same way I subclass DBI for some things, and haven't found any app-neutral solutions just yet (trying to wrap another JDBC driver and expose its driver specific methods seems to require a lot of extra heavy lifting). There are lots of people who have problems or complaints about subclassing the DBI :) Tim.
Re: GC API from discussion
On Wed, Aug 17, 2005 at 05:06:55 -, David Formosa (aka ? the Platypus)
wrote:
This should be changed, timelyness will not prevent deadlock. However
it will prevent resource starvation aka livelock.
What I meant is deadlock due to resource starvation:
my $semaphore = Sempahore.new(5);
my $object = Moose.new($semaphore); # takes as much as it likes,
# destructor releases semaphore
...
undefined($object);
my $other = Moose.new($semaphore); # this might or might not
# hang till the GC kicks in
BTW, we need an interface like:
class Resource { # a mutex of sorts
has enumLocked Free $:state = Free;
method claim ($claimee = $?CALLER::SELF) : atomic {
$:state = Locked;
$claimee but GC::timely GC::append_finalize({ $:state =
Free });
}
}
then an object can say:
class Object {
method use_this ($resource){
$resource.claim;
}
}
And without worrying about adding a finalizer of it's own (the added
finalizers don't conflict either, and due to post order happen
before the class's finalizer).
I'm not sure that replacing the GC is going to be easy, I expect
thats going to involve heavy magic.
If the runtime has an interface where it allows you to replace the
GC with some pluggable GCs it supports, then why not?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does not drink tibetian laxative tea: neeyah!
pgpWeYZw6jpT8.pgp
Description: PGP signature
Re: Modules::Starter question
Robert wrote: I am creating my first module (finally) and I was told a while ago to use Module::Starter. Which I did. I am fine there. When I look at the code generated I see that all the POD stuff is inline while I prefer to see POD stuff at the end. Is the inline POD the current preferred way? If it is, I am fine with that and will continue to chug along. If not, I will move it to the end and I would make a request to the M::S author to have a command line switch added to indicate which POD style to use (defaulting to whatever the auther wishes of course). About the most saliant point I can give on this is that it's easy to automate the endification of POD, but very very hard to automate the inlinification of it. In my codegen stuff I do it this way. Default generation is inline, with a flag to automatically endify the POD (or remove it outright) if the client prefers. PPI::Token::POD has a -merge method, maybe you would like to look at writing a POD::Endify to encapsulate all this? :) Adam K
Re: my $pi is constant = 3;
: If not a special form, should this work? : : my $pi is constant; : $pi = 3; That could be made to work by defining constant to mean you can assign to it if it's undefined. But then it gets a little harder to reason about it if $pi can later become undefined. I suppose we could disallow undefine($pi) though. Which would basically throw away compile-time optimizations relating to constants wouldn't it? Adam K
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 16:59:12 -0400, Mark Reed wrote:
On 2005-08-16 16:45, Nicholas Clark [EMAIL PROTECTED] wrote:
I'd find it hard defending a language that treated 1.e5 as a method call.
Guess we shouldn't sign you up for the Ruby Defense League, then?
irb(main):001:0 1.e5
NoMethodError: undefined method `e5' for 1:Fixnum
from (irb):1
irb(main):002:0
Well, I think the only sane alternative is to implement AUTOMETHOD
on int that makes it a float:
method AUTOMETHOD {
# parse scientific notation of method name (e.g. e5),
# and apply it to the invocant, returning a float
}
There, no ambiguity.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!
pgpmhsj4KhmEZ.pgp
Description: PGP signature
Re: DBI v2 - The Plan and How You Can Help
On 8/17/05 5:39 AM, Tim Bunce wrote: On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote: I think it'll take years, and much actual production experience building Perl 6 modules before the community learns what works and what doesn't for a Perl 6 API (let alone implementation). So trying to pin down a properly Perl-6-ish API before Perl 6 is even through the language design process strikes me as a Very Bad Idea. I remember the early years of Perl 5 development, when a new feature was added there'd be a period of over-zealous use followed by a hangover as all the problems and edge-cases became apparent. Early years? Just look at inside-out objects or MI with NEXT today! Maybe it never ends...for some people, anyway ;) With Perl 6 there's going to be some almighty hangovers :) Understatement of the week :) Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999 after that. Basically, get one or two willing DBD authors who will help you to test and then throw away the first two attempts at a Perl 6 DBI API. Then at least you'll have some confidence when you commit to a DBI 2.0 API...which will be several years after Perl 6 is released, I hope. It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but it'll be DBI 2.0.00xxx for quite a while :) I just meant that there should be several, possibly very different, attempts at DBI2 before the real DBI2 API is pinned down. Making the experiments have a 1.99x version helps to prevent people from thinking this is DBI2! when it's really just the first or second prototype. As for the actual 1.x DBI reaching 1.99, well, all I can say is to start using that hundredths place! :) -John
Re: my $pi is constant = 3;
On Wed, Aug 17, 2005 at 01:56:35PM +1000, Adam Kennedy wrote: : : : If not a special form, should this work? : : : : my $pi is constant; : : $pi = 3; : : That could be made to work by defining constant to mean you can assign : to it if it's undefined. But then it gets a little harder to reason : about it if $pi can later become undefined. I suppose we could : disallow undefine($pi) though. : : Which would basically throw away compile-time optimizations relating to : constants wouldn't it? You could still reason about it if you can determine what the initial value is going to be. But certainly that's not a guarantee, which is one of the reasons we're now calling this write/bind-once behavior readonly and moving true constants to a separate declarator: my $pi is readonly; $pi = 3; vs constant $pi = 3; or constant Num pi = 3; or if you like, even constant π = 3; Larry
Re: my $pi is constant = 3;
On Wed, Aug 17, 2005 at 08:47:18AM -0700, Larry Wall wrote:
: That could be made to work by defining constant to mean you can assign
: to it if it's undefined. But then it gets a little harder to reason
: about it if $pi can later become undefined. I suppose we could
: disallow undefine($pi) though.
If you can assign it when it contains an undefined value, bad
things happen:
sub f ($x is readonly) { $x = 10 }
my $a; f($a);
Compare this with:
my $x is readonly;
$x = 10;
If it is defined as bound to a immutable value cell, both cases
above would fail, which is imho the easiest to explain.
You could still reason about it if you can determine what the initial
value is going to be. But certainly that's not a guarantee, which
is one of the reasons we're now calling this write/bind-once behavior
readonly and moving true constants to a separate declarator:
my $pi is readonly;
$pi = 3;
The question remains, whether you can bind the readonliness away:
my $pi is readonly; # undef at this point
my $e is rw = 2.7;
$pi := $e;
$pi = 9;
I can argue both sides -- rebindable is easier to implement, but
non-rebindable is perhaps more intuitive.
Thanks,
/Autrijus/
pgppQH8aaeZBP.pgp
Description: PGP signature
Re: t/dynclass/gdbmhash.t failures
On Mon, 15 Aug 2005, Tim Bunce wrote:
Configure.pl said
Determining if your platform supports gdbm.yes.
But t/dynclass/gdbmhash.t fails completely:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13
with errors like:
# './parrot --gc-debug /Users/timbo/perl/parrot/t/dynclass/gdbmhash_1.pir'
failed with exit code 42
t/dynclass/gdbmhashNOK 2
# Failed test (t/dynclass/gdbmhash.t at line 56)
# got: 'no extension: file 'libgdbm'
# '
This is on OSX 10.4 with a recent svn update:
Last Changed Rev: 8966
Last Changed Date: 2005-08-15 04:57:58 +0100 (Mon, 15 Aug 2005)
Yes, I've been seeing that same failure for ages on Solaris. The gdbmhash
test has never worked for me; I had just assumed it was the same for
everyone else too.
The error message is, at best, unhelpful. I'd suggest applying the
patch below and then rerunning the test.
Here's some of what's going on: In src/dynext.c, get_path() tries to open
libgdbm. It has the following algorithm: First it tries to add an
extension PARROT_LOAD_EXT to libgdbm. (I'd guess that the extension used
in config/init/hints doesn't match the extension used when gdbm was built
for OS X.) get_path() then calls src/library:Parrot_locate_runtime_file()
to try to look in various standard paths. That is failing.
Finally, after trying various prefixes, get_path() simply tries finding
libgdbm without any extensions. However, Parrot_locate_runtime_file()
throws the internal_exception no extension in that case, so it's
pointless.
The patch below lets you call Parrot_locate_runtime_file() without any
extension. That will also fail to find a bare libgdbm. However, and
here's the point, get_path() will report the result from dlerror(), and
you'll get a useful error message back.
You can then take that error message, see what Parrot was looking for, and
see what the libgdbm file is actually called on your system.
--- parrot-current/src/library.cTue Aug 16 13:22:34 2005
+++ parrot-andy/src/library.c Tue Aug 16 15:46:49 2005
@@ -212,9 +212,11 @@
* if the extension is given use it
* TODO if not try extensions according to type
*/
+/*
if (!ext) {
internal_exception(UNIMPLEMENTED, no extension: file '%s',
file_name);
}
+*/
/* use absolute paths as is */
#ifdef WIN32
--
Andy Dougherty [EMAIL PROTECTED]
Re: Parrot - Java integration
On Mon, Aug 15, 2005 at 08:07:22PM +0100, Tim Bunce wrote: Anyone given any thought to Parrot - Java integration? I have been looking at IKVM: http://www.ikvm.net/ It's basically a full Java environment but using CLR instead of JVM as the underlying runtime. The JIT conversion from Java bytecode to CIL is very interesting. It's already reasonably mature for serious applications. Thanks, /Autrijus/ pgpJne9jAPM8l.pgp Description: PGP signature
Re: t/dynclass/gdbmhash.t failures
--- parrot-current/src/library.cTue Aug 16 13:22:34 2005
+++ parrot-andy/src/library.c Tue Aug 16 15:46:49 2005
@@ -212,9 +212,11 @@
* if the extension is given use it
* TODO if not try extensions according to type
*/
+/*
if (!ext) {
internal_exception(UNIMPLEMENTED, no extension: file '%s',
file_name);
}
+*/
/* use absolute paths as is */
#ifdef WIN32
this patch causes gdbm tests to be run on win32 when gdbm is
installed, but the tests all fail with a message similar to
t\dynclass\gdbmhashNOK 1# Failed test
(t\dynclass\gdbmhash.t at line 43)
# got: 'GDBMHash
# Couldn't load 'gdbm3': unknown reason
# Couldn't load 'gdbm3': unknown reason
# '
# expected: 'GDBMHash
# '
applied as r8980.
~jerry
ANN: Test.Simple 0.20
Fellow Testers, I give you Test.Simple 0.20. This latest version of my port of Test::Simple and Test::Harness to JavaScript now supports pure .js test scripts in the browser harness. Details and change log here: http://www.justatheory.com/computers/programming/javascript/ test_simple-0.20.html Enjoy! David
scopes of $?SELF and $?CLASS
Hello all,
I tried to search for this answer in AES12, but I did not see anything,
and a perl6.lang search just brought up the whole $_.method vs.
./method debate (which was too much to shlog through).
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
Are these (magical) globals who only have bound values in certain
contexts? If that is so, what value do they have outside of a valid
context? undef? or is attempting to accessing the value a runtime
exception?
Or ...
Is it a syntax error to access them outside of a valid scope, and
therefore caught at compile time? In this case, then it seems to me
that they are not behaving as global variables so much as they are
behaving like language keywords.
Now as for the valid contexts.
The obvious one is that they are both valid within a method. I asumme
that $?SELF is bound to the invocant, and $?CLASS is bound to the class
the method was defined within. It seems to me that this also mean that
in a class method, that $?SELF == $?CLASS?
Also (IIRC) we discussed $?CLASS being valid inside a class Foo { ... }
block at the hackathon. Would mean that something like this should be
possible.
class FooLoggerProxy is Foo {
has Logger $.logger;
for ($?CLASS.meta.superclasses()) - $super {
for ($super.meta.getmethods()) - $method {
$?CLASS.meta.add_method($method.label = method {
$?SELF.logger.log($method.label ~ has been called);
return $method.do([EMAIL PROTECTED])
});
}
}
}
I am not sure if there are any other valid contexts other than inside a
method or a class composition block. At least none that I can think of.
Thanks,
Stevan
Re: scopes of $?SELF and $?CLASS
Hi,
Stevan Little wrote:
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
Are these (magical) globals who only have bound values in certain
contexts? If that is so, what value do they have outside of a valid
context? undef? or is attempting to accessing the value a runtime
exception?
hm, I've thought of these as follows:
class Foo {...}# is really
class Foo {
my $?CLASS := Foo;
...;
}
method bar($self:) {...} # is really
method bar($self:) {
my $?SELF := $self;
...;
}
The obvious one is that they are both valid within a method. I asumme
that $?SELF is bound to the invocant, and $?CLASS is bound to the
class the method was defined within. It seems to me that this also
mean that in a class method, that $?SELF == $?CLASS?
I think so, too.
Also (IIRC) we discussed $?CLASS being valid inside a class Foo { ...
} block at the hackathon. Would mean that something like this should
be possible.
class FooLoggerProxy is Foo {
has Logger $.logger;
for ($?CLASS.meta.superclasses()) - $super {
for ($super.meta.getmethods()) - $method {
$?CLASS.meta.add_method($method.label = method {
$?SELF.logger.log($method.label ~ has been
called); return $method.do([EMAIL PROTECTED])
});
}
}
}
I'd opt for yes.
I am not sure if there are any other valid contexts other than inside
a method or a class composition block. At least none that I can think
of.
role, submethod?
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : 1.e5# all of these... : 1._e5 # : 1._0e5 # : 1.e_0_5_# == 1 * 10^5? The last three are illegal because underline is allowed only between digits. : The longest-possible-token metarule, common among languages, would want : all of these to be numbers. I see that perl5's lexer has this rule (3rd : edition, p49); is not perl6's specced to have it as well? If it's not a metarule, it's at least a metametarule. : Likewise, if hex numbers allow fractions, : : 0xDE_AD.BE_EF # 57005.7458343505859375 ? : 0xde_ad.be_ef # same : : should be taken as a number. (Naturally 'e' as exponent marker is here : problematic.) It's a problem even without fractions. I expect we can just disallow the exponent at that point and rely on constant folding. Or maybe there's some colon trickery we can do, so the general form might be something like: 16:abcd.ef:+23. (I'm presuming the exponent is always decimal, like the radix.) Of course, then someone will suggest that infix :+ means * 10 ** and we get things like $foo:+23. So maybe we should come up with a better way to write that and then just go the constant folding route. 16:abcd.ef*e(23) maybe, if you don't mind clobbering the e() function. But we can always stick with 16:abcd.ef*10**23. The situation probably doesn't arise often enough to justify syntactic sugar. I suppose I could just barely see dropping the 10 there to get 16:abcd.ef***23, but then we'd have to put up with $foo ***= 23; : If one wants to call a method on a number, surely one may follow the : usual advise and write : 1 ._5 : 1 ._foo : 1 .efoo : 1 .e_foo : 0xFF .dead : ? Yes, that's a convenient escape. But really, arguments from principle aside, the underlying question is what someone will see if they look at 1.e5, and I suspect most people will see a number with an exponent. This is a spot where Ruby violates Least Surprise, at least for people who aren't used to seeing methods hanging off of literals. Larry
Re: Ambiguity of parsing numbers with underscores/methods
On Wed, Aug 17, 2005 at 11:37:26AM -0700, Larry Wall wrote: On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : 1.e5# all of these... : 1._e5 # : 1._0e5 # : 1.e_0_5_# == 1 * 10^5? The last three are illegal because underline is allowed only between digits. ...yet Perl5 accepts them. So Perl6 is more restrictive? (Which is good, because that's how Pugs currently implements them) Thanks, /Autrijus/ pgpOmp2xwJGou.pgp Description: PGP signature
Re: scopes of $?SELF and $?CLASS
On Aug 17, 2005, at 2:28 PM, Ingo Blechschmidt wrote:
Hi,
Stevan Little wrote:
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
Are these (magical) globals who only have bound values in certain
contexts? If that is so, what value do they have outside of a valid
context? undef? or is attempting to accessing the value a runtime
exception?
hm, I've thought of these as follows:
class Foo {...}# is really
class Foo {
my $?CLASS := Foo;
...;
}
method bar($self:) {...} # is really
method bar($self:) {
my $?SELF := $self;
...;
}
Yes, this is how I saw it too.
The obvious one is that they are both valid within a method. I asumme
that $?SELF is bound to the invocant, and $?CLASS is bound to the
class the method was defined within. It seems to me that this also
mean that in a class method, that $?SELF == $?CLASS?
I think so, too.
Also (IIRC) we discussed $?CLASS being valid inside a class Foo { ...
} block at the hackathon. Would mean that something like this should
be possible.
class FooLoggerProxy is Foo {
has Logger $.logger;
for ($?CLASS.meta.superclasses()) - $super {
for ($super.meta.getmethods()) - $method {
$?CLASS.meta.add_method($method.label = method {
$?SELF.logger.log($method.label ~ has been
called); return $method.do([EMAIL PROTECTED])
});
}
}
}
I'd opt for yes.
I am not sure if there are any other valid contexts other than inside
a method or a class composition block. At least none that I can think
of.
role, submethod?
I think in a Role, $?SELF would still be the invocant in a method, and
$?CLASS would (eventually) bind to the class the role was composed
into.
As for submethods, I see them like this:
submethod foo () { ... }
is really ..
submethod foo () {
next METHOD unless $?SELF ~~ $?CLASS;
}
At least that is how larry explained to me about a month ago.
Stevan
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
Re: scopes of $?SELF and $?CLASS
On Wed, Aug 17, 2005 at 02:15:56PM -0400, Stevan Little wrote:
: So, onto my question, I am wondering what are the valid scopes for
: $?SELF and $?CLASS.
:
: Are these (magical) globals who only have bound values in certain
: contexts? If that is so, what value do they have outside of a valid
: context? undef? or is attempting to accessing the value a runtime
: exception?
:
: Or ...
:
: Is it a syntax error to access them outside of a valid scope, and
: therefore caught at compile time? In this case, then it seems to me
: that they are not behaving as global variables so much as they are
: behaving like language keywords.
They are variables known to the compiler but whose bindings change
during the course of the compile, so they tend to behave more like
lexically scoped entities, at least for any of them that the compiler
to save and restore. In a sense, they're lexical to the program
but dynamic to the compiler. So something like $?LINE does not
necessarily scope lexically, but the compiler does know where $?SELF
is valid and where it isn't, and which invocant to map it to when
it is valid.
: Now as for the valid contexts.
:
: The obvious one is that they are both valid within a method. I asumme
: that $?SELF is bound to the invocant, and $?CLASS is bound to the class
: the method was defined within. It seems to me that this also mean that
: in a class method, that $?SELF == $?CLASS?
:
: Also (IIRC) we discussed $?CLASS being valid inside a class Foo { ... }
: block at the hackathon. Would mean that something like this should be
: possible.
:
: class FooLoggerProxy is Foo {
: has Logger $.logger;
: for ($?CLASS.meta.superclasses()) - $super {
: for ($super.meta.getmethods()) - $method {
: $?CLASS.meta.add_method($method.label = method {
: $?SELF.logger.log($method.label ~ has been called);
: return $method.do([EMAIL PROTECTED])
: });
: }
: }
: }
:
: I am not sure if there are any other valid contexts other than inside a
: method or a class composition block. At least none that I can think of.
If there are more they will become obvious as we go along. $? variables
that scope lexically are probably just temp or let variables in
the Perl grammar, so they won't be hard to monkey with if we need to.
Larry
What will happen if the attribute's names are the same but declared with different keyword?
class T
{
has $.a =1;
my $.a=2;
};
my T $o .= new;
$o.a().say;
What the result will be please?
1 or 2?
Or an error?
Thanks,
Xinming
Re: What will happen if the attribute's names are the same but declared with different keyword?
On Thu, Aug 18, 2005 at 03:33:35AM +0800, Yiyi Hu wrote:
: class T
: {
: has $.a =1;
: my $.a=2;
: };
: my T $o .= new;
: $o.a().say;
:
: What the result will be please?
: 1 or 2?
: Or an error?
Definitely a compile-time error. You can't declare the same lexical
name even if the declarator is different. But even if that were
allowed, you also may not declare two attributes that generate an
accessor of the same name.
Larry
Re: scopes of $?SELF and $?CLASS
On Wed, Aug 17, 2005 at 02:42:57PM -0400, Stevan Little wrote:
: I think in a Role, $?SELF would still be the invocant in a method, and
: $?CLASS would (eventually) bind to the class the role was composed
: into.
Yes, such things stay generic as long as they need to, and no longer.
: As for submethods, I see them like this:
:
: submethod foo () { ... }
:
: is really ..
:
: submethod foo () {
: next METHOD unless $?SELF ~~ $?CLASS;
: }
:
: At least that is how larry explained to me about a month ago.
Can't use ~~ for that, since ~~ implies does, which is not an
exact class match. Probably need
next METHOD unless $?SELF.class =:= $?CLASS;
or some such. Except that BUILDALL/DESTROYALL have to be able to
invoke submethods on partial objects whose actual class is not the
same as the submethod, so there needs to be some way of forcing
$?SELF to consider itself in $?CLASS temporarily for infrastructural
purposes. Maybe it's as easy as temp $obj.class := $tmpclass
in the BUILDALL/DESTROYALL dispatcher. I dunno.
Larry
Re: Ambiguity of parsing numbers with underscores/methods
On Thu, Aug 18, 2005 at 02:40:12AM +0800, Autrijus Tang wrote: : On Wed, Aug 17, 2005 at 11:37:26AM -0700, Larry Wall wrote: : On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : : 1.e5# all of these... : : 1._e5 # : : 1._0e5 # : : 1.e_0_5_# == 1 * 10^5? : : The last three are illegal because underline is allowed only between : digits. : : ...yet Perl5 accepts them. So Perl6 is more restrictive? Yes. Larry
Hoping that Params::Validate is not needed in Perl6
One of the things I'm looking forward to in Perl6 is greatly improved
sub/method signatures.
I'm hoping that this will eliminate the need for anything like
Params::Validate, which IMO is a nasty hack to make up for a serious
weakness in Perl5.
I'm going to go over the various features in P::V and see if there are
equivalents in Perl6, and bring up any questions I have. I think this
will be interesting for folks still new to P6 (like myself) and existing
P::V users (I think there's a fair number, but maybe I flatter myself ;)
Mandatory vs. Optional Parameters
This is a pretty straightforward one in P6, I think. Parameters can be
marked as required with is required like this:
sub date ($year, ?$month, ?$day) # positional
sub date (+$year is required, +$month, +$day) #named
This is ok but frankly I'm not too keen on the fact that for positional
subs, the default is required, but for named params it's the other way
around.
Wouldn't it clearer to just use a leading ?+ for optional named params?
Default Values
sub date ($year, ?$month = 1, ?$day = 1)
sub date (+$year is required, +$month = 1, +$day = 1)
Again, nice and straightforward.
Type Validation, isa, can
Params::Validate allows for several ways to check the _value_ of a
parameter. One way is to specify a primitive type like SCALAR or
ARRAYREF. In P6 we have that with this:
sub date (Scalar +$year is required, ...)
I'm not sure is Scalar is a valid type though, but that's ok because we
have better types built in. In this case we should really use Int for a
year.
P::V also allows one to specify a class membership (isa) or one or more
methods (can) a given object/class must have. In Perl6 we can just
specify a class:
sub transmit (Receiver $receiver)
If I understand this correctly, Receiver is a role here, and one that many
different classes may use/implement. This basically combines the isa
can concepts. Instead of specifying required _methods_, we specify the
role, which seems conceptually cleaner anyway.
Regexes and Callbacks
P::V lets you validate a value based on a regex or one or more callbacks.
I think these can be replaced with subtypes, which is one of the most
exciting new P6 features (for me).
So instead of this (Perl5 P::V):
{ size = { callbacks =
{ 'is a valid month' = sub { $_[0] = 1 $_[0] = 12 }
we can now do this:
my subtype Month where { 1 = $^s = 12 }
This is so freaking awesome!
Then we just reference the subtype in our sub declaration:
sub date { $year, Month ?$month = 1, Day ?$day = 1 }
Subtypes can also be defined as regexes:
my subtype PerlIdentifier where / +alpha+[_] +alpha+digit+[_]* /;
(not 100% sure on that rule but you get the idea)
Dependencies, Exclusions, and Require one-of
With P::V I can do this:
{ credit_card_number =
{ optional = 1,
depends = [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration = { optional = 1 },
credit_card_holder_name = { optional = 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =
{ optional = 1,
excludes = [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say we need
credit card info _or_ bank account info.
For example, with the examples above, I probably want to require _either_
a credit card number _or_ a bank account number. Providing both is an
error, but so is not providing either.
Again, no idea how to do this in Perl6, but it seems like something that
could be supported via sub declarations
Since all of these can be checked at compile time (sometimes), it seems
like they'd be useful parts of the language, as opposed to something
user-created. Of course, I understand that there will be more ways to
mess with the compilation in Perl6.
Transformations
Another potential future feature for P::V is the ability to specify some
sort of transformation callback for a parameter. This is handy if you
want to be flexible in what inputs you take, but not explicitly write code
for all cases:
{ color = { regex = qr/^(?:green|blue|red)$/i,
transform = sub { lc $_[0] } }
}
I suspect that this could be implemented by a user-provide trait like is
transformed:
sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed {
lc })
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Anyway, I'd love to hear feedback on this. What did I get right? What
did I get wrong? Did I miss a more elegant way to do something? What
other types of param validation do other folks use/want to see?
-dave
Re: my $pi is constant = 3;
On Thu, Aug 18, 2005 at 12:02:53AM +0800, Autrijus Tang wrote:
: On Wed, Aug 17, 2005 at 08:47:18AM -0700, Larry Wall wrote:
: : That could be made to work by defining constant to mean you can assign
: : to it if it's undefined. But then it gets a little harder to reason
: : about it if $pi can later become undefined. I suppose we could
: : disallow undefine($pi) though.
:
: If you can assign it when it contains an undefined value, bad
: things happen:
:
: sub f ($x is readonly) { $x = 10 }
: my $a; f($a);
:
: Compare this with:
:
: my $x is readonly;
: $x = 10;
:
: If it is defined as bound to a immutable value cell, both cases
: above would fail, which is imho the easiest to explain.
Though I think most people have a pretty good understanding of worm
these days, what with CD and DVD burners...
Darn, I turned my third parameter into a coaster. Now what am I gonna do?
: You could still reason about it if you can determine what the initial
: value is going to be. But certainly that's not a guarantee, which
: is one of the reasons we're now calling this write/bind-once behavior
: readonly and moving true constants to a separate declarator:
:
: my $pi is readonly;
: $pi = 3;
:
: The question remains, whether you can bind the readonliness away:
:
: my $pi is readonly; # undef at this point
: my $e is rw = 2.7;
: $pi := $e;
: $pi = 9;
:
: I can argue both sides -- rebindable is easier to implement, but
: non-rebindable is perhaps more intuitive.
English has a long history of hoisting the adjectives from the object
to its container. I'd like a nice cup of tea and such. So in general
I think people will expect a readonly variable to contain a readonly
value, and maybe we should do the extra work to enforce that transitively.
That being said, there's also a history of rebinding references, as
in That woman is a man! But we intuitively recognize that there's
something funny going on there linguistically. We can deal with it
as humans, but maybe we can allow the soulless computer to throw a
exception on such contradiction instead of laughing like we do.
That being said, it's still quite possible that
my $pi is readonly;
realizes that it's not bound to anything reasonable yet, and set
up a worm container of some sort that binds lazily at run time.
As with parameter defaults, it's more about whether the container's
value exists than whether it's defined.
Larry
Re: my $pi is constant = 3;
On 8/17/05, Larry Wall [EMAIL PROTECTED] wrote:
You could still reason about it if you can determine what the initial
value is going to be. But certainly that's not a guarantee, which
is one of the reasons we're now calling this write/bind-once behavior
readonly and moving true constants to a separate declarator:
my $pi is readonly;
$pi = 3;
vs
constant $pi = 3;
or
constant Num pi = 3;
or if you like, even
constant π = 3;
Minor detail: when does the right side get evaluated? That is, what
happens here:
constant pi = make_pi();
sub make_pi() { 4*atan2(1,1) }
If you want this to succeed, then this must fail:
constant pi = 4*atan2(1,1);
BEGIN { say pi = {pi} }
Is it even possible to evaluate constants at CHECK time and then
constant-fold them in before the program is run?
Luke
Re: Hoping that Params::Validate is not needed in Perl6
DR == Dave Rolsky [EMAIL PROTECTED] writes: DR Mandatory vs. Optional Parameters DR This is a pretty straightforward one in P6, I think. Parameters can DR be marked as required with is required like this: DR sub date ($year, ?$month, ?$day) # positional DR sub date (+$year is required, +$month, +$day) #named DR This is ok but frankly I'm not too keen on the fact that for DR positional subs, the default is required, but for named params it's DR the other way around. DR Wouldn't it clearer to just use a leading ?+ for optional named params? there are usually more optional params than required ones when doing named params. so that makes sense to make the default optional. with positional params usually more of them are required (on the left) and some optional ones can be on the right. so marking those optional ones makes more sense. this is all huffman stuff IMO. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Hoping that Params::Validate is not needed in Perl6
On 8/17/05, Dave Rolsky [EMAIL PROTECTED] wrote:
I'm going to go over the various features in P::V and see if there are
equivalents in Perl6, and bring up any questions I have. I think this
will be interesting for folks still new to P6 (like myself) and existing
P::V users (I think there's a fair number, but maybe I flatter myself ;)
Thanks!
P::V also allows one to specify a class membership (isa) or one or more
methods (can) a given object/class must have. In Perl6 we can just
specify a class:
sub transmit (Receiver $receiver)
If I understand this correctly, Receiver is a role here, and one that many
different classes may use/implement. This basically combines the isa
can concepts. Instead of specifying required _methods_, we specify the
role, which seems conceptually cleaner anyway.
... Sometimes. We are missing the can functionality (except from
where clauses). That is, how do you specify that you want an object
that does a particular role, but doesn't know it yet. I'm thinking
something like:
role Mortal is automatic {
method die () {...}
}
That is, anything that can die is Mortal, even though it didn't say
that it was. Then what really gets tricky is this:
role Mortal is automatic {
method die () {...}
method jump_off_building() { die }
}
class Human {
method die () { die Auuugh }
}
Human.new.jump_off_building; # no method found or Auuugh?
Anyway, that's beside the point. Moving on.
Dependencies, Exclusions, and Require one-of
With P::V I can do this:
{ credit_card_number =
{ optional = 1,
depends = [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration = { optional = 1 },
credit_card_holder_name = { optional = 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration
defined $credit_card_holder_name }
{...}
But that's really yucky.
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =
{ optional = 1,
excludes = [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say we need
credit card info _or_ bank account info.
Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:
'$credit_card_number excludes $ach_bank_account_number'
You could say:
'You can't give a credit card number and a bank account number, silly!'
So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.
Transformations
Another potential future feature for P::V is the ability to specify some
sort of transformation callback for a parameter. This is handy if you
want to be flexible in what inputs you take, but not explicitly write code
for all cases:
{ color = { regex = qr/^(?:green|blue|red)$/i,
transform = sub { lc $_[0] } }
}
I suspect that this could be implemented by a user-provide trait like is
transformed:
sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed
{ lc })
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Even things that do add things at compile time don't need to be part
of the language. That's why use is a macro. :-)
Luke
Rebinding binding
Two years ago or so, I became very happy to learn that the left side
of binding works just like a routine signature. So what if binding
*were* just a routine signature. That is, could we make this:
sub foo () {
say hello;
my $x := bar();
say goodbye $x;
}
Equivalent to this:
sub foo () {
say hello;
- $x {
say goodbye $x;
}.(bar());
}
Then observe:
sub foo() {
say hello;
my $x := 1|2|3;
say goodbye $x;
}
foo();
__END__
hello
goodbye 1
goodbye 2
goodbye 3
If you bind an existing variable (instead of introducing a new one
with my), you get a delimited continuation for the scope of that
variable. Consequently, if you bind a global, you get a full
continuation.
I know, I know, this is putting continuations into the realm of
!/upper{10...}/, but I have an argument for this. The only people
who will ever see the continuations are the people *implementing*
junctions and junction-like things. And those people are already
gurus, so they should be comfortable in dealing with continuations.
The only other time that a user might get caught with continuation
weirdness is if they're binding to junctions as above (since there
are no other such values in the language... just yet). And with the
default no junctions, junctions aren't allowed in variables anyway,
so what do they expect?
Luke
Re: scopes of $?SELF and $?CLASS
Larry,
On Aug 17, 2005, at 2:53 PM, Larry Wall wrote:
: As for submethods, I see them like this:
:
: submethod foo () { ... }
:
: is really ..
:
: submethod foo () {
: next METHOD unless $?SELF ~~ $?CLASS;
: }
:
: At least that is how larry explained to me about a month ago.
Can't use ~~ for that, since ~~ implies does, which is not an
exact class match. Probably need
next METHOD unless $?SELF.class =:= $?CLASS;
or some such.
In the 2.0 version of the metamodel I compare the class object's .id to
the instance's class object's .id. Which is (I assume) how =:= would do
it under the hood.
Except that BUILDALL/DESTROYALL have to be able to
invoke submethods on partial objects whose actual class is not the
same as the submethod, so there needs to be some way of forcing
$?SELF to consider itself in $?CLASS temporarily for infrastructural
purposes. Maybe it's as easy as temp $obj.class := $tmpclass
in the BUILDALL/DESTROYALL dispatcher. I dunno.
I am not sure if changing classes makes sense here so much as just
providing a means for submethod calls to be forced. Currently the
metamodels do this by allowing a special parameter in the first
argument which is a flag to let the submethod wrapper know if can skip
the next METHOD branch. It is a bit of a kludge, but it seems to
work.
The other option I considered was to make BUILDALL and DESTORYALL
special somehow. But I am not sure if this makes any more sense than
the kludge described above.
Stevan
Larry
Re: Test::Code
--- demerphq [EMAIL PROTECTED] wrote: One idea might be to try using Data::Dump::Streamer for your tests. It will serialize the lexical context that the subroutine was compiled with (including bound anonymous subroutines and their lexical context). A small hack (that i would be happy to work with you to put into the next release) might allow you to rename the vars the in the sub as you wanted. IE, it could normalize all vars that are lexical bound to the subroutine so that comparisons would be easier. Of course by default DDS wouldnt consider the subs the same unless the values of said vars were the same too... That's sounds wonderful. The other day I was actually looking into what it might take to hack B::Deparse to normalize the variable names. Then I looked at the code :) (It actually didn't look that hard, but I haven't tried yet). I won't have time to return to this problem for a couple of days, but I'm glad to know there's a path to follow. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, Aug 17, 2005 at 22:06:07 +, Luke Palmer wrote:
{ credit_card_number =
{ optional = 1,
depends = [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration = { optional = 1 },
credit_card_holder_name = { optional = 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration
defined $credit_card_holder_name }
{...}
multi sub validate () { # no credit card info
}
multi sub validate (
$credit_card_number,
$credit_card_expiration,
$credit_card_holder_name
) {
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me beats up some cheese: neeyah!
pgpbIDpVzpej3.pgp
Description: PGP signature
Serializing code
In the last year AJAX has become a significant technology.
Now with perl 6 compiling to javascript and perl 5 and what not, i
think there is a big future when you merge the two and remove the
details.
The way HTML::Prototype works is:
you get an OO interface, which is clean and simple
you use it to generate mostly functions
the functions can be thought of as closures, sometimes being
curried by your values
the functions are in a foreign language, and cannot be executed
- they are really strings that work in another runtime.
Now, in the foreseable future I think it's plausible that the Ajax
libraries will be written in the server side's native language. When
the code is serialized by a template, the template will say to what
language to compile it, and the result is the PIL code, or compiled
foreign language code that will work on the remote side.
What I'm saying is that in the future HTML::Prototype could be
implemented in Perl 6, and the code in question is compiled by the
web app (this is more than quasiquoting - the code is actually
parsed into the native language - full macros, code reuse and so
forth).
The perl 6 code will just be suited for the runtime that a browser
presents, including DOM manipulations, for example.
Now, one step further - ruby is compiled to PIL. Ruby guys maintain
HTML::Prototype, because it's their thing. It's written in ruby, and
perl 6 code gets to use the ruby code, and compile that code down to
javascript for IE, but to PIR for firefox with embedded parrot.
How's that for code reuse and lack of vendor lock-in?
So now that the skeptics can see why this is important, on the
design side I'd like to ask for ideas on how the code serialization
looks...
sub { $?DOM.document.write(phello world!/p) }.emit(
:runtime($browser_autodetect_object),
# this can be guessed by asking the $runtime object:
# :languagejavascript,
);
This is superficially nice, but here's what's missing:
- this is basically the interface to the code emitters - they
need lots of control in terms of optimization flags, and so
forth, and command line options (which are just like named
arguments) absolutely do not scale, as any makefile can tell
you.
- These need to be defined and stabilized:
- runtime (the virtual machine and more)
- version
- features
- target language (The actual code)
- architechture
- definition version
- environment
- browser
- command line
- web server
- ...
- system
- $?OS (this should not be browser)
- ...
- compiler (the thing that makes your language into PIL)
- emitter (the thing that makes PIL into a language)
- handling included code (libraries could be compiled to static
JS files that are fetched)
- on the fly generation + caching
- precalculation
- standalone serialization (a single function has everything
it needs)
- what exactly is a code object?
- a wrapper for some PIL code
- that can be executed by the runtime
- what exactly is code.emit
- also an object?
- comparable to other emissions?
- further transformable?
- when is it just text or bytes?
- handling of data
- types of:
- globals?
- closures?
- serialization? proxying?
- two examples of data sharing policies:
- the border between the webapp and the browser is
smudged by serialization and proxy objects
- the border between the webapp and the browser is clear
and distinct, and calls between the two are done by
explicitly invoking one runtime from the other
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpaUlMpaw6xA.pgp
Description: PGP signature
Re: scopes of $?SELF and $?CLASS
On Wed, Aug 17, 2005 at 06:26:02PM -0400, Stevan Little wrote: : I am not sure if changing classes makes sense here so much as just : providing a means for submethod calls to be forced. Currently the : metamodels do this by allowing a special parameter in the first : argument which is a flag to let the submethod wrapper know if can skip : the next METHOD branch. It is a bit of a kludge, but it seems to : work. : : The other option I considered was to make BUILDALL and DESTORYALL : special somehow. But I am not sure if this makes any more sense than : the kludge described above. I'm not sure it's a kludge. I think it might just be a specific subcase of the I've already checked the parameters to this, just let me call you as a bare sub entry point. So maybe it's the same alternate entry point used by the junction threading code after it's already figured out how to thread. A lot of optimizations might want that bare entry point as well. This does imply that the next METHOD of a submethod is outside that bare entry point, of course. That's what your flag is emulating. Larry
Re: my $pi is constant = 3;
On Wed, Aug 17, 2005 at 09:37:08PM +, Luke Palmer wrote:
: On 8/17/05, Larry Wall [EMAIL PROTECTED] wrote:
: You could still reason about it if you can determine what the initial
: value is going to be. But certainly that's not a guarantee, which
: is one of the reasons we're now calling this write/bind-once behavior
: readonly and moving true constants to a separate declarator:
:
: my $pi is readonly;
: $pi = 3;
:
: vs
:
: constant $pi = 3;
:
: or
:
: constant Num pi = 3;
:
: or if you like, even
:
: constant π = 3;
:
: Minor detail: when does the right side get evaluated? That is, what
: happens here:
:
: constant pi = make_pi();
: sub make_pi() { 4*atan2(1,1) }
That should fail, I think. Constant pseudo assignment is equivalent to
is begin(make_pi()), in the same way that other pseudo-assignments
pay attention to the declarator to figure out when they really run.
And I think we want constants lexically scoped and known to the
compiler so it can do immediate constant folding. This also has the
nice property that it visually distinguishes values intended for
consumption by the compiler from values intended for consumption for
the runtime.
: If you want this to succeed, then this must fail:
:
: constant pi = 4*atan2(1,1);
: BEGIN { say pi = {pi} }
That one succeeds.
: Is it even possible to evaluate constants at CHECK time and then
: constant-fold them in before the program is run?
I think that sort of chicanery is best left for
sub pi() {...}
say pi = {pi};
sub pi() { 4*atan2(1,1) };
Larry
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Luke Palmer wrote:
Dependencies, Exclusions, and Require one-of
With P::V I can do this:
{ credit_card_number =
{ optional = 1,
depends = [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration = { optional = 1 },
credit_card_holder_name = { optional = 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration
defined $credit_card_holder_name }
{...}
But that's really yucky.
Hideous, indeed. Presumably with macros or some other compile time thing
that can be turned into something more palatable.
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =
{ optional = 1,
excludes = [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say we need
credit card info _or_ bank account info.
Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:
'$credit_card_number excludes $ach_bank_account_number'
You could say:
'You can't give a credit card number and a bank account number, silly!'
Actually, I forgot to mention this in my original post, but in general
it'd be nice to be able to provide some sort of callback/object to be
called whenever a parameter check fails, and it'd be nice to be able to
provide more than one, so I can have custom parameter exception logic per
class or sub.
So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.
It'd be nice to catch this at compile time whenever possible, though.
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Even things that do add things at compile time don't need to be part
of the language. That's why use is a macro. :-)
Yes, but see above. I know we can do things like add syntax at compile
time, but can we do these sorts of checks? I'm sure the answer is yes,
but how easy will it be? Of course, if it's implemented via a C6AN module
it's only got to be done once, but it's worth thinking about.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, 18 Aug 2005, Yuval Kogman wrote:
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration
defined $credit_card_holder_name }
{...}
multi sub validate () { # no credit card info
}
multi sub validate (
$credit_card_number,
$credit_card_expiration,
$credit_card_holder_name
) {
}
Yeah, while playing with datetime stuff for pugs it occurred to me that
providing a fallback multi sub could be quite handy.
But I'd really like to get this stuff done at compile time wherever
possible. If I write this:
validate( credit_card_number: $number );
it should blow up at compile time, right?
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Dave Rolsky wrote:
Type Validation, isa, can
Params::Validate allows for several ways to check the _value_ of a parameter.
One way is to specify a primitive type like SCALAR or ARRAYREF. In P6 we
have that with this:
sub date (Scalar +$year is required, ...)
I'm not sure is Scalar is a valid type though, but that's ok because we
have better types built in. In this case we should really use Int for a
year.
And another question. How will I make Perl6 not do automatic coercion for
me. If I have this sub:
sub date (Int +$year is required, +$month, +$day)
and someone does this:
date('this year', 12, 1);
I'd prefer for this to fail, rather than giving me -12-01! I vaguely
remember a mention of use strict 'types' either on this list or hanging
out with some pugs folks at YAPC.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote:
And another question. How will I make Perl6 not do automatic coercion for
me. If I have this sub:
sub date (Int +$year is required, +$month, +$day)
BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour
during the Oscon design meeting:
sub date (Int ++$year, +$month, +$day)
and someone does this:
date('this year', 12, 1);
I'd prefer for this to fail, rather than giving me -12-01! I vaguely
remember a mention of use strict 'types' either on this list or hanging
out with some pugs folks at YAPC.
You will probably get:
1. a compile time warning of unsafe coercion, possibly made fatal.
and
2. a NaN at runtime if you ignore the warning.
Thanks,
/Autrijus/
pgp1xZHMMuAGd.pgp
Description: PGP signature
Re: Time::Local
On Wed, 2005-08-17 at 01:28 -0500, Dave Rolsky wrote: Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact It's hardly short sighted to want leap seconds to be abandoned (not in Perl but world wide). The few people who _really_ care about syncing to midnight can still have them, but the rest of the world would be just fine with a leap hour every couple hundred years. Well, right now one of the great things about looking at the wall to read the clock and see the time, is that you know that based on the time of day and the time of year, and where you are, roughly how far through the actual solar day it is. It's crude, but useful. Just ask a Dairy Farmer. What else do you want the time of day to represent? You would prefer it something completely arbitrary, just to make it easier to program with? That we don't just use a straight solar clock is probably down to the fact that it was technically infeasible to have one without a sundial, which obviously doesn't work at night or in England. alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Great, so now code that works in one environment throws a cannot find an up-to-date leap seconds table exception in another? Eek! Well, only if you try to do something silly like ask for the number of seconds between two points of time in different days a long time in the future, where those times were composed from Gregorian components. If you were to ask for the number of minutes, or not cross the boundary of when leap seconds are allowed, then it would still be OK. I would expect a similar exception if I tried to calculate the number of hours between two dates in an unknown timezone. Of course feel free to consider this all worthless heckling, given the lack of time I've been putting towards an implementation of all this ;). Sam.
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, Aug 18, 2005 at 01:04:56PM +0800, Autrijus Tang wrote:
: On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote:
: And another question. How will I make Perl6 not do automatic coercion for
: me. If I have this sub:
:
: sub date (Int +$year is required, +$month, +$day)
:
: BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour
: during the Oscon design meeting:
:
: sub date (Int ++$year, +$month, +$day)
Yes.
: and someone does this:
:
: date('this year', 12, 1);
:
: I'd prefer for this to fail, rather than giving me -12-01! I vaguely
: remember a mention of use strict 'types' either on this list or hanging
: out with some pugs folks at YAPC.
:
: You will probably get:
:
: 1. a compile time warning of unsafe coercion, possibly made fatal.
: and
: 2. a NaN at runtime if you ignore the warning.
In this case it shouldn't get even that far since you'll get a fatal
error that says you tried to pass a positional list to a non-positional
parameter. + isn't a synonym for ?.
Larry
