Re: Alternately named arguments
On Mon, Oct 27, 2003 at 12:05:32PM +1100, Damian Conway wrote: : Luke Palmer asked: : (Or, in this precise case:) : : (+$name, +$id) := getinfo(); : : Err, no. Or at least: Please, No!. ;-) : : That would certainly be a way cool abbreviation, but I suspect it would be : a Very Bad Idea for unary plus to have two unrelated meanings out in the : actual code. I suspect that the named-only markers are only available : within actual parameter lists. I don't think there's any ambiguity with it. A C:= always forces its left side to a binding context. At that point in the parse, the left side tree has to be traversed anyway to reinterpret everything, so the meaning of the C+ can be determined subsequent to the initial parse. That being said, there is probably a style of programming enforced by a stricture that disallows binding to existing variables, for the same reason that we disallow binding subroutine parameters to global variables. In that case, you'd be required to introduce the list with a Cmy, and so you'd already know you were in a weird context when parsing. It could be argued that C:= implies a Cmy, in fact. But I still think it's better to require the Cmy for visual reasons, and to make it easy to search for declarations. Larry
Re: Alternately named arguments
Larry wrote: : (+$name, +$id) := getinfo(); : : Err, no. Or at least: Please, No!. ;-) : : That would certainly be a way cool abbreviation, but I suspect it would be : a Very Bad Idea for unary plus to have two unrelated meanings out in the : actual code. I suspect that the named-only markers are only available : within actual parameter lists. I don't think there's any ambiguity with it. Nor do I. At least, not to the machine. People may not be as clear on the distinction, though. A C:= always forces its left side to a binding context. At that point in the parse, the left side tree has to be traversed anyway to reinterpret everything, so the meaning of the C+ can be determined subsequent to the initial parse. Which the machine can do very easily, I agree. People may not be as good as reinterpreting everything in context. Especially a context thats imposed by a *trailing* infix operator. That being said, there is probably a style of programming enforced by a stricture that disallows binding to existing variables, for the same reason that we disallow binding subroutine parameters to global variables. In that case, you'd be required to introduce the list with a Cmy, and so you'd already know you were in a weird context when parsing. It could be argued that C:= implies a Cmy, in fact. But I still think it's better to require the Cmy for visual reasons, and to make it easy to search for declarations. Okay, I wouldn't have nearly as much problem with having two unrelated meanings for prefix '+' and '?', if the second meaning were always confined to the declaration lists of Cmy's and Csubs. Because (a) we're clearly prefix-marked as being in a declaration in both those cases, and (b) declarations are compile-time, so we can simply explain that +, ?, and * have distinct compile-time and run-time meanings. But trying to understand the run-time-only variations in what + and ? mean in this: ($X, +$Y, ?$Z) := ($x, +$y, ?$z); vs this: ($X, +$Y, ?$Z) = ($x, +$y, ?$z); is a novice's nightmare. :-( So can we say that, even if non-declarative bindings *are* allowed, within them unary + and ? and * always take their run-time meanings (i.e. almost always an error)? Damian
This week's Summary
The Perl 6 Summary of the week ending 20031026 Where does the time go? It seems like only yesterday that I was sat hiding Leon Brocard in the first letters of the first 11 body paragraphs of the last summary. Now, here I am, on the train, typing away in a desperate attempt to get this mailed out before Wednesday. Let's start with perl6-internals again. Object Freezing Whoever would have thought that freezing objects would be so controversial? Object freezing is when you take an object and generate a 'frozen' representation of it that can be used to make a copy of the original object. It's what Storable, Data::Dumper and YAML (to name three Perl 5 modules) all do more or less successfully. (Most of the time there's no problem, the tricky case is a composite object which involves a circular data structure. Consider this: Ring - A - B - C - D ^ | `--' (It's not *quite* a purely academic example, I can point to at least one text editor that uses a similar data structure). When you come to freeze your ring, you need some way of detecting the cycle and generating a finite representation that works. This isn't the only problem; thread safety is hard, for instance.) Dan's set some fairly stringent requirements on whatever mechanism is used for freezing. The most important/stringent is the requirement that (because freezing during object destruction will be a possibility) object traversal is not allowed to use additional memory for that traversal. Dan is convinced that we can do this using the Garbage Collector's object traversal system. Leo Ttsch is equally convinced that we can't. The resulting thread is rather meaty and hard to summarize without massive amounts of cut and paste so I'll just point you at the root message. The upshot is that we're doing it Dan's way; Glorious Leader continues to trump Pumpking Patchmonster. In another subthread there was a good deal of misunderstanding about XML declarations and parsing, which got cleared up surprisingly quickly. http://xrl.us/y99 Object Instantiation Dan had a moment of clarity and declared that the Parrot Way to instantiate an object in class Foo will be: new P5, .Foo All we need now is a working implementation. And, apparently, knowing what class a class is a member of might be handy, but Dan's punting on (ignoring the heck out of) that one. http://xrl.us/zaa A less controversial API addition In the middle of the discussion about object freezing, Dan popped up another thread to discuss how to invoke Sub/Method PMCs from C code. So Leo implemented Parrot_runops_fromc_args(), but he's not exactly happy about the name. Regardless of the name, having this implemented is rather spiffy. http://xrl.us/zab Old Big Problems before New Big Problems Melvin Smith popped up with a rant about the Parrot development effort's tendency to rush off to implement new stuff before making double sure about the 'old' stuff is actually complete and robust. To which I can only say Hear! Hear! Dan agreed, and threatened to give Melvin the pumpkin after Leo had finished with it. http://xrl.us/zac Class metadata for PIR/assembly files Donning his designer's cap again, Dan posted a rough spec for class metadata declarations in PIR and pasm files. It looks pretty decent to me. Melvin Smith made a few telling comments though, so it looks like Dan's post isn't quite the final word on the matter. http://xrl.us/zad Class creation in bytecode Mere moments after the metadata post, Dan went on to spec out the assembly language needed to support it. http://xrl.us/zae Open Patches Leo pointed everyone at http://xrl.us/zaf, the list of open Parrot patches and asked for a volunteer to go through and make sure that the list is in agreement with reality. http://xrl.us/zag Leo's notes on objects and classes Leo posted a list of thoughts about how classes and objects will work in Parrot and offered a suggestion about using OrderedHashes to handle things. http://xrl.us/zah Unifying vtables and method invocations Leo wondered if we should arrange things so that PMC vtables could be invoked in the same way as in methods on Parrot level objects are invoked. Dan answered that it won't be quite like that, but it will be close. (Yay! A reflective programmer writes). http://xrl.us/zai More fixed number assignments So, it turns out that adding PMC classes to the core breaks binary compatibility. Which needs fixing. Dan asked for volunteers. I'm afraid I don't know what fixing it would entail. http://xrl.us/zaj Plotz! Plotz (the Pol(l)y-Lingual Opcode Translation for the Z-machine) is Amir
