Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
On Saturday 20 March 2010 at 12:23, Richard Hainsworth wrote: In other words, I am suggesting a sort of mapping of the syntax of perl6 so that stable areas can us be used, perhaps avoiding instruments that are not yet explicitly stable. That assumes it's possible to know with sufficient certainty which pieces of syntax are sufficiently stable to mark as such. It's not *impossible*, and I encourage anyone willing to work on it to do so, but it seems like a large task. I wouldn't have predicted that =$fh would become $fh.lines. Manifest version number dependencies are an eventual necessity for Perl 6 (and hopefully Perl 5); moving to that model sooner rather than later could reduce a lot of pain. That seems like a smaller task which will pay off much more over time. -- c
Re: Gripes about Pod6 (S26)
On Wednesday 10 February 2010 at 13:49, Patrick R wrote: Actually, it's worth noting that (a slightly modified version of) Perl 5 POD has indeed been used to write several substantial books. I'd be very sad if (Perl 6) POD couldn't be easily used or converted into something that can be used to generate manual pages and reference documentation. I've written and edited several of these books. I'm happy to discuss features and misfeatures and scaffolding I've used to make POD suitable for writing and editing books. Perl 5 POD isn't too far off, but it does lack some important features. For the curious, the Modern Perl Github repository has a book in progress; see the tools/ directory for some hint of the necessary scaffolding: http://github.com/chromatic/modern_perl_book/ (Writing a book isn't too far different from writing documentation; many similar concerns apply.) -- c
Parrot 2.0.0 Inevitable Released!
The Beyond and below are like a deep of ocean, and we the creatures that swim in the abyss. We're so far down that the beings on the surface -- superior though they are -- can't effectively reach us. Oh, they fish, and they sometimes blight the upper levels with points we don't even understand. But the abyss remains a relatively safe place. -- Vernor Vinge, A Fire Upon the Deep On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0 Inevitable. Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.0.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 2.0.0 News: - Features + Context PMCs now support attribute-based introspection + Context and CallSignature PMCs merged into CallContext + .lex directive throws exceptions when used with incorrect register types - Platforms + Packaging improved for free OS distributions + PPC, PPC64, and ARM now tested when running Linux - Performance + Minor improvements to the profiling runcore + Improvements from the CallContext PMC merge - New deprecations + In/out parameters in STRING modification functions + Void handling in NCI signatures + Parameter passing opcodes order in PBC - Tests + Continued migration of core tests from Perl 5 to PIR - Tools + dependency checker improved - Miscellaneous + Deprecation cycle length changed to three months from six + GC accuracy improved + PMC freeze improvements; much more reliable + Makefile improvements for dependency handling Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 16 February 2010. Enjoy!
Announce: Rakudo Perl 6 Development Release #24 (Seoul)
On behalf of the Rakudo development team, I'm pleased to announce the December 2009 development release of Rakudo Perl #24 Seoul. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine (see http://www.parrot.org). The tarball for the December 2009 release is available from http://github.com/rakudo/rakudo/downloads Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo. Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. The December 2009 release is code named Seoul for Seoul.pm, who hosted Jonathan so well recently, and because they have a cake duck. Shortly after the October 2009 (#22) release, the Rakudo team began a new branch of Rakudo development (ng) that refactors the grammar to much more closely align with STD.pm as well as update some core features that have been difficult to achieve in the master branch [1, 2]. Most of our effort for the past month has been in this new branch, but as of the release date the new version had not sufficiently progressed to be the release copy. We expect to have the new version in place in the January 2010 release, but may elect to have an interim release from the new branch before then. This release of Rakudo requires Parrot 1.9.0. One must still perform make install in the Rakudo directory before the perl6 executable will run anywhere other than the Rakudo build directory. For the latest information on building and using Rakudo Perl, see the readme file section titled Building and invoking Rakudo. Some of the specific changes and improvements occuring with this release include: * Rakudo is now passing 32,192 spectests, a decrease of 561 passing tests since the November 2009 release. We pass fewer tests now because specification changes caused many obsolete (but passing) tests to be removed from the suite -- from 38,318 in November to 37,376 now. The percentage of passing tests has increased, from 85.5% in November to 86.1% today. * More improvements to the Rat type and related math functions to remain aligned with the specification. The Perl 6 language specification is still in flux. Please take note of the following changes, which might affect your existing programs. In the next release of Rakudo, the deprecated features will likely be gone. * The root of the object hierarchy has been changed from 'Object' to 'Mu'. The type 'Object' goes away. * The term 'undef' is gone. You can replace it with other constructs, depending on context: - 'Nil' is undefined in item context, and the empty list in list context - 'Mu' is the most general undefined value which does not flatten in list context - as a smart matching target, you can replace '$obj ~~ undef' by '$obj ~~ *.notdef' The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#25) is scheduled for January 21, 2010. A list of the other planned release dates and codenames for 2010 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! [1] http://use.perl.org/~pmichaud/journal/39779 [2] http://use.perl.org/~pmichaud/journal/39874
Re: .trim and 'gilding the lilly'
On Saturday 24 January 2009 05:56:03 Nicholas Clark wrote: And if left alone I can ramble that much, is anyone surprised that chromatic can't manage to minute several people discussing it? Amusingly, you were the one who didn't minute it; I wasn't on the call that week. -- c
Parrot 0.8.1 Tio Richie Released!
On behalf of the Parrot team, I'm proud to announce Parrot 0.8.1 Tio Richie. [1] Parrot is a virtual machine aimed at running all dynamic languages. Rat Creature #1: Comrade! We are about to feast! Quick, get your fat carcass behind this bush and get ready! Rat Creature #1: Hello, small mammal Could you step in here for a moment? I've got something to show you Fone Bone: Can't you show me out here, where I've got runnin' space? Rat Creature #1: No! No! Please! Step in here -- your friend the dragon isn't around, is he? Fone Bone: Hey, Ted! Where you goin'? Ted: You're on yer own, Bone! (exit stage left) Rat Creature #1: Quick, comrade! Start the cooking fire! Rat Creature #2: No. You called me fat. Fone Bone: Ted! Wait for me! Rat Creature #1: (pulls Bone into the bush) Well, well... Look who's joined us for supper... Go start the cooking fire!! Rat Creature #2: No. You called me fat. Rat Creature #1: No?!!! What do you mean, no?!!! Rat Creature #2: And it's not the first time you've done it either Rat Creature #1: Comrade... be reasonable! I wasn't thinking -- I was trying to catch our dinner -- this isn't the time -- I take it back you're not fat. Rat Creature #2: Too late! Rat Creature #1: Please, comrade! I just want to chop him up for the stew! Rat Creature #2: And that's another thing. I'm tired of stew! I want to put him in a crust and bake a light fluffy quiche! Rat Creature #1: Quiche?! What kind of food is that for a monster to eat?! Listen, do you think you could come back in half an hour? We'll have this straightened out by then! Bone: (runs away) Rat Creature #1: (beat) Why didn't you stop me? Rat Creature #2: Why should I? You're so smart! time passes Fone Bone: (hanging from a branch in a waterfall) Those rat creatures would have to be pretty stupid to follow me on to this frail, little branch! Rat Creatures: (follow Bone on to the frail, little branch) Fone Bone: Stupid, stupid rat creatures!! (branch breaks) -- Bone, by Jeff Smith Parrot 0.8.1 is available via CPAN (soon [2]). You may also see the Parrot download instructions[3]. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion [4] on our source code repository [5] to get the latest and best Parrot code. Please note the updated Parrot Roadmap [6] and our goals leading to the 1.0 release. Parrot 0.8.1 News: - Implementation + added CPAN module Storable 2.12 as a configuration and build dependency + removed the pseudo PIR opcode 'addr' + added the 'box' opcode + fixed 'pop_eh' handling in PIR libraries and examples + removed usage of .return for tailcalls (use .tailcall instead) + removed 'get_hash' and 'get_array' from Capture PMC and Capture_PIR + improved debugger and HLL coordination + allowed MMD primitive autoboxing + fixed all known memory leaks in PIR Hello, world! + NCI signatures now JITted on x86-32 platforms (Windows and Linux) + made the .const directive take a quoted type name instead of a constant + made IMCC more re-entrant - Languages + Rakudo - refactored Junctions implementation - added fire and forget tool to rebase/rebuild/test Parrot and Rakudo - updated container/reference semantics - added more builtin methods and functions - improved support for multilevel namespaces - added support for .Str, .succ, .pred in user-defined classes - implemented pointy blocks on if/loops - increased STD.pm convergence - added %*VM hash - improved MMD candidate sorting - improved integration of Num and Int - implemented increment on protoobjects - added initial support for MAIN subs - added .PARROT method + Pipp - added some predefined constants. - added implemention of the function basename(). + Cardinal (Ruby) - Added initial support for the classes Proc, Continuation, Queue, Dir, File , and FileStat - fixed various minor bugs - fixed broken Regexes - Compilers + PCT - added '.isa' method to PCT::Node - cleaned up 'immediate block' handling - allowed arguments to immediate blocks in loops/conditionals - metaclass objects can now 'add_method' + PIRC - integrated macro processing in PIRC's lexer - integrated heredoc lexer in PIRC executable - added preprocess and heredoc-preprocess commandline options - integrated the PASM grammar into PIRC - added a register allocator to optimize the built-in vanilla allocator - code cleanups and documentation - added 'make test' target + TGE - updated to work with new namespace/classname syntax - Deprecations + PARROT_API will become PARROT_EXPORT + :lexid will become :subid - Miscellaneous + Documentation
Re: The False Cognate problem and what Roles are still missing
On Wednesday 20 August 2008 15:16:12 Aristotle Pagaltzis wrote: It therefore seems necessary to me to specify dispatch such that method calls in the Dog role invoke the original Dog role methods where such methods exist. There also needs to be a way for a class that assumes a role to explicitly declare that it wants to override that decision. Thus, by default, when you say that Mutant does both Dog and Tree, Dog’s methods do not silently mutate their semantics. You can cause them to do so, but you should have to ask for that. How much of this does compile-time role method collision detection provide? If Dog and Tree both provide the bark method, the performing entity must disambiguate them. (I thought we had some syntax for When invoked as a Dog, do this and when invoked as a Tree, do that but I'm far too lazy to look that up at this moment.) -- c
Re: A few multiple dispatch questions
On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: I believe veto is giving the wrong idea here as something that happens after the fact. What's the term for only allowing acceptable candidates to put their names on the ballot? disenfranchise -- c
Re: A few multiple dispatch questions
On Tuesday 05 August 2008 15:25:47 Bob Rogers wrote: On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: I believe veto is giving the wrong idea here as something that happens after the fact. What's the term for only allowing acceptable candidates to put their names on the ballot? disenfranchise In the context of balloting, that applies to voters; the equivalent word for candidates is qualify (or disqualify). My state has closed primaries; same effect. -- c
Re: Fatal/autodie exception hierarchies for Perl 5
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote: Questions I'm seeking answers to are: * Is there a document that describes the current p6l exception hierarchy? My searching skills seem to be impaired today. * Does anyone have any input they'd like to make before I start fleshing out the hierarchy for p5 autodie? Hierarchies suck, especially singly-rooted hierarchies. Then again, multiply-rooted hierarchies turn into big cyclic graphs. Make a list of all possible types of exceptions, define them as roles, and group them that way. Any given exception can implement multiple roles (:CORE and :io, for example, or a specialization of that role that also does :USER). -- c
Parrot 0.6.2 Reverse Sublimation Released!
They were walking to the Hemlock, the Rooster and the Mice, and the Mice kept looking at one another, questioning. We don't know what the future holds, do we? said Chauntecleer. The Mice all shook their heads. They knew very little of anything. If, said Chauntecleer, I say, if I don't come back again, then you must make this food to last a long, long time. I trust your prudence, don't I? he asked, and they nodded automatically, but their eyes were very big. And I trust your integrity, right? They nodded. And you are mature, now, and I respect your maturity, isn't that so? Poor Mice, they nodded and nodded, and they blinked, and they nodded. They looked afraid. Good, said Chauntecleer. I know I won't be disappointed. In this way he gave each Mouse a manhood. They couldn't talk to him just now, having so much to turn over in their minds. But neither did they cry. -- The Book of Sorrows, by Walter Wangerin Jr. On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2 Reverse Sublimation. [1]Parrot is a virtual machine aimed at running all dynamic languages. Parrot 0.6.2 is available via [2]CPAN (soon), or [3]follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using [4]Subversion or [5]SVK on [6]our source code repository to get the latest and best Parrot code. Parrot 0.6.2 News: * Specification + updated and launched pdd28_strings.pod + updated pdd19_pir.pod * Implementation + added implementation of Rational PMC + simplified ops control flow syntax + enabled backtrace on non-glibc platforms too + improved some PIR error reporting + removed user stack opcodes (save, restore, lookback, entrytype, depth, rotate_up) (NOTE: This was scheduled to occur after 0.7.0, moved up to this release) + removed register stack, saveall, and restoreall opcodes + removed various deprecated features and unused code * Languages + Amber: retired + C99: grammar updated + Cardinal: resurrected, method calls and do blocks work now + Eclectus: use NQP as PAST generating code + Lua: o added big number library o updated to match PGE changes o added a bytecode disassembler a Lua 5.1 VM bytecode translator + Pheme: updated to match PGE/PCT changes + Plumhead: o use NQP as PAST generating code o use riaxpander for macro expansion + Rakudo: o updated ROADMAP o conditional and loop statement modifiers o lots of class, object, role, and method improvements o Str increment and decrement o improved spectest reporting o type checking on assignment o regexes and grammars o undef and self o placeholder vars + Squaak: added to repository + TAP: retired * Compilers + PGE: updated to match Synopsis 5, deprecated features removed + PCT: o improve handling of register types, conversion between registers o improved error diagnostics o add 'arity' to for loops * Configuration + added step auto::opengl + added step gen::opengl + added step gen::call_list * Miscellaneous + still more optimizations and performance improvements, especially in GC + new libraries: OpenGL/GLU/GLUT bindings (small subset working) + new dump_pbc.pl utility: PBC disassembly/source code weaver + improved C++ compiler support + optimized builds work again Gracias to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! References 1. http://parrotcode.org/ 2. http://search.cpan.org/dist/parrot 3. http://parrotcode.org/source.html 4. http://subversion.tigris.org/ 5. http://svk.bestpractical.com/ 6. https://svn.perl.org/parrot/trunk/
Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote: I have problems with a simple sum. The distance is artificially inflated if you make lots of small derivation steps vs one large change. The concept of derivation steps is ill-defined for parameterized types and types that change virtual type names during derivation so there is no subtype relationship. Those are precisely my objections. I'm not a fan of derivation in general, but I've never understood how changing MMD resolution based on degree of derivation didn't break Liskov. (Damian tried to explain it to me at least once, but he's smarter than I am and I didn't get it.) -- c
Re: First look: Advanced Polymorphism whitepaper
On Thursday 01 May 2008 06:35:12 John M. Dlugosz wrote: chromatic chromatic-at-wgz.org |Perl 6| wrote: This is why roles-as-types is so important: type inferencers can't infer allomorphism because allomorphism relies on explicitly-marked semantic meanings. What is your nomenclature here? vary in sound without changing its meaning? If I tell the type system that Foo and Bar are equivalent, then they're equivalent even if they have different internal structures and no other relationship in an inheritance sense. What are marked semantic meanings? Types. That is, in the context of Dog, bark means emit a sound. In the context of Tree, bark means the outer skin. Because guessing that bark and bark are cognates doesn't work (duck typing's false cognates) and because the internal structures don't have to be the same between actual cognates, someone has to tell the type checker that two separate entities are polymorphically equivalent. That person is the programmer, and that mechanism is the declaration that one entity performs the role of the other, or both perform the same role, or one subclasses the other. Note that you can implement polymorphic equivalence marking through subclassing in terms of roles, not vice versa. Note also that any given entity may perform multiple roles. -- c
Re: First look: Advanced Polymorphism whitepaper
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Then, since classes are open, the programmer can easily say
CGI does CGI::Simple;
That would be
class CGI is also { does CGI::Simple }
and means that CGI::Simple is a role, meant to serve as an interface
specification. It's not, it is a whole class that works on its own.
All classes imply the existence of a role of the same name.
-- c
Re: First look: Advanced Polymorphism whitepaper
On Friday 02 May 2008 11:55:54 Larry Wall wrote: On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote: : All classes imply the existence of a role of the same name. If a role is derived from a class, it must of necessity be a snapshot of the class, because roles are immutable, while classes are not. Agreed. The only interesting question in my mind is whether you can take another snapshot and override the previous one somehow, or whether such derived roles should version themselves so that the snapshots can be distinguished by longname. Alternately, we make one snapshot when a class is first composed, and refuse to make any other snapshots for that name regardless of how the class under that name changes. I'm not sure which is best. Snapshotting at the time of first composition (or the first time someone says Hey, I provide that other class's role!) seems right though. -- c
Re: All classes imply the existence of a role of the same name.
On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote: chromatic chromatic-at-wgz.org |Perl 6| wrote: All classes imply the existence of a role of the same name. Please justify that. http://www.perlfoundation.org/perl6/index.cgi?perl_6_people I could edit it into a Synopsis if you really want. -- c
Re: First look: Advanced Polymorphism whitepaper
On Friday 02 May 2008 12:48:43 Larry Wall wrote: On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote: : I'm not sure which is best. Snapshotting at the time of first : composition (or the first time someone says Hey, I provide that other : class's role!) seems right though. Or maybe a class is just a role that's been ORKED with a COW bit. Do we face a similar rug-yanking situation with delegatee classes being modified after delegate instantiation? I know there are some types of auto-handling, but are they all automatic? -- c
Re: All classes imply the existence of a role of the same name.
On Friday 02 May 2008 13:11:55 Larry Wall wrote: On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote: : I could edit it into a Synopsis if you really want. Tweet! Foul on #17. Two shots! What's the point of omnipotence if you can't swoop down from the rafters once in a while and save your hero from almost certain peril? -- c
Re: All classes imply the existence of a role of the same name.
On Friday 02 May 2008 16:07:56 John M. Dlugosz wrote: chromatic chromatic-at-wgz.org |Perl 6| wrote: Why is there any difference in declaring classes and roles if a class can be used as the target of either 'is' or 'does'? You can't instantiate a role. You can instantiate a class. When you declare a class, you're collecting behavior and state into a named entity. When you instantiate a class, you create an object with behavior and state conforming to that entity. When you perform type-checking against an object, you're specifying that you want something that conforms to a named entity. If you want polymorphism and genericity, you need a way to specify that -- despite the specific current class of an object -- anything which explicitly conforms to a named entity -- no matter *how* it does so -- is fine. There are two important points. 1) Naming collections of behavior and state is fundamental to the type system. 2) How any particular entity *implements* that behavior and state is not important, as long as you explicitly declare that conformance through some mechanism. 2b) If the only way to declare that conformance is through subclassing, you lose and I'll take your language designer license away*. 2c) If you have to edit other people's source code to extract a role from an existing class just so that you can declare explicitly that an entity of your own devising conforms to that role, you lose, and I'll take your language designer license away and salt the earth around your house*+. That's it. A class is a specialization of a role in that you can instantiate it. Everything else a role implies, a class implies implicitly. We are trying to avoid the java.lang.String is Final problem here in various ways. One of them is not allowing library designers to mark things as final. One of them is by allowing the happy coincidences of ad-hoc polymorphism by making polymorphic equivalence cheap and easy. One of them is by being a whole lot smarter and more handsome than the Java designers. * Note that there is no language designer license. Yet. + I do have salt. -- c
Re: First look: Advanced Polymorphism whitepaper
On Wednesday 30 April 2008 21:58:50 Brandon S. Allbery KF8NH wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of [Perl 6], it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. Given: my $result = $thingie.bark; ... where $thingie may be a Dog or $thingie may be a Tree, is bark a noun or a verb? Sure, it's a lousy example, but remember the immutable law of OO didactics: all examples must be terrible. Shapes, colors, and cars, -- c
Re: First look: Advanced Polymorphism whitepaper
On Wednesday 30 April 2008 08:56:24 Ovid wrote: That was always my goal for roles in the first place. I'll be a little sad if Perl 6 requires an explicit notation to behave correctly here -- that is, if the default check is for subtyping, not polymorphic equivalence. I had initially thought this, but think about the case where someone wants to rewrite something to be compliant to another interface. If I pass a CGI::Simple object to a method expecting a CGI object, there's an excellent chance that it will *just work*, even though there's no relation between the two. Sure; ad hoc polymorphism allows for cognates. Not all cognates are false cognates. (If no cognates were false, duck typing would work in a correctness sense. Sadly, both trees and dogs bark.) In this case, a role really doesn't work. I think that's a non sequitur. There's no allomorphism in your example. This is why roles-as-types is so important: type inferencers can't infer allomorphism because allomorphism relies on explicitly-marked semantic meanings. -- c
Re: Conceptual questions about Objects
On Saturday 05 April 2008 17:10:57 Larry Wall wrote:
On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
I suppose any object would do, it doesn't have to be but undefined, or
created using that Class{hash} syntax?
Possibly. Haven't really thought through the ramifications, and it
feels a bit like the problem of confusing clone with new. It would
be pretty easy for idioms to arise that create a lot of useless
temporary objects. You can only sweep so much under the carpet of
the optimizer could fix it...
In any case, the programmer really needs to keep straight when
an object is being used for its value vs when it's being used
for its type. Maybe that's not an issue here.
Parrot-wise, right now that's somewhat more expensive than it should be. The
carpet's not as large as I wish it were. (However it's possible not to
require instantiating a new object or class for type checks, let's do that!)
We have another possible level of granularity there too, insofar as we
could trust a single multi or a proto that represents all multis in
its scope. Maybe a proto exported from within a class automatically
conveys trust to all normal multis (of the same name) declared the
import scope.
Something about that I like.
Also, since classes can be re-opened, anyone can grab trust from any
class anyway, just by declaring a new method inside that class.
Well, sure. But whenever the programmer does that, the Perl 6 compiler
will automatically send email to the programmer's supervisor. :)
If you mean The World's Most Maintainable Programming Language, that was an
April Fool's joke.
-- c
Re: Conceptual questions about Objects
On Friday 04 April 2008 13:47:40 John M. Dlugosz wrote: But, it is also stated that in derived and trusted classes, and even in the class itself, $.a is an accessor call? As opposed to $!a which is the direct access to the attribute. Is this accessor different from the function form used outside the class? It shouldn't be. Why keep the variable syntax? Uniform access principle. See also Why Java programmers fetishize their IDEs, reason #482: autogeneration of metric boat-loads of accessors/mutators at just the click of a button. I'm getting a picture of 3 forms of access: Really direct, direct but asking the class to access it rather than knowing how storage works, and indirect that may involve your own code to do other things besides just get/set the attribute. But I think the middle one can be handled invisibly by the compiler -- it's no different from a tied hash. That really depends on how much external syntax you want to change if you change the internal representation of an object. For me, that's approximately none. -- c
Re: Conceptual questions about Objects
On Friday 04 April 2008 16:31:56 John M. Dlugosz wrote: chromatic chromatic-at-wgz.org |Perl 6| wrote: It shouldn't be. So you are saying that... I was talking about syntax. In that case, why allow the variable-name form at all? Because they're variables. Sure, they're instance variables, but like hearsay and conjecture are *kinds* of evidence, instance variables are kinds of variables. Sometimes it's nice to be able to assign to them, for example: method in_place_attribute_assignment ($.a, $.b, $.c); Why keep the variable syntax? Uniform access principle. See also Why Java programmers fetishize their IDEs, reason #482: autogeneration of metric boat-loads of accessors/mutators at just the click of a button. That seems to be saying that using the method-call form is preferred, as it abstracts whether it is a real hard attribute or not. Since my question was why keep the variable-name form, I think we are not understanding each other. Yeah, I think you're asking the question backwards. Maybe you should ask instead Why are there accessor methods for instance variables? Why not support only direct instance variable access? I'm getting a picture of 3 forms of access: Really direct, direct but asking the class to access it rather than knowing how storage works, and indirect that may involve your own code to do other things besides just get/set the attribute. But I think the middle one can be handled invisibly by the compiler -- it's no different from a tied hash. That really depends on how much external syntax you want to change if you change the internal representation of an object. For me, that's approximately none. I don't understand that sentence at all. Again, invisibly by the compiler sounds like what you want. I'm still talking about syntax; I don't care for lvalue methods that look more like methods, not variables. Maybe that's a personal failing. I also could be completely misunderstanding what you're asking. I *am* supposed to be researching a J2EE/SOA article at the moment. -- c
Re: Conceptual questions about Objects
On Friday 04 April 2008 16:56:44 Audrey Tang wrote: In other words, there needs to be no real hard attribute bar, no matter if you call the bar method as self.bar(), $.bar(), or simply $.bar. That's what I was trying to say with uniform access principle, except that Audrey's version is much clearer. -- c
Re: Perl 6 fundraising and related topics.
On Wednesday 26 March 2008 11:08:15 James Fuller wrote: can I add a few unsolicited ruminations from a lurker; * just release perl 6 now and move on To what extent? Larry just released Perl 5 some 13 and a half years ago, and there've been a few patches applied to it in the past 24 hours. (I wrote one of them.) If we released the current most-complete version of Perl 6 right now, we'd release code that's difficult to install, requires a difficult-to-install version of GHC, is out of date with regard to several tests and portions of the design, and is staggeringly slow. I can imagine that not everyone in the world would find that endearing. How many of them would stick around for Perl 6.01, let alone Perl 6.10? * do not hire 40 year olds with responsibilities, convince the young to spend their time for free ... isn't that what one is supposed to do after the age of 40 ? I'm under 40, and I've spent five years of my life working on this for free. I don't understand this idea; where does work magically happen? * use all funds to promote its usage, not fund its development See point one. * look at successful OS orgs like mozilla and apache (different to each other yes) and copy their techniques Their business plans started with: 1) start with corporate backing and paid developers We're approximately eight years late for that. a systematic plan past these points will then be possible. I think you're assuming a lot of MAGIC HAPPENS HERE points. -- c
Re: Perl 6 fundraising and related topics.
On Wednesday 26 March 2008 12:26:35 James Fuller wrote: I do not think that its right to release perl6 for the language, but it might be 'right' to do for language adoption no doubt cathedral / bazaar forces are in effect. I don't follow this; can you elaborate? -- c
Re: Perl 6 fundraising and related topics.
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote: What the perl6 language needs now is a systematic development plan, with broad aims and clear goals that will lead to good quality software and to the tools to enable ordinary programmers to use perl6 for a variety of tasks. Perl 6 has had several plans over the past eight years. What Perl 6 hasn't had in quite a while is paid developer time. Plans are good and plans are fine, but I've never seen a plan do the red-green-refactor loop once, let alone the few million times it'll take to finish Perl 6.0. -- c
Re: Perl 6 fundraising and related topics.
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote: What the perl6 language needs now is a systematic development plan, with broad aims and clear goals that will lead to good quality software and to the tools to enable ordinary programmers to use perl6 for a variety of tasks. Richard Dice mentioned that I should elaborate, lest it sound like I'm trying to lecture Richard Hainsworth (not my intent, and I apologize for doing so). It's important to keep in mind the degree to which one or two volunteers going on vacation can slow the progress of Rakudo (for a recent example) or to which one or volunteers putting in a few extra hours of visible work can improve the progress of Parrot (for a slightly less recent example). A plan that includes some degree of funding will help Perl 6 arrive much sooner. Previous plans glossed over this part, which is one reason they didn't work out in the long term. I just want to make sure that any discussion of a plan acknowledges that there's a fixed amount of work to go and an unknown amount of available resources to implement the plan. -- c
Re: Perl 6 fundraising and related topics.
On Thursday 21 February 2008 06:25:42 Joshua Gatcomb wrote: Here is something to consider. Unless we can afford to fund an individual full time with enough money for them to pay for their own health coverage and other benefits, the amount of time they are volunteering is already as much as they can afford. In other words, they still have to work a regular job and make time for their family (or whatever substitutes for the real world) and giving them money isn't going to equate to them being able to devote to more time. That isn't to say that these volunteers don't deserve to get compensated but it is unrealistic to expect that money will equate to more time in many of the cases. I could take a month's sabbatical from my day job for $5000 without losing insurance coverage or other benefits. That's slightly more than Audrey's $100/day, I know, but it's substantially less than my consulting rate and somewhat less than my salary too. I could probably make 100 - 150 high-quality commits to Parrot in that 30 day period. Perhaps more. I'm probably not the only Parrot/Perl 6 hacker in this situation. -- c
Re: [svn:perl6-synopsis] r14500 - doc/trunk/design/syn
On Tuesday 05 February 2008 20:02:53 Mark J. Reed wrote: Ah, macros, is there no problem you can't solve? :) If my experience with the Perl 5 core is any guide, the problem of too many macros. -- c
Re: pluralization idea that keeps bugging me
On Saturday 26 January 2008 08:58:43 Larry Wall wrote: That would cover most of the cases for English speakers using regular nouns, but I wonder whether there's some kind of generalization that would help for cases like: say There was/were $o ox/oxen That makes me wish for a subjunctive/optative mood marker. I'm not sure why. In-language localization and internationalization hooks do seem awfully useful, but English-only pluralization rules just might not cut it. Nearly pain-free l10n and i18n *is* kind of a killer feature though. -- c
Re: $?OS semantics
On Monday 07 January 2008 08:42:06 Trey Harris wrote:
Then we can have roles that describe cross-cutting behavior of various
OS's (like POSIX):
my trytolink;
give $?OS {
when OS::HasSymlinks { trytolink := *symlink; }
when OS::HasLinks { trytolink := *link; }
default { trytolink :=
- ($old, $new) { fail X::LinkNotAvailable }
}
}
I agree, but these examples seem more like characteristics of filesystems than
an OS.
-- c
Re: Official Perl 6 and Parrot wikis
On Saturday 29 December 2007 13:35:00 Mark J. Reed wrote: Ok, consider me duly chastised. Sorry for the sidetracking. It's not a *bad* idea, but it's less important in my mind than getting useful information on the wiki. Anyone who wants to pursue it can do so, but I'd like to forestall a long digression on the list about it. That's all. -- c
Re: Bite-sized Tasks for the Interested (was Re: Standards bearers)
On Thursday 13 December 2007 13:37:19 ispyhumanfly wrote: Any questions? :) Is it possible to see a list of tasks without the barrier of creating an account, requesting an invite, or logging in? I understand that a little bit of administrative overhead is useful, but I'd also like to see as little friction to getting started as possible. If the solution is to put a link on the appropriate Perl 6 sites saying Bite-sized tasks for the interested, see this wiki page and then hop on this IRC channel or send a mail to this list, that's probably fine. -- c
Bite-sized Tasks for the Interested (was Re: Standards bearers)
On Tuesday 11 December 2007 09:20:22 Paul Hodges wrote: But on this general note, is there any current organization or location where small problems are being parcelled out? I'd love to help, but my time is as limited as everyone's If I could get small bites of work to do, maybe I could contribute something useful. Anyone requesting one black-box module or function at a time? Or am I pipe dreaming? I used to publish a Pugs and a Parrot task of the week in the Perl.com newsletter, but there didn't seem to be much uptake and so it slowly dissolved. It might be nice to have a small list of bite-sized tasks for the interested linked off of dev.perl.org/perl6 and the various project pages. I know there's a Perl 6 wiki around here somewhere, so in theory all we need is someone to prune the page regularly and poke various projects asking for a couple of small tasks for the uninitiated. -- c
Re: Standards bearers (was Re: xml and perl 6)
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. If you send me or the Parrot list the Parrot test results, I will do my best to fix them. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Hey, I'm a trained musician and sometimes novelist who develops software on the side, and the primary reasons @Larry absorbed me are that: 1) I transcribe conversations faster than anyone else on the team 2) I had a working keycard to O'Reilly's Tarsier meeting room in Sebastopol and the reason I keep working on this stuff is: 3) I'm some combination of too stubborn or too stupid not to keep working on it All it takes to make a contribution is a fraction of my stupid or my stubborn plus some spare time. -- c
Re: Standards bearers (was Re: xml and perl 6)
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
Re: xml and perl 6
On Thursday 29 November 2007 03:21:18 cdumont wrote: By listening to you all, we shouldn't even think to implement file access... Please drop the sarcasm. A programming language is made by humans and subject to the same evolutions and bugs and in the end is alive and will die. A programming language should evoluate, try to respond quickly to the actual environment in order to survive or expand. Have you *seen* how much time p5p spends on keeping little-used modules that someone successfully argued were absoutely vital to the future of Perl now and forever up to date? If you want to talk about responding quickly to the environment, look at the CPAN. If you want to talk about a low work to value ratio, look at keeping things like B::CC up to date and passing their tests. Now there's a vestigial organ. -- c
Re: xml and perl 6
On Thursday 29 November 2007 07:07:18 James Fuller wrote: I have been arguing that having some simple functionality, provided by the core, would potentially harmonize usage across modules and promote better understanding of code, in general, through consistent usage. That didn't work for File::Find in Perl 5. What makes you think we'll SURELY get it right THIS time? (Put another way, of all of the uses you've seen of File::Find, how many of them were beautiful or seemed like natural expressions of programmer intent?) -- c
Re: xml and perl 6
On Wednesday 28 November 2007 10:59:30 James Fuller wrote: I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? Because it's not necessary for getting and installing other extension modules. The criterion for including a module in the core is Is this necessary to get and install other modules? not Why not include this module? -- c
Parrot 0.5.0 Caulked Snack released!
Jack had avoided looking into his sons' faces during this Oration, because he reckoned they'd not wish to be seen with tears streaming down their faces. But looking up at Jimmy now he saw dry eyes and a quizzical if impatient phizz. Turning the other way, he saw Danny gazing distractedly at the White Tower. ... Before you embark on a new life overseas, assuming that is your fate, Jack said, find Eliza and tell her she is my true love. And then he jerked the chains loose from the restraining grip of first Jimmy, then Danny. He leaned forward, pushed off against the rail with both feet, and launched himself into space above London. His cloak spread in the wind of his flight like the wings of an eagle, revealing, to anyone who might be gazing up into the sky, a lining made from cloth-of-gold that glistered in the rays of the setting sun like the chariot of Apollo. He was on his way down. -- Neal Stephenson, The System of the World On behalf of the Parrot team, I'm proud to announce Parrot 0.5.0 Caulked Snack. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.5.0 is available from the CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.0 News: - Implementation + PDD15 (OO) branch merged with trunk; this release contains a working, tested implementation of the latest OO model + Added pop_eh/push_eh_p/count_eh opcodes + Add --runcore command line option + Add gcdebug runcore to help track down GC bugs + minor improvements to IA-32 JIT - Documentation + PDD19 (PIR): updates to macros, .pcc* directives + PDD25 (Concurrency): updated + PDD26 (AST): draft approved + PDD23 (Exceptions): draft approved + Copyright cleanups - Languages/Compilers + languages/APL: minor updates, PDD15 conformance + languages/dotnet: minor updates + languages/lua: minor updates, PDD15 conformance + languages/lisp: minor updates + languages/perl6: minor updates, PDD15 conformance + languages/plumhead: minor updates + languages/punie: minor updates, PDD15 conformance + languages/nqp: minor updates + languages/scheme: many updates, PDD15 conformance, improved tests, use PMCs instead of primitive registers to represent values + languages/tcl: bugfixes, PDD15 conformance + languages/WMLScript: minor updates + compilers/pirc: updates from PDD19, PDD06 + compilers/pct: minor updates, PDD15 conformance + compilers/pge: PDD15 conformance + compilers/tge: PDD15 conformance - Configuration + Improve test coverage + Improve reporting when a step fails; allow abort on failure - Miscellaneous + More coding standard conformance, tests, cleanup, speedups, warnings cleanup + Bug cleanup, esp. GC bugs + Eliminate .imc extension (use .pir) + Simplify some core config steps to not allow interactive prompting - Removed + clear_eh opcode Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
Re: Web Module (Was: Perl6 new features)
On Monday 25 June 2007 00:57:18 Hakim Cassimally wrote: Releasing a language without a useful, easily installable library bundle could quite reasonably be construed as a stupid business practice. Of course. Yet some dozen years later, the argument for keeping interfaces such as File::Find (because sysadmins should learn all about closures and callbacks but can only understand global variables) and code such as CGI.pm (it was SelfLoader before SelfLoader was cool and *that* was a while ago) in the Perl 5 core has absolutely nothing to do with quality, ease of use, or suitability for the problem domain and everything to do with incidentally having been first and, thus, immediate evolutionary dead ends. -- c
Re: Web Module (Was: Perl6 new features)
On Thursday 21 June 2007 15:23:38 Smylers wrote: Has Larry yet decreed whether Web will be bundled with Perl 6? I also like to proceed from the assumption that the only core modules should be those required to install other modules. -- c
Re: Web Module (Was: Perl6 new features)
On Friday 22 June 2007 11:07:35 Chas Owens wrote: Please, god, no. Or at least make two distributions: Bare Perl 6 and Perl 6. Many companies have a Only Core Perl policy. They refuse to install CPAN modules because We don't trust them. I think of this the same way I think of Do not drink even if you mix with beer labels on bleach bottles. Stupid people often remove their genes from the pool. We should not discourage stupid business practices from doing the same. -- c
Re: propose renaming Hash to Dict
On Thursday 31 May 2007 17:36:40 Chas Owens wrote:
Except of course those poor schmucks who foolishly wrote code like
if (ref $arg eq 'HASH') { ... }
I know you're teasing, but it *would* be nice to see that sort of code just
magically go away.
-- c
Parrot 0.4.12 Of the Caribbean Released
As I sailed into Shadow, a white bird of my desire came and sat upon my right shoulder, and I wrote a note and tied it to its leg and sent it on its way. The note said, I am coming, and it was signed by me. ... The sun hung low on my left and the winds bellied the sails and propelled me onward. I cursed once and then laughed. I was free and I was running, but I had made it this far. I now had the chance I'd wanted all along. A black bird of my desire came and sat on my left shoulder, and I wrote a note and tied it to its leg and sent it off into the west. It said, Eric--I'll be back, and it was signed: Corwin, Lord of Amber. A demon wind propelled me east of the sun. -- Nine Princes in Amber, Roger Zelazny On behalf of the Parrot team, I'm proud to announce Parrot 0.4.12 Of the Caribbean. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.12 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. The next release will take place on 19 June 2007. Parrot 0.4.12 News: - Build: + even more refactorings and improvements in configuration system + improved tests and documentation for configuration system - Languages: + Updated abc, PHP (Plumhead), Lua, Tcl + Reclaimed Lisp - Design: + new PMC PDD draft partially completed - Implementation: + continued implementation of PDD 15 (Objects) + minor garbage collector and memory management improvements + several memory leaks resolved + extended support for compilers other than GCC + improved C++ compiler compatibility + enhanced support for Solaris, non-MSVC Win32, and other platforms Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote: I'm not a friend of potential conflicts between built-in operators and my identifier names (and especially the conflicts between scalar, aggregate, type, and function names). As I partially wrote Moritz, I a) don't think that it's the case very often. you have to write the sigil a thousand times where it wouldn't be useful for only 1 case where you'd have a name conflict. b) even if there would be a conflict, it might be considered bad style to use identical identifiers (besides the sigil) for different things (vars/objects/subs/operators/...). theproblemlinguisticallyspeakingisthatsometimespunctuationishighlyimportant\ fromareadabilitystandpointyoumaynotliketheuseofspacescommasdashesupper\ casinghyphensandperiodsbutitmakesatremendousdifferencetoreadabilitywhether\ youlikeitornotasitmaybebadstyleifyoudontputspacesbetweentwowordsandtheresult\ lookslikeawordthatsomeonemaydefineinthefuture There *are* a few linguists involved in Perl. So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. Somehow English seems to get by with periods at the ends of statements, though almost no one pronounces them. But I don't like doing implicit type casting with operators. It's even discouraged in Perl5 as we have a warning for that. So maybe it'd be a good idea to completely drop it. I can't really see that changing DWIM to DWTWM is anything but a step backwards in Perlishness. People not only want code that _is_ sexy, but they also want it to _look_ sexy. At least almost everyone to whom I said, that I do most work in Perl, responded with some sentence containing the word ugly or unreadable. To get away from that image, it's neccessary to do some radical changes I think. I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix that. By the way, I'm still waiting to meet your cadre of Dylan hackers. -- c
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote: BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? Perhaps you're not a native English speaker, but running into the room and saying Perl 6 doesn't have a compelling vision, Everyone thinks Perl is ugly, and Python and Ruby are doing things better than Perl 6 is *not* the way to start a friendly and neutral discussion, as if a sane, calm, neutral discussion of programming language designs and tradeoffs were possible. -- c
Re: Sigils by example
On Monday 14 May 2007 15:48:24 Thomas Wittek wrote: But it should be no problem to put out a warning/error at runtime (or maybe even at compile time) when a variable name clashes with a method name. Do you always know all of the method names in your entire memory space at compile time? -- c
Re: Is Perl 6 too late?
On Sunday 13 May 2007 15:42:30 Thomas Wittek wrote: What makes Perl hard to read is the excessive use of special characters (/\W/). It also makes Mandarin and other ideographic languages impossible to read. As evidence I admit that, though I am very smart, *I* can't read them. (Try to ignore the billion-plus people who can.) Global variables with cryptic names, that no beginner can make any sense of by reading it. And after not working with $ for some months I can't remember it either, although I've got quite some Perl experience. Most of those have gone away. Additionally I'm not a friend of sigils: I'm not a friend of potential conflicts between built-in operators and my identifier names (and especially the conflicts between scalar, aggregate, type, and function names). I would also like semicolons to be optional. There are far more cases of single line statements than multiline statements. So you would save quite some characters, when the semicolon would be optional and you could concatenate multiline statements with e.g. a backslash. When (smart) people talk about Python's whitespace problem, they don't mean *horizontal* whitespace. Some say that there are too much operators in Perl(6). I partially agree. That's like saying there are too many function calls in Scheme. Perl's an operator-oriented language! People not only want code that _is_ sexy, but they also want it to _look_ sexy. You'll have to find me more than a handful of Dylan hackers to start to convince me of that! -- c
Re: Is Perl 6 too late?
On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: What is nedded is a very simple step: Contributors. -- c
Re: Working on punie + rindolf (the implementation) Reloaded
On Tuesday 10 April 2007 18:51, Shlomi Fish wrote: (Although it seems the most interesting promises made by parrot - fast typeless code for example - are not going to be delivered, too). Hmmm I haven't been closely following Parrot. Despite this mention, this thread is off-topic for the Parrot list, and probably the Perl 6 Language list too. The Parrot list is happy to discuss implementations and languages targeting Parrot. Complaints are welcome only in the form of bug reports sent to [EMAIL PROTECTED] Neither flames nor whining are welcome at all. -- c
Re: Packed array status?
On Monday 26 February 2007 11:29, Geoffrey Broadwell wrote: Does Perl 6 on Parrot have Perl 5 connectivity? Not until Perl 6 can use PIR code. After that, it depends on what you want to do with the two. If you can get Parrot::Embed compiled and running on your machine, Perl 5 can have Parrot connectivity. (As far as I know, Windows is the only broken platform now, but I already knew that.) -- c
Re: What criteria mark the closure of perl6 specification
On Saturday 24 February 2007 22:42, Richard Hainsworth wrote: But while perl6 continues its evolution, without a tangible end, few are going to dedicate time and effort to write documentation for such as me. (eg. How out of date are the Exegesis files?) You could make a very similar argument for Perl 5. I'm not sure anyone expected--as recently as a year ago--that 5.10 would get a slew of new regex features, for example. -- c
Re: What criteria mark the closure of perl6 specification
On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote: As I mentioned in another thread, but didn't make clear in that email: I don't need a finished spec. I need the *current* version of spec to actually be mostly implemented. The implementors want the same thing. And if it's not fun, I won't end up putting any of my very limited free time into it. Neither will the implementors. -- c
Re: What criteria mark the closure of perl6 specification
On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote: I'm not trying to say that the implementors should rush either, nor am I complaining about current status; I grok the dynamics of volunteer code. I merely disagree with the spec is all-important crowd. I personally have a preference for rough consensus and working code, and I wanted to make sure that viewpoint wasn't lost. Me too. I also want to point out that we're not nearly at the point where adding more developers--for as much or as little as they want to contribute--will slow things down. -- c
Re: Packed array status?
On Sunday 25 February 2007 12:40, Geoffrey Broadwell wrote: What backends support packed native arrays at this point? And what's the performance like? Parrot does have ManagedStruct and UnManagedStruct PMCs for mapping complex C structures. The syntax to define them is a little grotty, but once you've done that, using them is easy--especially with named access. Performance is good. You don't have to cross the C/HLL boundary to work with the memory, as Parrot can do that directly. I don't know if Patrick has using PIR libraries working in Perl 6 yet, but the last time we talked about it, he said it would take just a bit of work. Wrapping well-designed libraries for Parrot's NCI is easy. I can show you the basics in an hour and you'll be well on your way. -- c
Re: Y not
On Tuesday 20 February 2007 12:42, Larry Wall wrote: 'Course, if someone goes ahead and adds the Y combinator, one must naturally begin to wonder what the YY combinator would be... :-) Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed existentialist solipsist operator. -- c
Re: where constraints as roles (was Re: how typish are roles)
On Saturday 28 October 2006 09:15, Larry Wall wrote: My initial inclination is to say that where clauses in a signature are only there for pattern matching, and do not modify the official type of the parameter within the function body. However, on a subset the where clause is there precisely to contribute to the typing, so if you want the extra constraints to apply to all uses of the parameter variable within the body, you'd need to declare a subset type that enforces it. Right; it's awfully difficult to have nominal typing in a room full of blank Hello my name is tags. On the other hand, I can imagine that an alternative would be to say that a where clause will always subsetize the official type; that would imply that we'd need to add a when clause for mere pattern matching. Something to be said for making such a distinction, if it can be taught. -- c
Re: Don't tell me what I can't do!
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: Would there be such tools used in the core libraries? Maybe, maybe not, we could discuss that. If they were implemented in the core libraries would there be a universal no bondage flag that shut them off? Probably, since that's something that Perl tends to like doing. The assumption I remember from the design meetings was always No library designer has the knowledge or the right to tell me how fast or strict my program has to run. Whatever BD you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. In my opinion,Perl 6 should spell no bondage: #!/usr/bin/perl6 -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 01:05, jesse wrote: One of the things that many shops have defected from Perl to Java for is the additional handcuffs that Java provides for less-than-experienced developers. Giving me the power to control what my team, or folks using my language variant, do could be a huge win. The point is that the person writing the program decides which handcuffs or costumes all of the code has to wear, not the person writing the libraries. If you want to set a policy for your organization, that's fine. It is just Not Okay for me or anyone to write a module right now that dictates exactly the strictness of every program written in the next twenty years that uses it. -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:09, jesse wrote: Perhaps I'm misunderstanding what you mean by person writing the program and person writing the libraries. In fact, I've _gotta_ be. I'd like to be able to put my strictures in a library rather than forcing them into the main body of a program. Are you saying you don't want to let people do this? Let me rephrase. Libraries and modules can be as strict or as lax as they like, but the program *using* those libraries and modules should always be able to override those strictures. If you write a class in a library and declare it as closed, that's fine -- but any program that uses the class should always have the option of saying Nope, not closed. I need to do something with it. It's the person *using* the libraries and modules and classes who knows how strict they need to be, how closed they need to be, and how optimized they need to be. If any of those policies are irreversible--if they leak out of libraries and modules and classes--then there is a problem. -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:48, jesse wrote: Ok. So, I think what you're saying is that it's not a matter of don't let people write libraries that add strictures to code that uses those modules but a matter of perl should always give you enough rope to turn off any stricture imposed on you by external code. Do I have that right? Yes. You might also add ... or enable further strictures, but that sounds like what I was trying to say. -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 13:25, Trey Harris wrote: I read it as yes, you *can* put strictures on the using code into a library, though I wouldn't do it and would say that any module that does so shouldn't be released on CPAN for general use. But even if you can do that, you *must* always be able to turn the strictures back off. chromatic, is that a fair paraphrase? Yes. I don't have any problem with that sentiment--if I were you and needed to enforce some style on other programmers who work with me, I'd just tell them to use my library and not unuse it. It's a human problem, not a technical one, if they insist on unusing it by nefarious means. Very much so. It seems silly to put up barriers such that clever people have to use ugly and hackish tricks to do clever things while attempting to use technology to solve the social problem of other people doing really bad things. If you violate my first law of software development (Don't hire monkeys!), then you should at least follow its corollary (Train your monkeys well and watch them very carefully. Note how unfulfilling your life is for violating the first law.). That philosophy doesn't present any problems with DBC checks, which as I mentioned before probably have to handled as a program-global flag rather than as a lexical pragma anyway. (I'm toying with the notion of jurisdictions that packages could subscribe to across which a set of contracts would be enforceable, allowing them to do DBC while still using or being used by code out in some other lawless jurisdiction. Code that doesn't explicitly join some jurisdiction would by default be lawless, thus living by the philosophy chromatic's espousing. I think that could be made to work, though jurisdictions would have to be at a package, not scope, level. I need to think about it more, though.) That sort of thing ought to be quite possible, but the less work we spend on giving people the illusion that this discipline is inescapable and perfectly capable, the more time we'll have to tell them how to avoid hiring monkeys, which actually fixes more problems in software development than anything else I've ever seen. -- c
Re: class interface of roles
On Monday 02 October 2006 08:58, Jonathan Lang wrote:
I wonder if it would be worthwhile to extend the syntax of roles so
that you could prepend a no on any declarative line, resulting in a
compilation error any time something composing that role attempts to
include the feature in question. So, for instance, you might have
role Bar {
no method baz (Num, Str);
}
class Foo does Bar {
method baz (Num $n, Str $s) { ... } # compilation error: Bar
forbade this method!
}
This feels like the false-cognate problem waiting to creep back in.
-- c
Re: Fwd: Classes / roles as sets / subsets
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote: Perl6 handles both object-orientation (through inheritance) and role-playing (through composition). What exactly does inheritance have to do with object orientation, except that some OO systems support inheritance? Plenty of OO systems get along just fine without it. I wrote a fuller explanation of roles in my work weblog: http://www.oreillynet.com/onlamp/blog/2006/08/roles_composable_units_of_obje.html -- c
Re: optimizing with === immutable comparitor
On Friday 14 July 2006 00:30, Darren Duncan wrote: This may go without saying, but ... If $a === $b means what I think it does, then I believe that a not-premature implementation optimization of === would be that it always $a := $b if it was returning true, so that any future === of $a and $b or aliases thereof could short-circuit with a =:= test even if they weren't created as aliases, and Perl would be automatically more memory efficient without those extra storage copies. I know that was an implementation issue, but I think that it stands to be explicitly stated anyway, as it is a very simple and effective way to make Perl programs more resource efficient, possibly by orders of magnitude, over not doing so. First there was copy-on-write and now there's share-on-compare? (The only time this may not work is if so-called immutable types are tied to external resourses, but then I'm not sure how often this would happen in practice so it could just be an exception if necessary. The above-stated rule would still stand for any resources managed by Perl itself.) In the absence of much Perl 6 code either way, I wonder at the value of adding such an extreme side effect to a simple comparison operation. This goes way beyond loop hoisting and constant folding. I can understand singleton value types (even Perl 5 does that with PL_undef), but ... wow, you have a lot more faith in local code analysis than I do. -- c
[svn:perl6-synopsis] r9305 - doc/trunk/design/syn
Author: chromatic Date: Sun May 21 14:11:09 2006 New Revision: 9305 Modified: doc/trunk/design/syn/S06.pod Log: Minor typo fix. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSun May 21 14:11:09 2006 @@ -53,7 +53,7 @@ =head1 Routine modifiers BMultimethods (keyword: Cmulti) are routines that can have multiple -variants that shares the same name, selected by arity, types, or some +variants that share the same name, selected by arity, types, or some other constraints. They may have multliple invocants. BPrototypes (keyword: Cproto) specify the commonalities (such
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
On Thursday 11 May 2006 14:54, Smylers wrote: What about :gappy, to indicate that there have to be gaps in the source text at the points where there are gaps in the pattern? I like this better. Forming a new compound word and then abbreviating it seems confusing -- and I'm a native English speaker. -- c
Re: A shorter long dot
On Saturday 29 April 2006 21:50, Damian Conway wrote: Is: $antler. .bar; $xyzzy. .bar; $blah. .bar; $foo. .bar; really so intolerable, for those who are gung-ho to line up the method names? I'm still wondering what's awful about: $antler.bar; $xyzzy.bar; $blah.bar; $foo.bar; -- c
Re: A shorter long dot
On Saturday 29 April 2006 16:58, Yuval Kogman wrote: On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote: This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( You're not counting the space around the dot, which counts. To me they look completely different Two invisible things look completely different to you? -- c
Re: A shorter long dot
On Saturday 29 April 2006 18:29, Yuval Kogman wrote: If dots looked like this: then they would be invisible. Use a laptop with a speck of dust in the wrong place in slightly wrong lighting and the wrong four pixels might as well be invisible. Precious few of @Larry deserve the nickname Ol' Eagle Eye. This really doesn't seem like a place to argue for such subtlety when the difference in behavior is so large. -- c
Re: foo..bar or long dot and the range operator
On Wednesday 12 April 2006 00:06, TSa wrote: Doesn't that discontinuity devalue the long dot? Its purpose is alignment in the first palce. For a one char diff in length one now needs foo. .bar; self. .bar; instead of foo .bar; self.bar; Or even: foo.bar; self.bar; I *still* don't understand the problem this long dot is trying to solve. -- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: Does this imply that we should think up this process? Go ahead. If I propose a concrete plan for the implementation of Perl 6 in a layered fashion it will probably be even more overlooked. I have no authority, and this is not something I can do on my own. If other people find it valuable, that's all the authority you need. The last time someone tried to set forth a complete specification in a particular order was the Perl 6 documentation project. That didn't work then. I have doubts that specifying a complete compiler and toolchain without at least some trial and error will work, but I could be wrong. Maybe the right place to start is to gather a list of all of the questions you need to have answered and all of the features people want, and then try to unify them into a Perl 6-ish whole. -- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 13:28, Yuval Kogman wrote: Right now the biggest problem in Perl 6 land is project management. I disagree, but even if it were true, I don't think the solution is to add more project management and design to partition the process into even more subprojects of nebulous definition and dubious benefit. If you *want* Perl 6/Scheme running on Spidermonkey, that's cool. I just don't see an army of volunteers magically appearing to make it work, not in the least because it's Yet Another Rewrite From Scratch. -- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote: If we have more steps and clearer milestones for whatever is between parrot and the syntax/feature level design implementation will be easier. Parrot has had such milestones for well over a year. De-facto we have people running PIL on javascript. It works more than parrot does. No, it works *differently* from Parrot, just as an LR parser works differently from an LR parser. Don't make the mistake of thinking Wow, it took Parrot X months to get a working PGE, while the Pugs version only took Y weeks, especially because the Pugs version had the benefit of looking at *already designed, debugged, and tested* Parrot code. The design of Perl 6 itself should be agnostic to where people are developing backends IRL. That's a nice goal in the sense of diversity, but I remain unconvinced of its utility in speeding up the implementation. Every abstraction comes at a price. The recent velocity of Pugs toward the goal of running on N multiple backends rather than one backend seems to argue that education is still cheaper than ignorance. -- c PS - Yes, that *is* a Greek-English pun. Language interoperability is a good thing.
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 15:56, Stevan Little wrote: The Pugs project and the Parrot project have had very different goals actually (at least Pugs did from the early days). Pugs aimed to be able to evaluate Perl 6 code, as a way of testing the language features and design. It did not really attempt (until the PIL work began) to provide a VM for Perl 6 to run on. In my mind, that's the most valuable thing Pugs could do. And even the PIL work began as a way to strip Perl 6 down to a more managable core calculus which was easier to interpret, the multiple backends seemed to grow out of that as a side-effect. But they're not free to support. Now I'm not arguing that the existence of multiple backends takes effort away from a single unified backend. This is open development. People work on what they want to work on. Still, finding the greatest common factor of features between LLVM, Scheme, Spidermonkey, classic Pugs, Parrot, the CLR, the JVM, Perl 5, and whatever other VM is out there means pushing a lot of things up the implementation stack. Much of what Yuval is proposing is ways to fill that hole and to decompose and refactor the current Perl 6 development process so that we can have a real production Perl 6 to play with that much sooner. I agree that that's his goal. I disagree on its appropriateness. There are people who can write a bootstrapping compiler from the top down in such a way that normal people can write the user-level primitives in that language. I've met those people. I'm not one of them. There are precious few of them for any language, much less Perl 6. It's not fast. It's not free. It's not clear that they'll suddenly appear to do this work if there's a comprehensive, intelligible rework of the Perl 6 plan. I could be wrong and if Yuval writes the plan and it works, great! I'm happy to be wrong. But also have a Perl 6 that some PhD canidate can re-write the type-checker for his thesis project or that some volunteer hobbiest can re-implement the core in FORTH or some open source hacker can hack the circular prelude to make the Schwartzian transformation that much quicker and efficient. Again, I can see the theoretical benefit to that, but it's still not free. The well-worn adage is Good, fast, or cheap -- pick two. Perl 6 development right now is cheap but hopefully good. Reducing the goodness might make it faster. Reducing the cheapness might too. I think the real problem is somewhere in there. IMHO breaking down the project into smaller more digestable chunks carries as much risk of failure as putting all the eggs into single Parrot nest. Exactly how is Yuval's proposal making the chunks more digestible? There's sort of a dearth of Scheme, CLOS, Haskell, and Scala experts in Perl 6 development right now. Where are they going to come from to write all this stuff? -- c
Re: Perl 6 OO and bless
On Friday 20 January 2006 07:14, Rob Kinyon wrote: I think this entire issue is rising out of the fact that very very few people in this discussion are familiar with the design of the MOP. Stevan and a few others are the primary movers and I'm lucky enough to have been Stevan's sounding board for a few pieces. Once you grok the MOP, it's really hard to imagine wanting to use bless(). I don't think that it's a fair assumption that, for example, I haven't followed the metamodel discussions and designs. Nor do I think it's a fair assumption that people who want to interoperate with a lot of Perl 5 code should have to understand the finer points of metamodels and metaobject protocols in the default case. -- c
Re: Perl 6 OO and bless
On Thursday 19 January 2006 21:53, Stevan Little wrote:
Okay, so when you say alternate storage then you mean that a class
like this:
class Foo {
has $.bar;
method new ($class, %params) {
$class.bless('p5Hash', %params);
}
method baz {
$.bar += 1;
}
}
should use a PMC representation of a p5 hash as it's storage, and
that the method baz does the right thing here?
Yes.
Because that makes sense to me. However, what doesn't make sense
would be if I had to write baz like this:
method baz {
self-{'bar'} += 1;
}
In other words, if this is just a detail of the storage, and does not
affect user code at all, then I am okay with it. This though would
mean that you would not have direct access to the underlying data
structure (the p5 hash).
I don't think it's impossible, but it's fairly ugly and I'm okay if you can't
do it by default from the Perl 6 side. I certainly wouldn't use it.
From the Perl 6 side, I would rather use Perl 6 looking code.
Okay, then I assume you mean it to behave the same way as with the
p5hash, that it is completely transparent to the user that you are
using a p5hash or a p6hash or a p6opaque?
From Perl 6? Yes.
In which case,.. I say okay. But note again that you have not
provided access to the underlying data structure (the p6hash a.k.a -
an instance of ^Hash).
Agreed.
With p5, you /can/ get to the underlying data structure. This is a
break which will hamper the backwards compatibility effort I think.
With Perl 5, you can *appear* to get to the underlying data structure. Yet
tie() is basically free on Ponie and there's a metaclass mediating access to
the underlying storage. I think that makes the problem solvable.
(Does using an alternate type of storage mean you need an alternate metaclass?
Perhaps, perhaps not -- but the practical effects of syntax have to come from
somewhere.)
As long as you can use Perl 5 classes in Perl 6 without rewriting all of the
Perl 5 code, I'm happy.
-- c
Re: Class methods vs. Instance methods
On Thursday 19 January 2006 06:48, Rob Kinyon wrote: Any practical programming language with structural subtyping will probably let you create and use aliases for type names (so you don't have to write the full form everywhere). However, the underlying type system will only consider the structure of the type when doing its job. What's wrong with Perl doing things that way? duck-typing with names ... sounds like a plan to me ... Accidental structural equivalence is a problem -- it's one of the things wrong with C's so-called type system, for example. I like to think of roles as nominally-tagged (and checked) structural subtyping. When you're *defining* a type, its structure matters. When you're *using* it, its behavior matters. It would be nice to keep those two separate. -- c
Re: Perl 6's bless is (seriously) broken
On Thursday 19 January 2006 13:10, Rob Kinyon wrote: bless was a brilliant idea for Perl5. It's wrong for Perl6. Perhaps you meant to write Tagging a reference with a package name worked for Perl 5. It's wrong for Perl 6. Certainly I can agree with that. Yet this whole discussion feels like the argument that there should be no system() operator in Perl 6 because the system() operator in Perl 5 returns the wrong value. -- c
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: On 1/18/06, chromatic [EMAIL PROTECTED] wrote: Answer me this then -- under your scheme, can I subclass a Perl 5 class with Perl 6 code, instantiate the subclass, and use that object in Perl 5 code as if the subclass were Perl 5 code, without rewriting all of my Perl 5 code? You have two cross-language interactions. 1) Subclass a LangX class in LangY 2) Instantiate a LangY class and use that object in LangZ That LangX === LangZ is irrelevant to the discussion. Unless, of course, if $omeone had promised backwards compatibility with LangZ 5 from LangY 6. So long as you aren't peeking behind the curtain (method calls only), Parrot should be able to mediate everything. In other words, if your code is good OO code, then you shouldn't have any problems. In other words, your answer to my question is no. Fine. Next question. If Ponie and Perl 6 are both running on Parrot, and if Ponie has PMCs that represent Perl 5 data containers, such as p5hash, p5array, p5symbol, and so on, what's the problem with having a Perl 6 object that uses one of those PMCs as its internal storage? I realize one of Stevan's objections is But if you use a Hash, does your object automatically support the .keys method and .kv and so on? to which I reply No, of course not. That's silly. It just uses the Hash for *storage*. Is that your objection to bless()? I don't mean to handwave here -- there are definitely issues to consider when crossing a language boundary related to method dispatch (and the last I remember from design meetings was things change there and you shouldn't expect that they stay the same), but the resistance to allowing different storage types for objects completely baffles me. Or is the question about Why is there a need for bless() when you can already pass arguments to CREATE()? In that case I dunno. -- c
Re: Perl 6 OO and bless
On Thursday 19 January 2006 19:50, Rob Kinyon wrote: Nothing. Just like it's not a problem if Perl6 uses one of the Ruby-specific PMCs for storage. In fact, the alternate $repr idea is specifically to allow for the use of foreign datatypes as storage. Luke's excellent example is to use a C-struct as your storage. ... but ... Storage of what? What are you trying to do that you need to use an object to store your attributes? Why aren't you just using the method -that- object is using? I can't reconcile these two paragraphs. No. My objection to bless() is BUILD() and CREATE(). There's already a mechanism in the P6 OO system for specifying the internal representation of the instance. This is Perl. The there should be one obvious way to do it ship, canoe, raft, and water wings have sailed, paddled, floated, and inflated. -- c
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 14:13, Stevan Little wrote: Do we really still need to retain the old Perl 5 version of bless? What purpose does it serve that p6opaque does not do in a better/ faster/cleaner way? Interoperability with Perl 5 code. Now if you want to write a p6opaque - Perl 5 thunking layer -- c
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote: Well, for one thing, you can't write OO code in P5. I'll play your semantic game if you play my what-if game. I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5 code to Perl 6 slowly. Everything new is Perl 6 code. When I have a chance, I migrate classes and modules from Perl 5 to Perl 6 code. I have a handful of Perl 5 classes. One day, I need to subclass one of them. Per my goal, I do so in Perl 6. Of course, it has to interoperate with the Perl 5 in the system, per that pesky Liskov rule. If I can specify an alternate internal representation for the object corresponding to the appropriate internal representation for the Perl 5 class I'm extending, great! If not, your programming language sucks and doesn't do what the box leads me to believe that it should do -- especially if the answer is Well you shouldn't want to do that. -- c PS - You can't write procedural code in Haskell. You can't write functional code in C. You can't write readable code in Ada. Okay, I think that's out of my system now.
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote: As for how that will be handled, I would think that it would be as follows: - in Perl6, objects created in another language will be treated as p6opaque (unless some other unbox is a more suitable $repr). ... and I specify this exactly how? -- c
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote: No, you want to specify the $repr in CREATE(). But, p6hash will still not be the same as a ref to an HV. Frankly, I think you're better off letting Parrot mediate things the same way it would mediate Ruby and Perl6 or Perl5 and Python. Worrying about it in userland is just going to cause you headaches. Answer me this then -- under your scheme, can I subclass a Perl 5 class with Perl 6 code, instantiate the subclass, and use that object in Perl 5 code as if the subclass were Perl 5 code, without rewriting all of my Perl 5 code? -- c
Re: [OT?] Quote (was: Re: handling undef better)
On Monday 19 December 2005 05:06, Michele Dondi wrote: Speaking of which: | The connection between the language in which we think/program and the | problems and solutions we can imagine is very close. For this reason | restricting language features with the intent of eliminating programmer | errors is at best dangerous. -- Bjarne Stroustrup In theory, I agree. In practice, HEY look over there at that thing that is not C++! -- c
Re: handling undef better
On Friday 16 December 2005 22:25, Darren Duncan wrote: At 10:07 PM -0800 12/16/05, chromatic wrote: This is fairly well at odds with the principle that users shouldn't have to bear the burden of static typing if they don't want it. This matter is unrelated to static typing. The state of whether a variable is defined or not is orthoganal to its container type. I didn't say container typing. As I see it, your concern is what happens when trying to *coerce* something containing the undefined value. But more to the point, if you assign your default values at strategic places, you are not writing very much extra code at all. Objection: not very much extra code is asymptotically greater than no extra code. A change this great from Perl 5 seems like it ought to provide a whole heap of benefit to make up for the whole big heap of inconvenience everyone now has to live with. So far, I'm not even seeing a little heap of benefit. Mathematical-theoretic purity is a nice idea, but I'm usually too busy trying to do actual work to appreciate anything beyond hey, can I write robust, maintainable working code without too much effort and time? Those few characters are nothing considering the amount of hassle they can save. I didn't buy that argument from the static manifest typing everywhere folks either. What happens if you have a sparse array with the greatest index of 10 and you want to assign something with an index of 100? Do you have to give the array an explicit default value? What if you create it in a module somewhere? What if it's a generic array and you don't know when you create it what type of default value it should contain? What if 0 is a valid value that means something entirely different from default initialized but unassigned? All of a sudden, am I going to have to care about the default value of every container I create or receive from somewhere, just in case its notion of truth and definedness doesn't match mine? If so, how inconvenient is the code? If not, why not? -- c
Re: handling undef better
On Friday 16 December 2005 18:15, Darren Duncan wrote: Therefore, I propose that the default behaviour of Perl 6 be changed or maintained such that: 0. An undefined value should never magically change into a defined value, at least by default. This is fairly well at odds with the principle that users shouldn't have to bear the burden of static typing if they don't want it. It sounds like you want to override the coercion of undef to fail, at least in a lexical scope. Go for it. I can't see it as a default behavior though. Sure, the literal expression 6 + undef is pretty silly, but I don't really want to write 6 + Maybe $variable (sorry, Haskellers) everywhere when the compiler is perfectly capable of DWIMming in the 98% of cases where $variable is undefined because I like being so lazy as not to initialize explicitly every possible variable I could ever declare, being very careful to distinguish between 0, '', and undef in boolean context. I suspect the remaining two percent of cases, I won't write 6 + undef either. -- c
Re: Flunking tests and failing code
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote: I wonder if there is a macroey thing that we can do here. That is, could we make: ok(1); is(1, 1); like(foo, /foo/); Into: ok(1); ok(1 == 1); ok(foo ~~ /foo/); Can you do it without giving up the nice diagnostics that Test::More::is() provides? Note that Test.pm in Perl 5 uses ok() for everything and that DWIMmery too often doesn't. -- c
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote: But my argument was: whenever you start introspecting a call frame, by almost whatever means, this will keep the call frame alive[1] (see Continuation or Closure). That is: timely destruction doesn't work for example... Destruction or finalization? That is, if I have a filehandle I really want to close at the end of a scope but I don't care when GC drags it into the void, will the close happen even if there's introspection somewhere? -- c
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote: This is a very valid concern, but the problem will not arise unless people start mixing these two styles --- something which is very obviously not a good idea. That doesn't mean that people will avoid it, by accident or on purpose. It's a serious concern worth more consideration than just don't do it! -- c
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote: Yet you have the choice of where to put your braces, even though the braces don't lend themselves to different tasks depending on whether you put them on a new line or not. You *don't* have the choice to use different types of braces, though -- at least not by default. Is Perl 6 really in such a desperate need of new and more powerful features that issues of convenience are irrelevant? I see the proposal to treat - and _ as identical in identifiers as a feature almost as useful as making identifiers case-insensitive. Heteronymity seems too dangerous to encourage by supporting as a default. -- c
Implicit Role Declarations (was Re: implicitly doing a role)
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote: If roles are interfaces, do we want any class that provides an interface consistent with a role to implicitly do the role? That is, if a class fulfills all of the interface requirements of a role without actually saying it does the role, does it do the role anyway? After thinking about this a little more, I think there may be a bit of misunderstanding about what I want here. Having a class implicitly *do* a role if it has methods and attributes of the appropriate name is a bad idea -- there's too much room for accidental collision there. Sure, people shiny-eyed about duck typing might reasonably say Why? That doesn't make sense! but it's a careless duck typer who randomly throws objects in collections and hopes for the best. You *can* mistakenly use an object that quacks incorrectly and spend some time debugging it, but if we're providing a system that can catch some of that incorrectness, I don't see what benefit there is to subverting its ability to detect incorrectness. What I want instead, and what might seem similar in the sense that it's exactly the opposite, is implicit declaration of a role for each explicitly declared class. That is, if I declare a Dog class, there immediately springs into being a Dog role empty of everything but the expectation that whatever does that role provides everything publicly accessible that an instance of the Dog class does. You don't get the nice code-reuse of roles, but you can use your doglike object -- Mock Dog, Dog Proxy, Logged Dog, Decorated Dog -- anywhere you can use a Dog and everyone's happy. They're man's best friends, you know. -- c
Re: implicitly doing a role
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the role, does it do the role anyway?
No.
role Dog
{
method bark { ... }
}
class Tree
{
has $.bark;
}
A role is a named collection of behavior and state, not just a list of
method and property names. The context is highly important. It's the
difference between homonyms and allomorphs.
-- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: I would prefer to use roles as they're closed by default, leaving class to be my powertool, if I need the power. I don't understand this desire; can you explain your reasoning? (NB: closed here, as I use it, still *does not* correspond to licensing or availability of the source code.) -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote: But we find that many programmers make decisions that trade readability and extensibility for an extra 1% of speed, even when they are writing a command-line frontend to MPlayer[1]. If those people are module writers, then we have a bunch of modules on CPAN that are not friendly to the user who wants to use the module in the one way the writer didn't expect. Worse, that's a *theoretical* 1% of speed based on non-profiled code. And if you're going to use roles for everything because they're closed and they will gain you 2% of speed on one particular backend, then we'll have to make the same rule for them too. I know it sounds like we're babying our programmers. We are, because it's such a widespread superstition. I prefer to think of it as Helping to prevent them from writing unreusable code. And just to reinforce that it's a superstition: a theory defines a vtable. If you extend the class in an incompatible way, you have to make a new instance of its theory, defining new vtable slots. Once the new vtable is created, it is just as fast as the old one. There is no speed loss whatsoever for keeping your class open. Even further, don't forget that someone, somewhere will really need to do something you didn't think of. Either he extends your class somehow or works around it in an ugly, funky way. Which one is faster to write? Which one is faster to execute? Which one is more likely to be correct? Which one is more maintainable? -- c
Re: Ways to add behavior
On Wed, 2005-10-26 at 14:52 -0400, Uri Guttman wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW One wants to coin a word like Qlass. Unfortunately qlass is LW too easy to misread as glass. Oy veh, I'm getting notions of LW the qlass is half empty for a partially instantiated object. [EMAIL PROTECTED], i think you need some immediate mental help. please step back from the keyboard before you commit such a sin again. the next time, i will ask gloria to stick you with a knitting needle. is the smiley :) or (: ? I can't believe you missed the opportunity to write qloria. -- c
