Re: Using Rules Today
> In any case, I was wondering if someone could provide me with an example of
> a mathematical expression parser (and evaluator).
> To properly compare to the others, it would need to handle the following
> operators
>
> +, - (left associative)
> *, /, % (left associative)
> ^ (right associative)
>
> handle parens 12 - (3 + 4)
>
> handle two functions sqrt() and abs() both of which must include the
> parens.
>
> If someone has time to do this for me, I would be appreciative. It might
> also serve as example documentation or cookbook ideas.
>
> I am specifically interested in examples that can be run in Perl 5 today
> without needing Pugs or Parrot.
It isn't specifically a parser designed for general language parsing, but
CGI::Ex::Template does have a mathematical expression parser. The parser is
located near the end of the parse_expr method. The output of the parse_expr
is an opcode data structure that can be played out through the play_expr
method.
The basic functionality is that a chain of operators is tokenized into a
single array. The apply_precedence method is then used to split the array
into the optree based upon the precedence and associativity of the operators.
The following is a sampling of the resulting "optrees" for the given
expressions (taken from the perldoc):
1 + 2 => [ \ [ '+', 1, 2 ], 0]
a + b => [ \ [ '+', ['a', 0], ['b', 0] ], 0 ]
a * (b + c) => [ \ [ '*', ['a', 0], [ \ ['+', ['b', 0], ['c', 0]], 0 ]],
0 ]
(a + b) => [ \ [ '+', ['a', 0], ['b', 0] ]], 0 ]
(a + b) * c => [ \ [ '*', [ \ [ '+', ['a', 0], ['b', 0] ], 0 ], ['c',
0] ], 0 ]
perl -e 'use CGI::Ex::Template; $s=CGI::Ex::Template::dump_parse("3 * 4 ** 2 +
5"); $s =~ s/\s+/ /g; print "$s\n"'
$VAR1 = [ \[ '+', [ \[ '*', '3', [ \[ '**', '4', '2' ], 0 ] ], 0 ], '5' ],
0 ];
I apologize that the expression parsing isn't a little more abstracted for
you, but the result should be usable. Also, the parse_expr is designed for
also parsing variable names in the TT2 language, so the first portion of the
method applies variable names. The entire thing could be cut down
considerably if all you want to parse is math (no variables).
Paul Seamons
Re: clarifying the spec for 'ref'
> Does this mean you can't write
>
>class Super { method something { ... } }
>
>sub foo (Super $bar) { $bar.something() }
>
> and expect foo($obj) to work, because $obj might be:
>
>class Sub is Super { # remove .something--how does that happen? }
>
>foo($obj); # Boom!?
>
> So what happens?
For the case in point if you tried to call @array.set(0, $element) I would
expect it to fail with an error saying you can't modify a constant array.
The method set still exists - it just politely tells you not to call that
method on that particular class.
No methods are removed.
This is very similar to read only strings.
Paul Seamons
Nested statement modifiers.
I'm not sure if I have seen this requested or discussed.
Is there a parsing reason why Perl 6 would allow nested statement modifiers or
is it mainly a sanity-please-don't-hurt-my-eyes reason.
It is silly to do things such as:
say "Interesting" if $just_because if $because;
But it is sort of useful to be able to do things such as:
say "Hrm $_" for 1 .. 3 unless $why_not;
The grammar_rules.pg defines a statement as:
token statement {
|
|
|
|
|
| ?
}
It seems like it should be possible to change that to:
token statement {
|
|
|
|
|
| *
}
pge2past.tg would need to be updated to loop on found statement modifiers
rather than only do the first one found. I'm afraid I'm not familiar enough
with PIR to write the looping portion but I can read the following section
enought to know that it shouldn't be too hard to change. The question is
would a patch to add the functionality be accepted if I went to the trouble
of figuring out how to do it?
Paul Seamons
Section of pge2past.tg that re-writes the expression to be enclosed by an if
block:
transform past (Perl6::Grammar::statement) :language('PIR') {
$P0 = node['statement_control']
if $P0 goto statement_control
$P0 = node['block']
if $P0 goto statement_block
$P0 = node['use_statement']
if $P0 goto statement_use
expression:
.local pmc stmt
$P0 = node['expression']
stmt = tree.'get'('past', $P0, 'Perl6::Grammar::expression')
$P0 = node['statement_modifier']
unless $P0 goto expression_1
stmt_modifier:
# handle if/unless modifier
.local pmc modifier, exprpast, thenpast, elsepast
modifier = $P0[0]
thenpast = stmt
null elsepast
$S0 = modifier['KEY']
if $S0 != 'unless' goto stmt_modifier_1
exchange thenpast, elsepast
stmt_modifier_1:
$P0 = modifier['expression']
exprpast = tree.'get'('past', $P0, 'Perl6::Grammar::expression')
stmt = new 'Perl6::PAST::Op'
stmt.'init'(exprpast, thenpast,
elsepast, 'name'=>'statement_control:if', 'node'=>modifier)
expression_1:
Re: Nested statement modifiers.
> This was definitively rejected by Larry in 2002: Yes. That is good to see and I do think I remember seeing that or some similar postings come to think of it. Thank you for shaking my memory. Now it is 2006. Object syntax has changed. Little bits and pieces (and sometimes larger chunks) of the Perl 6 grammar have changed and reverted and changed again. I don't know what the reasoning was back then and it may be the same today. I'm just wondering what that reason is. Maybe nested statement modifiers promote bad language skills. Maybe its because statement modifiers have always been frowned upon in the language and it wasn't a good idea to promote their status. Maybe it was very difficult to allow for parsing of nested statement modifiers. Maybe it was too difficult to rewrite the operation tree. Maybe nested statement modifiers violate spoken language too much. I can see some of these reasons still being valid. But others I don't see being valid anymore. It is trivial to change the grammar. It is some patches to the tg file to allow it to loop (which may take some more effort). It is a feature that may not be used by many but is useful to others. The following is one more interesting case. say "Ok then" if $yes and $true unless $no or $false; Without nested modifiers you'd have either: say "Ok then" if $yes and $true and ! $no and ! $false; or say "OK then" unless ! $yes or ! $true or $no $or $false; And everybody knows you shouldn't use double negatives. I can't change the mind of Larry but the mind of Larry can be changed. I can't speak for others, but I have found myself wanting to do similar things in Perl 5 and I would wager other people have also. I'll be quiet if you'd like me to be, unless you don't want me to be. :) Paul
Re: Nested statement modifiers.
> $no or $false or $yes and $true and say "OK then" ;
>
> $no or $false or say "OK then" if $yes and $true ;
Thank you for your reply.
I know there are other ways to do it. I've had no choice but to do it other
ways in Perl5.
I don't think I have ever used that notation (outside of file open and
close) - not because I don't know it, but because it puts the emphasis on the
wrong values. It also doesn't read very smoothly.
In the samples you gave I had to read the entire line to see what the outcome
of the code is. In code you either give emphasis to the condition or to the
action that happens should the condition prove successful. Generally
speaking, if the condition is the most important thing I will put it in a
normal if/unless block.
if ($no or $false) {
die "Some horrible death" unless $i_should_not;
}
But if the action is more important then I tend use a modifier.
print_greeting("Hello") if $logged_in unless $asked_not_too;
Allowing for multiple nested modifiers allows the action to retain its
significance. After I sent the last email I came across a statement in the
code I was working on that would have phrased better if I could use both an
if and an unless. These things do come up - we Perl 5 coders have just
trained ourselves to do things another ways.
The biggest setback I see to nested modifiers is that the order of lexical
scopes visually read on the screen are reversed in execution. But that is
already a problem with a single level statement modifier. I don't think
multiple levels introduces any more problem than is already there.
Plus - if there are multiple modifiers then Perl poetry can get even better.
And everybody wins if Perl poetry is better. :)
say "I'm ok"
if $i_am_ok
if $you_are_ok
while $the_world_is_ok;
Paul
Re: Nested statement modifiers.
> From my early conversations with Larry, I recall that the reason is that > RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw > many abuses of these over the years. Therefore, he decided not to repeat > that abomination, limiting it to precisely one level deep. I'm happy for > that. Thank you. This is the sort of answer I was looking for. > Yeah, every once in a while, I've wanted the second layer, but I'm willing > to rewrite the statement as a true normal if/while instead of a backwards > if/while, and it *does* help the overall readability. I'd concede that the actual useful uses are rare enough to not warrant giving a feature that could turn hopelessly ugly quickly - even if the current generation of tools make it easy to add the feature. Paul
Re: Nested statement modifiers.
> > Yeah, every once in a while, I've wanted the second layer, but I'm
> > willing to rewrite the statement as a true normal if/while instead of a
> > backwards if/while, and it *does* help the overall readability.
>
> I'd concede that the actual useful uses are rare enough to not warrant
> giving a feature that could turn hopelessly ugly quickly - even if the
> current generation of tools make it easy to add the feature.
Sorry to respond to my own post. As soon as I sent the reply I still felt an
itch for a second level.
I agree that such a thing could be abused as Randal mentioned. But how many
things are there in Perl 5 and Perl 6 that can't be abused (sorry - that is a
sort of subjective thing to ask so I am putting it out hypothetically)? It
still seems odd to take some things out of the language but leave others in
(ok - most things that have been left out have made perfect sense). I'm much
more a fan of the leaving in if the thing being left in doesn't have an
exponential cost and if there isn't a good reason to exclude it.
We still have goto statements. We have map and grep that now go forwards -
but can still go backwards.
Taking it out doesn't necessarily prevent abuses since we now have repeat.
repeat {
repeat {
say "Oh no. Not again";
} while $x++ < 10;
} while $y++ < 2;
As opposed to
say "Yes. Yes again"
while $x++ < 10
while $y++ < 2;
Additionally reading the documentation about repeat it seems that the
following should already be allowed since the conditional statement on a
repeat is not optional and if it doesn't come first then it MUST come later
and if it MUST come later then it isn't a modifier.
my $x = 1; repeat { say "hello"; $x = 0 } while $x if $x;
Though I would expect the following to break because it wouldn't know to parse
for the modifier after the closing brace:
my $x = 1; repeat while $x { say "hello"; $x = 0 } if $x;
This is what pugs does - though I'm not sure what it means.
pugs> my $x = 1; repeat { say "hello"; $x = 0 } while $x;
hello
0
pugs> my $x = 1; repeat { say "hello"; $x = 0 } while $x if $x;
>
I think it means that I will probably need to have the correct behavior be
clarified to me, obtain a commit bit and add a test to pugs.
Anyway. Once again if the alleged crime or the predicted crime is too great
then I concede. I can see that it could be abused by some. But that doesn't
mean I will abuse it.
Paul
PS. And not that it matters, but TT3 is planned to support nested statement
modifiers and my engine which does much of TT3 already supports them - and I
do use them on occasion - but that's a different mailing list.
Re: Nested statement modifiers.
> Of course, that wasn't exactly what you were asking, but it does present
> a practical solution when you want to:
>
> {say $_ for =<>}.() if $do_read_input;
>
> Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable.
But it also brings the question: If you can do it ugly [1] easily, why not
allow for it do be done prettily [2] ?
say $_ for =<> if $do_read_input
Paul
[1] It isn't really that ugly - just not as pretty.
[2] Arguably the "pretty" version is also more ambiguous whereas the "ugly"
version leaves little room for doubt.
Re: Nested statement modifiers.
> It relates to some old problems in the early part of the RFC/Apocalypse
> process, and the fact that:
>
> say $_ for 1..10 for 1..10
>
> Was ambiguous. The bottom line was that you needed to define your
> parameter name for that to work, and defining a parameter name on a
> modifier means that you have to parse the expression without knowing
> what the parameters are, which is ugly in a very non-stylistic sense.
Again, thank you for your reply.
I don't think that is ambiguous though. If you view statement modifiers in
their unwrapped state, that example isn't any more ambiguous than
for 1..10 {
for 1..10 {
say $_
}
}
The question is sort of related to asking if these two examples are equivalent
not just in operation, but also in how they scope.
Is the following a syntax error in Perl6:
use strict;
my $a = 1;
my $x for $a;
$x;
It isn't under Perl5 - but will it be under Perl6.
Either way the nested statement modifiers would work even if scopes aren't
introduced at each level.
.say for 1..$_ for 2..5;
I think it reads sort of nicely left to right.
Paul
Re: Nested statement modifiers.
> It may be more useful to discuss this issue using less contrived > examples. :) I would agree. I haven't had any use for a double "if" or a double "for". The double "if" case is handled by "&&". The double "for" case is handled by "for" and "map". The interesting cases are combinations of "if" and "for" and "while" and "unless". .say if cond($_) for =<>; That one is sort of not necessary now that grep can be lazy. .say for =<> if $read_the_rest; Which can obviously be written in other ways using other constructs, but not without changing how the statement reads or changing what it emphasizes. And as for Perl6 - well yes I'd love to see it get here more quickly also. But I don't think that discussing little nitpicks like this are delaying the release of Perl6. Maybe they are - but I would guess there are more pressing issues that are occupying development time. Paul
Re: Runtime role issues
> First, when a role is applied to a class at runtime, a instance of that > class in another scope may specifically *not* want that role. Is there a > way of restricting a role to a particular lexical scope short of applying > that role to instances instead of classes? Seems like you could use an empty intermediate role to accomplish the same thing while leaving the shared class alone. Shared Class A Mixin Role B Class C isa A does B Class D isa A Shared Class A is unmodified. Otherwise, I think that any runtime modification of a class should affect all instances and future instances of that class. On closer inspection, is it even possible to add a Role to a Class at runtime? I thought that Class and Role composition outside of compile time resulted in a new pseudo Class for the subsequent instances of that composition - in which case the original Class would remain unmodified. Paul
Re: List assignment question
> > my ($a, undef, $b) = 1..3; > > Huh. I didn't think that worked in Perl 5, either. What am I > misremembering? I distinctly recall having to do things like (my $a, undef, > my $b) to avoid errors because you can't assign to undef. Maybe I'm just > hallucinating. Are you remembering this: my $a = 1; ($a, undef, my $b) = 1..3; If you attempted to do my ($a, undef, $b) you'd get a warn error about re-declaring $a. Paul
Re: generic ordinal-relevant operators
> Yes. He also accepted the proposal to add min and max operators - > although I'm unsure why they weren't included as functions/methods > instead. It seems more natural to me to say 'max($a, $b, $c)' or > '($a, $b, $c).max' instead of '[max] $a, $b, $c' or '$a max $b max > $c'. Although it _does_ allow for such things as '$a max= $b' (which > is shorthand for something like '$a = $b if $a < $b'). And I suppose > that '&infix:' doesn't stop you from having '&max' as well. In true chicken and egg fashion: Which comes first the operator or the function. Do you define &infix: in terms of &max or vice versa. My guess is the operators should win because there could be some low-level shenanigans that optimize things. But maybe not. Paul
Re: Smart Matching clarification
> So maybe we have some or all of: > > .keys .sortkeys > .values .sortvalues > .kv .sortkv > .pairs.sortpairs > > Possible variations: .skeys, .ordkeys, etc. Also could flip the > default and make .keys sort by default and then you use .rawkeys to get > unordered--shades of PHP. Taking a page from Template Toolkit. .keys # same as perl5 .sort # the sorted keys I know that it isn't quite parallel with Array.sort and it doesn't provide for .sortkv or .sort pairs, but it might be an option. Paul
Re: Fwd: Numeric Semantics
> While I'm in general agreement with everything you've said it makes me a
> tad nervous to hinge so much on the difference of one character. Can you
> imagine trying to track down the bug where
>
> if ($alpha === $beta) { ... }
>
> really should have been
>
> if ($alpha == $beta) { ... }
>
> Anyway, it's not like this problem wasn't already there, it's just that
> your email made it stand out to me.
I'm not adding support to either side of the issue. I just wanted to point
out that with Perl 5 and other current languages I occasionally have to
search for that bug right now. Except it is spelled a little different with
if ($alpha = $beta) { ... }
When I really meant:
if ($alpha == $beta) { ... }
It is rare though. I think the == vs === will be rare also.
Paul
Re: for ... else
> foreach my $item (@items) {
> #process each item
> } else {
> #handle the empty list case
> }
>
> What do you think?
I'm not sure if I like it, but there have been several times that I would've
used it recently. I think it would certainly have utility.
Paul
Re: date and time formatting
> So, if we continue following this API, Perl6 core will contain time(), > but no localtime() nor gmtime(). The Date module will provide human > readable date and time strings, and basic date math. localtime() and gmtime() seem fairly core to me. The array contexts are simple, and the scalar context is an RFC valid string. Nothing too heavy there. The time() function is "typically" only moderately useful without localtime(). Paul
Re: File.seek() interface
> We should approach this from the perspective that $fh is an iterator, so > the general problem is "how do we navigate a random-access iterator?". Well - I kind of thought that $fh was a filehandle that knew how to behave like an iterator if asked to do so. There are too many applications that need to jump around using seek. The options that need to be there are: seek from the beginning seek from the end seek from the current location Now it could be simplified a bit to the following cases: $fh.seek(10); # from the beginning forward 10 $fh.seek(-10); # from the end backwards 10 $fh.seek(10, :relative); # from the current location forward 10 $fh.seek(-10, :relative); # from the current location backward 10 Paul
Re: WTF? - Re: method calls on $self
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
"legacy" in the Perl6 language.
OK - As I understand it, this is what A12 says:
class Foo {
# normal instance variables
has $.x;
has $.y is rw;
has $:z;
has @.foo is rw;
has @:bar
has %.baz is rw;
has %:ber
method one { return 1 }
method :two { return 2 }
# some class variables
our $.class_var1;
our $:class_var2;
our $.class_var3 is rw;
my $.class_var1_visible_only_to_class;
my $:class_var2_visible_only_to_class;
# implicit object set in $?SELF
method grr {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.baz = 'val';
%:ber = 'val';
my $a = .one; # hmmm - here is the subject of all of our pain
my $b = .:two;
}
# explicit object
method roar ($obj:) {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.baz = 'val';
%:ber = 'val';
my $a = $obj.one;
my $b = $obj.:two;
}
}
# external use of object
sub squawk ($obj) {
$obj.x = 1; # fails - no accessors
$obj.y = 2; # ok - lvalue accessor was created for us because of "is rw"
$obj.:z = 3; # fails - no public accessors - even if "is rw"
push $obj.foo, 'item'; # ok - lvalue accessor created
push $obj.bar, 'item'; # fails - even if "is rw"
$obj.baz = 'val'; #ok - lvalue
$obj.ber = 'val'; # fails - even if "is rw"
my $a = $obj.one;
my $b = $obj.two;
}
Somebody correct me if I had things wrong up above.
So in all of that example, all of the instance variables and methods are
easily accessed and almost all of the rules are clear cut. So under this
"final" proposal we now have the following:
class Foo {
has @.elems;
method rock {
.wizbang; # called on $?SELF - looks ambiguous (what is $_)
.foo for @.elems; # fails with an error - ambibuous compared to .wizbang
}
method stone ($obj) {
$obj.wizbang;
.foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(
}
}
sub conglomerate_solid ($obj) {
$obj.wizbang;
.foo for $obj.elems; # ok here
}
sub petra ($obj) {
temp $_ = $obj;
.wizbang;
.foo for .elems; # confusing - but ok (called on different objects)
}
I don't think the most recent proposal (er edict) is really all that friendly.
I've been hoping that it is a case of linguist/architect/benevolent president
turned psychologist and that it is a "foot in the door approach" of getting
both sides of the ./method argument to just give up and be quiet.
This latest proposal seems to add ambiguity all in favor of getting rid of a
slash. Looking at all of the instance variables and method accesses in the
method "grr" up above, a method call of "my $a = ./one really isn't that out
of place. Once the object is explicit, then all method calls change
(including the private ones) while all of the instance variables stay the
same.
I think that .method == $_.method needs to always hold true. I still think it
would be nice - though not as important to have ./method (or whatever
variation you want) work inside methods. I don't think that $_ should ever
default to the invocant ($_ =:= $?SELF) (which should be easy enough with
"method a ($_) { ... }").
method concrete {
./wizbang;
.foo for @.elems;
.foo for ./elems; # possibly odd looking - but not confusing
}
Please, lets pick something sane. Here I go speaking for the list, but I
don't think we will find many that think ".method syntax breaks in methods if
$_ is rebound" as a very sound concept.
Paul
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote: > * Don't need to topicalize self any more. > > * .foo can (again) always be the topic without warnings. Thank you. Do the following exist then: has @x; # private, lexically scoped has @_x; # private, class scoped, rw _x accessor has @.x; # read only, implies @_x for storage, is virtual ($obj.x) has @.x is rw; # implies @_x for storage, is virtual has %y; # private, lexically scoped has %_y; # private, class scoped, rw _y accessor has %.y; # read only, implies %_y for storage, is virtual ($obj.y) has %.y is rw; # implies %_y for storage, is virtual Paul
Re: Demagicalizing pairs
I don't think this example reads very clearly. Visually you have to parse until you see the next => and then back track one word to figure out the key. > move( from=> $x, $y, delta=> $up, $right ); Personally I'd write that as either move(from => [$x, $y], delta => [$up, $right]); OR assuming I has a Position object and a vector object move(from => $pos1, delta => $vec1); The original example just seems difficult to parse. Paul
Re: .method == $self.method or $_.method?
> Right. I believe the times one will want to do a method call on $_ when it
> is *not* the invocant will be greatly outnumbered by the times when you
> want to do a method call on the invocant. Thus adding ambiguity to .method
> is not worth it.
I think this boils it all down nicely. It seems more important to have
consistency on what .method does. I think it should stay bound to the
invocant and should die/warn if there is none. There are so many "almost"
short ways to call methods on the current topic of grep or map that it seems
a shame to mess up the consistency of .method just to remove a few
characters.
Consider:
method foo {
.do_one_thing
.and_another_thing
map { $_.do_something_with( .bar ) } .items;
# .bar worked on the invocant - not the items
.and_the_last_thing
}
method foo {
.do_one_thing
.and_another_thing
map { $^item.do_something_with( .bar ) } .items;
.and_the_last_thing
}
Both of those feel clean to me as opposed to
method foo {
o.do_one_thing
o.and_another_thing
map { .do_something_with( o.bar ) } o.items;
o.and_the_last_thing
}
Now granted - that the o. isn't the worst thing to look at. It still seems
harder to follow what is calling which method - you sort of have to deduce
that since the do_something_with call doesn't begin o and because you are in
a map then it must be behaving on the topic $_ even though $_ isn't in sight.
We have added a nother level of details (arguably ambiguity) to try and clear
up some ambiguity.
With the former methods it is clear and consistent which methods are being
called on which variables. The .method doesn't change mid method and I know
what variable is calling do_something_with because it is spelled out.
It seems that the "oc behavior" and the ".method acts on $_" are huffmanized
the wrong direction.
Now with an object in non-method we have with .method only on invocant we
have:
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { $_.do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
sub foo {
map { .do_something_with() } get_items();
# dies because there is no invocant
}
and with the .method uses $_ we have
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { .do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
We haven't really won anything other than dropping a few characters.
As I was thinking about that I began wondering if it was possible to
dynamically specify what the invocant is. Wouldn't you know it? That is
what $_ does currently - except you only get .methods, not $.properties.
The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:
method foo {
some_sub_bar();
.do_something();
# this now does get_some_other_object.do_something()
}
sub some_sub_bar {
$CALLER::_ = get_some_other_object();
}
That is kind of scary if call to another sub can hijack my method calls (I'm
sure there are other ways to hijack the method calls - but having the
invocant dynamically set offers too many dangers). Maybe it isn't possible
because $_ will be r only - but somehow I think $_ is rw and the invocant is
r only.
To sum up...
If you are in a method then you get .method and it always works even if $_ is
rebound to something else.
I think that the idea of $_ default to the invocant is necessary and good but
the mistake comes in inferring that .method then must work on $_.
.method should work on the invocant period - it just happens to be a
coincidence that $_ is the same as the invocant for most of the time.
Paul Seamons
I'll go back to lurking about now.
Re: eval (was Re: New S29 draft up)
> eval read :file("foo")
How about:
eval slurp "foo";
Paul Seamons
Re: [pugs] regexp ignore case
I would think that :p5 should behave as perl5 does by default. That would mean that /x and /s aren't on by default (for p5). As this is my first post about pugs - all I can say is "wow." It is great to already be coding perl6. Thanks Autrijus and crew. Paul On Thursday 14 April 2005 07:36 am, Autrijus Tang wrote: > On Thu, Apr 14, 2005 at 01:07:32PM +0300, Markus Laire wrote: > > Until :i is implemented, you can use > > `:i` is now implemented in r1963: > > * :p5 allows as well as :perl5 for regex. > * allow arbitary adverb orders. > * :i / :ignorecase implemented. > * /x and /s semantics are enabled for p5 regex by default. > * "$" no longer matches "\n" at end of line by default. > > As the default flags for :p5 is unspecified territory, I'd > welcome sanity-checking on the treatment above. > > Thanks, > /Autrijus/
Statement modifier scope
The following chunks behave the same in Perl 5.6 as in Perl 5.8. Notice the
output of "branching" statement modifiers vs. "looping" statement modifiers.
perl -e '$f=1; {local $f=2; print "$f"} print " - $f\n"'
# prints 2 - 1
perl -e '$f=1; {local $f=2 if 1; print "$f"} print " - $f\n"
# prints 2 - 1
perl -e '$f=1; {local $f=2 unless 0; print "$f"} print " - $f\n"''
# prints 2 - 1
perl -e '$f=1; {local $f=2 for 1; print "$f"} print " - $f\n"'
# prints 1 - 1
perl -e '$f=1; {local $f=2 until 1; print "$f"} print " - $f\n"'
# prints 1 - 1
perl -e '$f=1; {local $f=2 while !$n++; print "$f"} print " - $f\n"'
# prints 1 - 1
It appears that there is an implicit block around statements with looping
statement modifiers. perlsyn does state that the control variables of the
"for" statement modifier are locally scoped, but doesn't really mention that
the entire statement is as well. I'm not sure if this was in the original
design spec or if it flowed out of the implementation details, but either way
it seems to represent an inconsistency in the treatment of locality with
regards to braces (ok I guess there are several in Perl5).
So the question is, what will it be like for Perl6. It would seem that all of
the following should hold true because of scoping being tied to the blocks.
pugs -e 'our $f=1; {temp $f=2; print $f}; say " - $f"'
# should print 2 - 1 (currently prints 2 - 2 - but that is a compiler
issue)
pugs -e 'our $f=1; {temp $f=2 if 1; print $f}; say " - $f"'
# should print 2 - 1 (currently dies with parse error)
pugs -e 'our $f=1; {temp $f=2 for 1; print $f}; say " - $f"'
# hopefully prints 2 - 1 (currently dies with parse error)
As a side note - pugs does work with:
pugs -e 'our $f=1; {$f=2 for 1; print $f}; say " - $f"'
# prints 2 - 2 (as it should. It seems that statement modifiers don't
currently work with declarations - but that is a compiler issue - not a
language issue.)
I have wanted to do this in Perl5 but couldn't but would love to be able to do
in Perl6:
my %h = ;
{
temp %h{$_} ++ for %h.keys;
%h.say; # values are incremented still
}
%h.say; # values are back to original values
Paul
Re: Statement modifier scope
On Friday 15 April 2005 11:57 am, Juerd wrote:
> Paul Seamons skribis 2005-04-15 11:50 (-0600):
> > my %h = ;
> > {
> > temp %h{$_} ++ for %h.keys;
>
> Just make that two lines. Is that so bad?
>
> temp %h;
> %h.values »++;
>
For the given example, your code fits perfectly. A more common case I have
had to deal with is more like this:
my %h =
my %other = ;
{
temp %h{$_} = %other{$_} for %other.keys;
%h.say;
}
Ideally that example would print
aone
btwo
c3
It isn't possible any more to do something like
{
temp %h = (%h, %other);
}
because that second %h is now hidden from scope (I forget which Apocalypse or
mail thread I saw it in). Plus for huge hashes it just isn't very efficient.
I'd like to temporarily put the values of one hash into another (without
wiping out all of the modfied hashes values like "temp %h" would do), run
some code, leave scope and have the modified hash go back to normal. In
perl5 I've had to implement that programatically by saving existing values
into yet another hash - running the code - putting them back. It works but
there is all sorts of issues with defined vs exists.
So yes - your code fits the limited example I gave. But I'd still like the
other item to work.
Paul
Re: Statement modifier scope
>
> temp %h;
> %h{ %other.keys } = %other.values;
>
> or even
>
> temp %h{ %other.keys } = %other.values;
>
> should work well already?
Almost - but not quite.
In Perl5
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}="one"; print Dumper
\%h} print Dumper \%h;
$VAR1 = {
'a' => 'one'
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
I'm imaging the behavior would be the same with Perl6. Notice that 'b' is
gone in the first print. I only want to temporarily modify "some" values
(the ones from the %other hash). I don't want the contents of the %h to be
identical to %other - I already have %other.
So in Perl5 this does work:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h=%h; $h{a}="one"; print
Dumper \%h} print Dumper \%h;
$VAR1 = {
'a' => 'one'
'b' => '2',
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
But this won't work in Perl6 (temp $var = $var doesn't work in Perl6) and
again it may be fine for small hashes with only a little data - but for a
huge hash (1000+ keys) it is very inefficient.
This is good discussion - but it isn't the real focus of the original message
in the thread - the question is about the local (temp) scoping of looping
statement modifiers in Perl6.
Though, I do appreciate your trying to get my example working as is.
Paul
Re: Statement modifier scope
On Friday 15 April 2005 12:28 pm, Juerd wrote:
> temp %h{ %other.keys } = %other.values;
Oops missed that - I like that for solving this particular problem. It does
even work in Perl5:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local @h{qw(a b)}=("one","two");
print Dumper \%h} print Dumper \%h'
$VAR1 = {
'a' => 'one',
'b' => 'two'
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
I had never thought to do a hash slice in a local. That is great!!!
Thank you very much! Wish I'd know about that three years ago.
But, it still doesn't answer the original question about scoping in the
looping statement modifiers.
Paul
Re: Statement modifier scope
> I'm imagining it will be different, as I expect temp to not hide the old > thing. I'm not sure it will. That is another good question. I just searched through the S and A's and couldn't find if temp will blank it out. I am thinking it will act like local. Each of the declarations my, our and local currently set the value to undefined (unless set = to something). I imagine that temp and let will behave the same. In which case "local %h;" and "let %h" would allocate a new, empty variable in a addition to the original variable (which is hidden but still retains its contents). Paul
Re: -X's auto-(un)quoting?
I think the original (or the "latest original") reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now if we can introduce another way back so that we can always get to the
invocant if we want to, then I'd say lets leave .meth always working on $_ .
It does have beauty and simplicity.
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
for 1 .. 10 {
$_.say; topic of for
.say; # use $_
$^.say; # stringifies invocant 1
$^1.say; # stringifies invocant 1
$^2.say # stringifies invocant 2
}
}
The rules then are simple. .meth always operates on $_. $_ is always the
current topic. $_ defaults to the invocant of the method. $^1 refers to the
first invocant. $^ is an alias for $^1. $^n refers to the nth invocant.
Nice and simple. No conflict with existing naming conventions.
Paul
Re: -X's auto-(un)quoting?
> What is this "way back" you repeatedly mention?
>
> If it is having a name for the invocant, then there has always been one:
>
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
>
> Or, well, two:
>
> method foo {
> my $self := $_;
> ...
> }
>
> Three, even:
>
> method foo {
> my $self = \$_;
> for (1..10) {
> $$self.method(.sqrt)
> }
> }
By this reasoning - why have a shortcut to any of the invocants at all? This
thread has headed in the direction of finding a way to figure out how to call
methods on the invocant without using the signatures name. On a method call
without a signature and without invoking Perl5isms there would not be a "way
back" to the invocant once you enter nested block.
The point of all of this discussion is to not have to set $self to anything.
The argument for .meth as opposed to $self.meth of $_.meth was that .meth was
clear enough to mean the current topic and was a nice huffmanization.
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
That works great - so long as I specify the signature. I'm lazy, I don't want
to type the signature all the time. Consider:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
Still pretty readable. I kind of like $^1 too which seems to behave like
$^variable quite nicely. I guess that $^1 should actually be $^0 so that we
are properly zero indexed. At this point - it sort of looks like Perl5's
$_[0] except now $^0 is just an alias and and it gets all of the attributes
given by the signature (should a signature be given) - plus we don't have to
deal with the [EMAIL PROTECTED] array.
> Or, well, two:
>
> method foo {
> my $self := $_;
> ...
> }
If I didn't like typing the signature - why would I want to type all of that
code to bind the variable? I'm lazy. The signature wouldv'e been shorter.
That looks Perl5ish.
> Three, even:
Same argument as the last with a different "aliasing."
Yes, I know there "can be" a "way back." In this thread, none of the examples
give one using existing Perl 6 syntax. They are all proposing new ways.
This is one more.
Paul
Re: -X's auto-(un)quoting?
Paul Seamons wrote:
> Yes, I know there "can be" a "way back." In this thread, none of the
> examples give one using existing Perl 6 syntax. They are all proposing new
> ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to read.
Juerd wrote:
> $^ as an alias for the invocant works for me, because "" sorts before
> anything else, and the invocant's just the 0th argument.
Didn't see that in your response - I responded to the first topic section but
failed to see there was another.
Juerd wrote:
> I don't understand the concept of multiple invocants. How does that
> work?
If my ability to parse the Synopses was very good, I'd tell you where I saw
mention of it - or maybe it was in the mailing list. Either way that is the
point of the colon in the:
method foo ($self: $arg1, $arg2) {}
So that in theory there would be
method foo ($self, $otherself: $arg1, $arg2) {}
In the end, I'd just like the rules for what .meth does and what $_ is to be
concise and clear - whatever the sytax is that is adopted.
Paul
Re: -X's auto-(un)quoting?
> > meth foo {
> > $_.meth; # defaults to the invocant
> > .meth; # operates on $_ which defaults to the invocant
> > $^.meth; # is the invocant
> > $^1.meth; # is the first invocant
> > $^2.meth; # is the second invocant
>
> I'm starting to get confused at the "need" for all these special
> variables. I vote that we steal from prior art in numerous other
> languages and just auto-set $SELF or $THIS or whatever and call it done.
The problem is that there is no globally safe name to use that uses letters
only. Also there is a certain line noise problem (which may not really be a
problem - but looks like one once we have a more concise alternative):
method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say("Hello " ~ $SELF.prop);
}
That looks considerably more messy than:
method foo {
$.prop = .meth(.get_foo, .get_bar);
.say("Hello " ~ $.prop);
}
Perl syntax is wonderful for being able to say as much as possible without
losing meaning - assuming you can read perl. The short identifiers are able
to express a lot in a little space.
> Having .method assume $SELF is an added nicety, but if it introduces
> added parsing problems then it's hardly worth it.
The .method problem isn't about parsing - it is about knowing which variable
it applies to.
Current syntax would do:
method foo ($self:) {
return grep { $self.is_ok( .value ) } $self.info_pairs;
# .value called on the topic $_
}
Proposed syntax previous to this thread
method foo {
return grep { .is_ok( $_.value ) } .info_pairs;
# .is_ok called on invocant not the topic
}
Proposed syntax in this thread (among various others)
method foo {
return grep { $^.is_ok( .value ) } $^.info_pairs;
# .value called on the topic
}
The goal is to be able to be concise yet intuitive - so that you could do:
my @good_objects = grep { .is_ok } @candidate_objects;
> OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having
> dup short and long names is a waste, since people will always chose the
> short one (who uses English in Perl 5, really?)
That is the goal - to find some nice variable that looks vaguely usable and
that people won't rebel against using.
Paul
Re: Malfunction Junction, what's your function?
Minor note.
Would you want this:
>sub &infix:(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
to be:
sub &infix:(Str $a, Str $b) { return ($a eq $b) ? $a but bool::true:
''; }
(Is that the right way to do it ?)
Paul
Re: Nested captures
> =item *
>
> Quantifiers (except C and C) cause a matched subrule or subpattern to
> return an array of C objects, instead of just a single object.
What is the effect of the quantifiers C<**{0,1}> and C<**{0,1}?> ? Will they
behave like ? and ?? and return a single object - or will they cause the
quantified subrule or subpattern to return as an array of C objects?
Paul
Re: FW: Periodic Table of the Operators
Or for the few Perl emacs people out there: C-x 8 Y C-x 8 < C-x 8 > Paul On Tuesday 01 June 2004 10:27 am, Gabriel Ebner wrote: > Hello, > > Aaron Sherman wrote: > > Well, first off my US keyboard doesn't contain it. > > Sorry, mistakenly picked an US-International chart. > > > Second, you're not supposed to. > > So why has it been chosen then? > > > Â is a shorthand for "zip", > > Good to know. > > > and if you don't want to use the funky one-character operator, > > Would I complain if didn't want to? > > > just use the afunked three-character one. > > Or just use vim as many (helpful) posts noted. > > Gabriel.
Re: Synopsis 2 draft 1 -- each and every
> After all, a pull is the other end of a push. > > Larry So do we also get: %hash.push(key => 'value'); # harder than %hash<> = 'value'; %hash.unshift; # same as %hash.push %hash.shift; # same as %hash.pull %hash.pop; # same as %hash.pull Which then begs if you can do @array.push(3 => 'value'); # index 3 gets 'value' # which is harder han @array[3] = 'value' Paul Seamons
Re: Synopsis 2 draft 1 -- each and every
On Thursday 19 August 2004 02:14 pm, Paul Seamons wrote: > @array.push(3 => 'value'); # index 3 gets 'value' Hmm. Well that makes it hard to have an array of pairs - so never mind. Paul Seamons
Re: Instantiation
> So, I was wondering about a synonym, like: > > uses Some::Module::That::Defines::A::Class $foo; Well if the long name is the problem: use Some::Module::That::Defines::A::Class as Foo; my Foo $obj .= new; # OR # require Some::Module::That::Defines::A::Class; import Some::Module::That::Defines::A::Class as Foo; This seems to be more similar to what is done in other languages. You still have to write the class name repeatedly - but it does cut the typing. It does reduce the magic that is occuring behind the scenes (or at least redirects it to somewhere else). I guess Foo would be a full fledged class which inherits from Some::Module::That::Defines::A::Class. I doubt that it is optimal - but it does give a little bit of flexibility. Paul Seamons
parrotcode.org samples
Their is an example at http://www.parrotcode.org/examples/ that returns a list of integers that span two integers. The return types appear to be set wrong in the SPAN bsr. It seems the return values should be set I0, I7 # number of items on the stack set I1, 0 # no integer return values The current example is listed below. I am very much a novice at reading PASM so hopefully I didn't interpret the program wrong. Paul Seamons PS - By the way the new examples (I think they are new - they are new to me) are very nice and descriptive of PASM. -- set I0, 1 # prototyped set I1, 0 # no items on the stack set I5, 42 set I6, 56 bsr SPAN ne I0, 0, RETURNERROR # item on stack # we don't know the number of integers values returned ne I2, 0, RETURNERROR # string return values ne I3, 0, RETURNERROR # PMC return values ne I4, 0, RETURNERROR # numeric return values MORE: restore I2 print I2 print " " dec I1 if I1, MORE print "\n" end RETURNERROR: print "Error with return values from SPAN!\n" end SPAN: ne I0, 1, CALLERROR # not prototyped ne I1, 0, CALLERROR # items on stack set I7, 0 # count of integers REDO: saveI6 dec I6 inc I7 le I5, I6, REDO set I0, 0 # no items on the stack set I1, I7 # one integer return value set I2, 0 # no string return values set I3, 0 # no PMC return values set I4, 0 # no numeric return values ret CALLERROR: print "Error calling SPAN!\n" end --
Re: parrotcode.org samples
Sigh - sheepishly read that I can't even spell "There" correctly. - double sigh. On Wednesday 13 October 2004 12:13 pm, Paul Seamons wrote: > Their is an example at http://www.parrotcode.org/examples/ that returns a > list of integers that span two integers. The return types appear to be set > wrong in the SPAN bsr. It seems the return values should be > > set I0, I7 # number of items on the stack > set I1, 0 # no integer return values > > The current example is listed below. I am very much a novice at reading > PASM so hopefully I didn't interpret the program wrong. > > Paul Seamons > > PS - By the way the new examples (I think they are new - they are new to > me) are very nice and descriptive of PASM. > > -- > set I0, 1 # prototyped > set I1, 0 # no items on the stack > set I5, 42 > set I6, 56 > bsr SPAN > ne I0, 0, RETURNERROR # item on stack > # we don't know the number of integers values returned > ne I2, 0, RETURNERROR # string return values > ne I3, 0, RETURNERROR # PMC return values > ne I4, 0, RETURNERROR # numeric return values > > MORE: restore I2 > print I2 > print " " > dec I1 > if I1, MORE > print "\n" > end > > RETURNERROR: > print "Error with return values from SPAN!\n" > end > > SPAN: ne I0, 1, CALLERROR # not prototyped > ne I1, 0, CALLERROR # items on stack > > set I7, 0 # count of integers > REDO: saveI6 > dec I6 > inc I7 > le I5, I6, REDO > > set I0, 0 # no items on the stack > set I1, I7 # one integer return value > set I2, 0 # no string return values > set I3, 0 # no PMC return values > set I4, 0 # no numeric return values > ret > > CALLERROR: > print "Error calling SPAN!\n" > end > --
Re: Namespaces, part 1 (new bits)
I'll delurk here for a moment, I am of the opinion that there is not that much of a need to allow for simultaneous access to similarly named Perl data types in python. I am not aware of any CPA modules that export two or more of the same name but for different data types - such as $foo, @foo, %foo, and &foo. While it appears necessary, on the surface, to allow for access to all of these types at once I think the need for such access is being overstated. Though it isn't my place to dictate style, exporting multiple types of the same name seems ambiguous and should be avoided - even if the module is only to be used in a straight Perl context. I like that in the syntax Leo has used, there is no reference to what Perl type you are using. This seems to be the most natural way to merge the languages together. I don't know that bridges need to be built around gaps were languages do not perfectly merge together. If I export or place two data types with the same name in a "publicly" viewable namespace, I am fine that only one of them will be viewable in Python and will probably be chosen based upon type (so long as the decision about which is viewable is consistent). If the ability to reference all four data types at once is not easy to do from within Python as Leo has repeatedly stated, then it should probably be left alone. In this case being able to do something merely for the sake of being able to do it, doesn't seem to offer enough justification for the creation of new syntax in either language. Paul Seamons
Re: Referring to source code within Perldoc: the new A<> code
> > The solution is simple, you know, Mark. Why not just write up your own > > alternate S26, redesigning Pod 6 the way you think it should work, and > > then publish your proposal for consideration here? > > Couldn't most of this be figured out by making Pod6 extensible (or > whatever the right term is). Pod6 would be more of the syntax and basic > operation, but other people could have custom directives that their > Pod6 translators and formatters could then use. That is, not all of > this has to be in the spec if the spec has a way to make it possible > later. :) > > And, as far as writing a new S26, does this mean that this really isn't > open to discussion? That is, if we want something different than you > want we have to have competing specs and there won't be any compromise? My feeling on the matter is that both camps are right. I think that Damian is right that Pod6 should be completely independent. I think that Mark is right that we need a consistent way to output OO descriptions in pod. I think the problem is that we currently have the "perldoc" program which would probably be better named as poddoc or simply pod. I think perldoc is currently a bad and misleading name for the Plain Old Documentation generator. I think that perldoc should be the magic tool that does pod extraction (ala poddoc) and ALSO does some version of Mark's autoextraction of inlined documentation. @Larry hasn't said anything about having inlined/introspectable documentation. I think that it would be nice to have something standard and I think that Mark's proposal is pretty nice. The "real" perldoc program can have full access to the code. This is actually a downside as well - if the code doesn't compile, then perldoc would not be able to generate the code - but it could always show an error that the code doesn't compile and then show what poddoc would show. The outcome is that poddoc can be Pod6 "pure" and perldoc can be (as its name suggests) documentation for Perl. Just my opinions. Paul Seamons
Re: Referring to source code within Perldoc: the new A<> code
> The outcome is that poddoc can be Pod6 "pure" and perldoc can be (as its > name suggests) documentation for Perl. I failed to mention that it also has the benefit that developers can read the perldoc if they care about method details - or they could read poddoc if they only want a 7000 ft view (aka the executive summary). Paul
Re: Referring to source code within Perldoc: the new A<> code
> The outcome is that poddoc can be Pod6 "pure" and perldoc can be (as its > name suggests) documentation for Perl. Sorry to reply to myself twice. Making poddoc independent of Perl 6 opens the doors a little further for having pythondoc and phpdoc and yourlanguageheredoc which extract the POD tags ala poddoc and then add the inlined/introspectable documentation for that particular language. Now the "only" hard part is getting the other language designers to allow ignoring pod markup in their languages. All of the Parrot based variants could easily incorporate this feature. Paul
Re: [svn:perl6-synopsis] r14449 - doc/trunk/design/syn
> Other available chars: > > <`ws> > <^ws> > <&ws> > <*ws> > <-ws> > <|ws> > <:ws> > <;ws> > I'd vote for <:ws> which is vaguely reminiscent of the former non-capturing parens (?:). It (<:ws>) also bears little similarity to any other regex construct - although it looks a bit like a Perl 6 pair. Paul
Generic callback mechanism in NCI
I started to write an OpenGL library and was only a couple of dozen lines into the pir when I remembered the documentation about callbacks in docs/pdds/draft/pdd16_native_call.pod . Currently there are only two signatures supported on callbacks: one with user_data and extern_data and the other with extern_data and user_data (the positions are all that is different). These are nice and general functions and work well because the user_data is/should be opaque to the calling C function, the user_data provides a place to store the PMC, and the user_data is used to lookup the interpreter that should be used to run the sub stored in the PMC. The pdd says that outside the two provided signatures, anybody wanting to implement NCI connections to callback functions will need to do some hand C coding. Hand C coding isn't at all bad, but it would be nice to have a generic mechanism for storing callbacks from C functions that don't provide a slot for opaque user_data. I was on my way to coding a solution with my meager C skills and wanted to make sure that what I was doing was sane (for some definition of the word sane). So my proposal goes something like this: - Get a new unique id from a new op called get_callback_id - Call a variant of the new_callback op, passing in the unique id - The new_callback variant stores the user data under the unique id - The callback references a unique C function that will return that unique id - When the callback is fired, the unique id is used to lookup the user_data - Any external data is parsed as needed - The registered sub is played Ok, sounds hard enough - but it gets worse. Here is how I would implement this generic callback system and what I think would be required. There will probably need to a file similar to src/call_list.txt such as src/callback_list.txt with entries similar to: 10 v v 10 v ii Where the first number is the number of functions to pre-create, and the other two parts are the return type and signature. I'd rather not have the number be hardcoded and go with a jit solution or some other solution for runtime C function generation - but I'm not aware of anything else that would work besides pre-compiled C functions. I think it would be nice if libraries could generate/compile the needed functions independent of anything hardcoded (and that goes for call_list.txt too for that matter). The entires in callback_list.txt would generate functions similar to the following in nci.c # parrot callback functions void pcbf_v_JV_0(void) # depending up signature void pcbf_v_JV_1(void) ... void pcbf_v_JV_9(void) I would then add two more ops (I shudder to say that - I'm not sure if adding ops is a frowned upon thing). Those ops are (I haven't played with it to know if this is the right format): op get_callback_id(out INT, in STR) # the output is a unique INT for the given signature in STR # it would fail if called more times than the 10 listed # in callback_list.txt (unless a jit solution could be implemented) op delete_callback_id(in INT, in STR) # deletes the user_data in the storage structure, freeing it # for later use Currently the following op is defined in src/ops/core.ops: op new_callback(out PMC, invar PMC, invar PMC, in STR) I want to add one more variant of this op op new_callback(out PMC, in INT, invar PMC, invar PNC, in STR) Another piece that is required is that there be a global ResizablePMCArray (actually there may be multiple based on the registered signatures). Again, I can hear everybody shuddering at the mention of a global. I don't know enought about parrot yet to know if it should be a true global variable, or if it should be tied to an interpreter, or if there is somewhere I should register the PMC with, or if there is already a central structure that would take care of functions like this. My questions are: - Does anybody else want a generic callback function mechanism in NCI? - Is this a relatively sane/clean way to do it? - Is there a better way to generate the functions for each signature? - What is the right way to store that global user_data until the callbacks are fired? I don't think I've been clear enough, but I'll post and then answer questions. I think that it would be good to have something that libraries could use without having to drop down to the C level - I just am not sure if this is too much bloat to implement it. Paul Seamons I've been here all along - I'm just really quiet.
Re: Catching exceptions with the // operator
> in my mind, this strays too far from the meaning of C and adds
> ambiguity that makes the operator unusable. perhaps there's room for
> an operator that gives some sugar for
>
> my $bill = try { ack() CATCH { thpp() } };
>
> but to me that code is concise enough that it doesn't warrant syntactic
It seems that the following should address the issue while providing enough
indication about what is occurring:
my $bill = try { ack() } // thpp();
That seems to be closer to what the original post was desiring.
Paul
Re: Sequential bias in S04 (and Perl6 in general)
> I disagree with the idea that humans don't think concurrently (though > more often they think in terms of data dependencies). I think this is more analogous to event based programming rather than parallel programming. Event based and parallel based have some similarities but the are fundamentally different. Humans typically interact with events and only occasionally are able to walk and chew gum at the same time. Though not fully specified, Perl 6 will have as all the tools necessary to make event driven programs - but there isn't a way to do so automatically. It will take work. I'd argue the same is true for parallel. Paul
Re: Extending Parrot NCI callback functionality
> I am starting to implement a GLUT and OpenGL binding for Parrot. GLUT > is extremely callback-oriented. You essentially can't do anything > beyond open the top-level window until callbacks are functional. You > can't even draw in that window -- the rendered image never actually > appears, and in fact the window itself is simply transparent with just > the chrome showing. I started down this path several months ago. The following is the thread on the topic. http://tinyurl.com/3crzpu In that short thread, Allison Randall responded with: The immediate solution, to get OpenGL working now without waiting for the implementation of the concurrency scheduler and JITed call/callback thunks, is to add a few more callback signatures to the current set of alternatives, and to write a little bit of custom C code for the cases that can't pass dispatch information in a user data argument. It appears that NCI is on the roadmap a couple of months out (or more), but that when it is done it will be done right - for some definition of right. I would've put more work into a temporary solution, but real life has interfered. I'm glad to see other people interested in OpenGL on parrot. When the NCI PDD is up for drafting, it will be good to have a listing of sample libraries and required callback signatures available. I'm excited about the progress Parrot is making. Paul
