Re: new sigil
On 10/24/05, TSa <[EMAIL PROTECTED]> wrote:
> Does this capturing of the type into ¢T also involve runtime
> code template expansion? That is, if sametype(Int,Int) didn't
> exist it would be compiled on the fly for a call sametype(3,2)?
I think that's up to the implementation. From the language
perspective, no, it behaves as though it was compiled once. But an
implementation is free to instantiate the routine for various types
for optimization.
> Which brings up the question if ¢T will be allowed in multi defs?
Good question. I believe the ordering multi algorithm can be extended
to handle it, but I'll have to think about what it means.
> > So it's a type position thing if it can be. Good. (I wonder if,
> > since it's allowed in term position, we will come up with ambiguities)
> >
> > How about this:
> >
> > sub foo(c|T $x) {
> > my sub util (c|T $in) {...}
> > util($x)
> > }
> >
> > Is that c|T in util() a new, free type variable, or am I asserting
> > that the type of util()'s argument must be the same type as $x?
>
> I would guess there are two distinct ¢foo::T and ¢foo::util::T free
> type variables.
Hmm, yeah, that makes sense, but it can also be annoying. For
instance, in Haskell, I wrote this:
closure :: (Ord a) => (a -> [a]) -> [a] -> [a]
clsoure f init = closure' Set.empty init
where
closure' :: (Ord a) => Set a -> [a] -> [a]
closure' set [] = []
closure' set (x:xs) = ...
This gives me a type error on closure', because the inner "a" is
different from the outer "a". Incidentally, there is no signautre
that closure' can possibly have. So I was forced to leave off the
signature and let the type inferencer do the work. In this case it
would have been nice to have the variable carry over to inner clauses.
But letting that happen also has problems. You can't freely move code
around, because you depend on the type variables that were bound in
outer scopes. However, if the number of "type topicalizers" (as it
were) is small, then maybe that's okay.
> In the call of util($x) the type reference is handed
> or rebound down the call chain just like value refs. BTW, will there
> be a topic type ¢_, grammar type ¢/ and the exception type ¢! as well?
The topic type ¢_ is discussed in theory.pod. I don't see much use
for the others (there is no @/ or @!, for instance).
> What operations are available for type variables? E.g. ¢foo <= ¢bar could
> be the subtype relation. But what would ¢foo + ¢bar mean?
Nothing.
Perhaps ¢foo (+) ¢bar is a union type, but I don't think it should be.
Again, see theory.pod for formalisms of the difference between things
that are in type variables and the types you declare in the program.
Essentially the things that are in type variables are only
instantiable, concrete types, whereas the types you declare in the
program are more like interfaces. There is no concept of a subtype
in the concrete world; only in the interface world. But theory.pod
isn't gospel (yet ;-).
> Is ¢foo - ¢bar the dispatch distance?
Especially not since that concept doesn't exist anymore.
> Is the compiler obliged to separate type variables from value variables? Or
> does
>
>$foo = \¢bar;
>
> produce a type reference? How would that be dereferenced then? Is the type
> inferencer in the compiler automatically calculating a supertype bound
> for every expression? If yes, how is that accessable?
Hmm, don't know about that. Exactly how "first-class" are type variables?
Luke
check_progs is not portable
The subroutine check_progs defined in lib/Parrot/Configure/Step.pm is not portable (doesn't work on MSWin32). On MSWin32, the real filename of a program is prog.exe, prog.com, prog.bat or prog.cmd , so if -x 'prog' is not enough. This subroutine is currently used by config/inter/lex.pl & yacc.pl. I suggest the use of the module File::Which (see the attached patch). But I don't know if everybody is agree to depend of this module. François check_progs.patch Description: Binary data
Re: S04 default { } bug?
On 10/23/05, Ilmari Vacklin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> S04 says thus:
>
> The default case:
>
> default {...}
>
> is exactly equivalent to
>
> when true {...}
>
> However, that parses to:
>
> if $_ ~~ bool::true { ...; leave }
>
> Which is not executed if $_ is false, unless ~~ bool::true does
> something special.
Good catch. Given the discussions about given arglist pattern
matching, we may be able to make it:
when :(_) {...}
Or:
when -> _ {...}
And if not that, then this ought to work:
when ({ 1 }) {...}
(A nullary codeblock that is evaluated for truth).
Luke
[perl #37455] make hello fails
> [leo - So 23. Okt 2005, 12:25:29]: > > As Parrot_setup_args() is so far only used for passing 'output' to the > > exec runcore, I propose a quick fix. > > > > i. Do not use STRING register for passing options > > ii. Move interp->imc_info->output to interp->output_file and use > > interp->output_file for all uses of the 'output' option. > > or use interp->current_file (or rename that) - this is already marked > during DOD and otherwise unused. A global current_file doesn't make any > sense. The info is also covered by the debug PBC segment. In r9546 I have removed interp->imc_info->output, interp->current_file and usage of REG_STR(0). The output info in now in interp->output_file. Currently this is a plain 'const char *', but I could switch it to a 'STRING *'. So 'make hello' now creates 'examples/pasm/hello'. But execution still give a segfault. CU, Bernhard -- /* [EMAIL PROTECTED] */
2 of 3 TODOs done
Hi Nick, I've added a src test that shows iteration through a hash from C (t/src/hash.t #10) and disabled capturing SIGHUP, as mentioned on #parrotsketch. The other TODO [1] will take a bit of time. Currently the hash buckets are filled from right to left, which makes iteration not stable, when keys are added during iteration. Reversing the bucket fill direction will fix this, as extendending the hash bucket store will always happen towards right due to realloc(3). Would be great if someone could have a look at src/hash.c and reverse the fill direction of the bash bucket store (hash->bu.bs) and also the iteration direction. A distinct pointer to the bucket store (instead the current union) probably simplifies this task. Thanks, leo [1] Iterating through a hash should behave "reasonable" when keys are added (or even deleted) during iteration. It's not necessary that added keys are seen during iteration, but all keys, present before any changes, have to be visible during iteration.
Re: Perl 6 fears
I'll attempt to answer a couple of the Parrot fears. :-) "Doug McNutt" <[EMAIL PROTECTED]> wrote: I fear that Parrot will not come into widespread use until perl 6 is released. Parrot might not be ready to come into widespread use until Perl 6 is released - there's some stuff missing yet. But encouragingly, a number of people are working on compiling other languages to Parrot. The Ponie project covers Perl 5, there's quite a lot of work going on with a Tcl compiler, an Eiffel-like scripting language compiler is being developed and there's more. Personally, I'm working on translating .NET stuff into Parrot intermediate code (my thesis, though a good excuse to spend more time doing stuff on Parrot that's more generally useful). As a rocket scientist, who started before the first FORTRAN compiler was released, I like assembly language and the portability of the Parrot interpreter appeals to me. But perl magic cookies in an assembler? Will it ever fit into a 68HC11? Can it attract the attention of hardware manufacturers? I don't think the goal ever was to get Parrot implemented in hardware. From what I've heard about Sun's efforts to do this with their JVM, it doesn't work out too well. Yes, to some degree Parrot is a software CPU, but virtual machines for high level languages tend to deal with stuff that a software CPU doesn't. They provide support for much higher level stuff than hardware does (continuations, co-routines, objects, types). For common HLL features, making a large number of compilers deal with that kinda stuff isn't greatly efficient when you can implement it once in the VM. PMCs are an example of one of the things a HLL VM provides that a software CPU wouldn't. They're called Parrot Magic Cookies rather than Perl ones; the point of them is that they support an abstract set of operations that you could want to perform that are invoked via a v-table mechanism. This means that you can implement language specific behaviour for operations while still keeping inter-language operability. Hope this helps, Jonathan
For API changes, please update consumers when necessary
A question recently arose (about extend.c) about when it's OK to change a public API, or remove it as obsolete. Mostly I want to avoid surprise breakages. Not that I can eliminate them. (I suspect I'll be responsible for a good number of them. New lexical subsystem, anyone?) But for smaller things, let's try to keep to the rule of "You break it, you fix it": * If you change an API, it's up to you to make sure that consumers of that API in the Parrot subversion tree are updated. You can get the owner of the consuming code to do it, or you can get someone to volunteer to help you, or you can do it yourself, but if there's any question, the job is yours. So out-of-tree projects must keep up with API changes independently. Think of this as an incentive to have your favorite language in the Parrot tree. :-) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [PROPOSED PATCH] Generate src/extend.c
On Wed, Oct 19, 2005 at 09:59:15PM +0100, Nicholas Clark wrote: > I think the better solution is going to be to keep them in src/extend.c, > and auto-generate a second file for the vtable calls. So the version attached > generates src/extend_vtable.c I like that separation. > chromatic: > > I think the correct approach is to annotate vtable.tbl with more > > information -- including the documentation strings -- to make generating > > files easier. > > That seems reasonable. I like the idea of putting the docs together with the declarations. It'll kill the scannability of the file, though. I suppose that's what filters are for. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Perl 6 fears
Nate Wiger skribis 2005-10-24 10:44 (-0700): > The fact that there's not alot of active p5p'ers on this list should > alarm people more. I don't know about the other Perl 6 lists, are they as p5porterless? It does not alarm me that they are not *here*, this being a list where we mostly discuss the language. Perl 5's language is set in stone. It is inflexible, almost any conceivable change will be backwards incompatible in some way. P5p deals with implementation, and that too is mostly set in stone. Perl 5 has no detailed spec, so the implementation implicitly is the spec, which means that you can't just change something. We're very lucky to have some people here who care about both implementation and language. They form the bridge between the two. I personally care about the language, but not much about the implementation, as long as it gets implemented. What does alarm me is the number of people who are very familiar with Perl 5's language and guts, who hate Perl 6 and use every opportunity to whine about it. We cannot and probably should not do anything about this, but it is very alarming. It means that the Perl 6 community is not the same as the Perl 5 community is now. My take on that is that it is because Perl 6 is not a new version of Perl 5. I still think "Perl" is a misleading name, and mostly hurts the image of the language that is created here. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 fears
On 10/24/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Joshua Gatcomb wrote: > > On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote: > > > Feel free to add your own, or fears you heard about! > > > > FEAR: The Perl6 process is driving away too many good developers > > > > FEAR: Perl6 will not be as portable as p5 > > > > FEAR: Perl6 is un-necessary and the time, money, and resources is impacting > > p5. > > These are at the top of my list. Sooner or later big Perl advocates > (like myself) are going to look for other languages because the future > is too uncertain and unstable. > > Also, in terms of module rewriting: This is a massive effort. I don't > know if anybody's looked at the internals of stuff like Class::DBI and > its derivatives, but it's huge. I have. Module rewriting should be look at in terms of implementing something completely new to fit the current spec, at least in the beginning. Modules like CDBI are good because they have a lot of tests. So, you run the tests in P5 and have them access the P6 classes. Add new tests to test new P6-only features, like roles, and you're good to go. You don't need to read the internals to port the module. Plus, rewriting is going to happen over the space of 1-2 years, which is just fine. Remember, there's still Perl4 code out there, and that was over 10 years ago. In 10 years, there will still be Perl5 code out there, and it will run just fine on Parrot (and whatever other VMs are out there). This is the point I think you're missing - you can write pure native Perl5 in a Perl6 environment and call Perl6 modules, without a single issue. You can call Perl5 modules from Perl6 without a single issue. Everything else is icing. > The fact that there's not alot of active p5p'ers on this list should > alarm people more. Why? They're focused on Perl5, not Perl6, as it should be.
Re: Perl 6 fears
Joshua Gatcomb wrote: On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote: Feel free to add your own, or fears you heard about! FEAR: The Perl6 process is driving away too many good developers FEAR: Perl6 will not be as portable as p5 FEAR: Perl6 is un-necessary and the time, money, and resources is impacting p5. These are at the top of my list. Sooner or later big Perl advocates (like myself) are going to look for other languages because the future is too uncertain and unstable. Also, in terms of module rewriting: This is a massive effort. I don't know if anybody's looked at the internals of stuff like Class::DBI and its derivatives, but it's huge. The fact that there's not alot of active p5p'ers on this list should alarm people more. -Nate
Re: Perl 6 fears
On 10/24/05, John Macdonald <[EMAIL PROTECTED]> wrote: > On Mon, Oct 24, 2005 at 02:47:58PM +0100, Alberto Manuel Brandão Simões wrote: > > Another is because it will take too long to port all CPAN modules to > > Perl 6 (for this I suggest a Porters force-task to interact with current > > CPAN module owners and help and/or port their modules). > > I think Autrijus has the right idea that Perl 5 CPAN modules > should just work in Perl 6 without change. > > Just as Perl 6 is the community rewrite of Perl 5, moving > a module from CPAN to 6PAN should not be done as a hasty > make sure everything is moved over kind of event, but rather > should be done as a way of choosing the best features out of > the various Perl 5 modules on CPAN and peoples merging in the > experience people have gained from using them as well as the > experience people gain from *using* Perl 6. > > So, that is both good news and bad news - the good news is that > CPAN will be just as useful for Perl 6 right from the start; > the bad news is that the community rewrite of CPAN won't > happen overnight but could take as long for CPAN as it did > for Perl 6. (In fact, depending upon how you measure it, it > will take longer because some modules will never be rewritten, > but of course, those will be the modules that no-one feels a > sufficiently pressing need to rewrite; while for other modules, > the Perl 5 CPAN version will fit in well enough that there > is no urgency to convert it, even though it is being used, > until a few years done the road a rewrite allows additional > Perl 6/6PAN capabilities to be merged in.) I see modules being ported for a few reasons: 1) The module needs to be written in native P6 so that what was in XS now targets Parrot or the P6 grammars 2) Features are either easier or just plain old possible with P6. 3) The class is better written as a role. For example, having CGI written in Parrot ASM would be very nice. Having CGI written so that it's not as crufty would also be really nice. DBI being native P6 would be good. DBD's being roles that a DBI object does would be really nice. Rob
Re: new sigil
HaloO,
Luke Palmer wrote:
On 10/20/05, Larry Wall <[EMAIL PROTECTED]> wrote:
Another thing I didn't mention is that that binds both the variable
and its class. But the $ variable is of course optional after the
type, so you could just write that
sub sametype (¢T, ¢T) {...}
if you don't actually care about $x and $y. Basically, ¢T captures
the type of the associated scalar in any lvalue or declarative context,
whether or not hte scalar itself is captured.
Does this capturing of the type into ¢T also involve runtime
code template expansion? That is, if sametype(Int,Int) didn't
exist it would be compiled on the fly for a call sametype(3,2)?
Which brings up the question if ¢T will be allowed in multi defs?
And how does it influence dispatch then? Can type variables be
constrained with where clauses?
So it's a type position thing if it can be. Good. (I wonder if,
since it's allowed in term position, we will come up with ambiguities)
How about this:
sub foo(c|T $x) {
my sub util (c|T $in) {...}
util($x)
}
Is that c|T in util() a new, free type variable, or am I asserting
that the type of util()'s argument must be the same type as $x?
I would guess there are two distinct ¢foo::T and ¢foo::util::T free
type variables. In the call of util($x) the type reference is handed
or rebound down the call chain just like value refs. BTW, will there
be a topic type ¢_, grammar type ¢/ and the exception type ¢! as well?
What operations are available for type variables? E.g. ¢foo <= ¢bar could
be the subtype relation. But what would ¢foo + ¢bar mean? Is ¢foo - ¢bar
the dispatch distance? Is the compiler obliged to separate type variables
from value variables? Or does
$foo = \¢bar;
produce a type reference? How would that be dereferenced then? Is the type
inferencer in the compiler automatically calculating a supertype bound
for every expression? If yes, how is that accessable?
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: Perl 6 fears
I fear that, at age 70, I shall not live long enough to become efficient with perl 6. Two full years ago I purchased and read "Perl 6 Essentials". That lead me to this list which I have enjoyed but never felt competent to contribute much. Pretty much all of what I leaned in Essentials has been mucked with, or so it seems. I fear that Parrot will not come into widespread use until perl 6 is released. As a rocket scientist, who started before the first FORTRAN compiler was released, I like assembly language and the portability of the Parrot interpreter appeals to me. But perl magic cookies in an assembler? Will it ever fit into a 68HC11? Can it attract the attention of hardware manufacturers? -- --> Halloween == Oct 31 == Dec 25 == Christmas <--
Re: Perl 6 fears
On Mon, Oct 24, 2005 at 02:47:58PM +0100, Alberto Manuel Brandão Simões wrote: > Another is because it will take too long to port all CPAN modules to > Perl 6 (for this I suggest a Porters force-task to interact with current > CPAN module owners and help and/or port their modules). I think Autrijus has the right idea that Perl 5 CPAN modules should just work in Perl 6 without change. Just as Perl 6 is the community rewrite of Perl 5, moving a module from CPAN to 6PAN should not be done as a hasty make sure everything is moved over kind of event, but rather should be done as a way of choosing the best features out of the various Perl 5 modules on CPAN and peoples merging in the experience people have gained from using them as well as the experience people gain from *using* Perl 6. So, that is both good news and bad news - the good news is that CPAN will be just as useful for Perl 6 right from the start; the bad news is that the community rewrite of CPAN won't happen overnight but could take as long for CPAN as it did for Perl 6. (In fact, depending upon how you measure it, it will take longer because some modules will never be rewritten, but of course, those will be the modules that no-one feels a sufficiently pressing need to rewrite; while for other modules, the Perl 5 CPAN version will fit in well enough that there is no urgency to convert it, even though it is being used, until a few years done the road a rewrite allows additional Perl 6/6PAN capabilities to be merged in.) --
Re: Perl 6 fears
On 10/24/05, Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > > On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote: > > > > > >Feel free to add your own, or fears you heard about! > > This really isn't a fear as much as it is a complaint. It has to do with design decisions and the list. "Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite of Perl and of the community." - Larry Wall I think a lot of people that would contribute, myself included, are put off by the fact that it is nearly impossible to get a clear decision rendered on the list. Threads spin off tangents and typically end not in an answer, but in a loss of energy in trying to get back to the original question. My contribution to Perl6 has primarily been in advocation. I have contributed tests and code examples to Pugs as well as asked questions on the list. I would do more if getting answers was easier. Cheers, > Joshua Gatcomb > a.k.a. Limbic~Region >
Re: Perl 6 fears
On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote: > > > >Feel free to add your own, or fears you heard about! FEAR: Perl6 internals will be just as inaccessable as p5 FEAR: The Perl6 process is driving away too many good developers FEAR: Perl6 will not be as portable as p5 FEAR: Perl6 will not be able to fix the stigma of "just a scripting language" or "line noise" FEAR: Perl6 is un-necessary and the time, money, and resources is impacting p5. FEAR: There is too much misinformation surrounding Perl6 for people to feel comfortable. This last fear is likely the reason why you are collecting this list. I think the biggest problem is accessability and visibility for the casual observer. Unless you are devoted to the list and the IRC channels and the conferences your perception of what "is" and "isn't" Perl6 is out of date. We don't have a single source where people can go for relatively "up to the minute" facts concerning the project. Juerd Cheers, Joshua Gatcomb a.k.a. Limbic~Region
Re: JSON support
On Oct 23, 2005, at 6:44 PM, Leopold Toetsch wrote:
On Oct 21, 2005, at 18:07, Will Coleda wrote:
There is now rudimentary support for converting parrot objects to
JSON strings.
+ # generate a JSON representation of a PMC.
+ $S0 = _json( $P0 )
$P0 = new .Array
$P0[0] = $P0
et al, yada yada, ...
Anyway. library/Data/Dumper.imc has the same problem and uses a
hash to track PMC addresses. Parrot's builtin freeze code can of
course also deal with self-referential structures. I'm not sure
that a third (re-)implementation of "all almost the same" code is
really a Good Thing.
There is still another problem with deeply nested structures:
recursion and stack consumption, which is also handled in Parrot core.
Instead of reinventing quadratic wheels I'd rather like to have a
general VTABLE_dump method, which takes an extra structure
('dump_info' or such) and deals with:
pmc.dump
.repr
.to_json
.perl
.dunno_yet
It's in the same category as the freeze and thaw vtables, the
functionality is like the former one, except a visuable string is
created, details of it depending on further bits found in 'dump_info'.
I certainly agree that a centralized mechanism for this type of
action is desirable, and it would be silly not to reuse what code we
can. My primary concern here is that we provide an easy way to
register their code. For example, freezing to JSON is the same for
pretty much *every* array PMC type -- in the current implementation,
it's 100% identical. (I think *BooleanArray's should probably be
updated to use true/false for their values)
As long as the PMC class hierarchy permits strategic places to stick
our methods that inherit sanely, I'm all for that. An alternative
would be to upgrade "does" to actually provide methods, and be able
to use these as mixins. (which is actually closer to how JSON/Dumper
are implemented at the moment, they both key off 'does', but outside
the PMC.) This would involve making does a little less fluid than it
is now, but this is a good thing, IMO.
+ # generate a PMC from a JSON representation:
+ $P1 = _json_to_pmc( "[1,2,3]" )
+ #$P1 is now a array-like container PMC with three Integer
elements.
The question is of course, which type of PMC array?
Other concerns: see above - does JSON define to deal with self-
referential structs?
Already answered, not an issue for JSON. I'd be happy just passing
the recursion error, though with an addition to the freeze interface
to barf on self-referentials instead of handling them, we could
detect this earlier and generate a nicer exception.
Out of curiosity, do you expect to reuse any code for generic
thawing? I would expect that in general you're going to have most of
that in a central location rather than spread out over various vtables.
I don't have any objections against JSON - more the opposite of it.
I really like to have a "standard" interface to create e.g. static
PMC constants from strings, and actually such code is already used
inside Parrot to implement the argument passing opcodes.
Just my 2 ç
leo
Regards.
Re: JSON support
Leopold Toetsch wrote: > >> + #$P1 is now a array-like container PMC with three Integer elements. > The question is of course, which type of PMC array? The answer is surely, the array-type of the current HLL (as returned by Parrot_get_ctx_HLL_type). > does JSON define to deal with self-referential structs? JSON is a very simple specification that does not handle self-referential structures. I've already wrapped Will's JSON code in an Amber class and am using it for debugging output. I'm planning to use JSON later to initialize constants from strings. For sure, Parrot's various serialization libraries could be generalized, and the common stuff factored out. But in the meantime, the JSON lib is useful. Regards, Roger Browne
Re: Perl 6 fears
Christian Renz skribis 2005-10-24 15:31 (+0200): > >Feel free to add your own, or fears you heard about! > Fear: Perl 6 will not attract enough interested developers and > companies to gain momentum. People will continue to be excited about > digital watches and PHP 5. That's already expressed in: FEAR: Perl 6 will not be used as much as Perl 5 was! Also, I'd like to keep the fear descriptions short :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 fears
Christian Renz wrote: Feel free to add your own, or fears you heard about! Fear: Perl 6 will not attract enough interested developers and companies to gain momentum. People will continue to be excited about digital watches and PHP 5. I think Perl 6 will take time to insterest developers. One of the main reasons is because it is taking too long (not blaming, just stating). Another is because it will take too long to port all CPAN modules to Perl 6 (for this I suggest a Porters force-task to interact with current CPAN module owners and help and/or port their modules). Meanwhile, I think Perl 6 includes some amazing features people are waiting for. A lot of current perl hackers will love to start using it. But stability is important, and companies will wait before using it. I know you all know this, but I though it was good to state it again. Cheers Alberto -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal As traduções são como as mulheres. Quando são fieis, não são boas. Quando são boas, não são fieis.
Ways to add behavior
I'm mentally going over the ways to do it.
class Foo;
# the perl5 way
use base <>;
sub new {
my $class = shift;
my $self = $class.SUPER::new(@_); # syntax?
return $self;
}
sub do_it {
my($self, $arg) = @_;
say "doing $arg!";
}
class Foo is Base {
# the perl6 way
method do_it(String $arg) {
say "doing $arg!";
}
}
# add behavior through multi-dispatch
multi sub do_it(Base $x, String $arg) {
say "doing $arg!";
}
# behavior via mixin
my Base $x does role {
method do_it($arg) {
say "doing $arg!";
}
};
# behavior through prototype -- guessing realistic syntax
Base.meta.add_method(
do_it => method ($arg) {
say "doing $arg!";
});
# or, just add it to a single instance
$x.meta.add_method(
do_it => method ($arg) {
say "doing $arg!";
});
Did I miss any good ones? Or bad ones? :)
Ashley Winters
Re: Perl 6 fears
Feel free to add your own, or fears you heard about! Fear: Perl 6 will not attract enough interested developers and companies to gain momentum. People will continue to be excited about digital watches and PHP 5. Regards, Christian -- [EMAIL PROTECTED] - http://christian.web42.com - http://www.web42.com/crenz/ "If God were a Kantian, who would not have us till we came to Him from the purest and best motives, who could be saved?" -- C.S. Lewis, The Problem of Pain
Re: Perl 6 fears
Daniel Hulme skribis 2005-10-24 9:00 (+0100): > FEAR: I will need a lobotomy before I can make sense of Perl 6! This falls under "hard to learn". Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
S04 default { } bug?
Hi,
S04 says thus:
The default case:
default {...}
is exactly equivalent to
when true {...}
However, that parses to:
if $_ ~~ bool::true { ...; leave }
Which is not executed if $_ is false, unless ~~ bool::true does
something special. Perhaps default should be equivalent to:
when $_ { ... }
That is, $_ is always $_, so the block is always executed.
(It also strikes me that using booleans in when clauses could/should be
disallowed entirely.)
--
Ilmari Vacklin
(wolverian)
Re: Perl 6 fears
Here is my part. On Oct 24, 2005, at 07:20 , Juerd wrote: I've created pugs/docs/quickref/fears, a list of Perl 6 fears. Feel free to add your own, or fears you heard about! [snip] : FEAR: Perl 6 has too many operators! FEAR: Perl 6 has so many operators that it runs out of Unicode character repertoire :) # Time to learn (Hanzi|Kanji) for that? : FEAR: I will never be able to type Unicode ops! FEAR: I will need to hack an input method just to type those ops! : FEAR: Unicode ops cannot be read by me! FEAR: Unicode ops cannot be read by the compiler! : FEAR: Perl 6 will be too much like Haskell! Perl 6 will be too much like Ruby! # IMHO it already is and I love it! : FEAR: Perl 6 is made for big programs, not for oneliners and short : scripts! FEAR: Unicode ops of Perl 6 ought to make short scripts easier but how the heck can I type in those on shell? Dan the Perl 6 User -- Whatever that Means
Re: Perl 6 fears
> The current list of fears is: You don't include my personal fear. FEAR: I will need a lobotomy before I can make sense of Perl 6! -- Stop the infinite loop, I want to get off! http://surreal.istic.org/ Paraphernalia/Never hides your broken bones,/ And I don't know why you'd want to try:/ It's plain to see you're on your own.-- Paul Simon The documentation that can be written is not the true documentation.
Re: new sigil
On Sat, 22 Oct 2005 [EMAIL PROTECTED] wrote: If we find a lot of yen signs as zip-operators in the standard library, Japanese would have a big question: "Give up either Perl6 or Windows. Which do we need?" And I suppose the answer Hmmm, begins to sound interesting... ;-P Michele -- voices you're letting voices tell you what to do when you yourself don't know - Pennywise, "Come Out Fighting".
Re: wxParrot -- linking problems
Hi! > I like the idea of leveraging the wxPerl XS files. Any comments on why > you introduced xsubppp (on top of xsubpp) for some XS files? XS++ is much less verbose than plain XS when writing C++ code [1], and it allows me to handle some C++ features (like passing/returning references) without having to use CODE: blocks. Note that since xsubppp is just a XS++ -> XS translator, it should be possible to just ignore its existence when writing an XS -> Parrot translator. Regards Mattia [1] just compare any .xsp file with the output of running xsubppp.pl
Re: Accessing parrot functions/PMCs with Pugs
eval("print 1", :lang)
require_parrot 'foo.pir';
Would it also be possible to somehow 'link' it with a parrot bytecode
file?
Regards,
Christian
--
[EMAIL PROTECTED] - http://christian.web42.com - http://www.web42.com/crenz/
"The computer should be doing the hard work. That's what it's paid to
do, after all." -- Larry Wall
Re: wxParrot -- linking problems
Ciao Mattia, thanks for your reply. I read a bit about ABI and I guess it's something I only want to touch with a long pole, that pole being an extra layer of indirection I initially hoped to be able to avoid. I like the idea of leveraging the wxPerl XS files. Any comments on why you introduced xsubppp (on top of xsubpp) for some XS files? Regards, Christian -- [EMAIL PROTECTED] - http://christian.web42.com - http://www.web42.com/crenz/ "So, who am I to disagree with God? :-)" -- Larry Wall
