Re: @array = %hash
David Whipp <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Maybe we should just say 'sod it' and implement the entire Smalltalk
>> Collection hierarchy and have done with it? Sets, bags, hashes
>> (dictionaries for the Smalltalker), whatever, all have their uses...
>
> I'm not sure if you were being facetious,
I wasn't. I'd love to see something akin to the full Smalltalk
collection hierarchy available with Perl. And I'd love to see them
'blessed' into core Perl so people would *use* them. But I'm not sure
it'll actually happen.
> but I do think all the functionality of these should exist: how many
> times do we have to explain, to newbies, the perl idioms for using
> hashes as sets? Collections boil down to two basic properties:
> ordered/unordered and duplicates/unique. We only have c<%> and c<@>
> available for 4 combinations; and perl uses these to indicate the
> underlying implementation (sans ties), and the type of key. Seems to
> me that we will either end up using c<$> (objects) for most
> collections; or we'll be creative in our use of properties for @ and
> %.
%foo is Ordered
@bar is Set
Hmm... I think I'd rather see
my $foo is Bag = @array.as('Bag');
The idea being that one could treat hashes and arrays as syntactic
vitamins meaning 'Dictionary' (to use the Smalltalk term) and
'OrderedCollection', but all Collections would implement an C
method allowing conversion between the different classes.
Hmm... you know, the more I think about that idea, the more I like
it...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Implementing new control structures
This came up in a discussion on London.pm about Damian's Perl 6 talk,
which led us to wonder about control exceptions and how they're
handled. At the moment, control exceptions fall into the 'vaguely
handwavy' category, and what follows is my attempt to work out how I
think they should behave...
Damian Conway <[EMAIL PROTECTED]> writes:
> Lusercop wrote:
>
> > It has to be said that watching someone talk about this is rather easier
> > than trying to follow the exegeses and apocalypses (IMO). Certainly, in
> > the absence of a real, live Perl6 interpreter this is the case.
>
> H. Maybe that makes *me* the real, live Perl 6 interpreter at the moment. ;-)
>
>
> > One thing I am slightly confused about, though, is that if {} now delimits
> > a subroutine, what happens to this bit of code:
>
> The implicit question seemed to be if raw blocks and C blocks
> and C blocks and C blocks, etc. are all really
> closures/subroutines, what happens if they have a C in them?
>
> The answer is that C throws a "control exception". The named control
> structures catch and re-propagate this to the surrounding subroutine. Raw
> blocks do the same thing. So the effect is exactly as in Perl 5: a C
> in a controlled or raw block causes the surrounding subroutine to
> return.
So, when you're writing a looping construct for a class that will be
used like:
method lazy_search ($a_collection, $a_target) {
...
$a_collection.do -> $each {
$each =~ $a_target and return $each;
}
return;
}
ie, where a 'return' inside the arg block should return to the calling
scope, but where a normal 'fell off the end of the block' should just
continue 'round the block. How do we do that? Will there be some
cunning calling convention which will allow us to interrogate the
return value of a try to find out how it was arrived at?
method do ($self : &block) {
for $self.members █
CATCH Control::return { throw }
}
Hang on, that should just work shouldn't it? Just take advantage of
the fact that the current C already has those semantics and it
seems I'll need to think a good deal harder to come up with something
concrete that'd require knowledge of how something got returned.
Thinking about this, I suppose that one could arrange it so that a
C *always* sets $!, either to some error type exception that was
thrown, or to the control exception that escaped the block. If one
then overloaded C<< operator:? >> for control exceptions so that they
were false in a boolean context one could continue to write code like:
try █
if ($!) {...}
and have it work as expected, but still be able to get at the control
exceptions in the (rarer) occasions they were needed.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: @array = %hash
Damian Conway <[EMAIL PROTECTED]> writes:
> Uri Guttman wrote:
>
>> but what simon was saying (and i agree) is the the pair IS a single
>> item. it becomes the key and its value is 'scalars'.
>
> No. If it's a PAIR, then its key is the key and its value is the value.
>
>
>> hashes can now take objects as keys and won't just stringify them.
>
> Correct. But I believe that's only if the hash has a property that marks
> its keys as being objects, not strings:
>
> my %hash is keyed(REF);
>
> And, even if that's the default, it still oughtn't apply to PAIRs.
> To get keys that are PAIRs, you should have to say:
>
> my %hash is keyed(PAIR);
I really hope you're wrong about that last one. Or are you really
proposing that, given C, one can't do
C<%hash{$arbitrary_object} = $value> and get back the 'real'
C<$arbitrary_object> from C<%hash.values>, that seems to run counter
to what's been said about perl6 hashes. Requiring C
seems kludgy, but 'is keyed(PAIR)' for anything but optimization or
'contract' stuff seems Bad And Wrong.
>> @array = ( key => 1, key2 => 3, 4, 5 ) ;
>> %hash = @array ;
>> what does that do? 3 pairs in the hash or 2 (the first pair is the
>> key
>> for the second pair)?
>
> Three. As above. You'd get:
>
> %hash{'key'} = 1;
> %hash{'key2'} = 2;
> %hash{'4'}= 5;
I'm not sure I agree. If you're going to make it behave like that
then at least allow us to do something like
%hash = @array but no_special_pairs;
(Not sure that's a good property name, but it's the best I could come
up with at the moment.)
> > there needs to be some semantic way to select the hash assignment style
>
> C
No; that puts the property in the wrong place.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: core.ops ARGDIR
Hi Leo, > > This should be - from my (imcc) POV - reflected by these IN/OUT > settings: > > op set(in PMC, in INT) > op set(in PMC, in STR) > op set(in PMC, in NUM) > op set(out PMC, in PMC) # ok, $1 points to $2 now > > # P[i] = x > op set(in PMC, in intkey, in x) > # P[KEY] = x > op set(in PMC, in KEY, in x) > # p[KEY] = P[KEY] > op set(in PMC, in KEY, in PMC, in KEY) > Shouldn't all this PMC be "inout"? They depend on the previous value of the PMC, but they also modify it. This probably doesn't affect imcc now, but it might be useful in the future. -angel
[perl #16960] [PATCH] assemble.pl dulpicate labels
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16960]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16960 >
imcc and assembler did allow duplicate labels.
Fix for imcc is ready and follows with my other changes.
Please apply,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36393/29416/733a22/assemble.pl.diff
--- assemble.pl Sat Aug 24 20:31:59 2002
+++ /home/lt/src/parrot-leo/assemble.pl Tue Sep 3 11:03:21 2002
@@ -525,6 +525,7 @@
push @{$self->{local_labels}{$1}},$_->[1]; # Local label
}
else {
+ die("Label $1 already exists") if($self->{global_labels}{$1});
$self->{global_labels}{$1} = $_->[1]; # Global label
}
}
Perl 6 Summary for week ending 2002-09-01
Perl6 Summary for the week ending 2002-09-01 Well, it's been a week. Damian came to London and made our heads spin; perl6-language erupted in a flurry of interesting, high signal/noise threads; Parrot reached its 0.0.8 release; Larry made many of his wonderfully unexpected but obviously *right* interjections and the world kept on turning. So, we'll kick of with perl6-internals as usual. DOD etc The 'elimination of garbage collection handwaving' thread continued as Nicholas Clark asked a hard question about garbage collection and dead object detection (DOD). As far as Nick could tell, it seems that `if we have unrefcounted "deterministic destruction" objects somewhere freely in the GC system, then we'll be needing a DOD run after every statement' and he noted that `All ways of doing deterministic destruction seem to have considerable overhead'. Sean O'Rourke wondered if we could use a hybrid `full GC + refcounts where needed' scheme, but Juergen Boemmels pointed out that refcounting would be contagious. Anything which contained a reference to a refcounted object would need to be refcounted in its turn... Meanwhile, Mike Lambert wondered why we needed to promise deterministic destruction in the first place and proposed a couple of schemes to deal with the canonical `filehandle' case. Sean O'Rourke and Steve Fink both came forward with cases where deterministic destruction proved useful, and where Mike's scheme didn't really work. And that's where the thread came to rest. I have the feeling that it, or a thread like it, will be back. http://makeashorterlink.com/?K11642DA1 Dynamic Keys Tom Hughes, who has been doing good work on keyed access wondered about dealing with dynamic keys, and proposed a way forward. Dan asked whether Tom had looked at the proposed ops in PDD06, and pointed out that dynamic keys didn't necessarily need to go the whole PMC hog. `They're our internal structures--we can screw with them as we need :)'. Tom pointed out a few issues with the PDD06 op set, and proposed a few more ops with a (hopefully) consistent naming scheme. So far he's had no answer to the questions he raised in that post. http://makeashorterlink.com/?P12621DA1 Perl6 Test Failures Steve Fink wondered about all the test failures he keeps seeing for Perl 6; he doesn't want to go trying to make a language neutral regex engine play nicely with the Perl6 engine when that engine is in such a state of flux. Sean O'Rourke suggested nailing down some calling conventions and then both teams could code to those conventions. Steve pointed out that, so far, he knows of at least 5 attempts at a regex engine in parrot. Leopold Toetsch suggested Steve try the tests again, forcing a grammar rebuild, and the test failures got all better. http://makeashorterlink.com/?R23631DA1 Regex status On Wednesday, Dan wondered where we were with Apocalypse/Exegesis 5 compatible patterns/rules/regexes. Sean O'Rourke told him. (Answer: Still some way to go, but making good speed.) http://makeashorterlink.com/?U14651DA1 Counting down to 0.0.8 On Thursday, Jeff Goff posted his timetable for 0.0.8, `Octarine' release of Parrot, complete with a 25 hour code freeze. Markus wondered if using a GMT timetable might be more friendly for every one who wasn't on the East Coast of the United States. Parrot actually saw release on Monday September the second, which is slightly outside the scope of this summary, but I'll let it sneak in anyway. http://makeashorterlink.com/?Z55612DA1 http://makeashorterlink.com/?A16623DA1 An `Oops' moment. Leopold Toetsch found an interesting bug with the GC system interacting with initialization. examples/life.ar.p6 is a Perl6 implementation of Conway's Life, which has a rather lengthy initialization phase, after which it checks the @ARGS array, which is conventionally placed in "P0" at startup. But there's a catch. By the time it comes to make the check, @ARGS has been garbage collected. Peter Gibbs posted a quick fix patch, and Mike Lambert stuck his hand up to being a `lazy bum', but reckoned that Steve Fink's fixes should solve the problem. http://makeashorterlink.com/?U27631DA1 Various changes to IMCC Whilst `idly toying' with IMCC, Steve Fink made a bunch of speculative changes, bundled 'em up in a patch and offered them to the list. I'm not sure what people thought of the changes, but the thread morphed into a discussion of generating conditional makefiles and making sure that IMCC and the other tools needed to get the Perl6 compiler working were as portable as possible. Mike Lambert pointed out that it may make sense to have the files generated by bison/flex checked directly into the repository, since then thos
RE: Perl 6 Summary for week ending 2002-09-01
Hi team., thanx in advance Can you provide me a link or a zip file where i can download perl6 or perl 5.6 for solaris 7 or solaris 8 Would be appreciated.. cheers venkat -Original Message- From: Piers Cawley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 4:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Perl 6 Summary for week ending 2002-09-01 Perl6 Summary for the week ending 2002-09-01 Well, it's been a week. Damian came to London and made our heads spin; perl6-language erupted in a flurry of interesting, high signal/noise threads; Parrot reached its 0.0.8 release; Larry made many of his wonderfully unexpected but obviously *right* interjections and the world kept on turning. So, we'll kick of with perl6-internals as usual. DOD etc The 'elimination of garbage collection handwaving' thread continued as Nicholas Clark asked a hard question about garbage collection and dead object detection (DOD). As far as Nick could tell, it seems that `if we have unrefcounted "deterministic destruction" objects somewhere freely in the GC system, then we'll be needing a DOD run after every statement' and he noted that `All ways of doing deterministic destruction seem to have considerable overhead'. Sean O'Rourke wondered if we could use a hybrid `full GC + refcounts where needed' scheme, but Juergen Boemmels pointed out that refcounting would be contagious. Anything which contained a reference to a refcounted object would need to be refcounted in its turn... Meanwhile, Mike Lambert wondered why we needed to promise deterministic destruction in the first place and proposed a couple of schemes to deal with the canonical `filehandle' case. Sean O'Rourke and Steve Fink both came forward with cases where deterministic destruction proved useful, and where Mike's scheme didn't really work. And that's where the thread came to rest. I have the feeling that it, or a thread like it, will be back. http://makeashorterlink.com/?K11642DA1 Dynamic Keys Tom Hughes, who has been doing good work on keyed access wondered about dealing with dynamic keys, and proposed a way forward. Dan asked whether Tom had looked at the proposed ops in PDD06, and pointed out that dynamic keys didn't necessarily need to go the whole PMC hog. `They're our internal structures--we can screw with them as we need :)'. Tom pointed out a few issues with the PDD06 op set, and proposed a few more ops with a (hopefully) consistent naming scheme. So far he's had no answer to the questions he raised in that post. http://makeashorterlink.com/?P12621DA1 Perl6 Test Failures Steve Fink wondered about all the test failures he keeps seeing for Perl 6; he doesn't want to go trying to make a language neutral regex engine play nicely with the Perl6 engine when that engine is in such a state of flux. Sean O'Rourke suggested nailing down some calling conventions and then both teams could code to those conventions. Steve pointed out that, so far, he knows of at least 5 attempts at a regex engine in parrot. Leopold Toetsch suggested Steve try the tests again, forcing a grammar rebuild, and the test failures got all better. http://makeashorterlink.com/?R23631DA1 Regex status On Wednesday, Dan wondered where we were with Apocalypse/Exegesis 5 compatible patterns/rules/regexes. Sean O'Rourke told him. (Answer: Still some way to go, but making good speed.) http://makeashorterlink.com/?U14651DA1 Counting down to 0.0.8 On Thursday, Jeff Goff posted his timetable for 0.0.8, `Octarine' release of Parrot, complete with a 25 hour code freeze. Markus wondered if using a GMT timetable might be more friendly for every one who wasn't on the East Coast of the United States. Parrot actually saw release on Monday September the second, which is slightly outside the scope of this summary, but I'll let it sneak in anyway. http://makeashorterlink.com/?Z55612DA1 http://makeashorterlink.com/?A16623DA1 An `Oops' moment. Leopold Toetsch found an interesting bug with the GC system interacting with initialization. examples/life.ar.p6 is a Perl6 implementation of Conway's Life, which has a rather lengthy initialization phase, after which it checks the @ARGS array, which is conventionally placed in "P0" at startup. But there's a catch. By the time it comes to make the check, @ARGS has been garbage collected. Peter Gibbs posted a quick fix patch, and Mike Lambert stuck his hand up to being a `lazy bum', but reckoned that Steve Fink's fixes should solve the problem. http://makeashorterlink.com/?U27631DA1 Various changes to IMCC Whilst `idly toying' with IMCC, Steve Fink made a bunch of speculative changes, bundled 'em up in
imcc and 0.0.8, should this happen?
Using Mac OS X 10.1.5, on which I've successfully built 0.0.6 and 0.0.7. [localhost:~/parrot.1/languages/imcc] chris% make anyop.o definition of _n_symbols in section (__DATA,__common) make: *** [imcc] Error 1 [localhost:~/parrot.1/languages/imcc] chris% Then when I try to run a simple "Hello world" test.p6: [localhost:~/parrot.1/languages/perl6] chris% perl perl6 test.p6 Stopped at perl6 line 273. Stopped at perl6 line 273. [localhost:~/parrot.1/languages/perl6] chris% Are these two problems related?
Re: core.ops ARGDIR
Angel Faus wrote: > Hi Leo, > > >>This should be - from my (imcc) POV - reflected by these IN/OUT >>settings: >> >>op set(in PMC, in INT) >>op set(in PMC, in STR) >>op set(in PMC, in NUM) >>op set(out PMC, in PMC) # ok, $1 points to $2 now >> >># P[i] = x >>op set(in PMC, in intkey, in x) >># P[KEY] = x >>op set(in PMC, in KEY, in x) >># p[KEY] = P[KEY] >>op set(in PMC, in KEY, in PMC, in KEY) > Shouldn't all this PMC be "inout"? They depend on the previous value > of the PMC, but they also modify it. inout would be ok for me. set Px, Py is probably the only instruction, where $1 is OUT. (ev. assign, but I didn't look at this close enough). > This probably doesn't affect imcc now, but it might be useful in the > future. It does affect imcc (CVS as well as my upcoming patch). Currently there is a würgaround (workaround) in the code. Have a look at e.g. iMOVE(). > -angel leo
Re: Hypothetical variables and scope
On Mon, 2 Sep 2002 23:50:18 -0400 (EDT), Trey Harris wrote:
> In a message dated 2 Sep 2002, Aaron Sherman writes:
> > {
> > my $x = 2;
> > my $y = "The grass is green";
> > $y =~ /(gr\w+) {let $x = $1}/;
> > }
>
> Yes. $0{x} would be set to "grass". A lexical variable has been defined
> in the same scope as the hypothetical with the same name, so its value is
> set hypothetically (is hypothetically bound to?) $0{x}. When the rule
> succeeds, $x's hypothetical value is made permanent.
>
> > module foo;
> > rule gr_word { (gr\w+) {let $x = $1} }
> > my code
> > use foo;
> > my $x = 2;
> > "The grass is green" =~ //;
>
> No. $0{x} would be set to "grass". $x would stay as 2. $x is in a
> different scope from the hypothetical, so it doesn't get touched.
Presumably there is some variant of the strict pragma which would catch
misspellings of $x. Actually, I'd like to see something explicit in the
rule which states whether the hypothetical binding applies to the surrounding
scope as well as to the match variables. Unfortunately, the only way I can
think of doing this is to state $OUTER::x, which is pretty horrible, and
doesn't give the impression that both the external variable and the match
variable are being bound.
Also the different operators used (:= inside the rule, = inside the code)
seems a bit confusing to me; I can't see that they're really doing anything
different:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C< := > ?
--
Peter Haworth [EMAIL PROTECTED]
> Some more data?
No, no more. Please, no more...
-- Yanick, examining perl's strange behaviour
[perl #16962] [PATCH] add ICU to the glossary
# New Ticket Created by Kevin Falcone # Please include the string: [perl #16962] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16962 > Someone asked on IRC this morning about what ICU is. They mentioned not finding it in the glossary, so here is an explanation and a link. -kevin diff -u -p -r1.6 glossary.pod --- glossary.pod26 Aug 2002 03:02:26 - 1.6 +++ glossary.pod3 Sep 2002 13:30:04 - @@ -152,7 +152,18 @@ objects faster than memory) See also: L<"DOD"> +=head2 ICU + +International Components for Unicode + +ICU is a C and C++ library that provides support for Unicode on a +variety of platforms. It was added to Parrot with the 0.0.8 release to +provide future unicode support. + +http://oss.software.ibm.com/developerworks/opensource/icu/project/ + =head2 PMC + PMC stands for Parrot Magic Cookie. (Or cracker, your choice) It's the -- "The algorithm to do that is extremely nasty. You might want to mug someone with it." -- M. Devine, Computer Science 340
Re: [perl #16874] [BUG] Concatenation failing
Leon Brocard sent the following bits through the ether: > I have a weird bug where concatenation is sometimes failing Well, this bug is still here. I saw some patches fly by but which of them is the right patch and can it be applied please? ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ It's not in the manual!
Re: imcc and 0.0.8, should this happen?
On Tue, 3 Sep 2002, Chris Dutton wrote: > Using Mac OS X 10.1.5, on which I've successfully built 0.0.6 and 0.0.7. > > [localhost:~/parrot.1/languages/imcc] chris% make > > anyop.o definition of _n_symbols in section (__DATA,__common) > make: *** [imcc] Error 1 imcc had hard-wired version numbers 0,0,7. These need to be changed to 0,0.8. (Look in anyop.c and imcc.y (I think)). Or, you can apply my patches of yesterday which fix them with the appropriate Configure variables. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: @array = %hash
> Hmm... I think I'd rather see
>
> my $foo is Bag = @array.as('Bag');
>
> The idea being that one could treat hashes and arrays as syntactic
> vitamins meaning 'Dictionary' (to use the Smalltalk term) and
> 'OrderedCollection', but all Collections would implement an C
> method allowing conversion between the different classes.
>
> Hmm... you know, the more I think about that idea, the more I like
> it...
Likewise. I've always liked languages with complete standard libraries in
terms of data structures. It would be great to see Perl be one of them.
Luke
Re: Hypothetical variables and scope
Peter Haworth wrote:
> Also the different operators used (:= inside the rule, = inside the code)
> seems a bit confusing to me; I can't see that they're really doing anything
> different:
>
> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>
> Shouldn't they both use C< := > ?
Depends on what you want. The "$x :=" in the rule binds the
first match to $x -- it does not copy the value. The "$x ="
in the code block copies the value of the first match. You
can use either binding or assignment in the code block.
Both of them will be "undone" during backtracking. It's more
efficient to bind, but the copy guarantees changes to $x and $1
are independent.
- Ken
[perl #16965] [PATCH] Fix some test_prep dependencies.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #16965]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16965 >
This patch gathers together different testing dependencies into a new
test_prep target, and then uses that target where appropriate. This
should reclaim the Solaris 32-bit JIT tinderbox -- it was failing
because the testj: target didn't have the proper libparrot.a dependency.
Whatever the final resolution of that dependency, this patch consolidates
the debate into one test_prep target.
diff -r -u parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inTue Sep 3 10:28:29 2002
+++ parrot-andy/config/gen/makefiles/root.inTue Sep 3 10:46:00 2002
@@ -447,22 +447,25 @@
#
###
-test : $(TEST_PROG) ${blib_lib_libparrot_a} assemble.pl test_dummy
+test : $(TEST_PROG) test_prep test_dummy
+
+# Common prep for all test targets
+test_prep : ${blib_lib_libparrot_a} assemble.pl
test_dummy :
$(PERL) t/harness $(TEST_PROG_ARGS)
-testp : $(TEST_PROG) assemble.pl blib/lib/libcore_prederef$(SO)
blib/lib/libparrot$(SO) $(TEST_PROG_SO) test_dummy_p
+testp : $(TEST_PROG) test_prep blib/lib/libcore_prederef$(SO) blib/lib/libparrot$(SO)
+$(TEST_PROG_SO) test_dummy_p
test_dummy_p :
$(PERL) t/harness $(TEST_PROG_ARGS) -P
-testj : $(TEST_PROG) assemble.pl test_dummy_j
+testj : $(TEST_PROG) test_prep test_dummy_j
test_dummy_j :
$(PERL) t/harness $(TEST_PROG_ARGS) -j
-quicktest : $(TEST_PROG) assemble.pl quicktest_dummy
+quicktest : $(TEST_PROG) test_prep quicktest_dummy
quicktest_dummy :
$(PERL) t/harness $(TEST_PROG_ARGS) quick
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: @array = %hash
At 8:48 AM -0600 9/3/02, Luke Palmer wrote:
> > Hmm... I think I'd rather see
>>
>>my $foo is Bag = @array.as('Bag');
>>
>> The idea being that one could treat hashes and arrays as syntactic
>> vitamins meaning 'Dictionary' (to use the Smalltalk term) and
>> 'OrderedCollection', but all Collections would implement an C
>> method allowing conversion between the different classes.
>>
>> Hmm... you know, the more I think about that idea, the more I like
>> it...
>
>Likewise. I've always liked languages with complete standard libraries in
>terms of data structures. It would be great to see Perl be one of them.
PMCs can be loaded on demand. Make them good and there's no reason
they can't be in a standard SDK for parrot...
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: auto deserialization
From: Damian Conway
> But I must say I now like Adam's
>
> my Date $date .= new('June 25, 2002');
>
> much more than my own proposal.
This thread appears to have wound down, but I'm still a little confused. I
understand the above syntax could be used to pass initialization data to the
constructor, but why wouldn't the original suggestion work for an object
doesn't require it initialization data and supports lvalue assignment?
Don't the following statements have identical meaning?
my Date $date;
my Date $date = Date->new();
And admittedly, I don't have a firm grasp on how lvalue assignment would be
mapped to object methods... but wouldn't the following statements also be
identical?
$date = 'June 25, 2002';
$date->STORE('June 25, 2002');
So what again is wrong with:
my Date $date = 'June 25, 2002';
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
RE: auto deserialization
In a message dated Tue, 3 Sep 2002, Garrett Goebel writes:
> Don't the following statements have identical meaning?
>
> my Date $date;
> my Date $date = Date->new();
Not at all. The first declares that $date is a variable containing Date
objects, the second does the same, plus instantiates a new object. The
difference is analogous to
my str $foo;
my str $foo = "bar";
> And admittedly, I don't have a firm grasp on how lvalue assignment would be
> mapped to object methods... but wouldn't the following statements also be
> identical?
>
> $date = 'June 25, 2002';
> $date->STORE('June 25, 2002');
If it were a tied scalar, indubitably (assuming that Perl 6 ties work like
Perl 5 ties). But if it weren't, it would be like doing... oh, I don't
know, maybe:
%foo = "June 25, 2002";
Since typing of variables is new in Perl 6, there's no exact equivalent,
but you get the idea.
> So what again is wrong with:
>
> my Date $date = 'June 25, 2002';
Nothing--if Date is tieable and implements a STORE method which
instantiates a new object.
Trey
RE: auto deserialization
In a message dated Tue, 3 Sep 2002, Trey Harris writes:
> > So what again is wrong with:
> >
> > my Date $date = 'June 25, 2002';
>
> Nothing--if Date is tieable and implements a STORE method which
> instantiates a new object.
Well, now that I re-read my own comments, I have to retract this, because
you never tied $date, so there's no reason to expect STORE to be called.
BUT--if Date's TIESCALAR method provides for default arguments, I see no
reason why this couldn't work. But since we haven't heard anything about
tied variable changes yet, who knows?
This would actually be pretty nice. Something like
use DB6 is database('/tmp/db1.db'), mode(0644), type(DB6.btree);
my DB6 %foo;
$foo{bar} = "bat"; # Autovivifies %foo, which calls TIEHASH (with
# arguments already defaulted in use line),
# then STORE
Trey
[perl #16968] [PATCH] Add configuration summary
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #16968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16968 >
The following patch causes Configure to generate a 'myconfig' file that
summarizes the current parrot configuration (much like perl5's 'myconfig'
or perl -V output).
This patch also includes makefile targets to generate OK and Not OK
reports, and a simple tools/dev/genrpt.pl script to generate those
reports.
I think such things will be useful as we try to make parrot more portable
and assess how we are doing.
diff -r -u -N parrot-orig/MANIFEST parrot-andy/MANIFEST
--- parrot-orig/MANIFESTThu Aug 29 16:56:27 2002
+++ parrot-andy/MANIFESTTue Sep 3 12:24:25 2002
@@ -70,6 +70,8 @@
config/gen/makefiles/perl6.in
config/gen/makefiles/root.in
config/gen/makefiles/scheme.in
+config/gen/myconfig.pl
+config/gen/myconfig/myconfig.in
config/gen/platform.pl
config/gen/platform/ansi.c
config/gen/platform/ansi.h
@@ -590,6 +592,7 @@
t/src/basic.t
test_main.c
tools/dev/check_source_standards.pl
+tools/dev/genrpt.pl
tools/dev/lib_deps.pl
tools/dev/manicheck.pl
tools/dev/parrot_coverage.pl
diff -r -u -N parrot-orig/MANIFEST.SKIP parrot-andy/MANIFEST.SKIP
--- parrot-orig/MANIFEST.SKIP Wed Jun 12 18:12:15 2002
+++ parrot-andy/MANIFEST.SKIP Tue Sep 3 11:33:14 2002
@@ -9,7 +9,6 @@
/Makefile$
^lib/Parrot/Config\.pm$
^platform\.c$
-^config.opt$
^include/parrot/vtable\.h$
^include/parrot/jit_struct\.h$
diff -r -u -N parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inTue Sep 3 12:37:04 2002
+++ parrot-andy/config/gen/makefiles/root.inTue Sep 3 12:29:59 2002
@@ -31,7 +31,7 @@
GEN_CONFIGS = include/parrot/config.h include/parrot/platform.h \
lib/Parrot/Config.pm platform.c
-STICKY_FILES = $(GEN_CONFIGS) $(GEN_MAKEFILES) config.opt
+STICKY_FILES = $(GEN_CONFIGS) $(GEN_MAKEFILES) myconfig
###
@@ -276,7 +276,6 @@
lib/Parrot/PMC.pm : include/parrot/pmc.h pmc_pm.pl
$(PERL) pmc_pm.pl
-
###
#
# Examples (Assembly):
@@ -476,6 +475,18 @@
lifetest : $(TEST_PROG) examples/assembly/life.pbc
$(TEST_PROG) $(TEST_PROG_ARGS) examples/assembly/life.pbc
+# For reporting success or failure with different configurations
+ok:
+ $(PERL) tools/dev/genrpt.pl --ok
+
+okfile:
+ $(PERL) tools/dev/genrpt.pl --ok --File parrot.ok
+
+nok:
+ $(PERL) tools/dev/genrpt.pl --nok
+
+nokfile:
+ $(PERL) tools/dev/genrpt.pl --nok --File parrot.nok
###
#
diff -r -u -N parrot-orig/config/gen/myconfig/myconfig.in
parrot-andy/config/gen/myconfig/myconfig.in
--- parrot-orig/config/gen/myconfig/myconfig.in Wed Dec 31 19:00:00 1969
+++ parrot-andy/config/gen/myconfig/myconfig.in Tue Sep 3 12:34:46 2002
@@ -0,0 +1,20 @@
+Summary of my parrot ${VERSION} configuration:
+ configdate='${configdate}'
+ Platform:
+osname=${osname}, archname=${archname}
+jitcapable=${jitcapable}, jitarchname=${jitarchname},
+jitosname=${jitosname}, jitcpuarch=${jitcpuarch}
+perl=${perl}
+ Compiler:
+cc='${cc}', ccflags='${ccflags}',
+ Linker and Libraries:
+ld='${ld}', ldflags='${ldflags}',
+cc_ldflags='${cc_ldflags}',
+libs='${libs}'
+ Dynamic Linking:
+so='${so}', ld_shared='${ld_shared}',
+ld_shared_flags='${ld_shared_flags}'
+ Types:
+iv=${iv}, intvalsize=${intvalsize}, intsize=${intsize}, opcode_t=${opcode_t},
+opcode_t_size=${opcode_t_size},
+ptrsize=${ptrsize}, ptr_alignment=${ptr_alignment} byteorder=${byteorder},
+nv=${nv}, numvalsize=${numvalsize}, doublesize=${doublesize}
diff -r -u -N parrot-orig/config/gen/myconfig.pl parrot-andy/config/gen/myconfig.pl
--- parrot-orig/config/gen/myconfig.pl Wed Dec 31 19:00:00 1969
+++ parrot-andy/config/gen/myconfig.pl Tue Sep 3 11:21:37 2002
@@ -0,0 +1,15 @@
+package Configure::Step;
+
+use strict;
+use vars qw($description @args);
+use Parrot::Configure::Step ':gen';
+
+$description="Recording this configuration in myconfig...";
+
+@args=();
+
+sub runstep {
+ genfile('config/gen/myconfig/myconfig.in', 'myconfig');
+}
+
+1;
diff -r -u -N parrot-orig/lib/Parrot/Configure/RunSteps.pm
parrot-andy/lib/Parrot/Configure/RunSteps.pm
--- parrot-orig/lib/Parrot/Configure/RunSteps.pmTue Aug 27 01:05:06 2002
+++ parrot-andy/lib/Parrot/Configure/RunSteps.pmTue Sep 3 11:22:20 2002
@@ -29,6 +29,7 @@
gen/config_h.pl
gen/config_pm.pl
gen/makefiles.pl
+ gen/myconfig.pl
gen/platform.pl
gen/libparrot_def.pl
);
diff -r -u -N parrot-orig/tools/dev/genrpt.pl parrot-andy/tools/dev/genrpt.pl
--- p
Re: Hypothetical variables and scope
On Tue, 2002-09-03 at 11:35, Ken Fox wrote:
> Peter Haworth wrote:
> > Also the different operators used (:= inside the rule, = inside the code)
> > seems a bit confusing to me; I can't see that they're really doing anything
> > different:
> >
> > / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
> >
> > Shouldn't they both use C< := > ?
>
> Depends on what you want. The "$x :=" in the rule binds the
> first match to $x -- it does not copy the value. The "$x ="
> in the code block copies the value of the first match. You
> can use either binding or assignment in the code block.
Hmm... I had not thought of the copy aspect. Certainly, the code version
is more flexible. You could define C<$x> above as anything. For example:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
The binding version is just a simple, fast version of one special case,
no?
Re: auto deserialization
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Looks pretty groovy to me too. It looks like the .=
operator, no longer being employed as a string appender,
now means "use the class I just mentioned".
If so, perhaps it would only be a small step further for
it to also mean "and if I don't give the name of the method,
use new_from_[class of object being passed]". So, the following code
would call Date::new_from_String, passing 'Sep 21, 1963' as the
sole argument:
my Date $date;
$date .= 'Sep 21, 1963';
The Perl golfers will love it. It's almost as concise as the original
idea, w/o the ambuguity of what ought to be assigned (the string or a new
object). It shouldn't slow things down, either, because the determination
of the argument's class could be determined at compile time.
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: auto deserialization
In a message dated Tue, 3 Sep 2002, [EMAIL PROTECTED] writes:
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
>
> If so, perhaps it would only be a small step further for
> it to also mean "and if I don't give the name of the method,
> use new_from_[class of object being passed]". So, the following code
> would call Date::new_from_String, passing 'Sep 21, 1963' as the
> sole argument:
>
> my Date $date;
> $date .= 'Sep 21, 1963';
>
> The Perl golfers will love it. It's almost as concise as the original
> idea, w/o the ambuguity of what ought to be assigned (the string or a new
> object). It shouldn't slow things down, either, because the determination
> of the argument's class could be determined at compile time.
But...
no strict 'refs';
my Date $date;
$date .= 'Sep 21, 1963';
There is a method name there--'Date::Sep 21, 1963'.
Okay, maybe that's a far-fetched example. But:
no strict 'refs';
my Date $date;
$date .= 'today';
Call Date.today() and assign its result to $date, or Call
Date.new('today') and assign it to $date?
I think the method name is required in this case.
Trey
Re: auto deserialization
From: Trey Harris [EMAIL PROTECTED]
> no strict 'refs';
> my Date $date;
> $date .= 'Sep 21, 1963';
>
> There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or the class
because the compiler would understand what to call. It would see that
$date is in the Date class, and 'Sep 21, 1963' is in the String class, so
it would pretend the statement really reads
$date = Date::new_from_String('Sep 21, 1963');
mail2web - Check your email from the web at
http://mail2web.com/ .
Parrot: maximizing the audience
Hi there, As a recent parroter, what striked me most while reading perl6-internals, is that it's very perl-centric. Ok, I agree that: * only Perl (and Larry) has planned its roadmap to include Parrot as its final virtual machine. * the name "perl6-internals" is really too restrictive (but this point has already been discussed last week). * there's always some, erhm, rivalry between Perl and, say, Python or Ruby or (insert-your-second-eheh-favorite-language-here). But the ultimate goal of Parrot is World Domination^W^Wto be THE virtual machine, the one that every language should target, and the one that could spit whatever we want, either execution, or parrot precompiled/preoptimized bytecode, or corresponding C source, or native executable, or whatever. So, I think parrot could definitely benefit from a wider audience, and I'm sure: * development would be faster. Some of (insert-a-language-name-here) guys are really good and could help parrot tremendously. * development would be better. Remember the cathedral and the bazaar: the more people are looking at your code, the more bugs you can catch. * development would be more open. Maybe (I'm not a Parrot wizard) some things in Parrot are designed in a perl-centric way. This may be bad, since it would be more difficult to address new languages, and maybe being too perl-centric will lead to a bad design (once again, I'm not sure this is the case, I still have a lot of Parrot studying to do ;) ). I know it's easy to say this, but what could _we_ do in order to open parrot to non-perl centric people? Btw, I found this url while idling on the web: http://cvs.sf.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/parrot/parrot-gen.py This seems to be a beginning python->parrot compiler. I don't know wether you already know of this project, or wether it's still a work in progress. But it may be worth it to ask them if they want to "join the fun", and if they would like to participate with the design of parrot, instead of following and waiting for new releases of Parrot... Just my 2 cents, Jerome -- [EMAIL PROTECTED]
Re: auto deserialization
[EMAIL PROTECTED] wrote:
> From: Trey Harris [EMAIL PROTECTED]
>
>>no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>>There is a method name there--'Date::Sep 21, 1963'.
>
>
> But that's my point. You wouldn't have to put the method name or the
class
> because the compiler would understand what to call. It would see that
> $date is in the Date class, and 'Sep 21, 1963' is in the String class, so
> it would pretend the statement really reads
>
>$date = Date::new_from_String('Sep 21, 1963');
my Date $date;
$date .= getText("/Transaction/TransactionDTM");
does this call the locally visible function/method "getText", take the
string that results from that, and then does $date =
Date::new_from_String() on the result, or does it try to do
$date = $date.getText("/Transaction/TransactionDTM");
My feeling is the latter.
$date += 4; # $date = $date + 4;
$date -= 4; # $date = $date - 4;
$date *= 4; # $date = $date * 4;
$date .= foo; # $date = #date.foo;
I suspect that, if it makes sense to say
$foo = &$date.method;
then it would also make sense to say
$date .= $foo;
as well.
>
>
>
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
>
sub/method refs (was Re: auto deserialization)
In a message dated Tue, 3 Sep 2002, Buddha Buck writes: > I suspect that, if it makes sense to say > > $foo = &$date.method; > > then it would also make sense to say > > $date .= $foo; > > as well. Interesting, that first line $foo = &$date.method; I need a bit of a refresher here, as my searches of the archives have turned up blank. Ampersand replaces P5 C<\&> in taking a reference to a subroutine or method? And ampersand is no longer used to call a subroutine, in any context? So: $foo = &$date.method(); Would call $date.method, and return a reference to (a reference to) the subroutine returned by Date::method()? I have a feeling that, as much nicer as Perl 6 references will be compared to the Perl 5 punctuation-salad, it will take a long time to do it automatically. It'll feel like grabbing for the stick-shift and clutch that aren't there when you're driving an automatic Trey
Re: sub/method refs (was Re: auto deserialization)
Trey Harris wrote: > In a message dated Tue, 3 Sep 2002, Buddha Buck writes: > >>I suspect that, if it makes sense to say >> >>$foo = &$date.method; >> >>then it would also make sense to say >> >>$date .= $foo; >> >>as well. > > > Interesting, that first line > $foo = &$date.method; > > I need a bit of a refresher here, as my searches of the archives have > turned up blank. Ampersand replaces P5 C<\&> in taking a reference to a > subroutine or method? And ampersand is no longer used to call a > subroutine, in any context? Actually, I think I got confused... Most of my work recently has been in C++, which uses & for references. Perhaps that should have been: $foo = \$date.method; So: > > $foo = &$date.method(); > > Would call $date.method, and return a reference to (a reference to) the > subroutine returned by Date::method()? > > I have a feeling that, as much nicer as Perl 6 references will be compared > to the Perl 5 punctuation-salad, it will take a long time to do it > automatically. It'll feel like grabbing for the stick-shift and clutch > that aren't there when you're driving an automatic > > Trey > >
Re: auto deserialization
At 4:21 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
>From: Trey Harris [EMAIL PROTECTED]
>> no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>> There is a method name there--'Date::Sep 21, 1963'.
>
>But that's my point. You wouldn't have to put the method name or the class
>because the compiler would understand what to call. It would see that
>$date is in the Date class, and 'Sep 21, 1963' is in the String class, so
>it would pretend the statement really reads
>
>$date = Date::new_from_String('Sep 21, 1963');
This will potentially get out of hand quickly. So, to get this out of
the way *now*...
If you're going to do this, you might as well go fully multimethod,
because someone'll want new_from_Integer, new_from_Float,
new_from_BigNum, new_from_Thread, new_from_Grue, and
new_from_Superposition.
Decide whether that's a good idea or not, since that's the way things
are going to go if you start.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: auto deserialization
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
Not quite. .= means exactly what you'd expect it to mean, "call a method on
the object on the left and assign the result to the variable on the left". So
$date .= new('Jun 25, 2002');
means exactly the same as
$date = $date.new('Jun 25, 2002');
(I'd expect .= to be a valid operator anyway, so one could do $linked_list_item
..= next(), but that's beside the point).
The utility comes when $date.new() calls the (static) new function on the Date
class even if $date is undef. (In essence, "my Date $date;" makes $date an
interesting value of undef, one that's not defined but has a .class() value).
Of course, this doesn't do anything in particular for constructors. We could
also call any static class function on that object.
> If so, perhaps it would only be a small step further for
> it to also mean "and if I don't give the name of the method,
> use new_from_[class of object being passed]". So, the following code
> would call Date::new_from_String, passing 'Sep 21, 1963' as the
> sole argument:
>
> my Date $date;
> $date .= 'Sep 21, 1963';
The problem is that it's not just for static functions. The point is that
"$date .= foo" would be exactly like "$date = $date.foo", and having an
implicit constructor seems really messed up. I guess that would mean that I
could pass Date.'Sep 21, 1963' to anything expecting a Date object. I think
that might be just slightly too magical for comfort. I don't like the idea of
object types automagically converting themselves by context; that way madness
lies. If you want "new" just call it.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Why does man kill? He kills for food. And not only food: frequently
there must be a beverage.
-- Woody Allen, "Without Feathers"
Re: Parrot: maximizing the audience
On 3 Sep 2002 at 22:17, Jerome Quelin wrote: > Hi there, > > As a recent parroter, what striked me most while reading perl6-internals, is > that it's very perl-centric. Ok, I agree that: > ... > * the name "perl6-internals" is really too restrictive (but this point has > already been discussed last week). > ... Would it be possible to rename "perl6-internals" now to something better like "parrot-internals"? There probably are some big problems in renaming an active list, but this could give us more non-perl developers interested in parrot. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Parrot: maximizing the audience
On Tue, 3 Sep 2002, Markus Laire wrote: > On 3 Sep 2002 at 22:17, Jerome Quelin wrote: > > > Hi there, > > > > As a recent parroter, what striked me most while reading perl6-internals, is > > that it's very perl-centric. Ok, I agree that: > > ... > > * the name "perl6-internals" is really too restrictive (but this point has > > already been discussed last week). > > ... > > Would it be possible to rename "perl6-internals" now to something > better like "parrot-internals"? I think aliases can take care of this, though I'm not the sysadmin. Maybe it makes people feel better to send mail to "parrot-internals" instead of "perl6-internals", but I don't see how giving the list a different name will have any real effect beyond breaking my procmail setup. /s
Re: auto deserialization
On Tue, Sep 03, 2002 at 04:04:13PM -0400, [EMAIL PROTECTED] wrote:
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
Er, not quite. It's just like the other X= operators:
$a = $a + 1 -> $a += 1
$a = $a.new(...)-> $a .= new(...)
So, in the date example:
my Date $date .= new('Sep 21, 1963');
it calls $date.new() and since $date is a Date we get Date.new()
(at least that's how I understand things)
But what happens when someone accidently does this:
my Dog $spot .= Greyhound.new('Lightning');
Somehow I think this will be a common error if this syntax is adopted
(though, in truth, I like it MUCH better than the alternatives I've
seen so far). I'd expect Perl to complain loudly if someone does the
above, but other people may have other ideas.
> If so, perhaps it would only be a small step further for
> it to also mean "and if I don't give the name of the method,
> use new_from_[class of object being passed]". So, the following code
> would call Date::new_from_String, passing 'Sep 21, 1963' as the
> sole argument:
>
> my Date $date;
> $date .= 'Sep 21, 1963';
I too thought of this only it looked more like
my Date $date .= 'Sep 21, 1963';# swell foop
and then I thought things like:
What happens if there is no constructor?
How does it know which constructor to call?
The first question is easily answered by "Perl throws an
exception/error". The second question is more of a general question
about method resolution. I don't recall if it's been decided that there
will be a One True Constructor name (somehow I doubt it), or exactly how
you tag methods as being constructors, but if you can do this:
sub wilma is ctor (str $s) { ... }
sub betty is ctor (str $s) { ... }
then how does Perl know which constructor to call? Or would declaring
two constuctors like that cause Perl to carp at you? (I can't think
of a case where someone would want to have two constructors like that,
but I'm not letting my lack of imagination hinder this discussion :-)
Anyway, I think the method name should be required.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: auto deserialization
From: Dan Sugalski [EMAIL PROTECTED] > This will potentially get out of hand quickly I don't think this is a case where out-of-hand-generalization is necessary. I'm only saying that there could be a handy shorthand for a single very common case. Nevertheless, I'll simplify the proposal. Oh, and forget I said anything about the .= operator, I'm glad it's keeping its current job. Suppose there were a #= operator (or whatever you like) which means nothing more and nothing less than "instantiate an object of the type the variable is declared for using the 'new' method of that class. Pass the value on the right as the single argument, and assign the results to the variable on the left". To me that results in delightfully clean and unambiguous code like $date #= 'Sep 21, 1963'; If the compiler detects that there is no 'new' method that accepts a single argument of the type to the right of the operator then that's a compile-time error. mail2web - Check your email from the web at http://mail2web.com/ .
RE: auto deserialization
Damian Conway:
# Though I expect he probably will, since treating classes as
# "first class" entities in Perl 6 implies that capability
# (amongst many others).
I fear we're treading a little too close to classes being the "new
filehandles"--relatively limited entities with no sigils that confuse
the syntax horribly. There's already at least one ambiguous case:
module Foo::Bar::Baz {}
module Foo::Bar { sub Baz {} }
my $var = Foo::Bar::Baz;#module name or function call?
Which seems strangely reminiscent to:
sub foo {}
open foo, ">foo";
print foo $x; #filehandle or function call?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
RE: Parrot: maximizing the audience
Sean O'Rourke:
# > Would it be possible to rename "perl6-internals" now to something
# > better like "parrot-internals"?
#
# I think aliases can take care of this, though I'm not the
# sysadmin. Maybe it makes people feel better to send mail to
# "parrot-internals" instead of "perl6-internals", but I don't
# see how giving the list a different name will have any real
# effect beyond breaking my procmail setup.
And there's still that pesky @perl.org at the end. So if we do this, I
suggest we take the full jump:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
Re: auto deserialization
At 6:03 PM -0400 9/3/02, [EMAIL PROTECTED] wrote: >From: Dan Sugalski [EMAIL PROTECTED] >> This will potentially get out of hand quickly > >I don't think this is a case where out-of-hand-generalization is necessary. >I'm only saying that there could be a handy shorthand for a single very >common case. Each object has its own common case, and strings aren't always it. Date could reasonably want strings, but also an integer timestamp makes sense, as does an array with localtime information. Then again, maybe initializing from a localtime object would make sense. How about a JPEG object? Might take a string with the image data, an array with byte data, a filehandle that's got the data to it. There is no one common case that's common for everything, or even most things. If you want automatic initializers, you have to bite the bullet and go full multimethod, or spend the rest of eternity explaining why string-only "seemed like a good enough idea at the time" -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: auto deserialization
From: "Dan Sugalski" <[EMAIL PROTECTED]> > How about a JPEG object? Might take a string with the image data, an > array with byte data, a filehandle that's got the data to it. But those situations are all covered by the #= concept: call the new method passing the right argument. So for a JPEG that can take a string, a filehandle, or an image, it works: $myjepg #= $mystring; $myjepg #= $myfh; $myjepg #= $myarray; all of which would be as valid (or not) as $myjepg = JPEG->new($mywhatever); > If you want automatic initializers But again, I don't see that the idea requires automatic initializers. It's little more than a precompiler shorthand. It would simply rearrange the arguments a little bit, then compile or not based on if the same rules as always. -Miko
RE: auto deserialization
> my Date $date .= new('June 25, 2002');
If we're assuming that C creates an C
object, then that object should be able to overload its assignment operator.
I don't know what the perl6 syntax will be, but something along the lines of
class Date
{
method operator= ($value is rx//)
{
unless (defined $self)
{
$self = .new()
}
$.year = $value{year};
$.month = $value{month};
# etc.
}
};
should cover it, assuming it is "valid" style for a variable to act as a
value rather than an object-reference.
Dave.
Re: auto deserialization
At 7:48 PM -0400 9/3/02, Miko O'Sullivan wrote: >From: "Dan Sugalski" <[EMAIL PROTECTED]> >> How about a JPEG object? Might take a string with the image data, an >> array with byte data, a filehandle that's got the data to it. > >But those situations are all covered by the #= concept: We call that concept "multimethod dispatch". That's what you're asking for. > > If you want automatic initializers > >But again, I don't see that the idea requires automatic initializers. Look closer. It is *not* compiler shorthand--you can't fully know the types of the potential initializers at compile time. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Multimethod Dispatch
On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote: > We call that concept "multimethod dispatch". That's what you're asking > for. Dan, can you explain what "multimethod dispatch" is? Thanks! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Multimethod Dispatch
At 5:41 PM -0700 9/3/02, David Wheeler wrote:
>On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
>
>>We call that concept "multimethod dispatch". That's what you're asking for.
>
>Dan, can you explain what "multimethod dispatch" is?
Damian can explain it better than I can, but it's essentially when
you dispatch based on sub or method signature. You're allowed to have
multiple versions of a single sub as long as they differ in their
parameter signature.
So you could have a
sub xyzzy(Foo $a) {
print "Foo!\n";
}
as well as a:
sub xyzzy(Bar $a) {
print "Bar!\n";
}
And at runtime when you call xyzzy, the system looks at your
parameter to decide which to call. Inheritance trees are searched as
well, so if you had a Baz, which ISA Bar, calling xyzzy with a Baz
would print out "Bar!"
Things get... interesting with multiple inheritance, and multiple
parameters, but the general solution to potential conflicts, where
there are two or more equally "right" things is to either use a
default or throw an exception.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Argument aliasing for subs
Hello All,
Has anyone considered a syntax for allowing subroutines to have many
different names for the same argument? For example, in CGI.pm, many
methods support the "-override" parameter but can also accept the alias
of "-force":
$cgi->hidden(-name => "a", -override => 1); #same as
$cgi->hidden(-name => "a", -force => 1);
As far as I can guess, we could use the binding operator to make it work
something like this**:
sub hidden (str $name; int $force, int $override:=$force) { ... }
or maybe even
sub hidden (str $name; int $override:=int $force) { ... }
I have doubts about that last one, since I suspect that people will want
to know what
$force = "dp/dt";
sub work ($distance, $push:=$force) { ... }
is supposed to do, but these are only suggestions. Anyone else want to
shed light on the matter?
Thanks,
Peter Behroozi
**Of course, the real CGI::hidden() also has the "-default" named
argument, but I left that out for clarity.
Re: Multimethod Dispatch
On Tuesday, September 3, 2002, at 06:12 PM, Dan Sugalski wrote: > Damian can explain it better than I can, but it's essentially when you > dispatch based on sub or method signature. You're allowed to have > multiple versions of a single sub as long as they differ in their > parameter signature. Ah, yes, the same thing exists in Java. I remember, now. Thanks Dan, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: atomicness and \n
Damian Conway:
# Neither. You need:
#
# $roundor7 = rx /<+[17]>/
#
# That is: the union of the two character classes.
How can you be sure that is implemented as a character
class, as opposed to (say) an alternation?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
Re: [perl #16968] [PATCH] Add configuration summary
On Tue, Sep 03, 2002 at 04:59:44PM +, Andy Dougherty wrote: > > The following patch causes Configure to generate a 'myconfig' file that > summarizes the current parrot configuration (much like perl5's 'myconfig' > or perl -V output). > > This patch also includes makefile targets to generate OK and Not OK > reports, and a simple tools/dev/genrpt.pl script to generate those > reports. > > I think such things will be useful as we try to make parrot more portable > and assess how we are doing. Thanks, applied.
RE: atomicness and \n
On Tue, 3 Sep 2002, Brent Dax wrote: > Damian Conway: > # Neither. You need: > # > # $roundor7 = rx /<+[17]>/ > # > # That is: the union of the two character classes. > > How can you be sure that is implemented as a character > class, as opposed to (say) an alternation? What's the difference? :) Neglecting internals, semantically what I the difference? Luke
RE: atomicness and \n
On Tue, 3 Sep 2002, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > Damian Conway: > > # Neither. You need: > > # > > # $roundor7 = rx /<+[17]>/ > > # > > # That is: the union of the two character classes. > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? None, I think. Of course, if we ignore internals, there's no difference bewteen that and "rx / | 1 | 7/". /s
Re: atomicness and \n
On Tue, Sep 03, 2002 at 09:57:31PM -0600, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > Damian Conway: > > # Neither. You need: > > # > > # $roundor7 = rx /<+[17]>/ > > # > > # That is: the union of the two character classes. > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? I think the point still stands. How can you be sure that is implemented as a character class instead of being some other arbitrary rule? An answer is that perl should know how these things are implemented and if you try arithmetic on something that's not a character class, it should carp appropriately. Another answer might be that <+[17]> is actually syntactically illegal and you MUST perform character class arithmetic as <[abc]+[def]>. Somehow I prefer the former to the latter. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Parrot: maximizing the audience
On Tue, 2002-09-03 at 17:03, Sean O'Rourke wrote: > On Tue, 3 Sep 2002, Markus Laire wrote: > > Would it be possible to rename "perl6-internals" now to something > > better like "parrot-internals"? > > I think aliases can take care of this, though I'm not the sysadmin. > Maybe it makes people feel better to send mail to "parrot-internals" > instead of "perl6-internals", but I don't see how giving the list a > different name will have any real effect beyond breaking my procmail > setup. FWIW: I think you will eventually find that there are several different audiences here. There are the folks who are working on parrot and/or imcc. There are the folks who are working on actual Perl 6 internals (e.g. P6C). There are also others working on other language font-ends. I've been thinking about tackling a [bourne [again]?|korn] shell front-end to allow large shell programs (not mentioning names *cough* Big Brother *cough*) to be slowly replaced from the inside out.
Re: [perl #16965] [PATCH] Fix some test_prep dependencies.
On Tue, Sep 03, 2002 at 02:55:05PM +, Andy Dougherty wrote: > # New Ticket Created by Andy Dougherty > # Please include the string: [perl #16965] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=16965 > > > > This patch gathers together different testing dependencies into a new > test_prep target, and then uses that target where appropriate. This > should reclaim the Solaris 32-bit JIT tinderbox -- it was failing > because the testj: target didn't have the proper libparrot.a dependency. > > Whatever the final resolution of that dependency, this patch consolidates > the debate into one test_prep target. Thanks, applied. Although I sometimes wonder whether it should be using libparrot.a or libparrot.so, but I'll leave that for later.
RE: atomicness and \n
On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > On Tue, 3 Sep 2002, Luke Palmer wrote: > > > On Tue, 3 Sep 2002, Brent Dax wrote: > > > > > Damian Conway: > > > # $roundor7 = rx /<+[17]>/ > > > # > > > # That is: the union of the two character classes. > > > > > > How can you be sure that is implemented as a character > > > class, as opposed to (say) an alternation? > > > > What's the difference? :) > None, I think. Of course, if we ignore internals, there's no difference > bewteen that and "rx / | 1 | 7/". Then, why is there a C<+>? Why not make it C<|>? $foo = rx/ <||[cde]>|f /
Re: Parrot: maximizing the audience
IANADan, but he's aware of these issues, and is/has been thinking about them. Separating Parrot isn't as trivial as s/erl/arrot/g, and probably won't be done *completely*. We're not going to fool anyone that this isn't a Pet Perl Project, and while other communities are eyeing us, it's not clear that the amount of work to obliterate that line is going to be worth the cost. If there are going to be changes made, they'll most likely be made incrementally, which, of course, means that by the time the last changes are made, there will be even more to rip out and redo. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
