Re: Auto My?
- Original Message - From: Luke Palmer [EMAIL PROTECTED] Date: Saturday, December 18, 2004 4:16 pm Subject: Re: Auto My? Rod Adams writes: There are pros and cons, and it basically ends up being a design choice. Well, at least when strictures are on. When they are off, the coder is obviously playing fast and loose, and should get the easy 'everything global' behavior. When strictures are on, the compiler ought to die if you're tyring to use a variable without declaration. This is another reason why Perl doesn't like autodeclaration. As bad of an idea that I think this is, I wonder if Perl6's reflection capabilities will be powerful enough to where a module/pragma could be written that would be able to do this? For instance, one idea was: lexically change the current grammar to a subclass of the grammar. In this subclass, there is a hook on the variable deparsing rule that will implictly declare a variable into its outer scope if it has not yet been declared in the current scope. Totally whacky, sure; but doable? That brings up another idea that I had just now: will it be possible to load 2 different grammars at once if they don't conflict with each other? For instance, say we have loaded a grammer, Grammar::WhackyVars, that subclasses from the main Perl6 grammar but modifies the variable rule somehow. However, then say I want to use a grammar that also subclasses from the main Perl6 grammar that lets you use happyfunactiontime instead of the word class. Since the modified rules don't conflict with each other, can I just use Grammar::HappyFunActionTime and everything will work? Or will Grammar::HappyFunActionTime overload the changes done by the Grammar::WhackyVars? - Joe
Re: Why do users need FileHandles?
I define outside the core as anything that isn't packaged with Perl itself. Things you'd define as part of the language. I/O stuff, threading stuff, standard types, builtin functions, etc. And yeah, most of that stuff will be written natively in C, PIR, or be part of parrot itself. I think there will also be a much larger standard library that will be bundled separately, which would contain your libwww, libnet, and other widely/commonly used modules. The way I think of it is kinda like installing something with the windows installer: you can check to install the minimal or standard version, the full version (which would be perl + the standard library), or you could even check custom and choose what you'd like to install. And, of course, everything else would just be on the CPAN. - Joe
Re: Why do users need FileHandles?
- Original Message - From: David Storrs [EMAIL PROTECTED] Date: Monday, July 19, 2004 5:04 pm Subject: Re: Why do users need FileHandles? Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. How would integrating this in the core make it more efficient? Core or not, I'd see something like this being implemented with a custom pmc. I tend to think of inclusion in the core being more of a philosophical decision... - Joe
Re: xx and re-running
- Original Message -
From: James Mastros [EMAIL PROTECTED]
Date: Sunday, July 18, 2004 5:03 am
Subject: xx and re-running
Recently on perlmonks, at
http://perlmonks.org/index.pl?node_id=375255,
someone (DWS, actually) brought up the common error of expecting x
(in
particular, listy x, which is xx in perl6) to not create aliases.
What
he was doing in particular, I don't have any expectation of making
it
work, but what about the also-common problem of C @randoms = (int
rand
100) xx 100 ? In perl5, this picks one random integer between 0
and
99, and copies it 100 times -- not what was intended. The best
way to
do this is C my @randoms = map {int rand 100} 0..100; , which is
rather yucky -- conceptually, you aren't trying to transform one
list
into another. OTOH, C my @randoms; push @randoms, int rand 100
for
0..100 is even yuckier.
Perhaps if the LHS of a xx operator is a closure, it should run
the
closure each time around... or perhaps there should be an xxx
operator.
(Both suggestions from BrowserUk's reply,
http://perlmonks.org/index.pl?node_id=375344). The former raises
the
question of what you do if you really want to repeat a coderef,
and the
later raises the possibly of being blocked (really), and starts to
become confusing -- the difference between x and xx is sensical --
the
former repeats one thing, the later many... but what's the
reasoning for
xxx, other then that it's like xx? How will users be able to
remember
which is which?=
When I think about your description of xxx, I
summarized it in my head as Call a coderef a certain
number of times, and then collect the results.
That's pretty much what map is, except that xxx is
infix and map is prefix.
@results = { ... } xxx 100;
@results = map { ... } 1.. 100;
Doesn't seem that special to me.
- Joe
Re: Why do users need FileHandles?
- Original Message - From: Dan Hursh [EMAIL PROTECTED] Date: Thursday, July 22, 2004 3:07 pm Subject: Re: Why do users need FileHandles? Luke Palmer wrote: JOSEPH RYAN writes: - Original Message - From: David Storrs [EMAIL PROTECTED] Date: Monday, July 19, 2004 5:04 pm Subject: Re: Why do users need FileHandles? Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. How would integrating this in the core make it more efficient? Core or not, I'd see something like this being implemented with a custom pmc. I tend to think of inclusion in the core being more of a philosophical decision... Yes, it is. Whether or not a PMC is in the core, it should be equally fast. That is, unless Parrot is allowed intimate knowledge of the PMC's internals. And there are very few (any?) PMCs that possess this property even now. Even more philosophical is what is core? I get the impression that Larry is trying to blur the distinction between core and non- core as much as possible. So making it go in the core may just mean that it's on the list of recommended modules to install. Luke How about we say in core means it packaged with the perl6 source and covered in the coresponding camel lama books. :) Well, that's what all of the ruckus is about. There is a strong leaning towards including *no* builtin modules with the core. So, that leaves only the builtin functions and classes as the core, and so what is in core becomes a pretty big deal. - Joe
Re: push with lazy lists
On Wed, Jul 07, 2004 at 11:50:16PM -0400, JOSEPH RYAN wrote: To answer the latter first, rand (with no arguments) returns a number greater than or equal to 0 and less than 1 which when used as an index into an array gets turned into a 0. As to why the second pop would take forever, I'd imagine that in order to pop the last item from the array, all of the elements must first be generated (i.e. we lose all laziness). And unless we have some magic for generating them from either end, it'll start at the begining and continue until the end, then stop before it ever does the pop. :-) Ah, right, I should known that, in both cases. (: Thanks for answering my silly questions. - Joe
Re: push with lazy lists
- Original Message -
From: Larry Wall [EMAIL PROTECTED]
Date: Wednesday, July 7, 2004 11:25 pm
Subject: Re: push with lazy lists
On Fri, Jul 02, 2004 at 09:32:07PM -0500, Dan
Hursh wrote:
: how 'bout
:
: @x = gather{
: loop{
: take time
: }
: } # can this be @x = gather { take time loop }
: push @x, later;
: say pop @x;# later
Can probably be made to work right.
: say pop @x;# heat death?
Yes.
: say @x[rand]; # how about now?
Well, that's always going to ask for @x[0], which
isn't a problem.
However, if you say rand(@x), it has to calculate
the number of
elements in @x, which could take a little while...
Why would the second pop be a heat death, and why
would rand always return 0?
- Joe
Re: push with lazy lists
- Original Message -
From: Dan Hursh [EMAIL PROTECTED]
Date: Friday, July 2, 2004 10:32 pm
Subject: Re: push with lazy lists
Joseph Ryan wrote:
I guess that's true with X..Y lazy lists. I
thought there were
other
ways to make lazy lists, like giving it a closure
that gets called
lazily to populate the list with the result's
being cached. I
can't
remember the syntax though. I think gather was
one way. Maybe
I'm just
remembering wrong.
Anyhow, I was thiking that was how X..Inf was
implemented. That
would
be foolish in this case.
how 'bout
@x = gather{
loop{
take time
}
} # can this be @x = gather { take time loop }
push @x, later;
say pop @x;# later
say pop @x;# heat death?
say @x[rand]; # how about now?
I'm a bit confused by your syntax, but I think I
understand what you mean. I was under the impression
that loops were not lazily evaluated, but essentially
run until they were broken out of. The advantage of
using an infinite list is just that you have an
iterator that never runs out.
Also, any list that contains and infinite list
becomes tied.
The container list's FETCH would change so that
any accessed index
that falls within the indexes owned by the
infinite list would
be dispatched to the infinite list. So, with a
list like:
@array = ('a','b','c',2..Inf,woops);
Elements 0, 1, and 2 would be accessable as
normal, but then
elements 3 through Inf would be dispatched to the
infinite list.
However, since woops's index is also Inf, and
that index is
owned by the infinite list, it would be
impossible to access it
except through a pop call (which doesn't look at
indexes at all).
I was wondering about lazy list where we don't
know how many
element it
might generate. Admittedly, I picked a poor
example. I would
right to
assume woops would also be accessable with
@array[-1], right?
Oh yeah, that would work too. :)
- Joe
Re: if not C, then what?
- Original Message -
From: David Storrs [EMAIL PROTECTED]
Date: Thursday, July 1, 2004 7:55 pm
Subject: Re: if not C, then what?
On Thu, Jul 01, 2004 at 04:14:37PM -0700, Jonathan Lang wrote:
Juerd wrote:
If you're really enamoured with the infix operator syntax,
consider this
possibility:
sub infix:- ($before, $after) {
$before; # is this line redundant?
return $after;
}
print $a - $b - $c; # prints $c
where C[-] is read as followed by. You could even set up a
right-to-left version, C[-], but why bother?
You could do this, but you'd be overriding the current meaning of
C - as pointy sub.
You could also use, 'before':
# Recipe for (un)holy water that will irk the altar's god.
step_on_altar();
drop_water($_) before pray() for @water_potions;
OOC, can you define an operator that is made up of alphanumerics, or
only punctuation? e.g., is this legal?
sub infix:before ( $before, $after ){ ... }
--Dks
Sure. The parser won't care what kind of characters
make up the operator, as long as its defined by the
time the operator is encountered. The operator
rules in the grammar will probably be as simple as this:
# where x is the type of operator; infix, prefix, etc
rule x_operator:u2 {
%*X_OPERATORS
}
- Joe
Re: push with lazy lists
- Original Message -
From: Dan Hursh [EMAIL PROTECTED]
Date: Friday, July 2, 2004 2:23 pm
Subject: push with lazy lists
Hi,
If I can assume:
@x = 3..5;
say pop @x;# prints 5
@x = 3..5;
push @x, 6;
say pop @x;# prints 6
say pop @x;# prints 5
What should I expect for the following?
@x = 3..Inf;
say pop @x;# heat death?
@x = 3..Inf;
push @x, 6;# heat death or
# an array with infinity + 1 elements?
say pop @x;# prints 6?
say pop @x;# heat death?
The way I understand the magicness of lazy lists, I'd expect:
@x = 3..Inf;
say pop @x; # prints Inf
@x = 3..Inf;
push @x, 6; # an array with the first part being
# lazy, and then the element 6
say pop @x; # prints 6
say pop @x; # prints Inf
say pop @x; # prints Inf
say pop @x; # prints Inf
# etc
The way I think of a lazy infinite list is kind of like a special object. It needs to
keep track of what the start is and what the end is. Every other element doesn't
actually exist, but is calculated based on the index of the
FETCH/STORE/SPLICE/whatever call.
Also, any list that contains and infinite list becomes tied. The container list's
FETCH would change so that any accessed index that falls within the indexes owned by
the infinite list would be dispatched to the infinite list. So, with a list like:
@array = ('a','b','c',2..Inf,woops);
Elements 0, 1, and 2 would be accessable as normal, but then elements 3 through Inf
would be dispatched to the infinite list. However, since woops's index is also Inf,
and that index is owned by the infinite list, it would be impossible to access it
except through a pop call (which doesn't look at indexes at all).
Actually, I think that this logic could apply to any array/list constructed with .. or
..., and an infinite list would just be a special case of that. It would definitely
be useful in cases like: @array = 1..20;
- Joe
Re: undo()?
- Original Message - From: Luke Palmer [EMAIL PROTECTED] Date: Tuesday, June 29, 2004 7:31 pm Subject: Re: undo()? Oh no! Someone doesn't understand continuations! How could this happen?! :-) You need two things to bring the state of the process back to an earlierstate: undo and continuations. People say continuations are like time traveling; I like to put it this way: Say you're in the kitchen in front of the refrigerator, thinking about a sandwitch. You take a continuation right there and stick it in your pocket. Then you get some turkey and bread out of the refrigerator and make yourself a sandwitch, which is now sitting on the counter. You invoke the continuation in your pocket, and you find yourself standing in front of the refrigerator again, thinking about a sandwitch. But fortunately, there's a sandwitch on the counter, and all the materials used to make it are gone. So you eat it. :-) A continuation doesn't save data. It's just a closure that closes overthe execution stack (and any lexicals associated with it; thus the I want a sandwitch thought). If things change between the taking and invoking of the continuation, those things remain changed after invoking. You could make the programmer specify which variables he wants delta data for, and then any *others* wouldn't keep it and wouldn't be undoable. use undo foo bar baz; # Or use the funny characters I can't type. my $foo++; $foo.undo(); # Undoes the increment. my $quux++; $quux.undo(); # Throws an exception or something. A much more useful way to do this would be: use undo $foo $bar $baz ; my $foo = 41; my $state = undo.save; $foo++; $foo.undo($state); # or perhaps $state.remember; Do you think it would be possible to implement Cundo with pure Perl6 using continuations? My intuition thinks it could, but my brain starts hating me when I start to think about it... It would definitely be a pretty neat module if it could be done though. P.S. That was a truly spectacular explanation of continuations. :)
Re: A stack for Perl?
- Original Message - From: Luke Palmer [EMAIL PROTECTED] Date: Tuesday, June 29, 2004 6:13 am Subject: Re: A stack for Perl? 1; $_='foo bar baz'; split; # @STACK now is (1, 'foo', 'bar', 'baz'); To boot, I can't think of a way to implement that in currently-defined Perl 6, which should scare you. I think it could be implemented by proxying the base Perl PMCs (or, alternatively, tying each class for each of the base types, or whatever). Then, in each FETCH equivalant, wanted() could be checked to see if the FETCHish call was made in void context. If so, the object could push itself onto @*STACK. So, I think it could be implemented in a module, which is probably a good thing, because seeing something like this in standard code would just be annoying. (Although, now that I think about it, @*STACK seems to just be the inverse of $_/@_/%_, so maybe @*STACK should be named @¯ :)
Fwd: Re: OO inheritance in a hacker style
Woops, sent it to the wrong list! - Joe Joseph Ryan wrote: Luke Palmer wrote: Austin Hastings writes: Hmm. The text and examples so far have been about methods and this seems to be about multi-methods. Correct me if I'm wrong ... You're wrong. Consider my example, where via single inheritance we reach a layered list of methods, each of which replaces the previous one in the namespace (parent.method superseded by child.method). This is not multi-dispatch -- the class of the object being dispatched determines the method -- but I want to modify the dispatch chain so that some upstream class' method is ignored. It's surely possible by modifying that class's DISPATCH. Whether it should actually be in the language is up for debate. I'd say that if you need to do this with any frequency whatsoever, you're not thinking about roles right. A good example might be in order... :-) Well, what if the two classes you want to inherit from weren't designed with roles in mind? For instance, there might be two CPAN modules that each have a dozen methods that you want to inherit, but they each have 1 that overlap whose conflict you want to easily resolve. Besides, the user is not thinking about XXX right sounds like we need to give a ++ to the pythonometer ;) - Joe
Re: OO inheritance in a hacker style
Dmitry Dorofeev wrote:
Hi all.
Sorry if this idea|question has been discussed or has name which i
don't know about.
snip
I'd like to write
Class myclass : a {
forget method area;
forget method move;
method put;
}
so methods getX, getY, size will be 'inherited'.
Methods 'area' and 'move' will be not present in myclass at all!
so $a = new myclass;
$a.area()
will return an error. At some level of inheritance methods area() and
move() may be reimplemented again if required.
At first, I thought Hmmm, I'm not sure if this will be useful.
Besides, what would happen in the case of multipile inheri...
Then, it hit me. A forget (or block, or something similar)
keyword would be great in clearing up confusion with multiple
inheritance.
For instance, in an example like:
class A {
method a_method {}
method common_method {}
}
class B {
method b_method {}
method common_method {}
}
class C is A,B { # Is that right, or am I too java-ed out?
method c_method {}
forget A::common_method;
# or maybe something like: block A::common_method
}
Class C would now have access to:
A::a_method, B::b_method, C::c_method, and B::common_method
Of course, roles are another great way to prevent confusion with
multiple inheritance. A good question would be whether something
like forget is useful in addition, or whether everyone should
just use roles. :)
- Joe
Re: Control flow variables
David Wheeler wrote:
On Tuesday, November 18, 2003, at 06:11 PM, Joseph Ryan wrote:
Not to be a jerk, but how about:
my $is_ok = 1;
for @array_of_random_values_and_types - $t {
if not some_sort_of_test($t) {
$is_ok = 0;
last;
}
}
if $is_ok {
yada() # has sideeffects...
}
Isn't that just:
for @array_of_random_values_and_types, 'ok' - $t {
when 'ok' { yada(); last }
last unless some_sort_of_test($t);
}
IOW, the topic is only 'ok' when all of the items in the array have
been processed, which in your code is what happens when
some_sort_of_test($t) returns a true value.
And also if @array_of_random_values contains 'ok'.
- Joe
Re: Nested modules
Luke Palmer wrote:
So, we can have :: in names, but that doesn't represent any inherent
relationship between the module before the :: and the one after. I
think this is an important thing to keep.
However, will it be possible to, for example, do:
module Foo;
module Bar { ... }
And refer to the inner module as, say, Foo.Bar.
Kinda like an inner class in Java?
A more interesting
concept, can one use variables as modules, like:
::($foo)::somefunc();
except dynamic?
(On a side note, that syntax doesn't seem right, although I can't
fathom what is...)
Or some awful thing like that?
And of course this would imply the existance of anonymous modules. Yay.
How... would that be useful? What would one use an anonymous
module for that they couldn't do with an anonymous class? I
thought a module was more of a compiletime distinction, while
a class was a runtime + compiletime (i.e. all encompassing)
one.
- Joe
Re: Nested modules
Damian Conway wrote: Larry wrote: This kind of behaviour is more useful for nested classes, I suspect, but it should certainly be available for nested modules as well. So, what's the difference between a module and a class, and why would you want dynamic namespaces? Isn't that something you'd use a class for? I'm a bit confused. (-: - Joe
Re: Apocalypses and Exegesis...
Jonathan Scott Duff wrote: On Thu, Aug 14, 2003 at 03:00:54PM +0100, Alberto Manuel Brand?o Sim?es wrote: On Thu, 2003-08-14 at 14:49, Simon Cozens wrote: [EMAIL PROTECTED] (Alberto Manuel Brandão simões) writes: The question is simple, and Dan can have the same problem (or him or Larry). I am thinking on a Perl 6 book in portuguese (maybe only a tutorial... but who knows). But that means I must write something which will work :-) Just a hint: don't try writing it and revising it as the language changes. I wrote a Perl 6 chapter for a book in December and it is now almost unusable due to the pace of change. Yes. That's why I'm asking :-) I can start looking to apocalypses and exegesis to have an idea of the structure and content, but not really write them. I would need a running prototype, too. And that's more difficult to find :) Well, you can always find prototypical pieces in perl 5. For instance, Perl6::Classes, Perl6::Currying, Perl6::Rules, etc. (note, you may have to pull that last one out of Damian's head :- There's also P6C (parrot/languages/perl6), but use with caution, as its pretty kooky. - Joe
