Re: Arrays: Default Values
At 10:54 AM -0800 1/30/03, Mark Biggar wrote: and if we define a prop is no_default then you get what ever junk happens to be in memory. (this for even more speed) That's not going to happen. It's too unsafe, and too open to corruption attacks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
At 10:59 AM -0800 1/29/03, Austin Hastings wrote: Now: Does this require a fake undef and a real undef? WHO CARES? Very good answer. Leave the details to me and the p6i folks. (Though do please, everyone, pay attention when we tell you that what you want is slow or awkward) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
At 12:40 PM -0500 1/29/03, Aaron Sherman wrote: Elements of a has ARE ordered, just not the way you may expect. Just to nip this one in the bud... If people start assuming that there's *any* ordering to hashes, I promise I *will* make sure that parrot's external hash class starts returning keys and values in random order. Hashes have no guarantee of ordering, and perl 5 (as Nick demonstrated) delivers on that lack of guarantee. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Arrays: Default Values
At 2:18 PM -0800 1/29/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:59 AM -0800 1/29/03, Austin Hastings wrote: Now: Does this require a fake undef and a real undef? WHO CARES? Very good answer. Leave the details to me and the p6i folks. (Though do please, everyone, pay attention when we tell you that what you want is slow or awkward) Usually, I'm assuming that anything we ask for, you'll be unable, due to geek pride, to stand up and say I can't implement that. Oh, I can implement almost anything, and the quantum ninja take care of anyone who suggests things I can't implement. That's not the issue--it's efficiency, that's the issue. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Array Behaviors
At 8:46 AM + 1/28/03, Piers Cawley wrote: Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. Given the current implementation (And I hear rumors that you lurk on the internals list, Piers... :) I think we can manage something like this. Might require a drop to assembly somewhere, perhaps hidden behind a function rather than with syntax, but it should be doable... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Spare brackets :-)
At 8:47 AM + 1/28/03, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Array Behaviors (Take 2)
At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote: OK, here are the answers so far -- or more accurately, strawman interpretations of those answers that should be objected to if they're wrong. I think some of this is incorrect which, because Damian thinks otherwise, will need some hashing out from Larry on how he wants perl arrays to behave. Because... 1) Edge cases in array indexing: my int @a = (1,2,3); @a[3] # undef (warning: index out-of-bounds) Or a real 0, since you said @a can only return integers. @a[2**128]# EXCEPTION: index is above max allowed index Except we can manage this internally, so I don't know that it's a problem @a[ Inf ] # undef (warning: can't use Inf as array index) I'd throw an exception here. @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) Or zero, since it's an int array. 2) There is a platform-dependent maximum array size, ((2**32)-1 for 32-bit platforms.) Attempting to access an index outside that range throws an exception. Note that this applies to both 'real' and 'sparse' arrays. But since we've got big(int|float|rat)s there's no real reason for that to be a problem. If you want to use 10**100**100 as an array index, you could just throw an awful lot of memory at us... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Spare brackets :-)
At 4:17 PM -0500 1/28/03, Aaron Sherman wrote: Now the question becomes, do you WANT them for readability? Given that Larry's answer has been a resounding yes all along, the technical reasons (Which are, themselves, sufficient) are pretty irrelevant. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Spare brackets :-)
At 5:07 PM -0500 1/28/03, Aaron Sherman wrote: On Tue, 2003-01-28 at 16:34, Dan Sugalski wrote: At 4:17 PM -0500 1/28/03, Aaron Sherman wrote: Now the question becomes, do you WANT them for readability? Given that Larry's answer has been a resounding yes all along, I'm not sure that this specific case was brought up. I am. Larry was clear--square brackets for array access, squiggle brackets for hash access. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod/multisub thought...
At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod/multisub thought...
At 10:02 AM -0800 1/24/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but if it looks like a scalar ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar There's also the fun of: Dog bar(int); Cat bar(int); and xyzzy(Dog); xyzzy(Cat); with the call of: xyzzy(bar(1)); Just one of the many brain-benders that I'm glad Larry has to deal with, not me. (Though this may be one of the reasons A6 is taking so long...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Why Cmap needs work
At 11:02 AM -0800 1/23/03, Michael Lazzaro wrote: Yes, no doubt so, and good point. I think I should make it clear that my speculation on somehow unifying Cfor and Cmap is _not_ an attempt to gut A4, because I like A4 quite a lot. I'm just thinking out loud about how we could _extend_ A4 in one particular way. This, I think, is where I beg and plead--given how much effort it takes for Larry to get new apocalypses out, I'd really rather not make it so we want him to revisit old decisions while an apocalypse is in progress. (Yeah, for the week or two after one comes out, sure, just not when he's working on a new one) Either he'll be ignoring perl6-language (if I have to ask Robert to unsubscribe him :) or he'll be thrashing between the new stuff and revisiting the old stuff. Yeah, it's selfish, but I can't get perl 6 implemented if you guys keep distracting Larry so he never gets the darned thing designed. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod/multisub thought...
At 7:30 AM + 1/24/03, Piers Cawley wrote:
In my quest to eliminate as many explicit conditionals from my code as
possible, I found myself wondering if Perl 6's multidispatch mechanism
would allow one to write:
sub gmttime ( $time = time() ) is in_scalar_context {
strftime( $perls_default_time_format, $time );
}
sub gmttime ( $time = time() ) is in_list_context {
...
}
where 'in_scalar_context' and 'in_list_context' are place holders for
better syntax.
There's been some discussion of this, doing MMD based on return type
as well as the parameters. It's definitely cool, but IIRC it's
potentially a bit of a pain, since context is odd in spots.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/17/03, David Storrs wrote: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? Because it makes life significantly harder for everyone on the planet who already has a perfectly fine local system. What you're asking for is a massive software, hardware, and data conversion project, with all the work being done by all the world that doesn't use straight ASCII. Given that covers a good 80% of the world, well... seems just the tiniest bit arrogant to me. Very few people need to deal with inter-language data exchange. The vast majority of data is kept in the native language of the operator of the system, with most of the remainder in 7-bit ASCII, which fits in everyone's local character set anyway. Unicode is like XML. It's the least-bad solution we have for general data interchange. We just don't often *need* general data interchange. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/16/03, Austin Hastings wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 12:05 AM + 1/16/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. I was shooting for the good old days of sarcasm that people noticed, but alas I missed. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Array Questions
At 9:23 AM -0800 1/14/03, Michael Lazzaro wrote: On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Compile time error. 'is' is a compile time property, scalar values aren't. That's what I first thought, but... why is that a compiletime error, if the previous example my %data is FileBasedHash($path); is not? I'm not sure either of them *has* to be an error, as the compile-time properties that is imparts need to be evalutated and applied at runtime. The my $foo is $bar would mean that we couldn't do any compile-time type checking, but that's not a huge deal as presumably you wouldn't *want* any type checing in that case. Whether it is a good idea or not from a maintenance/programmer-brain standpoint is a separate issue. I think I'd rather dislike having to maintain code that did it, but I can see a few good reasons to do it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 6:35 PM + 1/13/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 1:10 PM + 1/6/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... Well, you'll certainly be able to use delegation to get in the way if nothing else. Go on, how would delegation help in the case where you want to be subclass Array so as to be able to do: my TiedArraySubclass @foo; Then (assuming that Larry either approves of or doesn't notice my Evil Plans) @foo is a variable of type TiedArraySubclass, which had best have a vtable capable of dealing with keyed access. How it does this, by completely reimplementing an array form, or acting as a layer on top of the base array implementation that it redispatches to is up to whoever implements TiedArraySubclass. Presumably, from the name, there wouldn't actually be a real array under the hood, but there certainly could be. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 10:52 AM -0800 1/13/03, Austin Hastings wrote: --- Mr. Nobody [EMAIL PROTECTED] wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Think it through... Perhaps not everyone feels they're a bad idea...? The question, then, is Does Larry? (I already do, but that's not necessarily a showstopper) Requiring things outside the ASCII 7-bit range is problematic, as it requires a Unicode-capable system. That's somewhat troublesome if you're already dealing with an extended ASCII system that's not Unicode. (Full Latin-1, Cyrillic, Japanese, Chinese, or Korean systems, for example, though you can potentially get by) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 11:19 AM -0800 1/13/03, Austin Hastings wrote: So the real question should be What kind of upgrade path are we providing for converting these tired old multigraphs into single uniglyphs? Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing, though there are then source-interchange problems. Dunno whether that'll be considered a problem, though. (I don't see it as such) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 2:08 PM + 1/9/03, Peter Haworth wrote: On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote: At 7:29 PM -0700 1/7/03, John Williams wrote: Perhaps you could explain how the $0 object will work in your mind. A5 assert that $0 is a object, and it behaves as an array and a hash, depending on how you subscript it. Typeglobs are gone, and we're all hoping the TIE interface is gone too, so how will this effect be accomplished? All variables in parrot are implemented as PMCs, and all PMCs may be accessed with a string, integer, or PMC subscript or set of subscripts. For PMCs that don't do subscripting this will be a fatal error, for those that do it'll do whatever the PMC is supposed to do. (In the case of $0, do the lookup) That's phrased like it's the type of the subscript value which determines whether it's a hash-like or array-like access. Shouldn't it be the type of brackets which do that? [snip] Maybe it is the right way round, and I've read your remarks the wrong way. Or maybe it is the value type which determines the type of access at the PMC level, and it's up to the compiler to force the type based on the brackets. Got it in two, more or less. I'm waffling on whether a type flag in the key structure is necessary--I can see it going both ways. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 7:29 PM -0700 1/7/03, John Williams wrote: On Tue, 7 Jan 2003, Dan Sugalski wrote: 2. There is a primitive array type that is promoted to an objectified Array class when needed. This would be analogous to the int/Int distinction for primitive numbers. This would be visible to programmers, but may be acceptable for the same reason as the int/Int types are. Not unless Larry really insists. Primitive arrays aren't sub-, super-, or side-classes of objects--they aren't objects at all. (They're arrays, hence the name array) You may be able to treat them in some ways as objects, but that doesn't make them objects any more than treating arrays like integers makes them integers. Perhaps you could explain how the $0 object will work in your mind. A5 assert that $0 is a object, and it behaves as an array and a hash, depending on how you subscript it. Typeglobs are gone, and we're all hoping the TIE interface is gone too, so how will this effect be accomplished? All variables in parrot are implemented as PMCs, and all PMCs may be accessed with a string, integer, or PMC subscript or set of subscripts. For PMCs that don't do subscripting this will be a fatal error, for those that do it'll do whatever the PMC is supposed to do. (In the case of $0, do the lookup) If you really, really, really wanted to, you could consider PMCs as objects. You may have to squint really hard and paint them pink, but...that PMCs do is allow you to call a method on them, which we don't guarantee will work as we don't guarantee there's even a package associated with a PMC) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 9:30 AM + 1/7/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Well, you'll certainly be able to use delegation to get in the way if nothing else. Beyond that I'm not sure, but anything that's not based on the parrot Object PMC (which we've not quite yet defined) won't necessarily be directly inheritable from. So make Hashes and Arrays based on the Parrot Object PMC. Why let implementation get in the way of a really good language? :) Ah, it's too early for a good rejoinder, but rest assured I almost had one. :) The short answer, I suppose, is that we're not recreating Smalltalk--at least some small nod is being made towards Practicality. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 10:54 AM + 1/7/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: The short answer, I suppose, is that we're not recreating Smalltalk--at least some small nod is being made towards Practicality. I really don't follow your argument here. What's impractical about being able to inherit from Arrays? Nothing, the impractical part is making arrays objects--they aren't, and we're not particularly going to go out of our way to make them so. Like I said, you can always use delegation to subclass an array, or limit yourself to an odd and restrictive subset of behaviour. (Basically just vtable method overriding) I'm dropping a dump of parrot's object model thursday, at which point everyone can rip into me properly and with good facts to back up theories of my crack-headedness. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 1:10 PM + 1/6/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... Well, you'll certainly be able to use delegation to get in the way if nothing else. Beyond that I'm not sure, but anything that's not based on the parrot Object PMC (which we've not quite yet defined) won't necessarily be directly inheritable from. Doesn't mean you won't be able to build your own custom PMC types based on existing PMC types, but I'm not really sure I'd consider that OO or inheritance as such. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 1:19 PM -0800 1/3/03, Dave Whipp wrote: I am taking the viewpoint that everything is in object. Then you'll likely be somewhat surprised at times. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
At 8:43 PM + 1/5/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: I am taking the viewpoint that everything is in object. Then you'll likely be somewhat surprised at times. Can you elucidate? (I admit to be very tempted to answer this Yes and leave it at that... :) I suppose it depends on what you consider object behaviour. If that definition is I can call methods on it then yeah, I guess everything'll be objects, but even my standards aren't that low, and I don't *do* objects. Things that aren't explicitly objects won't have reference semantics. They won't have attributes. They won't do any of the other dozen or so things objects should do. They will be neither pine fresh nor lemony scented. I can guarantee you that *I* won't be thinking particularly objectly (or objectively, to forestall the obvious rejoinder) about things that aren't objects. An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Everything is an object.
At 5:45 PM -0800 12/16/02, Dave Storrs wrote: On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote: At 11:12 AM -0800 12/16/02, Dave Storrs wrote: You find R2L easier to read, I find L2R easier. TIMTOWDI. Perl6 should be smart enough to support both. Why? Yes, technically we can do both R2L and L2R. We can also support an alternative Scheme/Lisp form of perl's syntax, as well as a Forth/Postscript style. Heck, we can probably manage a prolog-style unification style for a not-insignificant subset of perl programs. That doesn't mean its a good idea. Just so I'm clear, are you saying that you think L2R is a bad idea, and should not be supported? Or just that it has not yet been demonstrated that this is a good idea? I think it's a good idea, and that it should *not* be supported. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Everything is an object.
At 11:38 AM + 12/17/02, Andy Wardley wrote: Simon Cozens wrote: Once again we're getting steadily closer to inventing Ruby. Agreed, but I don't think this is necessarily a Bad Thing. Disagreed--we're getting steadily closer to inventing Smalltalk. :) Which isn't altogether a bad thing. (As long as we don't vet closer to inventing Lisp...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Everything is an object.
At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
Umm... I think some of these recent messages have had typos between
L2R and R2L. (?) In that people seem to have been arguing against
themselves. (??) I'll try using -- and --.
On Monday, December 16, 2002, at 05:45 PM, Dave Storrs wrote:
Just so I'm clear, are you saying that you think L2R is a bad idea,
and should not be supported? Or just that it has not yet been
demonstrated that this is a good idea?
We _must_ (for some value of must that is real close to being a
100% drop-dead requirement) support -- (L2R), in the form of
@a.grep( {...} )
.map( {...} )
.sort;
Those are simple method calls, so there's no reason we shouldn't
support them, though they will *only* work if each returns an actual
array, rather than a list. They are, however, not the same as doing:
@b = @a grep {} map {} sort {};
because that's true L2R, as it'll work for:
@b = (*@a, *@b, foobar()) grep {} map {} sort {};
That can't work as methods of the list, unless we're wildly
redefining how lists work, which I don't think we're going to do.
*That's* the sort of way, the L2R way, that I'd argue against.
Shifting directions in mid-stream is, well, really tough for us old
codgers.
And you can't get rid of the old way, since it's just implicit
function calls. To forbid
@b = sort {} map {} grep {} @a;
is the same as forbidding
@b = sort({}, map({}, grep({}, @a)));
which I think would be... unwise. As would chopping sort/map/grep and
friends from the language entirely. One of the hallmarks of perl is
its richness, and I think losing that would be ill-advised.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Everything is an object.
At 2:47 PM -0800 12/17/02, [EMAIL PROTECTED] wrote: On Tue, Dec 17, 2002 at 09:48:56AM -0500, Dan Sugalski wrote: Simon Cozens wrote: Once again we're getting steadily closer to inventing Ruby. Agreed, but I don't think this is necessarily a Bad Thing. Disagreed--we're getting steadily closer to inventing Smalltalk. :) Silly rabbit, Ruby is Smalltalk! And it's part of this nutritious breakfast! Well, adjacent to it, at least... :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Everything is an object.
At 11:12 AM -0800 12/16/02, Dave Storrs wrote: On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Mind you (purely devil's advocate), I'm not entirely sure the R-to-L syntax truly _needs_ to be in Perl6. It's true I use it all the time, but I can retrain to use L-to-R method calls with little effort.\ Personally I really don't like the L to R style; That's ok. Personally, I do. You find R2L easier to read, I find L2R easier. TIMTOWDI. Perl6 should be smart enough to support both. Why? Yes, technically we can do both R2L and L2R. We can also support an alternative Scheme/Lisp form of perl's syntax, as well as a Forth/Postscript style. Heck, we can probably manage a prolog-style unification style for a not-insignificant subset of perl programs. That doesn't mean its a good idea. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity
At 9:55 PM -0500 12/12/02, James Mastros wrote:
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd
have to assure that no object id's are *ever* reused -- so mem
addresses are out, since the same address may be used for
different things at different points in time.
There'll definitely be memory address reuse. If .id returns the
current object's memory address, it shouldn't be cached any place,
as otherwise you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above.
As long as valid!=correct, sure.
(That IDs should be unique across a process over all time.) If
that'd require that an object's ID be a combination of the header
address and a generation counter, that's OK. It means a
serilization point in the allocator, but I think we'd need one no
matter what (Dan?).
That's going to be expensive, and that's a bad idea. If you want an
expensive and long-lived variable tracking facility, build one and
add it on later. The base version should be fast, and sufficient for
the common case.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Comparing Object Identity
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd
have to assure that no object id's are *ever* reused -- so mem
addresses are out, since the same address may be used for different
things at different points in time.
There'll definitely be memory address reuse. If .id returns the
current object's memory address, it shouldn't be cached any place, as
otherwise you'll find things going bang with some regularity.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Comparing Object Identity
At 2:42 PM -0800 12/12/02, Dave Whipp wrote: Dan Sugalski [EMAIL PROTECTED] wrote in message news:a05200f00ba1ebb73c6d2@[63.120.19.221]... There'll definitely be memory address reuse. If .id returns the current object's memory address, it shouldn't be cached any place, as otherwise you'll find things going bang with some regularity. In a multi-threaded environment, even a simple $a.id == $b.id may have significant time between the two lookups. No, that's not a problem, since neither $a nor $b can possibly go anywhere, as they're both being referenced. The GC is aggressive, but we do wait until a variable is at least dead before reaping it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 2:28 PM -0800 12/11/02, Michael G Schwern wrote: On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote: On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote: This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Given that this will not be a commonly used feature, I wouldn't give it a special operator. Just use a method. $foo.sameas $bar; %foo.sameas %bar; @foo.sameas @bar; I'd have to agree. Testing for this sort of thing seems relatively uncommon, and wasting punctuation on it doesn't seem worth it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: right-to-left pipelines
At 3:24 AM + 12/12/02, Simon Cozens wrote:
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
Can we dictate that parentheses are optional in this case, and demand
parentheses in all others?
You see, the problem is that if we don't know what method we're going
to call until way after we've parsed the code, (which I hope we've
just proved above) we don't know how many parameters it's going to
take. And if we don't know how many parameters it's going to take
until we run it, we have next to zero chance of working out how many
parameters it's going to take when we compile it. Which was the basis
of my semi-serious notion of caching the whole set of possible parses.
It's even more interesting when you add function calls into things, like:
$foo = bar $x, $y, foo();
Since that may be either:
$foo = bar($x, $y), foo()
in which case it's in scalar context, or
$foo = bar($x, $y, foo())
in which case it's in list context (sort of)
The fun thing is that, potentially, you need to actually *call* foo()
to figure out what context to call foo in. (Since, depending on what
it returns, you may dispatch to different bar subs, which may or may
not actually need what foo returns, thus changing its context)
Except that this all sprung from my idea of having a block passed
directly to a method without the other arguments being
involved. (Which would work without parens, optional or
otherwise. (because it works exactly this way in languages like Ruby
(but most Perl 5 people can't get their heads around that (which is
why this idea is facing a dead end.
Ruby blocks that get passed to functions can only appear in a few
well-known places, and always at the end of the parameter list.
(Something's twigging my brain to make me think that the syntax for
those blocks is distinct enough to tell at compile time what block
type it is, but it's late and I may be mis-remembering) It still
can't handle the infix block stuff that sort/map/grep want.
Still, since all blocks are closures, it's not actually a problem for
parrot, since this:
foo $x, $y, {some_code()};
isn't a big deal--the only question is whether we pass in the PMC for
that closure to foo, or call it and pass in the results. (Or, I
suppose, figure out whether foo should do something bizarrely
multimethod)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 9:43 PM -0700 12/11/02, Luke Palmer wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sent: 11 Dec 2002 23:16:30 GMT Date: Thu, 12 Dec 2002 10:16:26 +1100 From: Damian Conway [EMAIL PROTECTED] X-Accept-Language: en, en-us X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I rather like that. It's used for hashing by default (in absence of a stringification or .hash (?) method), yes? Not for string key hashes, no. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Usage of \[oxdb]
At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Usage of \[oxdb]
At 10:16 PM -0500 12/9/02, Joseph F. Ryan wrote: Dan Sugalski wrote: At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? It should be; Doesn't mean it will be. And should is an awfully strong word... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: TERN-discuss mailing list finally available
At 9:07 PM -0600 11/20/02, david wrote: The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss Perl 5, or perl 6? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 6:09 PM +1100 11/19/02, Damian Conway wrote: Dan Sugalski wrote: We're definitely going to need to nail the semantics down. Would one thread throwing an exception require all the threads being aborted, for example? I would imagine so. You can't reasonably build a junction out of values that weren't successfully created. Whups, misunderstanding there. I realize that we need to throw an exception (or a junction of exception and not exception) if evaluating one of the junction members. The question is whether we should evaluate them all regardless and then figure it out at the end, and what to do with currently running junction evaluations if we've spawned off multiple threads to evaluate them in parallel. I expect I'm getting a bit too Quantum here, though. I'm thinking that we shouldn't parallelize junction evaluation by default. Dealing with threads has too many issues that must be dealt with to spring it on unsuspecting programs. As for short-circuiting: why not? Junctions are inherently unordered, so there's no guarantee which state of the junction is processed first (whether they're being processed in parallel or series). That's fine. One of the semantics I want nailed down. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
At 6:56 AM -0500 11/19/02, Tanton Gibbs wrote: How about this: $_ # current topic $__ # outer topic $___ # outer outer topic Unfortunately, or maybe fortunately, that is impossible to read correctly without having to move the cursor and count how many underscores exist. More to the point, I think it's too much to have to juggle in your (or at least my) head at once. Sure the computer can do it, but that's not much use if I can't figure out what's being referred to. It seems to me, that in English, it is hard to correctly jump to a previous topic without being fairly explicit. I expect this is due to inherent limitations in people. We can't keep too much stuff in flight at any one time in our heads, and stacking referents like this is not something we're well suited for. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 9:10 PM -0800 11/17/02, Dave Whipp wrote: Dan Sugalski wrote: The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up. Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. If it is the VM that implements the threading, then its data structures don't need to be locked. The main problem with that approach is that the multithreading would not be able to preempt C-level callouts: but that could be solved by spawning a true thread only when code makes calls out of the parrot VM. Parrot's not just a VM--if we did our own threads that'd slow down JIT-generated code universally, or forbid the use of the JIT when running with threads, both of which are no good, not to mention all the fun we'd have recreating all the threading mistakes of the past. Plus we wouldn't be able to use multiple processors on systems that have them. It's not easy to do right, and there's no real benefit to be had in doing it at all, so we're not. System threads are the way to go for us. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 2:57 PM + 11/18/02, Nicholas Clark wrote: But I'm not sure if parrot is going to give the perl interpreter cheap threading. (Does the async IO mean that one parrot interpreter could internally co-operatively thread perl in some cases?) Oh, it could do it preemptively. And parrot can (and, I think, will) provide inexpensive threading, but only in cases where there's minimal mutable data sharing. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 9:05 AM +1100 11/19/02, Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm wondering how you pass a junction.
Suppose I want to pass a junction to a subroutine instead of
calling the sub with each value of the junction... how would I do
that?
Tell the sub that it's expecting an undistributed junction as its argument:
Hrm. What happens if the junction is then used as an iterator?
$junction = File::Open(foo) | File::Open(bar);
for ($junction) {
...
}
Which could get interesting if inside the for loop the code creates
more junctions and iterates over them. (Potentially ad infinitum)
And here I thought Quantum INTERCAL was a joke... :)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: String concatentation operator
At 3:45 PM +1100 11/19/02, Damian Conway wrote: Dave Whipp wrote: Does the exception get deferred until after all the threads have completed? I would doubt it. We're definitely going to need to nail the semantics down. Would one thread throwing an exception require all the threads being aborted, for example? If both throw an exception: what happens then? You just get one or the other, in no defined order. (No, I'm *not* going to scare Dan by suggesting that $! ends up with a junction of the two exceptions. ;-) Don't worry about me. I'm still trying to shake that whole quantum thing... :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations
At 1:29 PM +1100 11/17/02, Damian Conway wrote: The formulation of coroutines I favour doesn't work like that. Every time you call a suspended coroutine it resumes from immediately after the previous Cyield than suspended it. *And* that Cyield returns the new argument list with which it was resumed. Hrm. I can see the power, but there's a fair amount of internal complication there. I'll have to ponder that one a bit to see if there's something I'm missing that makes it easier than I think. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 12:46 PM +1100 11/17/02, Damian Conway wrote: Dan Sugalski pondered: What does: $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? Creates a disjunction of three classnames, then calls the C.run method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). I was afraid you'd say that. It does rather complicate things, as the interpreter really isn't set up to be quantum for control flow. Can we at least guarantee undefined order of operations on things? (I can pitch heisenbunnies at people if it'll help) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 7:39 AM +1100 11/18/02, Damian Conway wrote: Dan Sugalski wrote: Creates a disjunction of three classnames, then calls the C.run method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). I was afraid you'd say that. Then you shouldn't have asked the question. ;-) Sometimes the answers to the questions I don't ask are scarier than the answers to the ones I do... ;-P It does rather complicate things, as the interpreter really isn't set up to be quantum for control flow. QCF is definitely not required because Junctions Are Not Quantum. Normal threading is quite enough. [Snip] It would be *vastly* better thought integrate junctive calls with the standard threading behaviour. Perl's standard threading behaviour's going to be rather heavyweight, though. I'm not 100% sure we're going to want to go that route, unless we can sharply restrict what the heisenbunnies can see. (Though the presentation on Erlang at LL2 has got me thinking more about efficient multithreading. I don't think we'll be able to use it for perl, though) Can we at least guarantee undefined order of operations on things? Yes. Please. I would certainly expect that the order of execution is undefined, since the states of a junction are not themselves ordered. Good. We shall have to enforce that, then. Wedge some randomness into the quantum thingies or something. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 1:00 PM +1100 11/18/02, Iain 'Spoon' Truskett wrote: * Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]: [...] Perl's standard threading behaviour's going to be rather heavyweight, though. Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, just wanting information =) ) Well, the problem is shared data. Firing off multiple interpreters isn't that big a deal, though there is some overhead in initializing an interpreter. If we do Clever Things, we can cut down the overhead, but there's still some, so creating a new interpreter will not be dirt cheap. (Which is fine, as it makes the common case faster) The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up. The threading model that perl leans towards is either a share-lots scheme, or a share-nothing-but-copy scheme, both of which are pretty expensive. The copy form, of course, requires copying data, which isn't cheap. The share scheme requires lots of locking, as the core data structures are too big for low-level atomic access. (Though the presentation on Erlang at LL2 has got me thinking more about efficient multithreading. Good! I don't think we'll be able to use it for perl, though) Not so good! =) Why? It's not perl's problem space. To do efficient large-scale multithreading you need a shared-nothing system with fast message passing and very little information being sent between threads. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 8:22 AM +1100 11/18/02, Damian Conway wrote: Luke Palmer asked: Of course, there will be a pragma or something to instruct it to operate serially, yes? I doubt it. Unless there's a pragma to instruct threads to operate serially. In any case, I'm not sure what such a pragma would buy you. The ordering of evaluation would still be inherently unordered. BTW, in thinking about it further, I realize that Dan is going to have to tackle this issue anyway. There's fundamentally no difference in the exigencies of: I've been noticing things have been getting rather more quantum lately. This may have some... interesting repercussions, as that has some subtle and not so subtle ramifications in how the interpreter needs to behave. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations
At 8:31 AM +1100 11/17/02, Damian Conway wrote: Peter Haworth asked: So to get the same yield context, each call to the coroutine has to be from the same calling frame. If you want to get several values from the same coroutine, but from different calling contexts, can you avoid the need to wrap it in a closure? I don't think so. I dunno. One of the things I've seen with coroutines is that as long as you call them with no arguments, you get another iteration of the coroutine--you actually had to call it with new arguments to reset the thing. (Which begs the question of what you do when you have a coroutine that doesn't take any args, but that's a separate issue) OTOH, forcing a closure allows you to have multiple versions of the same coroutine instantiated simultaneously, which strikes me as a terribly useful thing. Perhaps we'd be better with an explicit coroutine instantiation call, like: $foo = bar.instantiate(1, 2, 3); or something. (Or not, as it is ugly) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 5:57 PM -0500 11/14/02, Ken Fox wrote: Michael G Schwern wrote: Before this starts up again, I hereby sentence all potential repliers to first read: string concatenation operator - please stop http://archive.develooper.com/perl6-language;perl.org/msg06710.html The bike shed thing is like Godwin's Law. Only I don't know which side loses. ;) Wasn't one of the main problems with Jarkko's juxtaposition proposal that it would kill indirect objects? Have we chased our tail on this subject after the colon became required for indirect objects? I dunno. Makes the direct object syntax interesting as well. What does: $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unicode operators
At 1:27 PM -0800 11/6/02, Brad Hughes wrote: Flaviu Turean wrote: [...] 5. if you want to wait for the computing platforms before programming in p6, then there is quite a wait ahead. how about platforms which will never catch up? VMS, anyone? Not to start an OS war thread or anything, but why do people still have this mistaken impression of VMS? We have compilers and hard drives and networking and everything. We even have color monitors. Sure, we lack a decent c++ compiler, but we consider that a feature. :-) Lacking a decent C++ compiler isn't necessarily a strike against VMS--to be a strike against, there'd actually have to *be* a decent C++ compiler... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. Basically anything you can potentially find in a symbol table or lexical scratchpad will potentially be able to have a property attached to it. The only way that we'll be able to reasonably restrict (and optimize) the use of low-level data types is to keep them out of the symbol tables, which then makes using them in string evals and suchlike things somewhat problematic. (And not allowing properties on them will require us to throw runtime errors) It'll also make passing them in as parameters interesting, as we'd then need to construct temporary full variables that held them, which'd be somewhat interesting to deal with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
At 3:56 PM -0600 11/7/02, Garrett Goebel wrote: Dan Sugalski wrote: At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? Short(ish) answer: perl 6 attributes are much like the hash entries in a perl 5 object (assuming you use a hash as your object), only the keys are fixed at class definition time, and each parent/child/grandchild class can only see its own slots in the objects. And slot names don't collide, so every class in a 47-class inheritance chain can have an attribute Foo. perl 6 properties are more on the order of runtime notations on a variable. (Damian likes the properties-as-PostIt-note metaphor. As do I, come to think of it) Properties will be global to a variable, and queryable at runtime. Attributes are class-specific for a variable (okay, class instance specific, if you do Evil Things with multiple copies of a single base class in different legs of the inheritance tree and override the default behaviour of the engine) and not queryable at runtime without really nasty parrot assembly code. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: perl6-lang Project Management
At 2:26 PM -0600 11/6/02, Garrett Goebel wrote: Angel Faus wrote: So, while we all wait for Larry to wait the design, is there any reason not to start working in the documentation? Any chance of getting a wiki setup at: http://dev.perl.org/perl6/cathecism/ Wikis have serious scaling issues. Which isn't an argument against, merely something that must be kept in mind when considering one. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6-lang Project Management
At 9:57 PM +0100 11/6/02, Angel Faus wrote: It's like this: Larry writes the Apocalypses, Damian the Exegesis, and the community writes the Cathecism (a codified, detallied and anonymous explanation of the most boring details of the faith, written in a form that plain people can understand). Make these in the form of tests. Tight, small, unambiguous chunks of code with expected behavior. We will, I promise, roll every single correct test that comes in patch form into the parrot source distribution.[*] [*] Barring license issues, of course. Can't do much with tests labelled May not be distributed with Parrot for example... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6-lang Project Management
At 2:44 PM -0600 11/6/02, Allison Randal wrote: The obstruction you're imagining doesn't exist. The Parroteers ask for guidance from Dan. When Dan feels the details aren't clear enough yet he brings the issue to the rest of the design team. When none of us can give him an immediate answer (because we haven't covered it yet) and it is an important issue standing in the way of progress in Parrot, we sit down and hash it out until we have a clear answer. Shhh! Don't tell, but I really just make it up. ;-) Now, to put on my cranky curmudgeon implementor's hat... The answer's to Just Do It. (Which I know you've already done a number of times) Try for consensus to some extent, and try to get word on the bits that are up in the air from Larry so you've a good chance of it being correct, but... do it. Do it, send it in to the list, and be done with it. Unless you're covering already-well-hashed ground, nobody'll get unhappy and if we do, well, we're adults, we can deal with it. In general, coordinating with Allison's a good idea, so we don't have a dozen people doing the same thing, and so the results can be mushed together, but there's too much to do for a single person, and none of us like being choke points for progress. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6-lang Project Management
At 11:15 PM + 11/6/02, Simon Cozens wrote: I think you're equating a pool of available talent and labor with a pool of willing talent and labour. Everyone is willing to offer suggestions, but few people - you being one of the few - are willing to put the time into thrashing these suggestions out into a coherent set of documentation. This is an important observation most people miss. You can (and I've dealt with quite a few) find people who will spend hours, days, or weeks of their lives writing email discussing some damn thing or other that doesn't exist, yet never actually make that thing exist even if it'd only take an hour or two to do. Here is my suggested solution to the problem. And, though, snipped, a fine solution it is, with two caveats: 1) There *must* be someone who will drive the discussion, or it will wander off into some bizarre corner and die 2) Under no circumstances can Larry be allowed to subscribe, or even read, the lists. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6-lang Project Management
At 11:39 PM + 11/6/02, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: 2) Under no circumstances can Larry be allowed to subscribe, or even read, the lists. :) I thought that was so obvious it wasn't worth mentioning. :) It's the blatantly obvious stuff that gets missed the most. ;) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Wh[ie]ther Infix Superposition ops
At 11:22 AM -0600 10/29/02, Jonathan Scott Duff wrote: On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote: Also the idea of allways using 'function' style for something so basic like superpositions doesn't appeal to me. Superpositions are basic in a fabric-of-the-universe kind of way, but they are hardly basic in the everyone-learns-them-in-grade-school kind of way. I think the latter is more important for huffman coding of operators for the unwashed masses. But I'm willing change my mind if we start teaching everyone superpositions in grade school :-) Perhaps the best thing to do is to define a word operator for superpositions and, if they later become really popular, snag some generally-available* extended character to represent the operators. *Generally available meaning in all of the Shift-JIS, Big5, and Unicode sets, assuming there are some that aren't Kanji -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Wh[ie]ther Infix Superposition ops
At 10:02 AM -0800 10/29/02, Larry Wall wrote: On Tue, 29 Oct 2002, Dan Sugalski wrote: : Perhaps the best thing to do is to define a word operator for : superpositions and, if they later become really popular, snag some : generally-available* extended character to represent the operators. Sorry, I believe in the transactional model of QM, and the future has already reached back in time and grabbed | and . :-) Well, I suppose when people use them as bitwise operators they won't be any more confusingly wrong then they often are now... : *Generally available meaning in all of the Shift-JIS, Big5, and : Unicode sets, assuming there are some that aren't Kanji I believe and | already satisfy that particular constraint. :-) So does X, for that matter. I was thinking more of the double-vertical bar or one of the stars. I admit I'm really not sure that the quantum operations will be used enough to warrant blowing people's expectations of bitwise operations, even if the bitwise operations aren't used that much. Not my call, though--it's all assembly as far as I'm concerned. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Wh[ie]ther Infix Superposition ops
At 1:34 PM -0800 10/29/02, Brian Ingerson wrote: On 29/10/02 14:47 -0500, Dan Sugalski wrote: At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote: This is why I am nervous about introducing terms like eigenbunny, etc. Oh, I dunno, I kind of like it. Of course, now my kids want eigenbunny slippers... (Though the trouble with those is they may or may not be keeping your feet warm--you can never tell) Oh! I just remembered the ultimate word for a container. It's cozy, of course! Every eigenbunny needs a supercozy! Absolutely. Eigenbunnies in supercozens. Sounds like we've found the mascot for Perl 6! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, Damian's take
At 1:20 AM + 10/30/02, Simon Cozens wrote: [EMAIL PROTECTED] (Dave Mitchell) writes: (I'm thinking utf8 here). I'd strongly advise against that. I'd agree. Thinking UTF-8 is generally a bad idea. If you think anything, think fixed-size code points, since that's what you're ultimately going to get. Probably 8 bit if you're ASCII, Latin1, or EBCDIC, 16 if you're Shift-JIS or Big5 (either one), and 32 if you're dealing with Unicode. It's possible you'll get UTF-8 (or UTF-16) but I think you'll be hard-pressed to get there, at least without explicit hoop-jumping. I certainly hope so, at least. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
At 4:44 PM -0500 10/28/02, Mark J. Reed wrote: On 2002-10-28 at 16:39:10, brian wheeler wrote: [The below is actually from Larry, not Michael] explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) The post that started this thread was a complaint about leading 0 meaning octal - which is counterintuitive to everyone the first time they come across it in C or Perl or Java or wherever. That's not entirely true. Granted the set of the people for whom a leading 0 instinctively means octal is not that big (and getting smaller due to retirement and death from old age :) but it was meaningful at one time. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
At 2:21 PM -0800 10/28/02, Michael Lazzaro wrote: Dan Sugalski wrote: While we're at it, maybe we can add in 0rMCM to allow roman numerals too... OK, see, the sad thing is that I really have no idea whether you're joking or not. That's how wiggy this thread has gotten. I am joking--it's definitely a bad sign that you can't tell. :-P (Of course, I'm hardly one to talk, what with Parrot and all...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List, TAKE 4
At 12:37 AM +0200 10/29/02, Markus Laire wrote: On 28 Oct 2002 at 16:42, Dan Sugalski wrote: At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... Nope, not a problem. Roman Numerals are big-endian by definition. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Character Properties
At 10:53 AM -0700 10/21/02, Austin Hastings wrote: Yeah, but emacs isn't written in any of those languages. What, you're using emacs as an argument *for* something? :-P And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. --- Dan Sugalski [EMAIL PROTECTED] wrote: At 11:09 PM -0600 10/20/02, Luke Palmer wrote: What's the plan on having properties, or attributes (depending on how far we're taking it), on individual characters in a string? I think it's an essential feature, as Lisp has shown us. If there's an argument otherwise, I'm all ears. While they're certainly useful, I think essential's an awfully strong word there. You'll note that, just off the top of my head, C, BASIC, Fortran, Perl, Python, Java, Ruby, Pascal, Oberon, Modula (2 and 3), Forth, Eiffel, Haskell, BLISS, C++, C#, COBOL, PL/I, APL, B, and BCPL all don't do character properties/attributes. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Character Properties
At 7:22 PM + 10/21/02, Rafael Garcia-Suarez wrote: Dan Sugalski wrote : And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. Just like Perl 5 ;-) Almost. At least perl 5's macros look like C. Emacs' macro horrors make C look like Lisp... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A concept for Exceptions
At 2:33 PM -0400 10/15/02, [EMAIL PROTECTED] wrote: The constructor returns one of three values: an exception object, the DO_OVER constant, or the EXPRESSION constant. If an exception object is returned, that means that the interpretor should immediately exit the block, throwing the exception to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. While a nifty idea, this is not going to happen, at least not in the general case. Restartable exceptions are very, very difficult to do. (And parrot, alas, isn't going to be able to do them) You still need to establish an exception handler at the spot you want to restart at (which isn't free, alas) and you run into problems when you cross some internal boundaries in the interpreter. That won't stop you from throwing a continuation when you throw your own exceptions, which your own exception handlers can invoke when they see fit, but low-level exceptions like division by zero and suchlike things won't be able to do that. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Indeterminate math
At 10:38 PM +0100 10/14/02, Leon Brocard wrote: Michael G Schwern sent the following bits through the ether: Someone [1] wanted to know if 1/0 would produce a divide by zero error in Perl 6, or if it would return a value representing an indeterminate result (undef?) This is probably the mathematician in me escaping, but I also remember a discussion at Y::E about number systems. What if you didn't want Perl to use the normal number system, but instead only have, say, positive integers, or integers modulo prime P. This is possible with Perl 5, but with lots of scary overloading. Will it be any different in Perl 6? [Or are we not quite there yet?] I expect the overloading will be just as pervasive, though perhaps not as scary as in perl 5. (I suppose you could just go override the vtable methods for all the core data types... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6 operator precedence table
At 3:55 PM -0700 10/11/02, Larry Wall wrote: On 11 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Larry Wall) writes: : I was thinking more along the lines of: : : $x $y : $x ||| $y : : This isn't Perl; this is merely some language that looks a bit like : it. I can understand the attraction for confusing anyone who comes : from a standard Unix language background, but I'm not sure it's a : great idea, all told. I'm not sure either, and that's why I'm thinking about it. :-) I think that, for me at least, it'll be close enough to C to be really confusing. (I already have the problem of leaving parens off of my function calls when I write XS code...) There's a certain appeal to not having to swap in almost-but-not-quite-the-same sets of punctuations when moving from language to language. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft Proposal: Symmetry between Attributes and Accessors
At 10:58 AM +0200 10/5/02, Paul Johnson wrote: On Fri, Oct 04, 2002 at 04:42:27PM -0700, Michael Lazzaro wrote: - An attribute and a method are _not_ typically implemented in the same manner. Treating the two as interchangeable might imply runtime overhead. Bah! I bet the internals list will laugh at you :-) will? Nah, we've been laughing for days. ;-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Delegation syntax?
At 12:37 AM -0400 10/4/02, Michael G Schwern wrote: Delegation is a basic OO technique. We definately should have fast, well-designed core support for it. I'm pretty sure we will. I certainly need it internally... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft Proposal: Attributes: public vs. private
At 4:39 PM -0700 10/4/02, Michael Lazzaro wrote: Under the principle of TMTOWTDI, perl allows public attributes within a class. However, you must explicitly declare an attribute to be public. There won't be any direct access to attributes outside class methods of the class that defines the attributes, unless Larry changes his mind in a big way. (And, honestly, probably not even then) Instead it'll all be accessed via lvalue methods. If an attribute is exposed there's just an lvalue method created, if it's not exposed there isn't. Inside the class, we'll just cheat and smack straight into the slots of the attribute array, and if you've inherited from a perl 6 class we'll be doing Evil Things with that array and all, but that's an internal matter. :) Though, of course, there's nothing to stop you from using Introspection (A power so great, it can only be used for good or evil!) to go peeking around, but that's another matter entirely. Don't forget that we'll potentially be inheriting from *non* perl classes, at least non-perl-6 classes (and more if I manage to pull it off), so there's a limit to how much knowledge we want to require of the semantics that get exposed. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: for loop and streams
At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote: On Thu, 26 Sep 2002, Paul Johnson wrote: Is that sufficiently vague? Not vague enough, because the current implementation manages to miss the broad side of that semantic barn... The intention is to allow aggregates to have different default return values, IIRC. Right now we return undef as the default, when accessing elements that don't exist, but there are cases where you might want something else. (Numeric-only arrays might want to return 0, and string-only ones , for example) Different operators doing different things sounds awful to me, because it makes it hard to predict what will happen, because new operators will have to be able to control what they do with their operands, and because new types of array-like operands will have to tell operators how to treat them. Blech. Well... no, not really. I think this vagueness is my fault, as I badger Larry and Damian about it on occasion. The reason it's vague is that the Right Thing depends on the types of the variables on either side of an operator. Multiplying two matrices should work differently than multiplying two multidimensional arrays, or two vectors, or a vector by a matrix. We should get the default behaviour defined and in use so people get a handle on how things work, but we do want to make sure people keep in mind that it's the default behaviour, not the required behaviour. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex query
At 11:07 AM -0400 9/24/02, Trey Harris wrote: *shrug* Regardless of whether we like it, what Larry said is true unless and until he invokes Rule 2. And unless he invokes Rule 2, Cscalar(1,2,3) is equivalent to C[1,2,3]. Then perhaps, rather than fretting over the unpleasant consequences of the current decision, effort would be better placed in getting that decision changed? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[], (), and potential design issues
Folks, Larry is mostly out of touch this week, so working ourselves into a fury over a potential design issue is probably a bit counterproductive. Perhaps someone can put together a statement of the problem and post it, and we can leave the discussion for a bit, both to give larry time to get his mail (probably not for a week) and to give everyone a chance to mull over the issues? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex query
At 10:52 AM -0500 9/21/02, Jonathan Scott Duff wrote: So, you expect 7.pow(2) to work? I'd expect it to be an error (this isn't python after all). Sure, why not? I mean, we already use methods on integers all the time--what do you thin 12.5 is anyway, other than calling the 5 method on the constant 12? :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Hyperoperators and dimensional extension
At 8:27 AM -0700 9/19/02, Brent Dax wrote: Dan Sugalski: # Sort of, yes. # # Basically the behaviour of hyper-operated operators is delegated via ^ Spending time in England lately? ;^) Why, yes, actually. :-P But I've been using Pompous English Spelling for years. # multimethod dispatch to the hyper-operator functions. By default the Well, yeah. But that doesn't really answer my question. :^) What's the *language-level* behavior? Well, it does, though. Saying it's delegated to the variables and they have a default behavior's different than saying this is the behaviour. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Hyperoperators and dimensional extension
At 12:04 AM -0700 9/18/02, Brent Dax wrote: The Apocalypse on operators says that if one of the operands of a hyperoperator is a scalar, then that scalar is (nominally) treated as an array of copies of that scalar. In other words: my $foo=1; my @bar=(2, 3, 4); my @baz=$foo ^+ @bar; # @baz=(3, 4, 5) Does that extend to multiple dimensions? Sort of, yes. Basically the behaviour of hyper-operated operators is delegated via multimethod dispatch to the hyper-operator functions. By default the base perl variables will expand themselves out, but the engine itself won't enforce this, as the classes can potentially overload the hyper-operators. So if the multiple-dimensional aggregate provides a proper operate against a single scalar method that goes multidimensionally, then we'll do that. If it doesn't, we won't. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: XS in Perl 6
At 5:09 PM -0700 9/12/02, David Whipp wrote: Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: I'm thinking XS thoughts because we're going to need a few external things at SOME point It would be so nice if Perl 6's XS was part of the language, rather than an external pre-processor. [ some interesting stuff] Thoughts? Its good to start thinking about this early; but should we be thinking Parrot's XS; not Perl 6's? Yes, we should. Perl 6 XS is Apocalypse 21. That's likely rather a ways off... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Hypothetical variables and scope
At 6:59 AM + 9/7/02, Damian Conway wrote: Jonathan Scott Duff wrote: Sounds like an optimization that should be in the hands of the programmer to me. Possibly. Though leaving optimization in the hands of the programmer is generally a Bad Idea. Oh, I dunno... If that programmer is me or one of the other folks from perl6-internals I think you're OK. :) Generally things are better if people clarify what they want, rather than specify optimization hints, otherwise you end up with dopey things like Java's final stuff. If the optimizer knows what you want to do it is more likely to be able generate fast code, but that works best when you clearly express the semantics -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
At 9:27 PM -0400 9/4/02, Ken Fox wrote: Dan Sugalski wrote: At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? No. They can be both compile time things or runtime things, depending on the characteristics of the language. I don't think so. Those terms are well understood by the OO community. Bertrand Meyer wrote on the subject: http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf Yeah, but what he wrote was don't do that, in any of its forms. While an interesting argument, it's a touch late for perl. Prior to C++ there might have been some ambiguity (for example, some people have talked about run-time vs compile-time overloading), but C++ has completely stolen the term. Here's a slide from one of Damian's presentations that states multi-methods are Like C++ overloading, but polymorphic. http://www.csse.monash.edu.au/~damian/TPC/1999/MultipleDispatch/Presentation/sld010.htm Hrm. I generally use overloading in the operator overloading sense, which is where the confusion comes in, I expect. Operator overloading can be a compile or runtime thing, depending on your preferences. Figuring out what function/method to call based on parameters and return types can also be a runtime or compile time thing, once again depending on preferences. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: From: Ken Fox [EMAIL PROTECTED] Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? No. They can be both compile time things or runtime things, depending on the characteristics of the language. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
At 7:31 AM -0700 9/4/02, David Wheeler wrote: On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: No. They can be both compile time things or runtime things, depending on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? It probably isn't, though I'm unfamiliar enough with Java to say for sure. And will Perl 6 do it at compile-time or at run-time? Runtime. There's no way we could do it at compile-time--too much uncertainty. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 6 parser, built in rules, etc.
At 8:03 AM -0700 9/4/02, Erik Steven Harrison wrote: -- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? Perl's grammar didn't change much between 5.00 and 5.8. Once we ship the final grammar, we'll maintain it in a backward-compatible way, and document the places you can count on it to wedge in changes. Then we maintain it as long as Larry says so. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: @array = %hash
At 8:48 AM -0600 9/3/02, Luke Palmer wrote:
Hmm... I think I'd rather see
my $foo is Bag = @array.as('Bag');
The idea being that one could treat hashes and arrays as syntactic
vitamins meaning 'Dictionary' (to use the Smalltalk term) and
'OrderedCollection', but all Collections would implement an Cas
method allowing conversion between the different classes.
Hmm... you know, the more I think about that idea, the more I like
it...
Likewise. I've always liked languages with complete standard libraries in
terms of data structures. It would be great to see Perl be one of them.
PMCs can be loaded on demand. Make them good and there's no reason
they can't be in a standard SDK for parrot...
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: auto deserialization
At 4:21 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
From: Trey Harris [EMAIL PROTECTED]
no strict 'refs';
my Date $date;
$date .= 'Sep 21, 1963';
There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or the class
because the compiler would understand what to call. It would see that
$date is in the Date class, and 'Sep 21, 1963' is in the String class, so
it would pretend the statement really reads
$date = Date::new_from_String('Sep 21, 1963');
This will potentially get out of hand quickly. So, to get this out of
the way *now*...
If you're going to do this, you might as well go fully multimethod,
because someone'll want new_from_Integer, new_from_Float,
new_from_BigNum, new_from_Thread, new_from_Grue, and
new_from_Superposition.
Decide whether that's a good idea or not, since that's the way things
are going to go if you start.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: auto deserialization
At 6:03 PM -0400 9/3/02, [EMAIL PROTECTED] wrote: From: Dan Sugalski [EMAIL PROTECTED] This will potentially get out of hand quickly I don't think this is a case where out-of-hand-generalization is necessary. I'm only saying that there could be a handy shorthand for a single very common case. Each object has its own common case, and strings aren't always it. Date could reasonably want strings, but also an integer timestamp makes sense, as does an array with localtime information. Then again, maybe initializing from a localtime object would make sense. How about a JPEG object? Might take a string with the image data, an array with byte data, a filehandle that's got the data to it. There is no one common case that's common for everything, or even most things. If you want automatic initializers, you have to bite the bullet and go full multimethod, or spend the rest of eternity explaining why string-only seemed like a good enough idea at the time -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
At 5:41 PM -0700 9/3/02, David Wheeler wrote:
On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
We call that concept multimethod dispatch. That's what you're asking for.
Dan, can you explain what multimethod dispatch is?
Damian can explain it better than I can, but it's essentially when
you dispatch based on sub or method signature. You're allowed to have
multiple versions of a single sub as long as they differ in their
parameter signature.
So you could have a
sub xyzzy(Foo $a) {
print Foo!\n;
}
as well as a:
sub xyzzy(Bar $a) {
print Bar!\n;
}
And at runtime when you call xyzzy, the system looks at your
parameter to decide which to call. Inheritance trees are searched as
well, so if you had a Baz, which ISA Bar, calling xyzzy with a Baz
would print out Bar!
Things get... interesting with multiple inheritance, and multiple
parameters, but the general solution to potential conflicts, where
there are two or more equally right things is to either use a
default or throw an exception.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: atomicness and \n
At 9:24 PM -0400 8/31/02, Ken Fox wrote:
Damian Conway wrote:
No. It will be equivalent to:
[\x0a\x0d...]
I don't think \n can be a character class because it
is a two character sequence on some systems. Apoc 5
said \n will be the same everywhere, so won't it be
something like
rule \n { \x0d \x0a | \x0d | \x0a }
That should be
rule ASCII::\n
or something of the sort. That particular rule will only be valid for
ASCII data. Unicode will have a superset of that, and the other
character sets will have a different line ending rule.
This, like the other shortcut characters, will be character-set
specific. (And overridable, in case someone feels like making \b work
properly (FSVO properly) for asian data that doesn't use word
delimiters)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: auto deserialization
At 4:01 PM +0100 8/29/02, Nicholas Clark wrote: On Thu, Aug 29, 2002 at 07:52:42AM -0700, Steve Canfield wrote: From: Dan Sugalski [EMAIL PROTECTED] I actually had something a bit more subversive in mind, where the assignment operator for the Date class did some magic the same way we do now when we do math on strings. I was thinking a simple general purpose rule. If the variable is typed, and its class has a standard static method for instantiating from a string, and if a String object is being assigned to the variable, then the class's deserialization method is called, returning the new object and assigning it to the variable. This is possibly more an internals question, but I was assuming that the serialization/deserialization methods would normally be converting an object to an efficient packed 8 bit binary serial format (much like Storable does). The format that's used to store the serialized data is up to both the class serializing itself and the serialization method currently in force, though the latter is invisible to the classes serializing themselves. (That way the classes can use pure packed data, while the serialization method may turn that to base64 or something to make it safe to transfer, or something of the sort) Counting on the serlialized format to be human readable's probably a bad idea. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: auto deserialization
At 10:36 AM +0200 8/28/02, [EMAIL PROTECTED] wrote:
Will there be automatic calling of the deserialization method
for objects, so that code like this DWIMs...
my Date $bday = 'June 25, 2002';
Err... what do you mean it to do?
Wow, this is nice. He means (I think) that this will be translated into
my Date $bday = Date-new('June 25, 2002');
That's really unlikely. More likely what'll happen is:
my Date $bday;
$bday = 'June 25, 2002';
and it'll be up to $bday's string assignment code to decide what to
do when handed a string that looks like a date.
That should work OK for a variety of reasons. $bday is strongly typed
since you told perl what type it was in the my declaration. Date can
also override string assignment, thus Doing The Right Thing (pitching
a fit or taking a date) when you assign to it.
I can see downsides to it, though--it means you lose the compile-time
type checking, since just because we're getting the wrong type
doesn't mean it's really an error. OTOH it's not like we have strong
compile-time type checking now...
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
