Re: new sigil
On 10/25/05, Eric <[EMAIL PROTECTED]> wrote:
> I would just like to mention that 'class' is confusing because you
> don't realy mean class there. The whole conversation is about types
> so why not have it be 'type'?
If you read the introduction to theory.pod[1], you'll find that we are
actually talking about classes. First, let me define what I mean:
class: A concrete, instantiable type. Each value has exactly one of these.
type: A behavioral interface. Each value probably has more than
one of these.
One of the big ideas behind theories is that you can never write the
name of a class in your program... ever. The only way you can talk
about classes is through variables with constraints. So, when I say:
sub foo(Int $bar) { $bar + 1 }
I actually mean:
sub foo(¢T $bar where ¢T (in) Int) { $bar + 1 }
(Which is pseudosyntax)
That is, foo accepts any *class* which obeys the Int *type*. That's
the most specific you can get.
> BTW didn't you contradict your own real world usage of type1^type2 ?
> Even if we use ^ as a sigil why would it get confused on that? I
> don't think type1 ^type2 could have any realy meaning so it should be
> easy for the parser to know the difference.
Yeah, I didn't really follow his argument on that one. I, too, think
that the one() junction in general is silly, especially for types.
When you say Dog^Cat, you're saying "I want something that either
conforms to the Dog interface or the Cat interface, but *definitely
not both*!" Why the heck would you care about that? Does there
really arise a situation in which your code will be erroneous when the
variable conforms to both interfaces?
And in fact, its very existence defies another implicit principle of
mine, that is, the "principle of partial definition": Defining a new
type or instance can only break a previously typechecking program by
making it ambiguous. The idea behind that is that at some time you
may realize that oen of your types already obeys another type, and
declare that it conforms to that interface. But you don't go the
other way around, undeclaring that an interface holds, without your
program having been erroneous in the first place. Declaring that a
new interface holds (so long as it actually does) shouldn't break
anything that was already correct.
The principle also has strong implications with library code:
including a new library but doing nothing with it shouldn't start
randomly breaking stuff. (Unless, of course, it breaks the rules and
does crazy stuff, in which case anything goes)
Luke
[1] I'm still thinking in terms of this proposal. If it turns out to
be wrong, disregard my comments.
Re: new sigil
On 10/25/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 26, 2005 at 01:17:10AM +0200, Juerd wrote:
> : Larry Wall skribis 2005-10-25 15:51 (-0700):
> : > ^T would still have to be a placeholder variable.
> :
> : Which it is, in a way.
>
> Though we don't currently allow placeholders in ordinary sigs, or even
> in conjunction with ordinary sigs.
>
> : Still, I don't think ^ as a sigil needs to mean the same thing as ^ as a
> : twigil. Visually similar pairs are also not related:
> :
> : ?foo$?foo
> : *foo$*foo
> : +foo$+foo
> : =foo$=foo
> :$
> True, though it would be the first time we used the same character as
> both a sigil and a twigil. ^^T would certainly be a placeholder
> in that case, but that might be confusing.
>
> : I think that it would help, and in different ways, even, to see ¢ as a
> : prefix operator with special syntax, instead of as a sigil. It doesn't
> : fit well in the list of sub, hash, array, scalar.
>
> But then you can't have ¢*T, ¢+T, ¢^T, ¢?T, ¢.T, etc.
>
> By the way, the meaning of the + twigil just changed. Last week it
> meant "The $? of the currently compiling unit". That's been taken
> over by the COMPILING::<$?foo> notation, partly because I wanted to
> steal $+ for generalized "environment" variables, that is, dynamically
> visible lexicals, such as $_. See
>
> http://svn.perl.org/perl6/doc/trunk/design/syn/S02.pod
>
> I've also checked in various changes to
>
> http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod
>
> [Everyone please remember to start new threads for unrelated topics.]
>
> : Making it a prefix op would allow whitespace after it, which would make
> : the "class" keyword not seem so desperato. (I think it's a bad keyword
> : for this, and picking ^ instead would render it unnecessary, but more
> : about why I think "class" is bad for this in a later post.)
>
> Let's delete "sub" too while we're at it. :-)
>
> I'm not stuck on "class" as the ASCII workaround. It's not quite the
> same as "sub" since we don't allow "sub X" everywhere we allow "&X".
>
> : > And it might conflict with infix ^ if we ever allow xor'ed types,
> : > since declarations contain lots of things that look like juxtaposed
> : > terms.
> :
> : Is this the same "conflict" that occurs in %foo % %bar?
>
> Nope. Normal expressions always know whether they're expecting a term
> or operator. I'm talking about in signatures where (it seems to me)
> terms are juxtaposed to mean "and", and the available operators
> can only be ones that can't be confused with a term prefix or zone
> marker. We actually had that problem back when we had junctional
> types:
>
> T1&T2
>
> Is that a sub T2 returning a T1?
>
> T1 &T2
>
> Or is a type constraint that must match both types?
>
> T1 & T2
>
> Currently we've said that such junctions should be down in a "where"
> clause, but it would be nice to leave the door open for
>
> Int|Str
>
> type constraints. But it's somewhat problematic to have a junctional
> return type, so maybe that will never happen, and the most complicated
> thing we'll see (in the absence of where clauses and subsignatures),
> is
>
> sub foo (Mammal ¢T $fido)
>
> In that case ^ or | could be forced to work. But I'd still rather use
> something that doesn't shout "operator", especially if the notation can
> sneak into rvalue code. And I'd prefer to leave the ASCII characters
> available for real operators and metaoperators later.
>
> : (I cannot imagine needing a one() junction for types, by the way. If
> : someone can come up with a good real-life example, please do so.)
>
> Oh, that's easy, for some definition of "real". In real life, cats and
> dogs don't overlap, so if you say Cat|Dog, you really mean Cat^Dog.
> But these junctional types are only good for constraints. A given
> object may only have a set of types, not a junction of types.
>
> Larry
>
I would just like to mention that 'class' is confusing because you
don't realy mean class there. The whole conversation is about types
so why not have it be 'type'? On the whole i think ^ makes good sense
and looks pretty good. It also meets the needs of being a single
letter, not already being a sigil, etc. 'class ' is no longer a
twigil and leads to the confusing reasoning you had about where it
needs class and where it doesn't\
sub test (^T $x) {
my ^T $y = $x + 5;
}
Is pretty easy and straight forward. With class i can't figure and
obvious DWIM.
sub test (class T $x) {
my class T $y = $x + 5;
}
That doesn't look right because you have 'my class' so you would think
the type is 'class' except the type isn't class, its T. If you
bareword T then it might overlap (collide) with a real class named T.
In the following case it is not clear wether Dog is defined in the
signature, or a realy seperate class.
sub test (class Dog $x) {
my Dog $y = $x + 5;
}
The same example with ^ becomes much clearer to me.
sub test
Re: new sigil
On Wed, Oct 26, 2005 at 01:17:10AM +0200, Juerd wrote: : Larry Wall skribis 2005-10-25 15:51 (-0700): : > ^T would still have to be a placeholder variable. : : Which it is, in a way. Though we don't currently allow placeholders in ordinary sigs, or even in conjunction with ordinary sigs. : Still, I don't think ^ as a sigil needs to mean the same thing as ^ as a : twigil. Visually similar pairs are also not related: : : ?foo$?foo : *foo$*foo : +foo$+foo : =foo$=foo :$ notation, partly because I wanted to steal $+ for generalized "environment" variables, that is, dynamically visible lexicals, such as $_. See http://svn.perl.org/perl6/doc/trunk/design/syn/S02.pod I've also checked in various changes to http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod [Everyone please remember to start new threads for unrelated topics.] : Making it a prefix op would allow whitespace after it, which would make : the "class" keyword not seem so desperato. (I think it's a bad keyword : for this, and picking ^ instead would render it unnecessary, but more : about why I think "class" is bad for this in a later post.) Let's delete "sub" too while we're at it. :-) I'm not stuck on "class" as the ASCII workaround. It's not quite the same as "sub" since we don't allow "sub X" everywhere we allow "&X". : > And it might conflict with infix ^ if we ever allow xor'ed types, : > since declarations contain lots of things that look like juxtaposed : > terms. : : Is this the same "conflict" that occurs in %foo % %bar? Nope. Normal expressions always know whether they're expecting a term or operator. I'm talking about in signatures where (it seems to me) terms are juxtaposed to mean "and", and the available operators can only be ones that can't be confused with a term prefix or zone marker. We actually had that problem back when we had junctional types: T1&T2 Is that a sub T2 returning a T1? T1 &T2 Or is a type constraint that must match both types? T1 & T2 Currently we've said that such junctions should be down in a "where" clause, but it would be nice to leave the door open for Int|Str type constraints. But it's somewhat problematic to have a junctional return type, so maybe that will never happen, and the most complicated thing we'll see (in the absence of where clauses and subsignatures), is sub foo (Mammal ¢T $fido) In that case ^ or | could be forced to work. But I'd still rather use something that doesn't shout "operator", especially if the notation can sneak into rvalue code. And I'd prefer to leave the ASCII characters available for real operators and metaoperators later. : (I cannot imagine needing a one() junction for types, by the way. If : someone can come up with a good real-life example, please do so.) Oh, that's easy, for some definition of "real". In real life, cats and dogs don't overlap, so if you say Cat|Dog, you really mean Cat^Dog. But these junctional types are only good for constraints. A given object may only have a set of types, not a junction of types. Larry
Re: $_ defaulting for mutating ops
On Tue, Oct 25, 2005 at 02:51:35PM +0200, Juerd wrote:
: For comparison, here is the same code snippet again. First with, and
: then without explicit $_.
:
: With:
:
: given ($subject) -> $_ {
: $_ ~~ s/foo/bar/;
: $_++;
: $_ x= 2;
: $_ ~= "!";
: }
:
: Without:
:
: given ($subject) {
: s/foo/bar/;
Already the default.
: ++;
Can already use .++ there. That's because you can already use . on
any postfix operator, and since any . form defaults to $_, you get
.++ for free. I'll let you have .-- as well. And .! if you define
factorial. :-)
It would be possible to extend . to allow any infix plus its right argument
to be treated as a postfix, presuming there wasn't already a postfix of
that name. However...
: x= 2;
That might validly parse as assignment to an lvalue sub: x() = 2;
Unfortunately .x= 2 doesn't work either, since we also have lvalue
methods. Actually, x=2 should parse as x(=2), since a list operator
always expects a term next. Yes, we *could* throw all the infix
operators into the prefix pot and match them under longest-token, but
the basic problem with the proposal is rampant term/operator confusion.
What should the lexer do when it sees a statement starting with
/=*/
%=POD.say
*=$*IN
+=<>
Those could get away with
./= 2
.%= 2
.*= 2
.+= 22
But then you're only saving a character (and maybe a space) over $_.
: ~= "!";
That would validly parse as
~(="!")
: I think the latter is more elegant, without reducing legability or
: maintainability. I also think that the code is immediately obvious, even
: to people coming from Perl 5, who never read this thread.
I think you're relying on those people using whitespace to dwym,
but unfortunately people chunk things differently from computers.
And most people will be uncomfortable if the computer uses whitespace
to guess, more so because it's doing lookahead to find that whitespace.
And are you ready to disallow patterns that start with '='?
And basically I don't think people want to mutate $_ with math operators
all that often--and if they do want to, they probably don't. :-)
Larry
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
On Tue, Oct 25, 2005 at 11:49:33PM +0100, Jonathan Worthington wrote: > If people have free time to spend on configure stuff, might it not be > better spent working on the real configure system that we want to have > (e.g. a set of makefiles for each platform to build miniparrot, then > configure is a Parrot program run by miniparrot that figures stuff out that > we need to build the full Parrot)? Perhaps this is just me being navie but I had imagined that some form of the existing Configure system would live on as PIR/PBC that included with the distribution to executed by miniparrot. Someday we will be be able to compile perl5 to PIR, right? Or even p5 -> p6 -> PIR. ;) Cheers, -J -- pgpFdGquVQoqq.pgp Description: PGP signature
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
On Tue, Oct 25, 2005 at 10:19:50PM +0100, Nicholas Clark wrote: > On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote: > > > i've started developing a plugin architecture for $work, so i've been > > thinking about plugin engines lately. if you're up for working on a > > redesign, i'll gladly pitch in. even if you're looking only to clean > > it up, i'd certainly appreciate the effort. It's outright nasty. > I've used Module::Pluggable, and liked it. Anything would be an improvement. ;) -J -- pgphQLnMKMruD.pgp Description: PGP signature
Re: Perl 6 Summary for 2005-10-10 through 2005-10-24
"Matt Fowles" <[EMAIL PROTECTED]> wrote: =head3 Obsolete Win32 Exports Michael Walter found and removed some obsolete Win32 Exports. Jonathan Worthington applied the patch. Weren't we planning on auto generating these? The Plan is to mark functions that are to be exported with something that we'll #define to be the export directive on Win32, thus rendering the .def file as un-needed. However, before that's done we should really decide on what functions Parrot extension writers should be allowed access to, e.g. as part of the extension API. That's a design decision. I popped it in the ROADMAP, so it will be decided at some point. =head3 Leaky Parrot Alberto Simões is having trouble with Parrot leaking memory and a bad free. Warnock applies. The bad free was fixed by the patch I provided Alberto to try out (see below), though there are still lots of memory leaks that would be good to fix up. =head3 Fighting with a Tiger Alberto Simões was having troubles with Tiger. Jonathan Worthington provided a little C wizardry, and Alberto was happy. He asked to have the patch applied, but Warnock did instead. I did apply it. I thought I'd posted to the list that I'd applied it. I may be incapable of using an email client too. ;-) =head3 Debug Segments Jonathan Worthington announced that he was making progress on his debug segment work, but would soon half to dive into IMCC. As a slight corollary all existing PBCs were invalidated. I dived into IMCC. I'm survived the experience and did what was needed in there, though I think maybe my post about that was missed in the summary. I've got just a couple of small things to clear up now, but otherwise the PASM/PIR debug seg stuff is about done. Next up: HLL debug segs. Thanks for the summary, Jonathan
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
On Oct 26, 2005, at 0:49, Jonathan Worthington wrote: If people have free time to spend on configure stuff, might it not be better spent working on the real configure system that we want to have (e.g. a set of makefiles for each platform to build miniparrot, then configure is a Parrot program run by miniparrot that figures stuff out that we need to build the full Parrot)? Exactly. The more that a lot of stuff [1] currently handled by Configure could be done either by the Makefile or just much later for languages/*. Cleanup is very much welcome, as well as to revive miniparrot (the real one). [1] creation of various runtime/parrot/include/*.pasm comes to my mind Just a thought, Jonathan leo
Perl 6 Summary for 2005-10-10 through 2005-10-24
=head1 Perl 6 Summary for 2005-10-10 through 2005-10-18 All~ Welcome to another Perl 6 Summary. Sadly, this week's summary is not brought to you by cookies as I already finished them. Sadder still, it is also brought to you a week late. On the plus side, Mike Doughty's "Haughty Melodic" is quite good. =head2 Perl 6 Compilers This was a shockingly high volume fortnight for p6c with 5 different threads on it! =head3 Feather: A Retrospective Juerd thought that now would be a good time to evaluate the usefulness of feather to the community. Warnock applies, but he probably found answers off list... http://groups.google.com/group/perl.perl6.compiler/browse_frm/thread/f14d8337b681d4a9/c95fc3fdf6d46f5b#c95fc3fdf6d46f5b Google Groups : perl.perl6.compiler =head3 PGE Better, Stronger, Faster Patrick announced "significant internal updates" to PGE. It looks like things are coming along very nicely. Yay, Patrick! http://groups.google.com/group/perl.perl6.compiler/browse_frm/thread/10bff9a3100902a5/7135f5627205f9ca#7135f5627205f9ca Google Groups : perl.perl6.compiler =head3 PGE Now With Better Balance Patrick also announced the subrule C which is similar to C from Perl 5. Now where, did I put my darn push-down automata. http://groups.google.com/group/perl.perl6.compiler/browse_frm/thread/b52eb566b1b74920/19e4709aa8d2ecd6#19e4709aa8d2ecd6 Google Groups : perl.perl6.compiler =head3 Object Space Thoughts Stevan Little posted some of his thoughts about how the meta-model can be built up from run time primitives. It is pretty neat. http://groups.google.com/group/perl.perl6.compiler/browse_frm/thread/e97984486b61828b/f34b165f8a919dcf#f34b165f8a919dcf Google Groups : perl.perl6.compiler =head3 Parrot PMCs within Pugs Christian Renz wondered how to get at Parrot's PMCs from Pugs. Autrijus admitted that that feature was not currently available, but offered a commit bit and suggested that adding tests would be a good start. http://groups.google.com/group/perl.perl6.compiler/browse_frm/thread/2f09e7c0503ea02f/d200cbd33f975d1d#d200cbd33f975d1d Google Groups : perl.perl6.compiler =head2 Parrot =head3 README.win32 Michael Cartmel fixed a few spelling errors in README.win32. Joshua Hoblitt applied the patch. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/38ef8ca32b5fab74/f5fdce20a19d50a9#f5fdce20a19d50a9 Google Groups : perl.perl6.internals =head3 parrot-config.imc Documentation Roger Browne offered a patch fixing documentation in parrot-config.imc. Warnock applies. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/2d86e5015608cb9e/43969cc2f25a0f7b#43969cc2f25a0f7b Google Groups : perl.perl6.internals =head3 Train Parrot to Flex In the RT clean up, an old ticket has resurfaced. Parrot needs to be updated to use flex 2.5.31, which is incompatible with 2.5.4. Patches welcome. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/8dc8adf441fa6805/f24be3c94a3dfba7#f24be3c94a3dfba7 Google Groups : perl.perl6.internals =head3 Dynamism Defeats Static Analysis Patrick and I had a brief back and forth about detecting PGE recursion. The short answer is that it is possible in the static case, but not in the face of changing rules. Stupid halting problem, where did I put my PDA. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/b08ed4ac97e3090c/d934e5866bdc9a43#d934e5866bdc9a43 Google Groups : perl.perl6.internals =head3 void function return Will Coleda is tired of special casing void functions and wants C<() = function()> to be legal in PIR. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/c7e54dc1d2b887a9/74dcbe2b279de204#74dcbe2b279de204 Google Groups : perl.perl6.internals =head3 Bison >= 1.75c Joshua Hoblitt noticed that the newer Bisons have slightly different error messages than older ones. He felt that we should either standardize on the newer bison or explicitly declare error messages. No official ruling on which... http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/79e9151802ec9185/c9d1a7dd3236d16b#c9d1a7dd3236d16b Google Groups : perl.perl6.internals =head3 __set_pmc_keyed_* Patrick needed a way to distinguish C<__set_pmc_keyed_int> from C<__set_pmc_keyed>. Leo gave it to him. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/e8f0cf140b05669a/9a125b4a7524b9f2#9a125b4a7524b9f2 Google Groups : perl.perl6.internals =head3 HLL type mappings Roger Browne wondered how he could set HLL type mappings from PIR. Leo said it was not yet implemented or speced. Roger suggested adding a few opcodes. http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/5f6e488e14b5b859/39be8e39b16b9d71#39be8e39b16b9d71 Google Groups : perl.perl6.internals =head3 s/\@(directive)/:$1/g Jonathan Scott Duff submitted a patch which swapped @directives to :directives everywhere. Leo applied most of it in several smaller patches. Language maintainers
Re: [perl #37512] [PATCH] Adds nci support for 'T' and 'L' prototypes
On Oct 25, 2005, at 23:32, Nick Glencross wrote: I was looking at callbacks the other evening. Am I right in thinking that only two callback prototypes are supported, or have I missed a trick there as well? That's right. There are 2 callbacks (functions with 2 arguments only), one with the *transparent* (void *) user argument first, and one with it as second arg. Before including one or more 3 arg variants, I'd prefer to have some investigations (and results ;-) WRT possible alternatives like libffi. Nick leo
[perl #37532] Get a head start on a new computer career
# New Ticket Created by Margery Cantrell # Please include the string: [perl #37532] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37532 > Three steps to the software you need at the prices you want In order to get the feed, go to Settings -> Links Feed and provide the list of IPs PASTIME, n. A device for promoting dejection. Gentle exercise for intellectual debility. DISOBEDIENCE, n. The silver lining to the cloud of servitude. Complain to one who can help you. It's kind of fun to do the impossible. RESTITUTOR, n. Benefactor; philanthropist. Man is distinguished from all other creatures by the faculty of laughter.
[perl #37530] Want to learn how to build your own website?
# New Ticket Created by Tina Benjamin # Please include the string: [perl #37530] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37530 > Adobe+macromedia+OS etc all in CD under $99 In order to get the feed, go to Settings -> Links Feed and provide the list of IPs Back of every noble life there are principles that have fashioned it. The avoidance of taxes is the only pursuit that carries any reward. Mountains are earth's undecaying monuments. The first duty of a revolutionary is to get away with it.
Re: Avoid the Yen Sign [Was: Re: new sigil]
Jan Dubois skribis 2005-10-25 12:33 (-0700): > Just something to keep in mind in case you are tempted to use the Won > sign as a sigil or operator in the future. I don't know what stitch() will do, but this will have to be its infix operator :) zip ¥ Y stitch w Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
RE: Avoid the Yen Sign [Was: Re: new sigil]
On Tue, 25 Oct 2005, Larry Wall wrote: > As for the ¥ pitfall, so far we've intentionally been careful to use > it only where an operator is expected, whereas \ is legal only where a > term is expected. So at least for Perl code, we can translate legacy > ¥ to different codepoints. (Whether the Japanese font distinguishes > them is another issue, of course. I have a "Unicode" font on my > machine that prints backslash as ¥, which I find slightly irritating, > but doubtless will be par for the course in Japan for the foreseeable > future. Maybe that's a good reason to allow the doublewith backslash > as an alias for normal backslash. Maybe not.) BTW, the exact same thing happens with the Won sign ₩ on Korean Windows systems; it is also mapped to 0x5c in the default codepage, and paths are displayed with the Won sign instead of the backslash as separators. Just something to keep in mind in case you are tempted to use the Won sign as a sigil or operator in the future. Cheers, -Jan
Re: new sigil
Larry Wall skribis 2005-10-25 15:51 (-0700): > ^T would still have to be a placeholder variable. Which it is, in a way. Still, I don't think ^ as a sigil needs to mean the same thing as ^ as a twigil. Visually similar pairs are also not related: ?foo$?foo *foo$*foo +foo$+foo =foo$=foo $ And it might conflict with infix ^ if we ever allow xor'ed types, > since declarations contain lots of things that look like juxtaposed > terms. Is this the same "conflict" that occurs in %foo % %bar? (I cannot imagine needing a one() junction for types, by the way. If someone can come up with a good real-life example, please do so.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Tue, Oct 25, 2005 at 11:44:35PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-25 14:35 (-0700):
: > On Thu, Oct 20, 2005 at 11:18:14AM -0600, Eric wrote:
: > : Actualy i think ^ might be my favorite so far.
: > : sub sametype (^T $x, ^T $y) {...}
: > I thought that, too, until I realized it wouldn't work as an rvalue:
: > ^T.count# 1's complement of number of T instances
:
: Ehm, isn't that +^, ~^ (and ?^, perhaps) nowadays?
Er. It's, um, uh...a generic 1's complement operator! Yeah, that's
the ticket...
But leaving aside my tendencies toward senility, ^T would still have
to be a placeholder variable. And it might conflict with infix ^
if we ever allow xor'ed types, since declarations contain lots of
things that look like juxtaposed terms.
Larry
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
"chromatic" <[EMAIL PROTECTED]> wrote: On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote: Minor nit: when running Configure.pl with --nomanicheck, Configure should report the MANIFEST check as "skipped", not "done". particle beat me to this one, but *wow* the plugin system for configuration is grotty. Does anyone have a particular attachment to it? Would it be useful to clean it up a little bit, or does it need patching or updating very often? If people have free time to spend on configure stuff, might it not be better spent working on the real configure system that we want to have (e.g. a set of makefiles for each platform to build miniparrot, then configure is a Parrot program run by miniparrot that figures stuff out that we need to build the full Parrot)? Just a thought, Jonathan
NCI callbacks
Nick Glencross schrieb: I was looking at callbacks the other evening. Am I right in thinking that only two callback prototypes are supported, or have I missed a trick there as well? Yes, I think that hasn't changed since I've looking into interfacing Parrot with libsyck. As far as I remember, the standard workaround was to write some C-code that wraps the relevant shared lib, and provides the convenience functions for Parrot. CU, Bernhard
Re: check_progs is not portable
On Tue, Oct 25, 2005 at 03:59:44PM -0400, Will Coleda wrote: > I think that module is small enough and useful enough for the build > process to include in parrot if we need to (and copying it in is > better than rewriting it from scratch), but... > > I think this would be a good time (esp. after discussion on IRC) to > introduce the possibility of creating a CPAN bundle that is required > for parrot development. This would give us an external dependancy > (con), but it would allow us to remove all the bundled CPAN modules > that we currently have (good), and allow us to easily add or subtract > the required modules as necessary. I don't think that's necessarily a bad idea but is that really a practical option for things that Configure.pl needs in a non-developmental mode? In this particular case the module would only be needed when the '--maintainer' flag is in use but I imagine that will change in the future as I'd like to tidy up a lot of the probes to use a consistent set of [more rigorous] logic. > We could have a config check early on that checks for the presence of > the required bundled modules and bails, with instructions on how to > grab the Bundle from CPAN and install it. We can tie the required > bundle version to svn revision (or release version, or both) of parrot. That's easily do-able but again I'm not sure that is the right trade-off between ease of building and ease of maintenance. IMHO - since access to CPAN isn't currently a requirement there's nothing wrong with using the Module::Install style of bundling your build time dependencies. If it makes people feel better these could be kept in their own top level directory - perhaps named ./inc? Cheers, -J -- pgpi1OOQtUY5t.pgp Description: PGP signature
Re: new sigil
Larry Wall skribis 2005-10-25 14:35 (-0700):
> On Thu, Oct 20, 2005 at 11:18:14AM -0600, Eric wrote:
> : Actualy i think ^ might be my favorite so far.
> : sub sametype (^T $x, ^T $y) {...}
> I thought that, too, until I realized it wouldn't work as an rvalue:
> ^T.count # 1's complement of number of T instances
Ehm, isn't that +^, ~^ (and ?^, perhaps) nowadays?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 09:59:49AM -0600, Luke Palmer wrote:
: 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?
It's a new T according to the current thinking. Just use T if you
want the same one. (But that does force util to be recloned on every
entry to foo, I expect.)
Larry
Re: new sigil
On Thu, Oct 20, 2005 at 11:18:14AM -0600, Eric wrote:
: Actualy i think ^ might be my favorite so far.
:
: sub sametype (^T $x, ^T $y) {...}
I thought that, too, until I realized it wouldn't work as an rvalue:
^T.count# 1's complement of number of T instances
On top of which, if it did work, it should be a placeholder variable,
not something you see in a signature.
Larry
Re: [perl #37512] [PATCH] Adds nci support for 'T' and 'L' prototypes
Leopold Toetsch via RT wrote: On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote: Guys, call_list.txt lists 'T' and 'L' as being prototypes for passing arrays to nci functions, but no implementation exists in build_nativecall.pl. This patch provides an implementation, as well as new tests. I don't think that this is a good idea. There are way too many different array types. The code inside *ManagedStruct already deals with arrays of all standard types. See e.g. runtime/parrot/library/libpcre.imc, which works fine without new signatures. There is a second problem with this approach: permutation. All of these signature chars might be combined to create arbitrary function signatures. nci.c is already too big. I tend to agree. :-) Let's reject it. I was looking at callbacks the other evening. Am I right in thinking that only two callback prototypes are supported, or have I missed a trick there as well? Nick
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote: > i've started developing a plugin architecture for $work, so i've been > thinking about plugin engines lately. if you're up for working on a > redesign, i'll gladly pitch in. even if you're looking only to clean > it up, i'd certainly appreciate the effort. I've used Module::Pluggable, and liked it. Nicholas Clark
Re: Ways to add behavior
Larry,
On Oct 25, 2005, at 4:37 PM, Larry Wall wrote:
On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote:
: # 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!";
: });
I don't have a comment on your actual question, but I'd like to use
this opportunity to point out the symmetry of Base and $x at this
point, and the fact that .meta can't simply call .add_method in the
metaclass, or it would lose track of the original invocant, which is
needed to convey both class and instance information. I'm not sure
it's even possible to say
$m = $x.meta;
$m.addmethod($arg);
The only way that can work is if $x.meta returns a shadow class that
is prebound only to $x. (Though that might explain how .addmethod
knows it's only adding a method to the object.)
This is actually the principe behind the Ruby style singleton methods
(the shadow class), it basically creates an anon-class which inherits
from $x's original class, then it rebinds/blesses $x into the anon-
class. It is very simple really :)
As for if this is/should be accessible through .meta, i am not sure
that is a good idea. The reason being is that .meta brings with it
the idea of metaclasses, which then relates to classes, and so now
the user is thinking they are accessing the metaclass of the class of
which $x is an instance.
I would suggest instead that we have a method, which is found in
Object which allows instances to add methods to themselves (and only
themselves). In Ruby this is called 'add_singleton_method' or
something like that. I use that same name in the metamodel prototype
too.
In the absence of that, what's going on seems more like
$x.META::addmethod($arg);
where META:: is smart enough to dispatch to the proper metaclass
without
throwing away the invocant, and then the metaclass decides what to do
based on the instancehood of $x.
I am not sure I like this for 2 reasons.
1) META:: smells like ::SUPER, and that feels like re-dispatching to
me, which is not really what we need to be doing.
2) there is not need to send this back to the metaclass level. The
whole thing could be accomplished as an instance method of Object.
Here is how it could be done.
class ShadowClass does Class {}
class Object is reopened {
method add_singleton_method (Str $label, Method $method) {
if ($?SELF.class.class != ShadowClass) {
my $shadow = ShadowClass.new();
$shadow.meta.superclasses([ $shadow ]);
$?SELF.class = $shadow;
}
$?SELF.class.meta.add_method($label, $method);
}
}
Stevan
Re: Zip more than two arrays?
On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be
: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.
I expect zip ought to bundle up into tuples of some sort. But then
maybe zip is not what we want for typical loops. I'm thinking that
"for" wants to be a little more incestuous with -> anyway, so that
the optionality of the -> arguments can tell "for" how to deal with
short lists. And now that we have general multidimensional slices,
it'd be nice if "for" were one of the operators that is aware of that.
Then you might be able to say things like:
for (@foo; 1...) -> $val, $i {...}
for @foo <== 1... -> $val, $i {...}
1... ==>
for @foo -> $val, $i {...}
1... ==> ###v
@foo ==> #v v
for () -> $val, $i {...}
all of which should in theory be equivalent, and none of which use "zip".
(With a bit of handwaving about how ==> binds to the list before
a final -> block.)
With a clever enough parser, we even get back to the A4 formulation of
for @foo; 1... -> $val, $i {...}
But that's relying on the notion that a statement can function as a
funny kind of bracketing device that can shield that semicolon from
thinking it's supposed to terminate the statement. That's probably
not too far off from what it does now when it knows it wants a final
block, so that a bare block where an operator is expected pops back
up to the statement level.
I know that, with tuple matching signatures, zip can be made to work
even as a tuple constructor, but it seems like a waste to constuct
tuples only to throw them away immediately. And if we're going to
build surreal lists into the language, we should probably use them.
Larry
Re: Ways to add behavior
On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote:
: # 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!";
: });
I don't have a comment on your actual question, but I'd like to use
this opportunity to point out the symmetry of Base and $x at this
point, and the fact that .meta can't simply call .add_method in the
metaclass, or it would lose track of the original invocant, which is
needed to convey both class and instance information. I'm not sure
it's even possible to say
$m = $x.meta;
$m.addmethod($arg);
The only way that can work is if $x.meta returns a shadow class that
is prebound only to $x. (Though that might explain how .addmethod
knows it's only adding a method to the object.)
In the absence of that, what's going on seems more like
$x.META::addmethod($arg);
where META:: is smart enough to dispatch to the proper metaclass without
throwing away the invocant, and then the metaclass decides what to do
based on the instancehood of $x.
Larry
Re: check_progs is not portable
On 10/25/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > File::Which is a rather small amount of code in a single file so I'd be > inclined to include it in the Parrot tree rather then reinventing the > wheel. I've always been puzzled as to why there isn't a core perl5 > module with this functionality. > > What do others think about this proposal? > i agree with will, it's better placed in a cpan bundle. i realize this requires more effort than just checking in the module, but i think it's for the best to decouple external modules from parrot. ~jerry
Re: S04 default { } bug?
On Mon, Oct 24, 2005 at 07:39:23AM +0300, Ilmari Vacklin 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.
It did do something special at the time the Apocalypse was written,
but it was probably a bad idea. Smart match was going to recognize
obviously boolean expressions and just ignore the other argument.
The problem is that it's not always obvious what's obvious.
Larry
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
On 10/25/05, chromatic <[EMAIL PROTECTED]> wrote: > On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote: > > > Minor nit: when running Configure.pl with --nomanicheck, Configure > > should report the MANIFEST check as "skipped", not "done". > > particle beat me to this one, but *wow* the plugin system for > configuration is grotty. Does anyone have a particular attachment to > it? Would it be useful to clean it up a little bit, or does it need > patching or updating very often? > i'd love to see configure updated to use a better plugin system. it's difficult to extend or maintain without serious knowledge of the magic it uses. i already know more than i want to about configure, but i'm still nervous about modifying it. i've started developing a plugin architecture for $work, so i've been thinking about plugin engines lately. if you're up for working on a redesign, i'll gladly pitch in. even if you're looking only to clean it up, i'd certainly appreciate the effort. ~jerry
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
On Tue, Oct 25, 2005 at 05:26:32PM +0200, Juerd wrote:
: Michele Dondi skribis 2005-10-25 17:17 (+0200):
: > Hmmm... maybe you're right that $__ is too huffmanized (and hence
: > confusing) but $OUTER::_ is somewhat too few...
:
: for (1..9) -> $n { # ought to be more than enough
: eval qq[
: macro prefix:<\$_$n> { "\${ "OUTER::" x $n }_" }
: ];
: }
That can't work as is. A macro's syntactic effect is always limited to
a particular lexical scope, which is by default the lexical scope
of the declaration. You'll need to find some way of installing it
into the currently compiling lexical scope, which is going to resemble
something more like:
BEGIN {
for (1..9) -> $n { # ought to be more than enough
COMPILING::{"&term:<\$_$n>"} := macro { "\${ "OUTER::" x $n }_" };
}
}
Also, $_ has to be a term, not a prefix, or the next thing will
be expected to be a term rather than an operator. But probably
it shouldn't be a macro anyway, since you could just alias $_1 to
$OUTER::_ etc. directly:
BEGIN {
for (1..9) -> $n { # ought to be more than enough
COMPILING::{"\$_$n"} := COMPILING::("OUTER::" x $n)::<$_>;
}
}
maybe with something to catch the case of too many OUTERs.
Larry
Re: check_progs is not portable
On Oct 25, 2005, at 3:35 PM, Joshua Hoblitt wrote: On Tue, Oct 25, 2005 at 06:31:43AM +0200, Fran?ois PERRAD wrote: 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. Sorry about that. Did the old probe mechanism work on win32? 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. File::Which is a rather small amount of code in a single file so I'd be inclined to include it in the Parrot tree rather then reinventing the wheel. I've always been puzzled as to why there isn't a core perl5 module with this functionality. What do others think about this proposal? -J I think that module is small enough and useful enough for the build process to include in parrot if we need to (and copying it in is better than rewriting it from scratch), but... I think this would be a good time (esp. after discussion on IRC) to introduce the possibility of creating a CPAN bundle that is required for parrot development. This would give us an external dependancy (con), but it would allow us to remove all the bundled CPAN modules that we currently have (good), and allow us to easily add or subtract the required modules as necessary. We could have a config check early on that checks for the presence of the required bundled modules and bails, with instructions on how to grab the Bundle from CPAN and install it. We can tie the required bundle version to svn revision (or release version, or both) of parrot.
Re: Configure System (was Re: [TODO] --nomanicheck fibs)
chromatic <[EMAIL PROTECTED]> wrote: > On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote: > > > Minor nit: when running Configure.pl with --nomanicheck, Configure > > should report the MANIFEST check as "skipped", not "done". > > particle beat me to this one, but *wow* the plugin system for > configuration is grotty. Does anyone have a particular attachment to > it? Would it be useful to clean it up a little bit, or does it need > patching or updating very often? I can say that the one time I tried to patch it, I gave up. (My perldoc installation got hosed, so that the executable is there but none of the documentation is, so parrot thinks it's not there.) So it'd definitely be nice... but I don't know that it's a very high priority. -- matt diephouse http://matt.diephouse.com
Re: new sigil
On Tue, Oct 25, 2005 at 02:02:58PM -0500, Jonathan Scott Duff wrote:
> On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote:
> I don't think so. In the first example all the T (or ¢T) are the same
> type after the first ¢T (where the type is bound). In the second one
> you'd get two separate types ¢T and ¢U. But ¢U would probably get bound
> to the same type as ¢T as that's the type of thing that it returns
> (assuming perl can figure that out).
We have (or have had?) parameterised classes where you can specify
parameters to the class enclosed in [].
eg. class Foo[...] { ... }
So couldn't the same be used for functions? This way you wouldn't need
a special sigil for classes declared in such a way.
sub foo[Bar] (Bar $tab) { ... }
Since perl6 isn't really a static language, I don't think you need to be
allowed to have non-type variables in the [] (dependent-typing, or where
you can use primitive types like int in template parameters in C++),
since being parameters in [] means only that they're types, and not that
they are always bound at compile time.
(apologies for breaking the unicode)
--
Benjamin Smith <[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]>
Christ's College - Mathematics Part 1B
IRC: integral on irc.perl.org, and irc.freenode.net (channel: #perl)
Configure System (was Re: [TODO] --nomanicheck fibs)
On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote: > Minor nit: when running Configure.pl with --nomanicheck, Configure > should report the MANIFEST check as "skipped", not "done". particle beat me to this one, but *wow* the plugin system for configuration is grotty. Does anyone have a particular attachment to it? Would it be useful to clean it up a little bit, or does it need patching or updating very often? -- c
Re: check_progs is not portable
On Tue, Oct 25, 2005 at 06:31:43AM +0200, Fran?ois PERRAD wrote: > > 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. Sorry about that. Did the old probe mechanism work on win32? > 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. File::Which is a rather small amount of code in a single file so I'd be inclined to include it in the Parrot tree rather then reinventing the wheel. I've always been puzzled as to why there isn't a core perl5 module with this functionality. What do others think about this proposal? -J -- pgpUtmzouMoaJ.pgp Description: PGP signature
Re: new sigil
On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote:
> I like that symmetry between &foo and ¢foo. So to get the behavior
> that an outer type variable applies to an inner sub, could I do this:
>
> # a complicated identity function :-)
> sub foo (¢T $x --> ¢T) {
> my sub bar (T $z --> T) {
> $z;
> }
> bar $x;
> }
>
> Because omitting the ¢ would not bind T.
You can even do
sub foo (¢T $x --> T) {
my sub bar (T $z --> T) {
$z;
}
bar $x;
}
I do believe.
> Whereas if I wrote:
>
> sub foo (¢T $x --> ¢T) {
> my sub bar (¢T $z --> T) {
> $z;
> }
> bar $x;
> }
It would be semantically the same as above. (just like C
would only declare one C<$x>, so too C<¢T $x ... ¢T $y> should only
bind one type to T (or ¢T) for the duration of the scope.
> It would be a totally new variable in both spots in the inner sub, and
> if I wrote:
>
> sub foo (¢T $x --> ¢T) {
> my sub bar (T $z --> ¢T) {
> $z;
> }
> bar $x;
> }
>
> It would be equivalent to:
>
> sub foo (¢T $x --> ¢T) {
> my sub bar (T $z --> ¢U) {
> $z;
> }
> bar $x;
> }
I don't think so. In the first example all the T (or ¢T) are the same
type after the first ¢T (where the type is bound). In the second one
you'd get two separate types ¢T and ¢U. But ¢U would probably get bound
to the same type as ¢T as that's the type of thing that it returns
(assuming perl can figure that out).
That's if I understand Larry correctly.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: txt vs OO [was: "Re: Proposal to make class method non-inheritable"]
On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
: Also, Perl6 OO capabilities are already above the top of my head.
Sure, they're above my head too. Which should be obvious by now... :-)
: But maybe that's just me. Whatever, I guess that the {casual,average}
: programmer may be scared by its richness and complexity.
But we're trying to design the OO features (indeed, all of Perl 6)
such that you can usefully cargo cult those aspects that are of
immediate interest without being forced to learn the whole thing.
It's not the number one design goal, but it's right up there.
Larry
Re: new sigil
On Tue, Oct 25, 2005 at 01:57:52PM -0400, Rob Kinyon wrote: : I'm assuming that when you allow : : my ¢T := sometype(); : : you're also allowing : : my class T := sometype(); Yes, that's the idea. : So, what happens when stupid me names a class "class" through : symbol-table craziness? How much class could a class class class if a class class could class class? What happens is either that you have to say "class class" or "¢class" or you redefine the "class" keyword to something else like "frobnitz". I think "class" and "sub" are keywords in the, er, class of things that trump mere symbol table entries. Either that, or "class" is merely the name of the metaclass, and you'll get a class collision when you try to redefine it. But I expect "class" is really a declarator of the same status as "sub", at least syntactically. Larry
Re: new sigil
On 10/25/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> We're probably converging on a general rule that two or more
> declarations of the same variable in the same scope refer to the
> same entity:
>
> my $x = 1; # outer $x;
> {
> $x = 2; # bound to OUTER::<$x>
> if my $x = foo() {...} # new $x declared here
> if my $x = bar() {...} # same $x, "my" is optional
> baz(); # baz sees single inner CALLER::<$x>.
> }
...
...
Cool!
> So too these would mean the same thing:
>
> sub Bool eqv (¢T $x, T $y) { my T $z; }
> sub Bool eqv (¢T $x, ¢T $y) { my ¢T $z; }
I like that symmetry between &foo and ¢foo. So to get the behavior
that an outer type variable applies to an inner sub, could I do this:
# a complicated identity function :-)
sub foo (¢T $x --> ¢T) {
my sub bar (T $z --> T) {
$z;
}
bar $x;
}
Because omitting the ¢ would not bind T. Whereas if I wrote:
sub foo (¢T $x --> ¢T) {
my sub bar (¢T $z --> T) {
$z;
}
bar $x;
}
It would be a totally new variable in both spots in the inner sub, and
if I wrote:
sub foo (¢T $x --> ¢T) {
my sub bar (T $z --> ¢T) {
$z;
}
bar $x;
}
It would be equivalent to:
sub foo (¢T $x --> ¢T) {
my sub bar (T $z --> ¢U) {
$z;
}
bar $z;
}
(Thus causing a "signature too general" type error)
Right? Totally off?
Luke
Re: Perl 6 fears
On Tue, Oct 25, 2005 at 11:57:10AM -0600, Luke Palmer wrote: > On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > > On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]> > > wrote: > > > FEAR: Perl6 internals will be just as inaccessable as p5 > > > > paradox. Many people don't find perl5 inaccessible at all > > Who? Do you know anybody who hacks the regex engine? It happens that Merijn does, partly as a side effect of being an active Perl 5 committer. But assuming that you're questioning his use of "many", then I agree with you. Few people find perl5 accessible. Mostly as a side effect of banging their heads at it until it starts to change from inaccessible to accessible. And inaccessibility is something that both perl6 and parrot should actively strive to avoid. Having looked at src/hash.c today, I fear that currently parrot is showing signs of failing in this. > I wonder how hard it would be to actually convert perl 5 formats to > Perl6::Form. Having never used the former myself, I wouldn't really > know the order of magnitude of this problem. It's probably easier to implement strict perl5 formats as a compatibility module, using the exiting Perl 5 source and parrot's NCI. Nicholas Clark
Re: Perl 6 fears
On 10/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > > On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]> > > wrote: > > > FEAR: Perl6 internals will be just as inaccessable as p5 > > > > paradox. Many people don't find perl5 inaccessible at all > > Who? Do you know anybody who hacks the regex engine? japhy. Though, granted, he's on a whole new level of insanity. Rob
Re: new sigil
> Basically, ¢T is a close analog of &t, which is the variableish form
> for "sub t". When used in a declaration, both of them introduce a
> bare name as an alias into whatever scope the declaration is inserting
> symbols, albeit with different syntactic slots. So just as
>
> my &t := { ... }
>
> introduces the possibility of
>
> t 1,2,3
>
> so also a
>
> my ¢T := sometype();
>
> introduces the possibility of
>
> my T $x;
I'm assuming that when you allow
my ¢T := sometype();
you're also allowing
my class T := sometype();
So, what happens when stupid me names a class "class" through
symbol-table craziness?
Rob
Re: Perl 6 fears
On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]> > wrote: > > FEAR: Perl6 internals will be just as inaccessable as p5 > > paradox. Many people don't find perl5 inaccessible at all Who? Do you know anybody who hacks the regex engine? > > FEAR: Perl6 will not be able to fix the stigma of "just a scripting > > language" or "line noise" > > perl5 has never been "just a scripting language" Yeah, but he's talking about the cultural stigma, which is definitely present. However, given the increasing number of high-level design constructus, I think that this fear will never realize itself. The only way it could is from the name "Perl", and once anybody uses it, it will go away. > My only current fear is that I won't live long enough to be able to use and > understand the full richness of what perl6 is going to offer me. > > (Oh, and that perl6 will never be able to upgrade my scripts that use > 'format', but I'm aware of the plan to make that `obsolete' as in: the > perl526 translator will dump core on those) I wonder how hard it would be to actually convert perl 5 formats to Perl6::Form. Having never used the former myself, I wouldn't really know the order of magnitude of this problem. Luke
Re: Avoid the Yen Sign [Was: Re: new sigil]
: On 10/23/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: : > In addition to your handy table, the >> and << french quotes, which are used : > quite heavily in Perl 6 for both bracketing and hyper operators, also have : > full width equivalents: : > : > 300A;LEFT DOUBLE ANGLE BRACKET;Ps;0;ON;Y;OPENING DOUBLE ANGLE BRACKET : > 300B;RIGHT DOUBLE ANGLE BRACKET;Pe;0;ON;Y;CLOSING DOUBLE ANGLE BRACKET : > : > Half width: «» : > Full width: 《》 I think we actually speculated about that identity in the Apocalypse. : > One way to approach it is to make Perl 6 accept both full- and : > half-width variants. : > : > Another way would be to use ASCII fallbacks exclusively in real programs, and : > reserve unicode variants for pretty-printing, the same way that PLT Scheme and : > Haskell recognizes λ in literatures, but actually write "lambda" and : > "\" respectively : > in everyday coding. I think we should enable both approaches. Restricting Unicode characters to literature is wrong, but so is forcing Unicode on someone prematurely. On Sun, Oct 23, 2005 at 07:07:33PM -0400, Rob Kinyon wrote: : Isn't this starting to be the question of why we have the Unicode : operators instead of just functions? Would it be possible to have a : function be infix? At which precedence level? Larry
Re: Avoid the Yen Sign [Was: Re: new sigil]
On Sun, Oct 23, 2005 at 10:55:34PM +0900, Dan Kogai wrote: : To make the matter worse, there are not just one "yen sign" in : Unicode. Take a look at this. : : ¥ U+00A5 YEN SIGN : ￥ U+FFE5 FULLWIDTH YEN SIGN : : Tough they look and groks the same to human, computers handle them : differently. This happened when Unicode Consortium decided to make : BMP round-trippable against legacy encodings. They were distinct in : JIS standards, so happened Unicode. : : Maybe we should avoid other symbols like this for sigils -- those not : in ASCII that have 'fullwidth' variations. q($) and q(\) are okay : (or too late) because they are already in ASCII. q(¥) should be : avoided because you can hardly tell the difference from q(￥) in the : display. : : But this will also outlaw the cent sign. I have attached a list of : those affected. As you see, most are with ASCII equivalents but some : are not. We'd have to outlaw A..Z as well. :-) I think a better plan might just be to say that we'll treat any fullwidth character as equivalent to its narrow companion, at least when used as an operator. Canonicalizing identifiers may be another matter though. On the other hand, certain of the double-width characters are likely to be confused with two singles, such as ＝ FF1DFULLWIDTH EQUALS SIGN ＿ FF3FFULLWIDTH LOW LINE so maybe they should be equivalent to == and __, or outlawed. And one could (un)reasonably argue that ～ FF5EFULLWIDTH TILDE ought to mean ~~ rather than ~. But in general we need to go slow on such decisions. For now just sticking our toe into Latin-1 is enough, as long as we're looking ahead for visual pitfalls. As for the ¥ pitfall, so far we've intentionally been careful to use it only where an operator is expected, whereas \ is legal only where a term is expected. So at least for Perl code, we can translate legacy ¥ to different codepoints. (Whether the Japanese font distinguishes them is another issue, of course. I have a "Unicode" font on my machine that prints backslash as ¥, which I find slightly irritating, but doubtless will be par for the course in Japan for the foreseeable future. Maybe that's a good reason to allow the doublewith backslash as an alias for normal backslash. Maybe not.) Anyway, I think people will be able to distinguish visually between "A ¥ B" and "¥X" as long as we keep the operator/term distinction. Larry
Re: new sigil
On Sat, Oct 22, 2005 at 06:00:38AM -0400, Damian Conway wrote:
: Autrijus wrote:
:
: >Indeed. Somehow I think this makes some sense:
: >
: >sub Bool eqv (|T $x, |T $y) { ... }
:
: Except that it prevents anyone from ever writing:
:
: multi sub circumfix:<| |> (Num $x) { return abs $x }
: multi sub circumfix:<| |> (Vec $x) { return $x.mag }
:
: which many mathematically inclined folks might find annoying.
:
: (It also precludes intriguing possibilities like:
:
: multi sub circumfix:«| >» ($q) { return Quantum::State.new(val => $q)
: }
:
: which I personally would find irritating. ;-)
I considered | last week, but decided it was better to hold unary | in
reserve, especially since it's likely to be confusing with junctions.
And if we use | for type set notation, then unary | would preclude
the ability to stack types, and I've been treating an utterance like
my Mammal ¢T $fido where Bark :($a,$b,$c --> Wag)
as having at least five implicitly ANDed type specifications:
must do Mammal
must do Class
must do Scalar
must do Bark
must do Wag
plus there must be three components that are Scalar, plus whatever
extra type constraints Wag puts onto those three components. Having
Mammal |T be ambiguous with Mammal|T would be bad, at least visually.
Anyway, having mulled over all this while off in Amsterdam and
Budapest, my current thinking is that the ascii shortcut for ¢T is
simply "class T", so you could write any of:
sub Bool eqv (¢T $x, T $y)
sub Bool eqv (class ¢T $x, T $y)
sub Bool eqv (Any ¢T $x, T $y)
sub Bool eqv (Any class T $x, T $y)
and mean the same thing.
Basically, ¢T is a close analog of &t, which is the variableish form
for "sub t". When used in a declaration, both of them introduce a
bare name as an alias into whatever scope the declaration is inserting
symbols, albeit with different syntactic slots. So just as
my &t := { ... }
introduces the possibility of
t 1,2,3
so also a
my ¢T := sometype();
introduces the possibility of
my T $x;
Use as an rvalue can be either T or ¢T without declaring a new type.
We're probably converging on a general rule that two or more
declarations of the same variable in the same scope refer to the
same entity:
my $x = 1; # outer $x;
{
$x = 2; # bound to OUTER::<$x>
if my $x = foo() {...} # new $x declared here
if my $x = bar() {...} # same $x, "my" is optional
baz(); # baz sees single inner CALLER::<$x>.
}
So too these would mean the same thing:
sub Bool eqv (¢T $x, T $y) { my T $z; }
sub Bool eqv (¢T $x, ¢T $y) { my ¢T $z; }
Only the first declarative ¢ actually installs a new symbol T.
An inner scope would of course establish its own type space, but
the formal parameters to a block count as part of the block, which
is why the second form above applies the existing T to $z rather
than capturing the type of $z. But it's a bit like writing &foo()
when you could just say foo() instead.
Larry
Re: $_ defaulting for mutating ops
Sebastian skribis 2005-10-25 9:17 (-0700): > > I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on > > their LHS when there is no obvious operand. > It'd be nice to have these, but is it something that can wait? I > wouldn't mind if more effort was spent on other pieces if this can be > easily done in the future It can wait, in theory, but implementing this should be trivial for the people doing implementation. One problem with waiting until after the first release is that there will very quickly be code that works with 6.0.1, but not with 6.0.0, if what you're waiting for is a small thing to implement... Things that can wait are usually very non-trivial, and have little impact on the rest of the language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $_ defaulting for mutating ops
> I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on > their LHS when there is no obvious operand. It'd be nice to have these, but is it something that can wait? I wouldn't mind if more effort was spent on other pieces if this can be easily done in the future - sebastian
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
On Tue, 25 Oct 2005, Juerd wrote:
for (1..9) -> $n { # ought to be more than enough
eval qq[
macro prefix:<\$_$n> { "\${ "OUTER::" x $n }_" }
];
}
And then you can use $_1 .. $_9. I think $_1 is much clearer than $__,
but I think neither is needed in the standard language.
Can I beg to differ any more? (Implicit answer: no, I can't!)
Michele
--
The trouble with engineers is that given the problem of knocking down
a stack of 100 bricks, they will start at the top, and work all
day removing them one at a time, while the mathematician will, after
a momemt's thought, remove the bottom brick and be done with it.
The "trouble" part, is having to brook the noise of the engineer
boasting about how much harder he worked while one is trying to
think about the next problem.
- Bart Goddard in sci.math
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
Michele Dondi skribis 2005-10-25 17:17 (+0200):
> Hmmm... maybe you're right that $__ is too huffmanized (and hence
> confusing) but $OUTER::_ is somewhat too few...
for (1..9) -> $n { # ought to be more than enough
eval qq[
macro prefix:<\$_$n> { "\${ "OUTER::" x $n }_" }
];
}
And then you can use $_1 .. $_9. I think $_1 is much clearer than $__,
but I think neither is needed in the standard language.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: txt vs OO [was: "Re: Proposal to make class method non-inheritable"]
On Tue, 25 Oct 2005, Stevan Little wrote:
Well, the point is that it is interesting to note that "text processing"
is an _application area_, whereas "OO programming" is a programming
language paradigm.
Allow me to clarify.
Perl 5 (and below) are known by outsiders (non-perl users) as being a really
good language for processing text. Ask any friend you know who has had little
or no exposure to Perl and they will probably tell you this. Of course they
will also tell you that it is all line noise, etc, etc etc. This is the most
common perception of Perl by those people who have (for the most part) never
encountered it.
ack!
I think that Perl 6 may become like that for OO. When people who have never
used or encountered Perl 6 talk about it, they will say, "I've never used it,
but I hear it has lots of really cool OO features". Just as now they the same
thing re: text-processing.
I see your point. And I admit I slightly misunderstood you. In any case
people who don't know Perl and think it's great for text processing may be
eventually become interested in it if they will have to do... ehm... text
processing.
But even if Perl will gain a name for it's "cool OO features", will it
become an actual interest for someone if he/she has to do... OO stuff?!?
The basic idea being that one is attracted by a language or another if its
features are well suited for some specific application he/she has in mind.
Not for its features as an abstract thing.
Also, Perl6 OO capabilities are already above the top of my head. But
maybe that's just me. Whatever, I guess that the {casual,average}
programmer may be scared by its richness and complexity.
After all, being known for text processing capabilities may be somewhat
restictive and not faithful of Perl's (including Perl 5) full
potentiality,
Of course not, Perl is also used for CGI, but you can do that better with
Java now (which is a real language cause it's compiled)
Of Perl is IMHO even _too_ known for CGI.
but "OO programming" is somewhat immaterial either, the "only" relevance
being the suitability for big projects management.
The idea that OO is only relevant for big projects is just as silly as saying
that Perl is only good for text processing.
ack. I was oversimplifying.
Sure I would not use OO to write a small utility script, but the modules I
access in the script would probably be written using OO. And those may be
very small modules too, but their re-usability is greatly enhanced by various
OO features (encapsulation, ability to compose-into or use within another
class, etc etc etc). This kind of thing (IMHO) is why so many people are
being drawn to Python and Ruby. Hopefully Perl 6 can draw them back.
Also, some methods will be very handy even for non-patently-OO blocks,
e.g. the .pos() one which will replace the somewhat ad hoc pos() function
or the .subst() one (or whatever it is called, I can't remember exactly)
which hopefully will get rid of the "why doesn't s/// work inside a map()"
question...
Michele
--
Have you ever stopped to consider that what is crashing
your Perl is sitting between the keyboard and chair?
- Sherm Pendley in clpmisc, "Re: Perl IDE" (edited)
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
On 2005-10-25 11:17 AM, "Michele Dondi" <[EMAIL PROTECTED]> wrote: >> I find $__ confusing, and prefer $OUTER::_, which already exists. > > Hmmm... maybe you're right that $__ is too huffmanized (and hence > confusing) but $OUTER::_ is somewhat too few... What's confusing about $__ is that it looks too much like $_. In my font, for instance, there's no gap - it's just a longer underline, which is far too subtle a difference...
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
On Tue, 25 Oct 2005, Juerd wrote:
Michele Dondi skribis 2005-10-25 17:05 (+0200):
Now, one that I've sometimes desired is a "two level" $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
I find $__ confusing, and prefer $OUTER::_, which already exists.
Hmmm... maybe you're right that $__ is too huffmanized (and hence
confusing) but $OUTER::_ is somewhat too few...
Michele
--
A question out of curiousity: who is this Green of Green's functions?
Is he the same person of Green's theorem? :)
Yes. He was also an early environmentalist; hence the current
phrases "green" this and "green" that...
- David C. Ullrich in sci.math, "Re: Who is Green?"
Re: Pronouns ["Re: $_ defaulting for mutating ops"]
Michele Dondi skribis 2005-10-25 17:05 (+0200):
> Now, one that I've sometimes desired is a "two level" $_, i.e. a variable,
> say, $__ referring to the _second next_ enclosing lexical scope. I am
> aware that in this vein one may ask a third analogue and so on, but let's
> face it: $_ already covers 95% of cases, my hypothetical var would cover I
> guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
> for @vert {
> put_point $_, $__ for @horiz;
> }
I find $__ confusing, and prefer $OUTER::_, which already exists.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Pronouns ["Re: $_ defaulting for mutating ops"]
On Tue, 25 Oct 2005, Juerd wrote:
Reducing line noise isn't my goal, though. I feel that the implicit
defaulting to $_ makes Perl a more natural and elegant language, and
would like this principle being extended to these operators.
Indeed, both the implicit defaulting to $_ AND the availability of $_
itself. Which occasionally makes me desire even more pronouns. After all
in a natural language like English we have 'it', 'them', 'we', etc... now
it's obvious that
(i) we can't hope nor desire a full correspondence,
(ii) there _already_ are some analogues of _some_ of the above, but
somewhat more limited in usefulness wrt $_.
Now, one that I've sometimes desired is a "two level" $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
Note: I am aware that P6 will already provide other ways to do it, but
this is not in contrast with Perl's TMTOWTDI-ness. I expect it to be
useful enough in nested {map,grep}'s.
Michele
--
you look around what do you see?
I'll tell you what I see is a world belonging to me
- Pennywise, "Living For Today".
Re: Deprecation warning - last call: newsub
Patrick R. Michaud wrote: On Tue, Oct 25, 2005 at 01:53:52PM +0200, Leopold Toetsch wrote: The C opcode will be removed RSN. Please read docs/compiler_faq.pod for replacing C. How do I get an anonymous coroutine into a register? PGE currently does something similar to the following: As these 2 .subs are generated in one bunch and compiled ... .sub _pge_rule .param pmc mob ... drop the var decl: .local pmc corou newsub corou, .Coroutine, _pge_rule_coroutine and use a .Sub constant (.Sub is ok despite the PMC is a Coroutine). .const .Sub corou = "_pge_rule_coroutine" The coroutine label is resolved at compile-time. setattribute mob, "PGE::Match\x0&:corou", corou ... .end .sub _pge_rule_coroutine .sub _pge_rule_coroutine :anon Pm leo
Re: txt vs OO [was: "Re: Proposal to make class method non-inheritable"]
On Oct 25, 2005, at 6:31 AM, Michele Dondi wrote: On Fri, 14 Oct 2005, Stevan Little wrote: I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to Sorry for replying so late. Thought it seems appropriate to post this in this time of "Perl 6 fears" and rants threads... Well, the point is that it is interesting to note that "text processing" is an _application area_, whereas "OO programming" is a programming language paradigm. Allow me to clarify. Perl 5 (and below) are known by outsiders (non-perl users) as being a really good language for processing text. Ask any friend you know who has had little or no exposure to Perl and they will probably tell you this. Of course they will also tell you that it is all line noise, etc, etc etc. This is the most common perception of Perl by those people who have (for the most part) never encountered it. I think that Perl 6 may become like that for OO. When people who have never used or encountered Perl 6 talk about it, they will say, "I've never used it, but I hear it has lots of really cool OO features". Just as now they the same thing re: text-processing. Sure, this means nothing to people who are actually using it, but this is mostly about outside perception. These kinds of things are sometimes what will bring people to the language initially, so they are not to be taken lightly. Despite the intro above, this is not meant to be a rant or to express a fear. But it is intended to raise a meditation. After all, being known for text processing capabilities may be somewhat restictive and not faithful of Perl's (including Perl 5) full potentiality, Of course not, Perl is also used for CGI, but you can do that better with Java now (which is a real language cause it's compiled) ;) People who are not familiar with a language tend to rely heavily on the common "knowledge" about that language. And also tend to hold tightly to the myths and pseudo-facts surrounding their own languages. The combination of these two things tends to lead to silly statements like the one above. but "OO programming" is somewhat immaterial either, the "only" relevance being the suitability for big projects management. The idea that OO is only relevant for big projects is just as silly as saying that Perl is only good for text processing. Sure I would not use OO to write a small utility script, but the modules I access in the script would probably be written using OO. And those may be very small modules too, but their re-usability is greatly enhanced by various OO features (encapsulation, ability to compose-into or use within another class, etc etc etc). This kind of thing (IMHO) is why so many people are being drawn to Python and Ruby. Hopefully Perl 6 can draw them back. Stevan
Re: $_ defaulting for mutating ops
On Tue, 25 Oct 2005, Rob Kinyon wrote:
On 10/25/05, Juerd <[EMAIL PROTECTED]> wrote:
I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on
their LHS when there is no obvious operand.
[snip]
Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
No, to address the fear that P6 won't be just as suitable for
{obfuscation,golfing} as P5 is and that it would spoil those cultures.
Incidentally I think it'd be great too.
Michele
--
Free software, not just Linux, is a major problem for Microsoft.
It's a big mistake thinking they don't understand free software, or its mechanics.
They understand it all too well, and they don't like it - not one little bit!
- Eddy Macnaghten
Re: Deprecation warning - last call: newsub
On Tue, Oct 25, 2005 at 01:53:52PM +0200, Leopold Toetsch wrote: > The C opcode will be removed RSN. > > Subroutines (and coroutines) created just from a label are lacking vital > information, like name, namespace, and especially register usage. > > Please read docs/compiler_faq.pod for replacing C. How do I get an anonymous coroutine into a register? PGE currently does something similar to the following: .sub _pge_rule .param pmc mob .local pmc corou ... newsub corou, .Coroutine, _pge_rule_coroutine setattribute mob, "PGE::Match\x0&:corou", corou ... .end .sub _pge_rule_coroutine ... .yield() ... .end Note that PGE does this for many rule compilations -- i.e., "_pge_rule_coroutine" gets re-used over-and-over again. It works because in the C above, _pge_rule_coroutine is resolved at compile-time and not at run-time. I haven't tested this, but I fear that if I change the newsub above to be corou = find_global "_pge_rule_coroutine" then this changes things to a runtime binding instead of a compile-time one, i.e. the rule would always call the last coroutine generated, not the one generated when the dynamic code was compiled. Yes, it would be possible for me to generate a unique label for each coroutine, but I'm concerned that in doing so we'll be creating lots of non-GCable subroutines (could be bad if we're dynamically generating lots of rules). So, any suggestions? Am I missing something obvious? Pm
Re: $_ defaulting for mutating ops
Rob Kinyon skribis 2005-10-25 8:37 (-0400):
> Did you post this specifically to anti-address the fear that P6 will
> be more line-noise-ish than P5? :-p
No. Leaving out $_ is one of the important features in *reducing* line
noise. We're all very used to seeing it, but to most people it is just
two more non-alphanumeric characters.
Reducing line noise isn't my goal, though. I feel that the implicit
defaulting to $_ makes Perl a more natural and elegant language, and
would like this principle being extended to these operators.
For comparison, here is the same code snippet again. First with, and
then without explicit $_.
With:
given ($subject) -> $_ {
$_ ~~ s/foo/bar/;
$_++;
$_ x= 2;
$_ ~= "!";
}
Without:
given ($subject) {
s/foo/bar/;
++;
x= 2;
~= "!";
}
I think the latter is more elegant, without reducing legability or
maintainability. I also think that the code is immediately obvious, even
to people coming from Perl 5, who never read this thread.
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
Joshua Gatcomb skribis 2005-10-25 8:30 (-0400): > IIRC, Andy has taken up the Perl6 PR hat. I think Juerd should like be > working with Andy on this one. The rebuttals to these fears needs to be well > thought out and convincing because from my personal experience they are > prevalent. I'll work with anyone, but I do believe in collaborative editing. That's why I put it in pugs' svn, so that everyone can help. If this list of fears is ever used for more official purposes (not my original intent), like putting it online as an article, of course PR people must be involved. For now, if Andy wants to change anything, he is free to do so, like everyone else. If he thinks I shouldn't continue without his approval, he knows where to find me. So far, most of my subprojects have been undiscussed before they started. It has all worked out well. If anyone objects, please do let me know. But if you want me to discuss things beforehand, people better be reachable and responding, because I generally lose interest if I don't get started within a few days. That kind of thing has been a problem with other projects, and I love how Perl 6 development is so open and free, focussed on fun and a common goal, rather than bureaucracy and people wearing very specifically coloured hats :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $_ defaulting for mutating ops
On 10/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on
> their LHS when there is no obvious operand.
>
> This clashes with &prefix:<=>, but that's nothing a space cannot fix.
> Same for lvalue subs called x or xx (or X or XX).
>
> my $subject = "foo foo foo";
> given ($subject) {
> s/foo/bar/; # "bar foo foo"
> ++; # "bar foo fop"
> x= 2;# "bar foo fopbar foo fop"
> ~= "!"; # "bar foo fopbar foo fop!"
> }
>
> Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
Rob
Re: Perl 6 fears
On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > My only current fear is that I won't live long enough to be able to use > and > understand the full richness of what perl6 is going to offer me. > > (Oh, and that perl6 will never be able to upgrade my scripts that use > 'format', but I'm aware of the plan to make that `obsolete' as in: the > perl526 translator will dump core on those) Those were not my fears. They are comments and concerns I see made day in and day out in various online forums over the last 3 years. Juerd's whole point to collecting these fears was to point out that, by and large, they are unfounded. Stating that plenty of people find p5's internals very accessible isn't going to allay the concerns of the people with the fear. Stating that p5 has never been "just a scripting language" isn't going to change the perception of those people that hold that opinion. IIRC, Andy has taken up the Perl6 PR hat. I think Juerd should like be working with Andy on this one. The rebuttals to these fears needs to be well thought out and convincing because from my personal experience they are prevalent. -- > H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) > Cheers, Joshua Gatcomb a.k.a. Limbic~Region
Deprecation warning - last call: newsub
The C opcode will be removed RSN. Subroutines (and coroutines) created just from a label are lacking vital information, like name, namespace, and especially register usage. Please read docs/compiler_faq.pod for replacing C. leo
Re: Yet another C compiler
Maybe someone wants to experiment a bit, if it compiles Parrot. Here's another thought... "The ACK achieves maximum portability by using an intermediate byte-code language called EM. (..) EM is a relatively high-level stack-based machine, and one of the tools supplied with ACK is an interpreter capable of executing EM binaries directly, with a high degree of safety checking" See also http://tack.sourceforge.net/doc/em.html It's stack-based, but a EM->PASM converter might be an interesting way to compile Modula-2 to Parrot ;-) -- [EMAIL PROTECTED] - http://christian.web42.com - http://www.web42.com/crenz/ "Real theology is always rather shocking to people who already think they know what they think. I'm still shocked myself." -- Larry Wall
txt vs OO [was: "Re: Proposal to make class method non-inheritable"]
On Fri, 14 Oct 2005, Stevan Little wrote: I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to Sorry for replying so late. Thought it seems appropriate to post this in this time of "Perl 6 fears" and rants threads... Well, the point is that it is interesting to note that "text processing" is an _application area_, whereas "OO programming" is a programming language paradigm. Despite the intro above, this is not meant to be a rant or to express a fear. But it is intended to raise a meditation. After all, being known for text processing capabilities may be somewhat restictive and not faithful of Perl's (including Perl 5) full potentiality, but "OO programming" is somewhat immaterial either, the "only" relevance being the suitability for big projects management. Michele -- Ira Kane: If I was a giant nasty alien bird in a department store, where would I be? Harry Block: Lingerie. Ira Kane: Not you, the bird. Harry Block: Lingerie. - "Evolution", Ivan Reitman
Yet another C compiler
The Amsterdam Compiler Kit http://tack.sourceforge.net/ is the default compiler for Minix 3.0 and should also work on Linux. Maybe someone wants to experiment a bit, if it compiles Parrot. leo
Re: Perl 6 fears
On Mon, 24 Oct 2005, H.Merijn Brand wrote: FEAR: Perl6 will not be able to fix the stigma of "just a scripting language" or "line noise" perl5 has never been "just a scripting language" But sadly enough it is often _perceived_ as such. And also like "line noise", as the person you're answering to correctly states: an opinion we all beg to differ, I suppose, but a widespread one indeed... Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, "perl bug File::Basename and Perl's nature"
[perl #37524] [TODO] --nomanicheck fibs
# New Ticket Created by Will Coleda # Please include the string: [perl #37524] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37524 > Minor nit: when running Configure.pl with --nomanicheck, Configure should report the MANIFEST check as "skipped", not "done".
RE: Microsoft Visual Toolkit
> I have a copy of XP Pro: I just installed ActiveState Perl, Visual C+ > + Toolkit 2003, the MS SDK and the .NET SDK (On my Virtual PC > installation on my mac, btw. Only took about 10 hours, on and > off =-) > trying to build parrot using the toolkit command prompt, I get: ... > > Y:\>type test.ldo > LINK : fatal error LNK1104: cannot open file 'user32.lib' > -nodefaultlib' > cl : Command line warning D4002 : ignoring unknown option '-debug' > cl : Command line warning D4002 : ignoring unknown option > '-machine:x86' > LINK : fatal error LNK1104: cannot open file 'ut:test.exe' > > Suggestions? > You need better environment vars and settings (vcvars32.bat). Recent README.win32 from perl distro explain that, and I saw good descriptions at perlmonks site. Also, start with compiling perl itself, so you'll be sure settings are ok.
Microsoft Visual Toolkit
I have a copy of XP Pro: I just installed ActiveState Perl, Visual C+
+ Toolkit 2003, the MS SDK and the .NET SDK (On my Virtual PC
installation on my mac, btw. Only took about 10 hours, on and off =-)
trying to build parrot using the toolkit command prompt, I get:
Y:\>perl Configure.pl --nomanicheck
Parrot Version 0.3.0 Configure 2.0
Copyright (C) 2001-2005 The Perl Foundation. All Rights Reserved.
Hello, I'm Configure. My job is to poke and prod your system to
figure out
how to build Parrot. The process is completely automated, unless you
passed in
the `--ask' flag on the command line, in which case it'll prompt you
for a few
pieces of info.
Since you're running this script, you obviously have Perl 5--I'll be
pulling
some defaults from its configuration.
Checking
MANIFEST.done.
Setting up Configure's data
structuresdone.
Tweaking settings for
miniparrot..done.
Loading platform and local hints
filesdone.
Determining nongenerated header
files.done.
Determining what C compiler and linker to
use.done.
Determining whether lex is
installed...skipped.
Determining whether yacc is
installed..skipped.
Determining if your C compiler is actually gcc..Linker failed
(see test.ldo)
at lib/Parrot/Configure/Step.pm line 361
Parrot::Configure::Step::cc_build() called at config/auto/
gcc.pl line 30
Configure::Step::runstep('undef', 'undef') called at lib/
Parrot/Configur
e/RunSteps.pm line 124
Parrot::Configure::RunSteps::runsteps
('Parrot::Configure::RunSteps', 'no
manicheck', 1, 'debugging', 1) called at Configure.pl line 402
Y:\>type test.ldo
LINK : fatal error LNK1104: cannot open file 'user32.lib'
-nodefaultlib'
cl : Command line warning D4002 : ignoring unknown option '-debug'
cl : Command line warning D4002 : ignoring unknown option '-machine:x86'
LINK : fatal error LNK1104: cannot open file 'ut:test.exe'
Suggestions?
[perl #37520] [TODO] rename library files from .imc to .pir
# New Ticket Created by jerry gay # Please include the string: [perl #37520] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37520 > some time ago, it was decided by @chip (or maybe even @dan) that we'd change the file extension for PIR files from .imc to .pir, for obvious reasons. many files have changed, but the library files (runtime/parrot/library/*) remain largely untouched. these files should be renamed. ~jerry
Re: Perl 6 fears
On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > 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 paradox. Many people don't find perl5 inaccessible at all > FEAR: The Perl6 process is driving away too many good developers From what? > FEAR: Perl6 will not be as portable as p5 I will subscribe to that fear, but only for now. > FEAR: Perl6 will not be able to fix the stigma of "just a scripting > language" or "line noise" perl5 has never been "just a scripting language" > FEAR: Perl6 is un-necessary and the time, money, and resources is impacting > p5. very untrue. And this does not sound like a FEAR, but more like an opinion > 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 My only current fear is that I won't live long enough to be able to use and understand the full richness of what perl6 is going to offer me. (Oh, and that perl6 will never be able to upgrade my scripts that use 'format', but I'm aware of the plan to make that `obsolete' as in: the perl526 translator will dump core on those) -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
$_ defaulting for mutating ops
I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on
their LHS when there is no obvious operand.
This clashes with &prefix:<=>, but that's nothing a space cannot fix.
Same for lvalue subs called x or xx (or X or XX).
my $subject = "foo foo foo";
given ($subject) {
s/foo/bar/; # "bar foo foo"
++; # "bar foo fop"
x= 2;# "bar foo fopbar foo fop"
~= "!"; # "bar foo fopbar foo fop!"
}
Especially bare ++ would be useful, I think.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
