Re: A6: Quick questions as I work on Perl6::Parameters
On Tue, 18 Mar 2003 20:43:00 +, Luke Palmer wrote:
Damian wrote:
caller :{.label eq 'MAINLOOP};
Errr what is that odd and disturbing notation? I don't recall ever seeing
that.
It's vaguely sinister. Must be the moustache operator.
-- c
This week's Summary
The Perl 6 Summary for the week ending 20030323 Assuming I can tear myself away from stroking the cat who has just magically appeared on my chest and is even now trying to wipe his dags on my nose, welcome one and all to another Perl 6 summary, which should go a lot quicker now that Sully has moved off and let me see the screen. He'll be back though. But before that happens we'll start with perl6-internals. Speed question: save/restore vs push/pop Benjamin Goldberg wondered about how many saves it takes to be slower than one pushx. Steve Fink pointed out that save and pushx are not interchangeable as they push things onto totally different stacks (save pushes onto the generic user stack, pushx push onto type specific register frame stacks). Leo Tötsch ignored this difference (which Ben was apparently aware of) and did some tests which showed that, on his local architecture and core, 2 saves were slower than one push. On Dan's machine, it took 3 saves to be slower than one push. Dan also pointed out that, on some architectures, there's a subtle win with saves because a push would dirty the L1 and L2 caches while the save wouldn't. (On SPARC at least, apparently). http://xrl.us/eth Baby Steps in porting IO to the PIO architecture Last week, Leon Brocard posted his implementation of the uniq(1) Unix utility to PASM. This week, Jürgen Bömmels' ongoing project of moving Parrot's IO operators from the STDIO library to Parrot's own PIO library (which is asynchronous and a combination of lovely and scary by all reports.) broke this because PIO didn't have any read buffering capabilities, which means that the readline op didn't work. On Monday, Jürgen had write buffering working, which Dan applied with alacrity while making noises about needing to finish up the documentation for Parrot's asynchronous IO system. There was some debate on whether a PIO flush should force a write to the disk, or simply ensure that all the buffers were flushed to the OS. Nicholas Clark discussed some issues he'd had with Perl 5.8's PerlIO system, and the need for two different kinds of flush, or more succinctly, the need to distinguish 'flush' from 'sync'. Dan was convinced by this argument and Steve Fink seconded the decision. Then, on Sunday, Jürgen released a patch which got read buffering working. Dan had a few problems with it and the patch hadn't been applied by the end of the week. I'm sure it'll go in like a greased weasel once that's been fixed though. http://xrl.us/eti -- Jürgen adds write buffering http://xrl.us/etj -- Nicholas discusses different types of flush http://xrl.us/etk -- Jürgen adds read buffering PBC Object Files Michael Collins wondered if it might be a good idea to come up with a parrot 'object file' specification. I liked Michael's description of an object file as 'a file that contains compiled instructions plus a section with a table that maps subroutine/constant labels to their corresponding byte offsets within the file.' Leo Tötsch's answer was 'not yet'. Apparently the basic functionality is there but there are some cleanups and a couple of opcodes needed. http://xrl.us/etl Parrot binaries Ask Bjørn Hansen posted to say that he'd been trying to make an RPM .spec file for parrot and had noted the lack of a make install target. He also wondered about the permissions of various files in the distribution, which seem somewhat cockeyed. Steve Fink posted a patch which covered some of this (or at least the make install and RPM issues) with tools which would generate RPMs and asked for comments on his work. Leo Tötsch liked it and offered a couple of suggestions http://xrl.us/etm http://xrl.us/etn -- Steve's working patch Some comments on PDD 14 Big Numbers Mark Biggar, who implemented the original Big* packages for Perl had some suggestions about Parrot's big number handling based on PDD 14. Benjamin Goldberg wondered if it would be a good idea to design our BigInt type so that we could replace the maths engine with a different engine so that users could pick which ever engine they prefer as configuration option, and so that new maths engines could be added without having to make wholesale changes. http://xrl.us/eto 99 bottles of beer on the wall Douglas Hunter appears to have noticed that, up until now, Parrot had lacked a vital program -- one which would output the lyrics to that well known song, *99 Bottles of Beer on the Wall*. So, being a community spirited kind of chap, he implemented just that and posted it to the list. A few people quibbled about his style (unnecessary labels, that sort of thing). Leo Tötsch pointed out, with the aid of some IMCC output that the optimizer caught those issues
Re: is static? -- Question
suppose I want this behaviour :
sub new_counter($start=0) {
my $cnt = $start;
my sub incr {
++$cnt;
};
my sub decr {
--$cnt;
};
return sub (str $how=incr)
{
given $str {
when /incr/ incr ;
when /decr/ decr ;
}
}
and then has allows me to do that .
sub new_counter($start=0) {
has $cnt = $start;
has sub cnt {
$cnt;
};
has sub incr {
++$cnt;
};
has sub decr {
--$cnt;
};
return 1; # this is 1 with properties
}
and then :
our $cnt = new_counter ;
$cnt.incr
$cnt.decr
$cnt.cnt
this does not seem to give second unrelated meaning to has.
but, actually, I dont know .
arcadi
A6: argument initializations via //=, ||=, ::=
Getting back to A6, a few thoughts. From the 'Re: is static?' thread:
On Wednesday, March 19, 2003, at 08:30 AM, Larry Wall wrote:
Well, people *will* write
state $foo = 0;
The question is what that should mean, and which major set of people
we want to give the minor surprise to, and how much effort we want
to expend in training to avoid the surprise in the first place.
There's something to be said for keeping = as assignment outside
of sigs. But it's not clear whether that = is part of a sig...
snip
Most use will be to init with a compile-time constant, so I suppose
we could train people to just say:
state $foo ::= 0;
We don't have a word for START right now. It's somewhat equivalent
to
state $foo //= 0
unless $foo gets undefined, I suppose.
That's where that particular thread ended -- from there, it diverged
into a subthread about Cstate behavior within nested subs/closures.
Ignoring the closure parts, and getting back to the more generic idea
of Cstate:
Assuming we have a static-like scope called Cstate, one can
definitely see the use of having an assignment variant for not yet
initialized or doesn't yet exist, the proposed spelling of which was
C::=. That gives us:
state $baz = 0;
state $baz ::= 'blah'; # if doesn't exist or not
initialized
state $baz //= 'blah'; # if $baz is undefined
state $baz ||= 'blah'; # if $baz is false
state $baz = 'blah'; # if $baz is true
state $baz ??= 'blah' :: 'blarp'; # if $baz is true|false
Of course, for Cstate scoped vars, C::= is the only one that makes
much sense, and C::= doesn't make much sense for lexical vars. (One
could argue that C= should just mimic C::= for Cstate-scoped, but
I'm not going to.)
---
OK, so tying that back in to A6... people have suggested extending //=
and/or ::= into signatures. The more I think about it, the better I
like this approach, and the more justified it seems. Right now we have:
sub foo($x = 0) {...}# same as C$x is default(0)
to set the $x param to 0 _if it was not specified by the caller_. But
it is certainly possible to extend the initialization capabilities to
be more robust:
sub foo($x = 'blah') {...} # wrong: use one of the below
sub foo($x ::= 'blah') {...} # same as C$x is default('blah')
sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
The utility of this is that it gives the signature significantly more
control over the initialization of individual parameters, regardless of
the actual function/method implementation. Maybe sigs _should_ be
able to make certain assertions about their arguments, and even
adjustments to them, before they hit the 'real' implementation.
There has been some debate about the power that sigs should be given.
Specifically, I'm thinking of the old how do you make an assertion
upon an argument debate of a few months ago, and the terror of
ten-line-long function sigs with assertions attached to the various
parameters. But it's largely a false debate, I would argue: if you
want all possible implementations of a given function/method to share
the same precise parameter assertions, they _should_ be specified in
one place, not in twenty. (subs are objects, have inheritance, etc...
more on this later). But TMTOWTDI, if that's not your style.
Anyway, I can definitely see merit in allowing those particular
constructs for the sake of significantly smarter sigs. I can see
_practical_ uses for C::=, C//=, and ||= -- enough so that they
probably should be differentiated, and that I would even propose the
C= spelling, in sigs, be dropped as ambiguous/meaningless.
?
MikeL
P6ML?
So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? MikeL
Re: P6ML?
Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? Imho P6ML is a bad idea, if it means what I think it means (creating a parser for quasi-MLs). People will laugh at our folly, and rightly so for trying to be able to parse all the horrors of the world in a sensical manner will lead to the same madness that happened with HTML. People will also hate us, and rightly so, for increasing tolerance for that kind of behaviour goes against the work accomplished over the past five years. There are a number of pockets of bugosity that still produce broken XML, but they are being quenched one by one. Being too kind to them will only encourage them. As someone that works with XML every single second of my work time (and much of my fun time), I can only too well understand the frustration of developers faced with other people's buggy output and do want to help. But as someone that also had to parse other people's random formats before we had XML, I would like to stress strongly the fact that the current situation is *much* better than it was. Encouraging people to produce broken data by making efforts in that area at more or less language level visibilities is a step backwards (Oh, it's broken but they use Perl so it doesn't matter). If it is creating a /toolset/ to make recuperating data from a quasi-XML (aka tag soup) then it is an interesting area of research. I can think of two approaches: - have a parametrisable XML grammar. By default it would really parse XML, and barf with extreme prejudice on errors. However individual rules will be relaxable and modifiable to accept different, possibly slightly broken, input. This is imho the least desirable approach. - base a quasi-parser on something that does quasi-parsing well, namely an HTML parser, which would be wrapped to look like an XML parser but would be able to correct most typical problems (poorly defined entities, missing end tags, encoding errors, etc). Advantages are: a) it addresses 98% of existing problems, b) trying to solve the remaining issues in any non ad hoc manner is suicidal, c) can be pointed to to developers in trouble, and d) has very low general public visibility. Oh, and e) the perl-xml community is already on it, expect something in the month to come. Either way, I really think it shouldn't be called P6ML. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: A6: argument initializations via //=, ||=, ::=
On Tue, Mar 25, 2003 at 10:42:39AM -0800, Michael Lazzaro wrote:
But it is certainly possible to extend the initialization capabilities
to be more robust:
sub foo($x = 'blah') {...} # wrong: use one of the below
sub foo($x ::= 'blah') {...} # same as C$x is default('blah')
sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
While this looks pretty in email, it makes me wonder what the ::
operator does outside of regular expressions and how that operator
interacts with ??::
And don't forget these other argument initializations:
sub foo($x = 'blah') {...}# sets $x whenever $x is true
sub foo($x += 1) {...} # add 1 to whatever $x given
sub foo($x -= 1) {...} # subtract 1 to whatever $x given
sub foo($x *= 2) {...} # multiply by 2 whatever $x given
sub foo($x /= 2) {...} # divide by 2 whatever $x given
sub foo($x ~= foo) {...} # Append foo to whatever $x given
Depending on how you're bent, the default() property starts to look
pretty good at this point. :-) (with the others relegated to be the
body of the sub)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: P6ML?
At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? I, for one, think it's a great idea, and the thought of altering perl 6's grammar to make it a functional language is sheer genius, making the concepts behind ML more accessible to folks used to procedural languages. Darned good idea--I say start right away! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: P6ML?
--- Robin Berjon [EMAIL PROTECTED] wrote: If it is creating a /toolset/ to make recuperating data from a quasi-XML (aka tag soup) then it is an interesting area of research. I can think of two approaches: - have a parametrisable XML grammar. By default it would really parse XML, and barf with extreme prejudice on errors. However individual rules will be relaxable and modifiable to accept different, possibly slightly broken, input. This is imho the least desirable approach. Why is this the least desirable approach? =Austin - base a quasi-parser on something that does quasi-parsing well, namely an HTML parser, which would be wrapped to look like an XML parser but would be able to correct most typical problems (poorly defined entities, missing end tags, encoding errors, etc). Advantages are: a) it addresses 98% of existing problems, b) trying to solve the remaining issues in any non ad hoc manner is suicidal, c) can be pointed to to developers in trouble, and d) has very low general public visibility. Oh, and e) the perl-xml community is already on it, expect something in the month to come.
Re: P6ML? [OT]
--- Austin Hastings [EMAIL PROTECTED] wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? I, for one, think it's a great idea, and the thought of altering perl 6's grammar to make it a functional language is sheer genius, making the concepts behind ML more accessible to folks used to procedural languages. Darned good idea--I say start right away! |==[*]| Sarcasmeter? lol -- I think my BS-o-meter just redlined, too But just to make sure I'm not completely clueless on this one, would someone give me a clue as to exactly what P6ML is supposed to mean, and whether or not the original post was intended as humor? No insult intended (at least not from me, lol), but ML as in Markup Language? Or maybe as in the ML programming language (you know, the one used in recursion examples), and it was a question of whether it was being ported to parrot __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: P6ML? [OT]
--- Paul [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? I, for one, think it's a great idea, and the thought of altering perl 6's grammar to make it a functional language is sheer genius, making the concepts behind ML more accessible to folks used to procedural languages. Darned good idea--I say start right away! |==[*]| Sarcasmeter? lol -- I think my BS-o-meter just redlined, too But just to make sure I'm not completely clueless on this one, would someone give me a clue as to exactly what P6ML is supposed to mean, and whether or not the original post was intended as humor? No insult intended (at least not from me, lol), but ML as in Markup Language? Or maybe as in the ML programming language (you know, the one used in recursion examples), and it was a question of whether it was being ported to parrot My assumption is that Dan has chosen to deliberately misinterpret the P6ML as being P6/ML -- and that he's all in favor of making P6 more functional since it will make the parser easier. Sadly, however, P6ML comes from P6/XML, and so Dan is condemned to slave away at a grammar which is going to make PL/I look easy, when all is said and done. (Although I still maintain that Fortran is currently underrepresented in core, since FORMATs went away. :-) =Austin __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::= [OT]
(Note forwarded to the list as penance for my silliness. :)
sub foo($x .= foo) {...} # Append foo to whatever $x given
sub foo($x ~= foo) {...} # smart-test $x against foo
Well, last time I looked (granted, it could've changed numerous times
since then) ~ was the string concatenator and ~~ was the smart
match op, so those should be:
sub foo($x ~= foo) {...}# Append foo to whatever $x given
sub foo($x ~~= foo) {...} # smart-test $x against foo
lol -- flashbacks. Was off on both!
I'm obviously behind the curve on ~ and ~~ ... but .= is P5, so TOTALLY
wrong. Sorry!
So _ isn't going to be the string catenation operator any more?
Ok, I need an op reference, lol
Is there a page up anywhere that summarizes the latest
prognostications?
Thanks for straightening me out. ;o]
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: P6ML? [OT]
At 11:52 AM -0800 3/25/03, Paul wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? I, for one, think it's a great idea, and the thought of altering perl 6's grammar to make it a functional language is sheer genius, making the concepts behind ML more accessible to folks used to procedural languages. Darned good idea--I say start right away! |==[*]| Sarcasmeter? lol -- I think my BS-o-meter just redlined, too Heh. Sorry 'bout that. Bring it to OSCON and I'll get it fixed. :) I think the original was an XML in perl 6 proposal of some sort. XML makes me twitch, though. Ick. A (or is that an?) ML compiler for parrot'd be really cool, though. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A6: argument initializations via //=, ||=, ::= [OT]
On Tue, Mar 25, 2003 at 12:19:30PM -0800, Paul wrote: Is there a page up anywhere that summarizes the latest prognostications? Mike Lazzaro had compiled the state-of-the-ops for perl6, but I don't know if it's anywhere other than in the archives for this list. Just go to google groups and search for Perl Operator List. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: P6ML?
On Tuesday, March 25, 2003, at 11:02 AM, Robin Berjon wrote: Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? Imho P6ML is a bad idea, if it means what I think it means (creating a parser for quasi-MLs). People will laugh at our folly, and rightly so for trying to be able My own musing was not something that would accept bad XML, but something more geared as a P6-based replacement for the steaming hunk of crap known as XSL. An XML-based derivative that performs XML transformations, allowing/using embedded P6 regexs, closures, etc., and able to more easily translate XML == P6 data. Something like that might significantly help P6 adoption rates.[*] While we're stuck with XML, I'm not willing to say we in Perl-land should be stuck with the currently craptacular XML transformation methods being adopted by other languages. :-P Anyway, it's a future library issue more than a language development one, but I'd be interested in hearing if any such plans were already underway. MikeL [*] For example, one of the Very First Things I'll be doing with Perl6 is, of course, creating a P6-specific companion to ASP/JSP/PHP, but one that's substantially more OO in nature... all of those *Ps have pretty poor capabilities, and do not allow sufficiently flexible OO-based templatizations, in my experience. And while P5's Mason is impressive, one can imagine a more firmly P6, OO-based solution that would have a *lot* of additional speed/capability. (I have a longtime P5 prototype that we use here, but limitations of the P5 implementation makes it annoyingly slow during template compilation init.)
Re: P6ML? [OT]
At 12:47 PM -0800 3/25/03, Paul wrote: |==[*]| Sarcasmeter? lol -- I think my BS-o-meter just redlined, too Heh. Sorry 'bout that. Bring it to OSCON and I'll get it fixed. :) lol -- when/where is that? (Seems all I do here is ask dumb questions). *sigh* Portland Oregon, July 7-11. The 7th and 8th are tutorials, the conference proper is wednesday the 9th through friday the 11th. The conference is just down the street from Powell's (www.powells.com) which is possibly the single best, and certainly biggest, used bookstore in the US, if not the planet. Bring lots of money and a spare pair of suitcases. A (or is that an?) ML compiler for parrot'd be really cool, though. Anything in Parrot is likely to be pretty cool. :) I dunno. Can *anything* make INTERCAL cool? I think not! :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A6: argument initializations via //=, ||=, ::=
On Tue, Mar 25, 2003 at 01:47:32PM -0800, Michael Lazzaro wrote:
On Tuesday, March 25, 2003, at 11:08 AM, Jonathan Scott Duff wrote:
On Tue, Mar 25, 2003 at 10:42:39AM -0800, Michael Lazzaro wrote:
But it is certainly possible to extend the initialization capabilities
to be more robust:
sub foo($x = 'blah') {...} # wrong: use one of the below
sub foo($x ::= 'blah') {...} # same as C$x is default('blah')
sub foo($x //= 'blah') {...} # sets $x whenever $x is undefined
sub foo($x ||= 'blah') {...} # sets $x whenever $x is false
While this looks pretty in email, it makes me wonder what the ::
operator does outside of regular expressions and how that operator
interacts with ??::
Well, := is the binding operator, and ::= is the compile-time binding
operator.
Interesting. When juxtaposed against //= and ||= it looks more like
bind unless already bound to me.
I'm arguing for these three defaulting options in particular, but my
more encompassing argument is the wrapper-like notion that signatures
should be able to specify assertions, invariants, and initializations
that may then be inherited by all implementations of that
function/method.
Don't we already have the pre() trait and PRE block for this?
Placing such extensive capabilities in the sig is especially useful if
we can 'typecast' subs, as others have pointed out.
class mysub is sub(...big long signature...) returns int {...}
sub foo is mysub { ... }
sub bar is mysub { ... }
If ...big long signature... contains initializations and assertions
that are required to be shared by all sub implementations, than it
makes the sig a quite powerful thing. Sure, a complex sig could be
pretty big. But it's one big thing, as opposed to repeating the same
assertions in N implementations.
From A6:
sub Num foo (int $one, Str [EMAIL PROTECTED]) { return [EMAIL PROTECTED] }
is short for saying something like:
sub foo is signature( sig(int $one, Str [EMAIL PROTECTED]) )
is returns( sig(Num) )
will do { return [EMAIL PROTECTED] }
So, it seems to me that we might be able to do something like this:
$sig = sig(...big long signature...);
presub = { ...initializations, etc. ... };
sub foo is signature($sig) is pre(presub) { ... }
sub bar is signature($sig) is pre(presub) { ... }
Resisting assignment in signatures (for now),
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: A6: argument initializations via //=, ||=, ::=
I don't see how ::= (compile-time-bind) can be used as the
initialize-if-non-existent operator.
I mean, it happens in the wrong phase (compile-time, not run-time) and it does
the wrong thing (binding, not assignment).
For example:
sub foo {
state $count ::= 0;# $count bound to constant zero
$count++; # Error, can't modify constant
...
}
Or:
sub bar ($start, ?$end ::= $start+1) {...} # $end bound to 1.
# ($start is undef
# at compile-time)
I think that all we need to do is to mentally distinguish assignment from
initialization:
my $x = 1;# initialization
$x = 1;# assignment
and say that initialization happens only on declarations and only once, at the
very beginning of the lifetime of a variable. Thus:
state $count = 0;# initialization: happens only once
$count = 1;# assignment: happens every time
We then simply define the = in:
sub foo ( ?$bar = $baz ) {...}
to be an initialization (since it's on the declaration of the parameter).
If the parameter has already be bound to some other container, then that other
container isn't at the start of its lifetime, so the initialization doesn't
occur. If it hasn't been bound during the call, then it's just starting its
existence and the initialization does occur.
And I don't think that allowing 20 different types of assignment in the
parameter list of a subroutine actually helps at all. Especially since the
vast majority of parameters in Perl 6 will be constant.
Damian
Re: A6: argument initializations via //=, ||=, ::=
On Wed, Mar 26, 2003 at 09:19:42AM +1100, Damian Conway wrote: my $x = 1;# initialization $x = 1;# assignment Woo, C++ :-) Considering 'our' merely declares a lexical alias to a package var, how do we initialize package vars? -- Matthijs van Duin -- May the Forth be with you!
Re: A6: argument initializations via //=, ||=, ::=
On Wed, Mar 26, 2003 at 09:19:42AM +1100, Damian Conway wrote:
We then simply define the = in:
sub foo ( ?$bar = $baz ) {...}
to be an initialization (since it's on the declaration of the
parameter). If the parameter has already be bound to some other
container, then that other container isn't at the start of its
lifetime, so the initialization doesn't occur. If it hasn't been bound
during the call, then it's just starting its existence and the
initialization does occur.
And I don't think that allowing 20 different types of assignment in
the parameter list of a subroutine actually helps at all. Especially
since the vast majority of parameters in Perl 6 will be constant.
But does allowing even one type of assignment help? I'm thinking that
something like
sub foo (?$bar is init($baz)) { ... }
is better than an assignment with slightly different semantics than
usual.
Of course, I also think that instead of state we should do something
like this too:
sub CallMe {
my $count is kept is init(1);
print you've called me $($count++) times\n;
}
Boy am I glad Larry is the language designer. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: A6: argument initializations via //=, ||=, ::=
On Tue, Mar 25, 2003 at 11:27:55PM +0100, Matthijs van Duin wrote: On Wed, Mar 26, 2003 at 09:19:42AM +1100, Damian Conway wrote: my $x = 1;# initialization $x = 1;# assignment Woo, C++ :-) Considering 'our' merely declares a lexical alias to a package var, how do we initialize package vars? The first time they are assigned to, it's an initialization :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: P6ML?
of crap known as XSL. An XML-based derivative that performs XML transformations, allowing/using embedded P6 regexs, closures, etc., and able to more easily translate XML == P6 data. I'm still quite XML-phobic, but I see the need for strong XML support in Perl 6. However, I'd like to work with XML in Perl 6 in a way that I don't even notice it's XML. Would it be possible to come up with an interface to XML that is at least as intuitive as tie is for hash-DBM file? And that can cope with megabyte-sized XML files? In fact, if we're talking about data storage only, it would be interesting to have such a tie that allows me to store my data in an XML file, YAML file, SQL database etc. XML transformations sounds to me like it would be useful to be able to transform data that is structured according to one grammar into another grammatical structure. (Please excuse my long sentences.) Is that already possible with Perl 6 Grammars? (Please excuse my ignorance.) If yes, we might even think about an C-to-Intercal translator. (Please excuse me, Dan.) creating a P6-specific companion to ASP/JSP/PHP, but one that's substantially more OO in nature... Although it doesn't end in P, I'd add Zope to that list. Definitely sounds like a killer-app for Perl 6. Greetings, Christian -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/ No Christian and, indeed, no historian could accept the epigram which defines religion as 'what a man does with his solitude.' -- C.S. Lewis, The Weight of Glory
Re: A6: argument initializations via //=, ||=, ::=
Damian Conway wrote:
I don't see how ::= (compile-time-bind) can be used as the
initialize-if-non-existent operator.
I mean, it happens in the wrong phase (compile-time, not run-time) and
it does the wrong thing (binding, not assignment).
The only case I can think of where is might be useful is with a
optional parameter with an is rw trait, so you could provide an
default binding. Possible example:
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
open f /a/d/v/f/r;
myprint file = f, Hello World!\n; # goes to f
myprint Differnet World!\n;# goes to IO:STDOUT
although maybe what I really want is := instead.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: A6: argument initializations via //=, ||=, ::=
On Tuesday, March 25, 2003, at 03:35 PM, Mark Biggar wrote:
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
open f /a/d/v/f/r;
myprint file = f, Hello World!\n; # goes to f
myprint Differnet World!\n;# goes to IO:STDOUT
As a side note... that sig will not do the behavior you've described.
You instead want this:
sub myprint([EMAIL PROTECTED], +$file is IO:File is rw ::= IO:STDOUT) {...}
The named parameter +$file has to go behind the positional [EMAIL PROTECTED] in
the signature, but still goes _before_ [EMAIL PROTECTED] in the actual call.
(Insert image of a five-year-old me jumping up and down on a chair,
pointing my finger, saying see! see! I told you people would do that!)
MikeL
Re: A6: argument initializations via //=, ||=, ::=
On Tuesday, March 25, 2003, at 02:19 PM, Damian Conway wrote:
And I don't think that allowing 20 different types of assignment in
the parameter list of a subroutine actually helps at all. Especially
since the vast majority of parameters in Perl 6 will be constant.
Twenty types of _initialization_. :-D
Seriously, tho, I'm not sure I understand the constantness part.
sub foo($x = 1) {...} # A6 syntax
I read the above as saying $x is indeed constant, but if it's not
explicitly placed by the caller, we're going to pretend the caller
passed us a 1. Likewise, I read
sub foo($x //= 1) {...}
as saying the value stored in $x is a constant, but if the caller
passed an undefined value (or didn't pass anything at all), we're going
to instead pretend they passed us a (still-constant) 1. I'm not sure
why that violates any rules.(?)
As a marginal bonus, perhaps an assertion-style
sub foo($x //= 1) {...}
optimizes to be faster, runtime, than
sub foo($x) { $x //= 1; ... }
when passing a constant in $x, e.g Cfoo(5) or Cfoo('BLAH'), since
it can optimize out the assertion at compile-time?
MikeL
Re: A6: argument initializations via //=, ||=, ::=
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
As a side note... that sig will not do the behavior you've described.
You instead want this:
sub myprint([EMAIL PROTECTED], +$file is IO:File is rw ::= IO:STDOUT) {...}
The named parameter +$file has to go behind the positional [EMAIL PROTECTED] in
the signature, but still goes _before_ [EMAIL PROTECTED] in the actual call.
*sigh*
I haven't been the sharpest tool in the shed today, and I know that the
usual cases will be simpler, and that I'll get used to it with use
until it makes sense and comes naturally.
But in the meantime, I kinda hafta agree.
It's burning my brain.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::=
--- Damian Conway [EMAIL PROTECTED] wrote: However I still think we're probably multiplying entities unnecessarily. A beautiful if somewhat understated reference to Occam's Razor. While the synoptic synthesis of the writing of William of Occam is often translated into English as One should not multiply entities needlessly, it's more colloquially stated as the simplest answer is usually best. So why am I multiplying words? :) Ok. I agree with Damian (which is usually a safe thing to say anyway, lol...) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: P6ML?
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: So, is anyone working on a P6ML, and/or is there any discussion/agreement of what it would entail? I, for one, think it's a great idea, and the thought of altering perl 6's grammar to make it a functional language is sheer genius, making the concepts behind ML more accessible to folks used to procedural languages. Darned good idea--I say start right away! |==[*]| Sarcasmeter? =Austin
