Re: L2R/R2L syntax (was Re: Everything is an object.)
Just when you thougth it was safe to go back on the mailing list,
Damian attempts to resurrect a dead can of worms:
And all because Mike Lazzaro wrote:
Honestly, I still don't see what's so evil about R2L as:
@out = sort given map {...} given grep {...} given @a;
A few things.
First, Cgiven already has a non-void-context meaning.
Second, I find this *really* hard to decipher. ;-)
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
Further suppose that ~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort ~ map {...} ~ grep {...} ~ @a;
Or, under a special rule for variables on the LHS:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the expressions
actually *look* like processing sequences.
Damian
Re: Pike 7.4
Chris Dutton wrote:
Given discussions about hyper operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operators give more flexibility.
For example, I'm struggling to see how one could use the [*] to do this:
@names = «Gödel Escher Bach»;
@ages = $today »-« %date_of_birth{@names}
Damian
Re: Variable Types Vs Value Types
One of the wise may override my evaluation, Or I could do it. ;-) Can the type of a variable vary independenty of its value? My understanding is that the type of a variable merely restricts the type of value you can assign to it. (Well, it probably does more, but I'm not clear on what or how yet.) There are in fact *two* types associated with any Perl variable: 1. Its storage type (i.e. the type(s) of value it can hold) This is specified before the variable or after an Cof or Creturns. It defaults to Scalar. 2. Its implementation type (i.e. the class that tells it how to act) This is specified after an Cis. It defaults to the type indicated by the variable's sigil. So: Declaration Storage Implementation Type Type === === == my $var; Scalar Scalar my @var; Scalar Array my %var; Scalar Hash my Int @var; Int Array my @var of Int; Int Array my @var returns Int; Int Array my @var is SparseArray; Scalar SparseArray my Int @var is SparseArray; Int SparseArray my @var is SparseArray of Int; Int SparseArray my @var is SparseArray returns Int; Int SparseArray BTW, the use of Creturns may seem a little odd, until you realize that, like a subroutine, a variable is just an access mechanism for values. There's rather a nice node on PerlMonks just now about just that notion. Consider the following: my @a = (1,2,3); my $b := @a; @a and $b both refer to the same object. $b's object has methods such as PUSH, POP, etc, as does @a's. Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). The latter, in fact. When trying to puzzle out what any binding does imagine that the LHS is a subroutine parameter, and the RHS the corresponding argument. my @a = (1,2,3) but implements_sum_method; # add .sum method to vtable my SummingArray $b := @a; Actually, (unless implements_sum_method is a subclass of SummingArray,) That won't help. Value (i.e. Cbut) properties don't confer class status. it looks like an error to me, because @a is an array and/or an implements_sum_method, but $b is restricted to holding a SummingArray. Yep. As counter-example, consider: my Array @array := SpecialArray.new; Should the value in @array act like an Array or a SpecialArray? Most people would say SpecialArray, because a SpecialArray ISA Array. Weell...*I'd* say that @array should act like an Array (that is, you should only be able to call the methods specified by the Array class), except that any method calls should be polymorphically resolved to invoke the equivalent SpecialArray methods. But maybe that's just saying the same thing. Is there a linguist in the house? ;-) I can also interpret what you want as saying my SpecialArray @array := Array.new should autopromote the value to a subclass somehow which would be very strange. To say the least! Damian
Re: AW: my int( 1..31 ) $var ?
Christian Renz wrote: Now, I might be stupid, but I keep asking myself what you would need a property for in this example. Yes. It's important to remember that the shiny new hammer of properties is not necessarily the appropriate tool to beat on *every* problem. :-) Damian
Re: AW: AW: AW: AW: nag Exegesis 2
Murat Ünalan wrote:
Then i could pray to the god of the camel herdsman, that
my DNA human size(4) ($alpha, $beta, $gamma, $delta)
= ('atgc', 'ctga', 'aatt', 'ccaa');
may be activated through perl6 custom parser options 8-)
*Any* consistent syntax may be activated through perl6 custom parser options.
Whether it *should* be is, of course, another matter entirely. ;-)
I have a german background.
BTW, I wasn't criticizing your English. Someone who's German is as poor as mine
doesn't have the right. ;-)
But my litte english-vs-perl6 example sounds
not so odd to me (what doesn't mean to much):
my aged uncles ( john, james, jim, tony ) are
( 102, 99,88, 79 )
That's perfect English. But not necessarily good programming language design.
Thanks for your patience with me,
It's not a matter of patience. You raise important issues (which I very much
appreciate), and it's my job -- and my desire -- to address them.
Damian
Re: Array Questions
Michael Lazzaro wrote:
my int @a;
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;
Those lines are all absolutely synonymous, and all declare an array of
integers, right?
Right. (This week, at least ;-)
Likewise, Arrays have methods:
my int @a = (1..100);
print @a.length; # prints 100
my @b = @a.grep { $_ 50 }; # gets 51..100
... which is also known, based on previous Apocalypsii.
Right.
If we accept those as valid syntax -- and I *think* they have been --
then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
from objects, regardless of implementation.
The later, I strongly suspect.
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
does not.
Correct. Though the instantiated Foo is the implementation object and
not directly accessible (just as the implementation object in a Perl 5
tie isn't).
BTW, Cmy Foo $a is Foo is just sick!
(i.e. I'll *definitely* be using it ;-)
Damian
Re: Array Questions
Jonathan Scott Duff wrote: On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Um ... ick. I'd hope that autoinstantiation wouldn't happen without some clear syntactical clue. (I don't think is that clue. To me all three of those look like they should just earmark $a to contain a Foo and this Foo-thing can/will be instantiated later) I doubt it. The Cis Foo tells Perl that this variable is *implemented* by a (hidden) Foo object. The variable better be able to get in touch with that inner Foo at the point the variable is first used in any way. So it probably needs to be autocreated at the point of declaration (or, at least, trampolined into existance before the variable is first used). Damian
Re: Variable Types Vs Value Types
John Williams wrote: I'm still not buying the autoinstantiation argument. All the other (non-M.L.) threads I have read are requiring my $a is Foo = .new; # or some such... Yes. You're confusing auto-instantiation of *implementation type* (good) with autoinstantiation of *stored value* (bad). Both your examples above create the varible $a, but it contains the value of undef, not an instance of Foo. Correct. But: my Foo $var; is implemented by an underlying (possibly optimized-away) Scalar object. Whereas: my $var is Foo; is implemented by an underlying Foo object. It's only this underlying Foo object that is auto-instantiated. Damian
Re: Array Questions
From: Deborah Ariel Pickett [EMAIL PROTECTED] Date: Wed, 8 Jan 2003 09:42:18 +1100 (EST) [...] But everybody has to learn Perl once. I agree with you entirely :) Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Date: Wed, 08 Jan 2003 12:14:10 +0800
From: Damian Conway [EMAIL PROTECTED]
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
Further suppose that ~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort ~ map {...} ~ grep {...} ~ @a;
Or, under a special rule for variables on the LHS:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the expressions
actually *look* like processing sequences.
I think this is a big step towards readability. It allows you to put
whatever part of the expression wherever you want (reminiscent of
Latin); i.e. always keep the important parts standing out. I also
think that the operator (especially a cool 3d-looking one like ~) is
also much more readable than a word in this case.
It's a shame ~ is ambiguous. It's a lexical ambiguity, which can be
solved with whitespace
Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote: I think this is a big step towards readability. It allows you to put whatever part of the expression wherever you want (reminiscent of Latin); You didn't think Perligata was just for *fun*, did you? ;-) It's a shame ~ is ambiguous. It's a lexical ambiguity, which can be solved with whitespace ...and the longest token rule. And, of course, it's no more ambiguous than the ~~ operator: foo ~~ $bar # means: foo() ~~ $bar # not: foo( ~ ~$bar ) Damian
Re: More thougths on DOD
Mitchell N Charity wrote: The attached patch adds a scheme where: - gc flags are in the pool, and - pmc-pool mapping is done with aligned pools and pmc pointer masking. Observations: - It's fast. (The _test_ is anyway.) I did try it and some more in realiter. Summary: its slower :-( Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. There seems to be remaining only: smaller PMCs for scalars. leo
Re: Variable Types Vs Value Types
On Tue, 07 Jan 2003 12:21:48 +0100, Rafael Garcia-Suarez wrote: Delegation has drawbacks compared to inheritance : you can't use a object that delegates to class Foo where an instance of Foo is expected. That sounds more like a problem with the polymorphism implementation than an argument against delegation (or even mixins). isa() considered harmful! -- c
RE: L2R/R2L syntax (was Re: Everything is an object.)
# Damian Conway wrote:
# @out = sort ~ map {...} ~ grep {...} ~ @a;
#
# Or, under a special rule for variables on the LHS:
#
# @out ~ sort ~ map {...} ~ grep {...} ~ @a;
Hello,
Can one see it as a shell redirection/pipe? This may sound funny,
but is the following ok?
@b ~ @a ~ @c; # @c = @b = @a;
(@b ~ @a) ~ @c; # same order i guess
so one can also:
@keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;
is this if valid too?
@b ~ @a ~ @c; # push @a, @b, @c;
or: @b, @c ~ push @a;
qw/hello world/ ~ print
I guess it modifies $_
print $_ \t %stat{$_} \n ~ grep /^[Aa]/ ~ keys %stat
print $_ \t %stat{$_} \n for grep /^[Aa]/, keys %stat
Could we get pairs (or more), and also something like a step, for
example to only take one array elements every two?
Have a nice day,
Frederic
Re: Variable Types Vs Value Types
Damian Conway [EMAIL PROTECTED] wrote: There are in fact *two* types associated with any Perl variable: 1. Its storage type (i.e. the type(s) of value it can hold) This is specified before the variable or after an Cof or Creturns. It defaults to Scalar. 2. Its implementation type (i.e. the class that tells it how to act) This is specified after an Cis. It defaults to the type indicated by the variable's sigil. How does it work regarding inheritance and polymorphism ? E.g. consider my @a is Set of Apple; my @b is Basket of Fruit; with Apple isa Fruit, and Basket is a Set. I assume I can use @a or @b where the expected type is: @a @b Set ok ok Set of Fruitok ok Set of Appleok no(?) Basket no ok Basket of Fruit no ok Basket of Apple no no(?) the errors being compile-time or run-time, depends on how much verification the compiler can perform with its input. Reminds me the SetApple C++ templates. And the whole mess that comes with it (when you've got a statically typed language.)
Re: Variable Types Vs Value Types
[EMAIL PROTECTED] (Damian Conway) writes: There are in fact *two* types associated with any Perl variable: Is there any chance we could make this a little more confusing? One or two people still appear to be following you. -- You advocate a lot of egg sucking but you're not very forthcoming with the eggs. - Phil Winterbottom (to ken)
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro [EMAIL PROTECTED] wrote: Can one see it as a shell redirection/pipe? This may sound funny, but is the following ok? @b ~ @a ~ @c; # @c = @b = @a; (@b ~ @a) ~ @c; # same order i guess so one can also: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; is this if valid too? @b ~ @a ~ @c; # push @a, @b, @c; or: @b, @c ~ push @a; qw/hello world/ ~ print Just add ^~ and v~ and we've got our own Befunge flavor.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
@out = @a ~ grep {...} ~ map {...} ~ sort;
@out = sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can ~ and ~ be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
@a ~ grep (...) ~ sort ~ for ~ map (...) ~ @b {
(for content goes here)
}
With the understanding that
(1) EWWW, that is horribly ugly, but it was the first thing I could come
up with that meaningfully takes two list args
(2) Anyone who ACTUALLY does this with a for be shot on sight?
It would be more meaningful in another function that takes two lists and
does something useful, but without a body block ... More of a
@a ~ grep (...) ~ apply ~ sort ~ @b ;
So that the grep'd elements of @a are applied, 1:1, to the sorted @b ... ala
apply (grep (..., @a), sort(@b));
(again, more useful for a longer chain)
--attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
Atriel:
Damian:
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
@out = @a ~ grep {...} ~ map {...} ~ sort;
@out = sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can ~ and ~ be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
Damian's proposal didn't say anything about array params. If I understood
him correctly, then this should print FOO on standard out:
my $foo = FOO;
$foo ~ print;
The opposite 'squiggly arrow' fiddles the indirect object, so perhaps this
would print FOO on standard error (modulo the STDERR syntax, which I think
changed when I wasn't looking):
$foo ~ print ~ STDERR;
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should ensure this E-mail is checked for viruses. The Carphone Warehouse Group PLC
makes no representations as regards the absence of viruses in this E-mail. If you have
received this E-mail in error please notify our ISe Response Team immediately by
telephone on + 44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
immediately destroy this E-mail and any copies of it.
Please feel free to visit our website:
UK
http://www.carphonewarehouse.com
Group
http://www.phonehouse.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
(b) Can ~ and ~ be used at the same time? I'm not entirely sure of what functions take two array params meaningfully, but could we do: Damian's proposal didn't say anything about array params. If I understood him correctly, then this should print FOO on standard out: DOH! All the examples were using @'s, and somehow that translated to this is an array opthingy :o $foo ~ print ~ STDERR; That makes a fair amount of sense (and certainly more than any of my array-based flawed examples :) Thanks for clearing up my fogginess :o --attriel
Re: This week's Perl Summary
Steve Fink [EMAIL PROTECTED] writes: On Jan-04, Leopold Toetsch wrote: Damian Conway wrote: Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals Remembering e.g. perl6 operator threads, brrr, I just can say ... Thank-you, Piers! me2 Me3. But watch out -- you are single-handedly responsibility for the sanity of hundreds of us, and are therefore responsible for anything we might do in this unnatural state. I accept no responsibility for any such actions, and reserve the right to cease producing summaries at any time (but not in the foreseeable future). Now, I've got the perl6-internals section of the christmas/new year summary written, hopefully I'll have the perl6-language and other bits written and mailed out later today. Hang in there people. -- Piers
RE: L2R/R2L syntax (was Re: Everything is an object.)
Note 1) This is the second time I'm typing this Note 2) Ctrl-Shift-Capslock apparently closes all current instances of mozilla ... that was weird I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... I would, from the descriptions, imagine that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Would parse as: @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Due to that being what is almost always going to be intended, I think. Also, since we'd want $a ~ 2 + 4; to be $a = 6;, I would imagine that ~ and ~ would need low priorities. Further, since ~ stars at the end of the list and works its way left, it would need a lower priority than ~ which starts at the beginning and works its way right. So if it did have a parenthetical variation, I would imagine it would be @keep ~ grep /good/ ~ (@list ~ grep /bad!/ ~ @throw); Which is, still, probably not what you wanted. OTOH, I'm still new at posting here, and I may not be following all the bits that came before :o --attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Oh, then we just need a syntax to split the streams. ... I know! @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; which, of course, could be written in the more readable form: @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; And that, of course, leads us to sort of unzip were mutual exclusion is not a requisite: @list ~| grep length == 1 ~ @onecharthings ~| grep [0..29] ~ @numberslessthan30 ~| grep /^\w+$/ ~ @words ~| grep $_%2==0 ~ @evennumbers; :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 08, 2003 at 08:31:51AM -0800, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
@out = @a ~ grep {...} ~ map {...} ~ sort;
...
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
For the record, I think this is great.
Brilliant! Keep pushing this. Finally, I'll be able to get investor
backing for my USB foot-pedal shift-key device.
http://www.tuxedo.org/~esr/jargon/html/entry/double-bucky.html
--Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 8 Jan 2003 11:30:51 -0500 (EST) From: attriel [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ Note 1) This is the second time I'm typing this Note 2) Ctrl-Shift-Capslock apparently closes all current instances of mozilla ... that was weird I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... I would, from the descriptions, imagine that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Would parse as: @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Nope. ~ and ~ only *rearrange* arguments, so if you only type @list once, you can only do things that you could before when you typed @list only once. When we present this in the documentation (wishful thinking, now), it will be important that we present it in precisely that way, as argument rearrangers, lest people actually try that kind of foulplay. In that documentation we should probably suggest that the arrows go only one way per statement, otherwise you might not get what you expect. Due to that being what is almost always going to be intended, I think. Also, since we'd want $a ~ 2 + 4; to be $a = 6;, I would imagine that ~ and ~ would need low priorities. Precedences. Yes. Further, since ~ stars at the end of the list and works its way left, it would need a lower priority than ~ which starts at the beginning and works its way right. Not necessarily. ~ will necessarily need to be right-associative, while ~ left, however. It would be logical to give them the same precedence, except for the opposite associativity thing, where parsers get different results based on their parse method. So different precedences would be good only to ensure that different parsers saw the same thing. So if it did have a parenthetical variation, I would imagine it would be @keep ~ grep /good/ ~ (@list ~ grep /bad!/ ~ @throw); Which is, still, probably not what you wanted. Right. And probably not recommended. OTOH, I'm still new at posting here, and I may not be following all the bits that came before :o You're quickly getting the hang of it. Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 8 Jan 2003 10:45:37 -0600 From: Jonathan Scott Duff [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mail-Followup-To: frederic fabbro [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Disposition: inline X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Oh, then we just need a syntax to split the streams. ... I know! @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; which, of course, could be written in the more readable form: @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; Spookily, this quantumish operation can be achieved with Perl's quantumish operators. @list ~ (grep /bad!/ ~ @throw) | (grep /good/ ~ @keep); I'd actually think I'd be happier if that didn't work. Fortunately, I don't think it does (how do you put an argument on the end of a | expression?)). What we really need is a beam-split operator: @list ~ (-grep /bad!/ ~|~ grep /good/) ~ @result; Then @result would contain all things bad or good, but not both, because they interfere! :) And that, of course, leads us to sort of unzip were mutual exclusion is not a requisite: @list ~| grep length == 1 ~ @onecharthings ~| grep [0..29] ~ @numberslessthan30 ~| grep /^\w+$/ ~ @words ~| grep $_%2==0 ~ @evennumbers; I'm not going even to try this one. :-) (-: Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote:
I would, from the descriptions, imagine that:
@keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;
Would parse as:
@keep ~ grep /good/ ~ @list;
@list ~ grep /bad!/ ~ @throw;
Nope. ~ and ~ only *rearrange* arguments, so if you only type @list
once, you can only do things that you could before when you typed
@list only once.
So what we have is (using a scalar for an arbitrary variable) is:
$a ~ subroutine $arg1;
is equivalent to:
subroutine $arg1, $a;
and
subroutine $arg1 ~ $a;
is equivalent to:
subroutine $arg1 $a:; # or , equivalently, subroutine $a: $arg1;
and
.. ~ $a;
is equivalent to
$a = ...;
and similarly,
$a ~ ...;
is equivalent to
$a = ...;
~ is left associative, ~ right associative, have the same precedence,
and can't be mixed in one expression because of conflicting associativity
That means that a standard chain like:
@list ~ grep /good/ ~ map - { s/good/bad/ } ~ @badlist;
would parse as
((@list ~ grep /good/) ~ map - { s/good/bad/ } ) ~ @badlist;
to
((grep /good/ @list) ~ map - {s/good/bad/ } ) ~ @badlist;
to
(map - {s/good/bad/}, (grep /good/ @list)) ~= @badlist;
to
@badlist = (map - {s/good/bad/}, (grep /good/ @list));
to
@badlist = map - {s/good/bad/}, grep /good/ @list;
(modulo possible regex sytax).
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- attriel [EMAIL PROTECTED] wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... I would, from the descriptions, imagine that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Would parse as: @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Actually, if you can say @a ~ sort ~ grep /foo/ ~ @output then it's pretty obvious that ~ is left-associative, a la in C++. Remember: cout Hello, world! nl; First does coutHW and returns cout-prime, then does cout-prime nl Likewise, the perl example does @a ~ sort, returning @a-prime @a-prime ~ grep /foo/, returning @a-2prime @a-2prime ~ @output, returning @output-prime, I hope! Reversing the direction: @output ~ grep /foo/ ~ sort ~ @a First does sort :@a, (I hope the syntax is right) returning @a-prime then does grep /foo/ :@a-prime, returning @a-2prime then does @output.operator() :@a-2prime which we hope gets transmogrified into assignment, and I likewise hope this will return @output-prime. So ~ looks right-associative. @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Assuming that ~ and ~ have equal precedence, and that there's not some hideous special case backing this syntax, the above becomes: 1: @list ~ grep /bad!/ 2: ~ @throw 3: grep /good/ ~ 4: @keep ~ Which greps the @throw list for goodies -- not what I think you want. @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Due to that being what is almost always going to be intended, I think. Which brings up the point: What DO we want here? Frankly, I'm in love with the idea of a simple pipeline operator. I find it really easy to write AND read scripts like this: cat file | sed -e ... | grep -v ... | nl | sort -k ... | awk ... | sort output Being able to draw the pipeline make it really readable for the maintainer. The idea of doing something similar: @a ~ grep ~ map ~ @output is attractive. Regardless, I'm sure I don't like $foo ~ print ~ STDOUT That one's going to die a lonely death. =Austin
Re: Array Questions
On Wednesday, January 8, 2003, at 02:17 AM, Damian Conway wrote: Jonathan Scott Duff wrote: On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Um ... ick. I'd hope that autoinstantiation wouldn't happen without some clear syntactical clue. (I don't think is that clue. To me all three of those look like they should just earmark $a to contain a Foo and this Foo-thing can/will be instantiated later) I doubt it. The Cis Foo tells Perl that this variable is *implemented* by a (hidden) Foo object. The variable better be able to get in touch with that inner Foo at the point the variable is first used in any way. So it probably needs to be autocreated at the point of declaration (or, at least, trampolined into existance before the variable is first used). Yes, I should have used something more clear than Foo, and it would have been more obvious what I was getting at: my MyScalar $a; # (1) my $a is MyScalar; # (2) my MyScalar $a is MyScalar; # (3) (1) creates a scalar variable that may store a MyScalar value. (2) creates an untyped variable in which the scalar variable $a is _implemented_ by an instance of class MyScalar. (3) creates a variable that stores a MyScalar AND is implemented by an instance of class MyScalar. Note that (3) is just plain sadistic. My point was simply that scalars, like arrays and hashes, also should use the 'is' syntax to declare an implementor class, and that the implementor class is, by necessity, always autoinstanciated. E.G. this is what our new Ctie syntax is gonna look like, fates willing. MikeL
Re: Array Questions
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
MikeL
Re: Array Questions
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Re: Array Questions
On Wednesday, January 8, 2003, at 10:39 AM, Chris Dutton wrote:
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Yes, I think that was tentatively confirmed a while back. But it would
be spelled:
class WierdHash is Hash of int { ... }
such that:
my %h is WierdHash; # automatically stores ints!
my str %h is WierdHash; # but this is probably an error
MikeL
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway wrote: [...] ~ and ~ Michael Lazzaro wrote: I too think this idea is fabulous. You are my hero. I also think this is semantically fabulous but syntactically slightly dubious. '~' reads 'match' in my book, so I'm reading the operators as 'match left' and 'match right'. Or perhaps even 'stringify left' and 'stringify right' with a different reading of '~'. I would prefer something like | and | which has a more obvious connotation (to me at least) of pipe left or pipe right. Damian is my hero regardless. :-) A
Re: More thougths on DOD
Summary: its slower :-( :( Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. Hmm... the first reason, a second bit of pointer arithmetic, seems surprising, cycles being sooo much cheaper than cache misses. So I modified the tpmc test with a second calc. Plus two extra function calls to make sure it wasn't optimized away (to a separately compiled file and back). The two real test cases (linear flag-only walk, and random PMC-flag) were fine (unchanged and perhaps 1/3 slower), though the fast toy case of linear PMC-flag was 5x slower (still faster than the equivalents). So it's not the first reason. That leaves the cache being stressed by other things. Do we have any candidates? I'd expect some interference effects between flag arrays, given _lots_ of arrays and random access. I'm not sure the stressX benchmarks are lots enough. But while this interference might be worse in reality than in the test program, it should still be much less than for touching PMCs (say by 10x). So that doesn't seem a likely candidate. Is the gc run doing anything memory intensive aside from the flag fiddling? I don't suppose it is still touching the PMC bodies for any reason? Puzzled, Mitchell ([..] in realiter?) Message-ID: [EMAIL PROTECTED] Date: Wed, 08 Jan 2003 15:00:38 +0100 From: Leopold Toetsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: P6I [EMAIL PROTECTED], Dan Sugalski [EMAIL PROTECTED] Subject: Re: More thougths on DOD References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mitchell N Charity wrote: The attached patch adds a scheme where: - gc flags are in the pool, and - pmc-pool mapping is done with aligned pools and pmc pointer masking. Observations: - It's fast. (The _test_ is anyway.) I did try it and some more in realiter. Summary: its slower :-( Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. There seems to be remaining only: smaller PMCs for scalars. leo
Re: More thougths on DOD
At 6:15 PM -0500 1/6/03, Mitchell N Charity wrote: +pool_pmc[i] = memalign(ALIGN, SIZE*sizeof(PMC)); This is the only problem--memalign's not universal unless we build with the malloc we provide. Have we looked into whether we can mix this malloc with the current memory allocation system? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19807] [PATCH] rx.ops doc typos
At 10:09 PM + 1/7/03, Jim Radford (via RT) wrote: I found a few typos while reading through the documentation in rx.ops. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #19834] [PATCH] sub, add, mul, div with combinations of INT, NUM, PMC
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #19834]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19834
Hi,
I have been looking into the possibility of adding complex numbers as PMCs.
When looking at core.ops I was missing some operations, where INT, NUM
and PMC interact.
For addition I found the operations:
add_i_i, add_n_n, add_p_i, add_p_n, add_p_p, add_i_i_i, add_n_n_n,
add_p_p_i, add_p_p_p.
Trying to make this more consistent I added:
add_n_i, add_n_n_i and app_p_p_n.
This means that there are now 12 addition ops.
I also brought 'sub', 'mul' and 'div' to the same level.
I have put some tests in t/op/arithmetics.t. Each of the operations
mentioned above should be called in the test.
However I still wonder about operations like 'div_p_n_p'. Unlike
'div_p_p_n', it can't be implemented with the vtable-function divide_float.
I have attached the patch for core.ops and the file arithmetics.t.
CU, Bernhard
--
*
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel:+49 89 89 55 74 - 839
Fax:+49 89 89 55 74 - 25
PGP:https://ssl.biomax.de/pgp/
Email: mailto:[EMAIL PROTECTED]
Web:http://www.biomax.de
*
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/47101/37035/779e55/core.ops.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/47101/37036/45ee9d/arithmetics.t
--- core.opsWed Jan 8 20:13:48 2003
+++ core.ops.20020108 Wed Jan 8 18:57:49 2003
@@ -1279,8 +1279,6 @@
=item Badd(inout INT, in INT)
-=item Badd(inout NUM, in INT)
-
=item Badd(inout NUM, in NUM)
=item Badd(inout PMC, in INT)
@@ -1293,14 +1291,10 @@
=item Badd(out INT, in INT, in INT)
-=item Badd(out NUM, in NUM, in INT)
-
=item Badd(out NUM, in NUM, in NUM)
=item Badd(inout PMC, in PMC, in INT)
-=item Badd(inout PMC, in PMC, in NUM)
-
=item Badd(inout PMC, in PMC, in PMC)
Set $1 to the sum of $2 and $3.
@@ -1312,11 +1306,6 @@
goto NEXT();
}
-inline op add(inout NUM, in INT) {
- $1 += $2;
- goto NEXT();
-}
-
inline op add(inout NUM, in NUM) {
$1 += $2;
goto NEXT();
@@ -1342,11 +1331,6 @@
goto NEXT();
}
-inline op add(out NUM, in NUM, in INT) {
- $1 = $2 + $3;
- goto NEXT();
-}
-
inline op add(out NUM, in NUM, in NUM) {
$1 = $2 + $3;
goto NEXT();
@@ -1357,11 +1341,6 @@
goto NEXT();
}
-inline op add(inout PMC, in PMC, in NUM) {
- $2-vtable-add_float(interpreter, $2, $3, $1);
- goto NEXT();
-}
-
inline op add (inout PMC, in PMC, in PMC) {
$2-vtable-add(interpreter, $2, $3, $1);
goto NEXT();
@@ -1477,91 +1456,40 @@
-=item Bdiv(inout INT, in INT)
-
-=item Bdiv(inout NUM, in INT)
-
-=item Bdiv(inout NUM, in NUM)
-
-=item Bdiv(inout PMC, in INT)
-
-=item Bdiv(inout PMC, in NUM)
-
-=item Bdiv(inout PMC, in PMC)
-
-Divide $1 by $2.
-
=item Bdiv(out INT, in INT, in INT)
-=item Bdiv(out NUM, in NUM, in INT)
-
=item Bdiv(out NUM, in NUM, in NUM)
-=item Bdiv(inout PMC, in PMC, in INT)
-
-=item Bdiv(inout PMC, in PMC, in NUM)
-
=item Bdiv(inout PMC, in PMC, in PMC)
+=item Bdiv(inout PMC, in INT)
+
Set $1 to the quotient of $2 divided by $3. In the case of INTVAL division, the
result is truncated (NOT rounded or floored).
=cut
-inline op div(inout INT, in INT) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div(inout NUM, in INT) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div(inout NUM, in NUM) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div (inout PMC, in INT) {
- $1-vtable-divide_int(interpreter, $1, $2, $1);
- goto NEXT();
-}
-
-inline op div (inout PMC, in NUM) {
- $1-vtable-divide_float(interpreter, $1, $2, $1);
- goto NEXT();
-}
-
inline op div(out INT, in INT, in INT) {
$1 = $2 / $3;
goto NEXT();
}
-inline op div(out NUM, in NUM, in INT) {
- $1 = $2 / $3;
- goto NEXT();
-}
-
inline op div(out NUM, in NUM, in NUM) {
$1 = $2 / $3;
goto NEXT();
}
-inline op div (inout PMC, in PMC, in INT) {
- $2-vtable-divide_int(interpreter, $2, $3, $1);
+inline op div (inout PMC, in PMC, in PMC) {
+ $2-vtable-divide(interpreter, $2, $3, $1);
goto NEXT();
}
-inline op div (inout PMC, in PMC, in NUM) {
- $2-vtable-divide_float(interpreter, $2, $3, $1);
+inline op div (inout PMC, in INT) {
+ $1-vtable-divide_int(interpreter, $1, $2, $1);
goto NEXT();
}
-inline op div (inout PMC, in PMC, in PMC) {
- $2-vtable-divide(interpreter, $2, $3, $1);
- goto NEXT();
-}
+
@@ -1703,28 +1631,18 @@
=item Bmul(inout INT, in INT)
-=item Bmul(inout NUM, in INT)
-
=item Bmul(inout NUM, in NUM)
=item Bmul(inout PMC, in INT)
-=item Bmul(inout
Re: L2R/R2L syntax (was Re: Everything is an object.)
Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? [Yes, I'm twisting things somewhat. the perl5 parser, written in C, can parse perl5] Although my brain thinks that having expressions with both ~ and ~ should be illegal, because it's too damn confusing. Roughly: ~ ... ~ # My brain leaking out of my ears ~ ... ~ # My brain collapses because it's under too much pressure. Nicholas Clark
Re: Variable Types Vs Value Types
At 7:29 PM -0700 1/7/03, John Williams wrote: On Tue, 7 Jan 2003, Dan Sugalski wrote: 2. There is a primitive array type that is promoted to an objectified Array class when needed. This would be analogous to the int/Int distinction for primitive numbers. This would be visible to programmers, but may be acceptable for the same reason as the int/Int types are. Not unless Larry really insists. Primitive arrays aren't sub-, super-, or side-classes of objects--they aren't objects at all. (They're arrays, hence the name array) You may be able to treat them in some ways as objects, but that doesn't make them objects any more than treating arrays like integers makes them integers. Perhaps you could explain how the $0 object will work in your mind. A5 assert that $0 is a object, and it behaves as an array and a hash, depending on how you subscript it. Typeglobs are gone, and we're all hoping the TIE interface is gone too, so how will this effect be accomplished? All variables in parrot are implemented as PMCs, and all PMCs may be accessed with a string, integer, or PMC subscript or set of subscripts. For PMCs that don't do subscripting this will be a fatal error, for those that do it'll do whatever the PMC is supposed to do. (In the case of $0, do the lookup) If you really, really, really wanted to, you could consider PMCs as objects. You may have to squint really hard and paint them pink, but...that PMCs do is allow you to call a method on them, which we don't guarantee will work as we don't guarantee there's even a package associated with a PMC) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: perl6-lang Project Management
On Wednesday, November 06, 2002, at 11:54 AM, Michael Lazzaro wrote: On Tuesday, November 5, 2002, at 11:18 PM, Allison Randal wrote: Since you're interested in the management of the Perl 6 project, I'll let you in on some of it. Let's start with a step back into a bit of history: OK, let me pause for a second... pause, pause, pause... OK, I'm better now. Please forgive me, I'm going to be quite forceful in my evaluation of the situation here. To the point of making a Simon C. post look mellow. Get ready for some spectacular virtual coffee-mug-throwing here. I'm replying to your coffee-mug-throwing posting *very* late simply because I got so far behind on p6l that I had 1000 unread messages. Largely because of the hellacious thread reworking operators. I just now got caught up to November 6th. I just want you to know how much I personally appreciate your efforts. I agree that we need to be creating some unified description of the current status. I'd be interested in helping, but one reading of your summary convinced me that I can't write anywhere near as well as you do. And, of course, it is discouraging to think about putting that much effort into a language description when that language is shifting so wildly, often on a day-to-day basis. Now, just before Christmas, I archived my unread heap, and starting time slicing between current postings and my archive. So I can see you're still actively participating in p6l, and I'm glad to see that. I still have November 6th-December 24th to read, so I don't yet know how others responded to your outburst. But it made me realize two things: (1) I don't want you to get discouraged, and (2) I haven't given you any feedback (let alone, appreciative feedback). You have been among the handful of posters whose messages I look forward to. Your messages are a breath of fresh air -- an island of sanity -- amid the quicksand shiftings of p6l. So please accept my thanks for the tremendous amount of time and productive thought you are sharing with us. And now, my unread pl6 archive has been reduced to 772 messages. Sigh. I wish I could beat back my anal-retentive tendencies long enough to be satisfied with the fine Piers Cawley summaries. But always want the fine-grained detail, too =thom Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. --Dr. Jubal Harshaw (Robert Heinlein's _To_Sail_Beyond_the_Sunset_)
Re: L2R/R2L syntax (was Re: Everything is an object.)
Buddha Buck [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
and similarly,
$a ~ ...;
is equivalent to
$a = ...;
But with the different precedence. At last, I can assign from a list without
using parentheses:
@a = 1, 2, 3; # newbie error
@a ~ 1, 2, 3; # would work
Something else springs to mind. Consider the Cfor syntax:
for 1,2,3 ~ foo - $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
Dave.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Nicholas Clark wrote in perl.perl6.language : Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? I meant that if ~ and ~ are going to have the same precedence, you can't parse s ~ t ~ u It's not a well formed phrase of the language (even though this language can't described by a nonambiguous BNF grammar.) In fact, this is different from the Perl 5 situation you're alluding to.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote in perl.perl6.language : But with the different precedence. At last, I can assign from a list without using parentheses: @a = 1, 2, 3; # newbie error @a ~ 1, 2, 3; # would work or : @a ~ 1 ~ 2 ~ 3; or : 1, 2, 3 ~ @a; which would be also written as : 3 ~ 2 ~ 1 ~ @a; shoot me : 3 ~ 2 ~ @a ~ 1; (Aha, Damian's 1st proposal seems to imply that ~ has highest precedence than ~).
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote:
Something else springs to mind. Consider the Cfor syntax:
for 1,2,3 ~ foo - $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
I think I see what you're saying...
$a ~ foo;
calls foo on $a, while
$a - $x { ... }
um, does nothing... OK, I didn't see what I thought I said.
Actually, I do see something like:
$a ~ - $x { ... }
as having meaning, namely call the anon sub with $a as an argument.
Does syntax already exist for doing that? Can one do:
- $x { ... } ($a);
already?
If not, then the ~ - construct has a use, perhaps a semi-common use,
and perhaps it should be simplified. Not to suggest another operator
here, but $a ~- $x { ... } anyone?
But you were looking for a way to play off their similar meanings to
avoid having to use a tilde
The BNF for anonymous subs is something like (I haven't read the
existing grammars, so if I'm not using the standard terms...sorry):
anon_sub :== sub block
| sub ( paramlist ) block
| - block
| - paramlist block
The BNF for left-to-right pipelines would be something like:
lr_pipe :== lr_pipe ~ variable
| lr_pipe ~ function_call
If we were to combine - and ~, would it lead to any ambiguity? I'm
not sure. Certainly we'd be talking about more than a one-token lookahead.
Actually, I'm not sure the lr_pipe is unambiguous in its own right. I
don't have it complete, obviously, but I see problems with the two calls
as is...
What is the result of:
$input ~ %functionTable{$state} ~ $state;
Is it equivalent to:
%functionTable($state) = $input;
$state = %functionTable($state);
or
$state = %functionTable($state).($input);
How does the grammar differentiate between the two?
Or would I have to type
$input ~ %functionTable{$state}.() ~ $state;
instead?
Dave.
Re: Pike 7.4
--- Damian Conway [EMAIL PROTECTED] wrote:
Chris Dutton wrote:
Given discussions about hyper operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operators give more
flexibility.
For example, I'm struggling to see how one could use the [*] to do this:
@names = «Gödel Escher Bach»;
@ages = $today »-« %date_of_birth{@names}
Damian
We can't use « or ». Not only are they impossible to type on some editors,
but they're different in CP437 (the DOS charset), Latin1, and UTF8.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Luke Palmer [EMAIL PROTECTED] wrote:
Date: Wed, 08 Jan 2003 12:14:10 +0800
From: Damian Conway [EMAIL PROTECTED]
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
Further suppose that ~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort ~ map {...} ~ grep {...} ~ @a;
Or, under a special rule for variables on the LHS:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions
actually *look* like processing sequences.
I think this is a big step towards readability. It allows you to put
whatever part of the expression wherever you want (reminiscent of
Latin); i.e. always keep the important parts standing out. I also
think that the operator (especially a cool 3d-looking one like ~) is
also much more readable than a word in this case.
I don't like either of these operators. What's wrong with @out = sort map
{...} grep {...} @a?
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
Trey Harris wrote: I love this. And any class could override the ~ operator, right? Right. I suppose it could be done like arithmetic overloading, if you define both ~ (I'm being pointed at from the right) and ~ (I'm being pointed at from the left) in your class then Perl will use whichever appears in code, but if you define just one, Perl will use it for both. H. Maybe. I'm not certain that Perl 6 operator overloading will be as highly dwimical as Perl 5's is. Damian
Re: [perl #19834] [PATCH] sub, add, mul, div with combinations of INT, NUM, PMC
At 7:41 PM + 1/8/03, Bernhard Schmalhofer (via RT) wrote: I have been looking into the possibility of adding complex numbers as PMCs. When looking at core.ops I was missing some operations, where INT, NUM and PMC interact. For addition I found the operations: add_i_i, add_n_n, add_p_i, add_p_n, add_p_p, add_i_i_i, add_n_n_n, add_p_p_i, add_p_p_p. Trying to make this more consistent I added: add_n_i, add_n_n_i and app_p_p_n. This means that there are now 12 addition ops. I also brought 'sub', 'mul' and 'div' to the same level. I have put some tests in t/op/arithmetics.t. Each of the operations mentioned above should be called in the test. However I still wonder about operations like 'div_p_n_p'. Unlike 'div_p_p_n', it can't be implemented with the vtable-function divide_float. I have attached the patch for core.ops and the file arithmetics.t. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
The perl 6 parser
Could one of the folks working on the perl 6 parser give us a status update as to where it stands? Which bits of the apocalypses don't work, and what parts of the regex definiton's not done yet? Things have stalled a bit, and I'd like to get it going again, and the perl 6 tests into the standard parrot test suite. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
This week's summary
The Perl 6 Summary for the week ending 20030105 Hello and welcome to the first summary of 2003, welcome to the future. This summary covers 2 weeks, but they've been quietish what with Christmas and the New Year. So, starting as usual with perl6-internals A pile of patches to the Perl 6 compiler Joseph F. Ryan submitted a bunch of patches to the Perl 6 mini compiler, (found in the languages/perl6 subdirectory of your friendly neighbourhood parrot distribution) mostly implementing the the semantics for string and numeric literals discussed on perl6-documentation. Garbage Collection headaches Heads have been put together in an attempt to get Parrot's Garbage Collection system working efficiently and accurately (no destroying stuff before anyone's had a chance to use it, dammit!) It appears that there's still a good deal of head scratching to be done in this area (the chaps over on the LL1 list are wondering why we aren't just using the Boehm GC system...) I freely admit that GC makes my head hurt (especially as, in my current Perl 5 project I'm busy implementing mark and sweep collection for a persistent object store whilst also making sure that my random assortment of circular data structures has weakened references in just the right places so that stuff gets destroyed but only when it *should* be destroyed... Boy, am I looking forward to Perl 6 and not having to worry about this stuff ever again...) but I I'll have a go at summarizing the issues. The main problem appears to be that of 'Infant mortality', an issue that I will now attempt to explain. All the objects in memory can be represented as nodes in a graph, and the pointers between those objects can be represented as edges in that graph. The process of garbage collection involves taking a subset of those nodes (the rootset) and freeing (or marking as freeable) all those nodes in the graph which are not reachable from the rootset. Now, consider a function that sets up a new PMC, specifically a PMC that contains another PMC. The first step is grab the memory for our new PMC. Next we create the contained PMC, a process which allocates more memory... and there's the rub. Garbage Collection can get triggered at any point where we go to allocate more memory; unless the *containing* PMC is reachable from the rootset then it will get freed at the point. And that leads to badness. So the Infant Mortality problem can also be thought of as the problem of rootset maintenance. Which is, in theory, simple; just treat all C variables as members of the rootset. However, in practice it isn't that simple, mostly because hardware registers complicate the issue. Steve Fink offered an overview of the issues and some of the possible approaches to dealing with them, which sparked a fair amount of discussion amongst those who understood the issues. http://makeashorterlink.com/?K2FE52303 http://makeashorterlink.com/?Y20F32303 -- Steve's overview Variable/value vtable split Leo Tötsch posted a summary of where we stand on doing the variable/value vtable split, suggesting that he wanted to start feeding in patches soon. Mitchell N Charity supplied a handy dandy 'context' post with links to appropriate articles, and he and Leo did a certain amount of thrashing out of issues. http://makeashorterlink.com/?B11F21303 http://makeashorterlink.com/?G12F32303 Parrot gets another new language Ook! Jerome Quelin offered an implementation of the latest silly language, Ook! which can be thought of as brainf.ck for Librarians. Due to insanity, the Ook! compiler is implemented in Parrot assembly, and emits parrot assembly too, which led Jerome to ask for an 'eval' opcode. Which Leo promised to supply. And which Dan specced out in PDD6. All of which led Leo to comment that, for all these languages are toys, they do seem to be driving the implementation of important bits of Parrot. Nicholas Clark reminded everyone that a zcode interpreter would be another good thing to have a crack at because it would require a couple of other really useful bits of Parrot functionality. Ook! is now in the core. http://makeashorterlink.com/?R53F23303 Returning new PMCs David Robins wondered what was the resolution about creating and returning a new PMC in PMC ops that take a PMC* dest parameter. He and Dan discussed it back and forth and it became apparent that Dan really needs to get Parrot Objects defined... http://makeashorterlink.com/?Q24F21303 Fun with PerlHash Jerome Quelin noticed that you couldn't delete an item from a PerlHash. Leo fixed it. Jerome later asked how one could retrieve the keys of a PerlHash in Parrot assembly and wondered if there was a way to traverse a hash. Sadly the
LXR - source-code indexing
I am pleased to announce that LXR has been installed on perl.org to index the source of parrot and perl5 (additional modules, such as perl6, can be added as needed). So, you might be asking: What is LXR? LXR is a source-code indexing tool that was originally developed for the Linux kernel. With LXR, you can browse the source, search by filename (regular expression match), search by contents (regular expression match), or search for identifiers (functions, preprocessor macros, etc...). Furthermore, all source files are linkified, so that clicking on a function name gives the location where it was defined, and all references to that function (this works with subroutines in perl code too). LXR will even allow you to do diffs between two versions, comparing (for example) how a file changed between the 5.6.x branch and the 5.8.x branch. And where can I get this tool if it is so great? That's easy! Just hop on over to tinderbox.perl.org/lxr and choose the source-tree you want. You can then select the version you want to browse with from the top of the next page. But of course, there is always a catch. LXR is running rather slow at the moment, despite mod_perl. I think this is mostly because it needs more use for the cache to build up, but I'm going to try to do some more profiling and see where the problem is. Occasionally, LXR will return a blank or near-blank page. If you hit this bug, hitting reload a couple of times should make the correct file show up. The code is updated every night, parrot is pulled from the cvs repository at 11:00pm, and perl5 from the activestate rsync server at 1:00am. If you would like more frequent updates, please let me know and I can arrange for more. Please let me know about any bugs you hit or feature requests, and I'll do my best to incorporate them. Remember, it's tinderbox.perl.org/lxr. Zach
Re: More thougths on DOD
Mitchell N Charity wrote: Summary: its slower :-( :( Yep Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. Hmm... the first reason, a second bit of pointer arithmetic, seems surprising, cycles being sooo much cheaper than cache misses. Here are the relevant bits: # define pool(o) ((struct Small_Object_Arena *) (PTR2UINTVAL(o) POOL_MASK)) # define DOD_FLAGS(o) \ ((POOL_FLAG_TYPE *)pool(o)-flags) \ [((char*)(o) - (char*)(pool(o)-start_objects)) / pool(o)-object_size] (object_size is copied from pool, not currently there) This is a general version that plugs in as a replacement for PObj_get_FLAGS(o), but it was called only once per function. I think the real problems are here not the cycles of pointer arithmethic, there are different problems: - we can't use explicit pool pointers, handling flags directly is faster (getting the pool pointer has the same cache impact) - when there are no explicit pool pointers, something like above has to calulcate the pool position, which needs a fixed sized POOL_MASK i.e the pool size. - with fixed sized pools (buffer PMCs) all alike, a List, List_chunk, Hash, String and so on, get all the same pool size, though they may be used just once, leading to huge buffer and bufferlike pools too. - e.g. stress.pasm needs 500K PMCs, fastest is to grow pools huge to some Megs of mem or finally ~200.000 PMCs per pool-arena. - e.g. life.pasm needs per cycle only ~ 50 strings, but needs really fast recycling of these, so the pool size should be not really bigger then the demand (which holds for all programs). - with fixed sized pools, I see no possibilty, to deal with these to extreme demands. - I did also try to not add_free all objects immediatly and reduce arena-used, so that the free_unused_pobjects is faster, but this needs a DOD run before. We don't know, in which header_pool is the shortage. And, when one pool holds ~10^6 objects and other pools ~nothing, a DOD run for allocating more for the rarely used pool is too expensive. stress.pasm with fixed sized pools spends the time in free_unused_pobjects() because there are too many (dead - or better never alive) objects around. ... So I modified the tpmc test with a second calc. The test is for one fixed sized pool with one header kind. We have pools for objects of sizeof Buffer, List_chunk, List, hash, PMC and probably more which may have very different header counts from 0 to 1e6 or more. All have to be somehow equally fast. We can trade a little bit to favor one kind of headers, but not all. We can't allocate a fixed size huge pool arena for the worst case, all others and memory consumption suffer. I don't suppose it is still touching the PMC bodies for any reason? No. But wading through the root set, zig header pools, marking stacks and so on, needs cache space. Puzzled, So was I. Tests looked really fine. BTW If you (or anyone) wants a patch just mail me Mitchell leo
Re: The perl 6 parser
On Wed, 8 Jan 2003, Dan Sugalski wrote: Could one of the folks working on the perl 6 parser give us a status update as to where it stands? languages/perl6/README mostly reflects the status with respect to the language definition of about 4-5 months ago. Differences include: - IIRC hyper-assignment operators are there. - regex capture groups are partial/flaky, not completely unimplemented. Joseph Ryan has updated string and numeric literals to correspond to the latest consensus on the list. Other than that, it's inconsistent with the current spec in a number of ways. A lot of it's just syntax (e.g. hyper-ops, for which I'll have to cut-and-paste the non-ASCII bits). The tests should all still pass (barring inclement GC bugs), but they reflect the outdated spec. /s
Re: The perl 6 parser
Dan Sugalski wrote:
Could one of the folks working on the perl 6 parser give us a status
update as to where it stands? Which bits of the apocalypses don't
work, and what parts of the regex definiton's not done yet? Things
have stalled a bit, and I'd like to get it going again, and the perl 6
tests into the standard parrot test suite.
I think that before development kicks back up again, perhaps we use
the long absense to look objectively at P6C and look for potential
places to refactor.
For instance, one thing that I'd like to do is abstract operator
symbols from their node definition. After the monster operator
thread on p6-lang awhile back, at least 50% (guess) of the operators
are no longer the same as they used to be.
However, these symbols are still hardcoded into the Binop node type,
meaning that nearly every single module in P6C needs to be updated.
However, if the symbols were mapped to an operator name/number in the
tree deciphering phase in Tree.pm, then updating the operators would
be simple if future changes occur.
So, a node like this:
bless {
op = '_', # yes, it is '~' now, but there are still dozens of
# usages of '_' throughout P6C
l = bless {type='PerlUndef', name='$x'}, 'P6C::variable'
r = bless {type='PerlUndef', name='$y'}, 'P6C::variable'
}, 'P6C::Binop';
Might become:
bless {
op = 'concat',
l = bless {type='PerlUndef', name='$x'}, 'P6C::variable'
r = bless {type='PerlUndef', name='$y'}, 'P6C::variable'
}, 'P6C::Binop';
or
bless {
op = 1, # or whichever operator number concat is
l = bless {type='PerlUndef', name='$x'}, 'P6C::variable'
r = bless {type='PerlUndef', name='$y'}, 'P6C::variable'
}, 'P6C::Binop';
The operator name/number could then be resolved during IMCC code
generation phase using a dispatch table similar to the one already
in place.
Joseph F. Ryan
[EMAIL PROTECTED]
