Re: IMCC and locals/lexicals
[EMAIL PROTECTED] wrote: ... this seemed reasonable, but it doesn't help: .sub _foo .local int x x = 5 .namespace ANON .local int x x = 3 print x .endnamespace ANON print x .end All untested features are b0rken. I got namespace now running, above snippet behaves now as expected. I'll check it in later after spltting the parser. Thanks for your feedback, leo
Re: logical_not issue
On Fri, Dec 06, 2002 at 05:01:21PM -0500, Dan Sugalski wrote:
> It is OK for an undef value to be true, though. That's not only
> allowable, it has to be allowed. For perl, at least, it's how Larry
> plans on getting around the "function returns undef, but it's a real
> undef value, not a false 'I didn't work' value" issues we have in
> perl 5 now.
Are you sure you want to spell that concept "true"?
Because then if &foo can legitimately return numbers, strings and undefs
does it return
"pie" "pie"
2 2
undef: undef but true,
0 0
"" ""
so now
if (&foo(...)) {
warn "Bang!"
}
warns on traditional true values, and undef?
So the caller then needs to launder the true property from undef before putting
it somewhere else? That feels like a pain.
Or does it return
"pie" "pie"
2 2
undef: undef but true,
0 0 but true
"" "" but true
which makes
if (&foo)) {
warn "Bang!";
}
consistently noisy?
It seems to me that the distinction between intentional undef and failure
undef needs to be made with some property other than "true". It feels like
the distinction between doesn't exist and exists but undef in a hash, the value
returned off the end of an array, or (maybe) the different between the empty
list () and the list (undef)
undef but valid. Or maybe undef but invalid for the failure case?
[so that by default things have no properties]
It's like the argument about the meaning(s) of NULL in SQL, isn't it?
"I just don't know", "known - this isn't applicable" and "this isn't valid"
This is more a perl6 language message, isn't it? If it can't quickly be
quashed, should it migrate there?
Nicholas Clark
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: purge: opposite of grep
Damian Conway wrote:
>
> Michael Lazzaro wrote:
>
> > How would you do something like:
> >
> > (@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
>
> Since I don't understand what that's supposed to do, I probably *wouldn't*
> do something like it. What effect are you trying to achieve?
Sorry. A shorthand for:
for @source {
given {
when /foo/ { push @foo, $_ }
when /bar/ { push @bar, $_ }
when /zap/ { push @zap, $_ }
}
}
that "classifies" (or "parts") @source according to the results of a
series of tests, not just one.
MikeL
Re: purge: opposite of grep
Michael Lazzaro wrote:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
A shorthand ... that "classifies" (or "parts") @source according to
> the results of a series of tests, not just one.
You mean, like:
(@foo,@bar,@zap) := part { when /foo/ {0}; when /bar/ {1}; when /zap/ {2} } @source;
???
And there's always:
push (/foo/ && @foo || /bar/ && @bar || /zap/ && @zap), $_ for @source;
But perhaps there would also be a hashed form, in which each key is a test
(i.e. a rule or closure) and each value an index:
(@foo,@bar,@zap) := part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
or even a arrayed form, when the corresponding index was implicit:
(@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source;
Damian
Re: purge: opposite of grep
Michael Lazzaro wrote:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
A shorthand for:
for @source {
given {
when /foo/ { push @foo, $_ }
when /bar/ { push @bar, $_ }
when /zap/ { push @zap, $_ }
}
}
How about just
(@foo,@bar,@zap) := classify [ rx/foo/, rx/bar/, rx/zap/ ] @source;
and implement classify as a normal sub? Why does everything
have to be built into the first version of Perl 6?
Is there any reason classify can't be a normal sub? e.g. can
a sub return ( [], [], [] ) and have that bound to 3 array
variables? What about return @AoA when @AoA = ( [], [], [] )?
- Ken
Re: Usage of \[oxdb]
On Sat, Dec 07, 2002 at 01:20:26PM +1100, Damian Conway wrote:
> Nicholas Clark mused:
>
> >I just had this thought - can I interpolate in there?
> >
> >Something like
> >"\c[$(call_a_func())]"
>
> Why not just:
>
> "$(chr call_a_func()]"
>
> ???
Well, I was wondering if my function returned "CR", then
"\c[$(call_a_func())]" would mean that the "CR" gets run thought the
\c[...] conversion and a single byte ("\r") is what ends up in the string.
Even if that's of little practical use, what does the language design team
say should happen when perl6's 1 level lexer finds something that looks like
an attempt to interpolate within one of the other double-quotish
constructions?
[should it (a) phone a friend, (b) ask the audience (c) 50/50 ?]
Q "Is that your final answer?" A "for this week" :-)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: purge: opposite of grep
Damian Conway wrote: > or even a arrayed form, when the corresponding index was implicit: > > (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source; That's kinda nifty. But admittedly, it's not to-die-for necessary, if I'm the only one fond of it. Ken Fox wrote: > and implement classify as a normal sub? Why does everything > have to be built into the first version of Perl 6? Yeah, I agree! Oh, except when it's things _I'm_ asking for. _Those_ are always 100% necessary. :-/ (We're basically asking for everything under the sun, but I think we all know that < 10% of it will actually get in, which is a Good Thing. :-) But sometimes the brainstorming shakes loose something more broadly interesting.) MikeL P.S. As for judging the value of a proposal, I personally try to ask the following questions: 1) Is it a simplification of a universally common but otherwise long/tedious algorithm? 2) Is there only One Way To Do It (Correctly)? 3) Is there a name for the operation so obvious that you can, after being first introduced to it, easily remember what it does? (like "reverse", "split", "while", etc.) Not that I always take my own advice. :-) Other people might have different informal criteria. (For future teaching purposes, I'd love to hear what they are.)
Re: purge: opposite of grep
> Damian Conway wrote: > > or even a arrayed form, when the corresponding index was implicit: > > > > (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source; > > That's kinda nifty. But admittedly, it's not to-die-for necessary, if > I'm the only one fond of it. I think this makes a nice specialization of the hash approach. However, I believe it will become cumbersome with anything other than trivial expressions. The hash approach, in that case, would be clearer. Tanton
Re: purge: opposite of grep
Ken Fox asked:
How about just
(@foo,@bar,@zap) := classify [ rx/foo/, rx/bar/, rx/zap/ ] @source;
and implement classify as a normal sub?
We could certainly do that. But let's call it C.
Et voilà:
sub part ($classifier, *@list) {
my &classify := convert_to_sub($classifier);
my @parts;
for @list -> $nextval {
my $index = try{ classify($nextval) } // next;
push @parts[$index], $nextval;
}
return @parts;
}
sub convert_to_sub ($classifier is topic) is cached {
when Code { return $classifier }
when Array {
my @classifiers = map {convert_to_code($_)} @$classifier;
return sub ($nextval) {
for @classifiers.kv -> $index, &test {
return $index if test($nextval);
}
return;
}
}
when Hash {
my %classifiers = map { convert_to_code(.key) => .value } %$classifier;
return sub ($nextval) {
my @indices = map { defined .key()($nextval) ?? .value :: () } %classifiers;
return @indices ?? any(@indices) :: undef;
}
}
default{ croak "Invalid classifier (must be closure, array, or hash)" }
}
But then the thousands of people who are apparently clamouring for this
functionality and who would have no hope of getting the above correct,
would have to pull in some module every time they wanted to partition an array.
> Why does everything have to be built into the first version of Perl 6?
Everything doesn't. Everything shouldn't be. Just the really common,
important stuff.
I have to confess though, there are *many* times I've wished for this particular
functionality as a built-in. Which is why I'm spending time on it now.
Damian
Re: purge: opposite of grep
Damian Conway wrote:
Et voilà:
Or, of those who prefer their code sanely formatted:
sub part ($classifier, *@list) {
my &classify := convert_to_sub($classifier);
my @parts;
for @list -> $nextval {
my $index = try{ classify($nextval) } // next;
push @parts[$index], $nextval;
}
return @parts;
}
sub convert_to_sub ($classifier is topic) is cached {
when Code { return $classifier }
when Array {
my @classifiers = map {convert_to_code($_)} @$classifier;
return sub ($nextval) {
for @classifiers.kv -> $index, &test {
return $index if test($nextval);
}
return;
}
}
when Hash {
my %classifiers = map { convert_to_code(.key) => .value } %$classifier;
return sub ($nextval) {
my @indices = map { defined .key()($nextval) ?? .value :: () } %classifiers;
return @indices ?? any(@indices) :: undef;
}
}
default{ croak "Invalid classifier (must be closure, array, or hash)" }
}
Damian
Re: purge: opposite of grep
[EMAIL PROTECTED] (Damian Conway) writes: > > Why does everything have to be built into the first version of Perl 6? > > Everything doesn't. Everything shouldn't be. Just the really common, > important stuff. > > I have to confess though, there are *many* times I've wished for > this particular functionality as a built-in. Which is why I'm > spending time on it now. This may be a useful distinction: stuff which is built into the language versus stuff which is shipped in the default libraries of the language. A categorise method would be just grand, and I think it should be shipped with the default Perl 6 array classes, but Perl 6 The Core Language wouldn't need to know about that particular method if it didn't want to. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: purge: opposite of grep
> push (/foo/ && @foo ||
> /bar/ && @bar ||
> /zap/ && @zap), $_ for @source;
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
> But perhaps...
>
> ( @foo, @bar, @zap) :=
> part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
Why not:
part ( @source, /foo/ => @foo, /bar/ => @bar, /zap/ => @zap );
or maybe:
@source -> /foo/ => @foo, /bar/ => @bar, /zap/ => @zap;
To end up with @foo entries being *aliases* of
entries in @source. Btw, could these be valid,
and if so, what might they do:
@source -> $foo, $bar;
@source -> @foo, @bar;
--
ralph
Re: purge: opposite of grep
Simon Cozens wrote: A categorise method would be just grand, and I think it should be shipped with the default Perl 6 array classes, but Perl 6 The Core Language wouldn't need to know about that particular method if it didn't want to. Err. Since arrays are core to Perl 6, how could their methods not be? Of course, as long as you can call C without explicitly loading a module, it's merely a philosophical distinction as to whether C is core or not. Damian
Re: purge: opposite of grep
ralph wrote:
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
True.
Why not:
part ( @source, /foo/ => @foo, /bar/ => @bar, /zap/ => @zap );
Because C, C, C etc all take the list they're
operating on as the last argument. And they do that for a very good reason:
so it's easy to build up more complex right-to-left pipelines, like:
(@foo, @bar) :=
part [/foo/, /bar/],
sort { $^b <=> $^a }
grep { $_ > 0 }
@data;
@source -> /foo/ => @foo, /bar/ => @bar, /zap/ => @zap;
Huh???
That's the equivalent of:
@source, sub (/foo/ => @foo, /bar/ => @bar, /zap/ => @zap);
which is just a syntax error.
To end up with @foo entries being *aliases* of
entries in @source. Btw, could these be valid,
Err. I very much doubt it.
Damian
Re: purge: opposite of grep
Damian Conway wrote:
> (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source;
If we're worried about the distance between the source and destination
when there are many tests, maybe:
part { /foo/ => @foo, /bar/ => @bar, /zap/ => @zap }, @source;
Or, 'long' formatted:
part {
/foo/ => @foo,
/bar/ => @bar,
/zap/ => @zap,
}, @source;
Assuming the type system can handle that. But people will forget the
comma before C<@source>, because it looks so similar to C. And
think of the { ... } as a code block, not a hashref. Pffft.
I keep thinking we're missing something here. This is just a
multi-streamed C, after all. It should be easy.
Was it ever decided what C would look like with multiple streams?
Maybe we could just use the stream delimiters in the C like we do
in C?
grep {
/foo/ -> @foo,
/bar/ -> @bar,
/zap/ -> @zap,
} @source;
???
MikeL
IMCC and constants?
Leo --
Here's the simple bench.jako example (again):
const int N = 100;
var int q = 1;
while (q < N) {
var int i, j, w = 1;
while (w < N) {
i++;
j += i;
w++;
#print("$q, $w\n");
}
q++;
}
I used to work harder in the Jako compiler to track constants
and substitute their values, but I figured thats the sort of
shared functionality IMCC would either have now or in future.
So, I've removed those smarts from jakoc (which has the added
benefit, IMO, of leaving symbolic constants symbolic in the
..imc file). Now, I generate the following IMC code for the
above Jako code:
.sub __MODULE__
.local int N # const int N = 100;
N = 100
.local int q # var int q;
q = 1 # q = 1;
.namespace WHILE_BLOCK
_W1_WHILE:
_W1_NEXT:ge q, N, _W1_LAST# _W1: while (q < N)
{
_W1_REDO:.local int i # var int i;
i = 1 # i = 1;
.local int j # var int j;
j = 1 # j = 1;
.local int w # var int w;
w = 1 # w = 1;
.namespace WHILE_BLOCK
_W2_WHILE:
_W2_NEXT:ge w, N, _W2_LAST# _W2: while (w <
N) {
_W2_REDO:add i, 1 # i += 1;
add j, i # j += i;
add w, 1 # w += 1;
_W2_CONT:branch _W2_NEXT # }
_W2_LAST:.endnamespace WHILE_BLOCK
add q, 1 # q += 1;
_W1_CONT:branch _W1_NEXT # }
_W1_LAST:.endnamespace WHILE_BLOCK
end
.end
(I'm still not making use of all the imcc language features)
You can see that as far as the generated IMC is concerned,
variables and constants are treated equivalently. I do track
the const-ness of the identifier to prevent Jako code from
trying to do "N = 5" when N was declared earlier as a constant.
The current IMCC converts the above to this:
__MODULE__:
set I4, 100
set I3, 1
_W1_WHILE:
_W1_NEXT:
ge I3, I4, _W1_LAST
_W1_REDO:
set I1, 1
set I2, 1
set I0, 1
_W2_WHILE:
_W2_NEXT:
ge I0, I4, _W2_LAST
_W2_REDO:
add I1, 1
add I2, I1
add I0, 1
_W2_CONT:
branch _W2_NEXT
_W2_LAST:
add I3, 1
_W1_CONT:
branch _W1_NEXT
_W1_LAST:
end
Which looks pretty good. Here we can see that IMCC does
not discover that I4 can be optimized away. Is that something
I should be expecting in forthcoming IMCC releases? Or, should
I go back to handling it in the Jako compiler?
I was thinking it might be nice to be able to do something like
this in the .imc file:
.local int N 100 # Constant implied by value after name
BTW, thanks for producing imcc. I'm very happy I don't have to
do register allocation anymore. The Jako compiler is still not
a work of art, but imcc is allowing me to incrementally remove
complexity (which I'm turning right around and re-adding in
other areas... :). And, thanks also for fielding my numerous
questions as promptly as you have!
Regards,
-- Gregor
I am that which is not everything else.
Re: purge: opposite of grep
Michael Lazzaro wrote:
If we're worried about the distance between the source and destination
when there are many tests
Are we? I'm not.
maybe:
part { /foo/ => @foo, /bar/ => @bar, /zap/ => @zap }, @source;
Or, 'long' formatted:
part {
/foo/ => @foo,
/bar/ => @bar,
/zap/ => @zap,
}, @source;
I really dislike the use of dative arguments (i.e. those that are modified
in-place by a function).
Besides, you can already write:
push (
/foo/ ?? @foo ::
/bar/ ?? @bar ::
/baz/ ?? @baz ::
[]
), $_ for @source;
Heck, even in Perl 5 you can write:
push @{
/foo/ ? \@foo :
/bar/ ? \@bar :
/baz/ ? \@baz :
[]
}, $_ for @source;
I keep thinking we're missing something here. This is just a
multi-streamed C, after all. It should be easy.
Famous last words. ;-)
Was it ever decided what C would look like with multiple streams?
for zip(@x, @y, @z) -> $x, $y, $z {...}
and its operator version:
for @x ¦ @y ¦ @z -> $x, $y, $z {...}
Maybe we could just use the stream delimiters in the C like we do
in C?
No. We gave up special stream delimiters in Cs,
in preference for general zippers.
Damian
Re: Usage of \[oxdb]
Nicholas Clark wrote:
Why not just:
"$(chr call_a_func()]"
???
Well, I was wondering if my function returned "CR", then
"\c[$(call_a_func())]" would mean that the "CR" gets run thought the
\c[...] conversion and a single byte ("\r") is what ends up in the string.
I seriously doubt it. %-)
Damian
Re: purge: opposite of grep
Ian Remmler decloaked and wrote: I'm not sure the meaning of the name C would be obvious > to someone who hadn't seen it before. What, as opposed to C or C or C or C or C or C or C or C or C or C or C or C or C or...? ;-) I keep thinking C would be nice, or maybe C. Just a thought... C is quite good. Though I still like C best. Damian
