Re: Why pass by reference?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: HaloO, Matthew Walton wrote: If a user of your API contrives to make it change while you're running, that's their own foot they've just shot, because they can look at the signature and know the semantics of the parameter passing being used and know that if they change the value externally before you return Bad Things Could Happen. I agree that the caller is responsible for the constness of the value he gives to a function. With this we get the best performance. I don't understand why John thinks that an intermediate proxy is needed. A very shallow wrapper that ensures the readonlyness suffices. Most of the time not even that when the constness is known statically. Regards TSa. shallow wrapper is what I'm talking about. That is indeed a proxy: if a full-blown run-time check is needed (when it gets passed beyond its ability to track at compile time) it forwards methods, intercepts others, and modifies accessors.
Why pass by reference?
In Perl 6, the default parameter passing is to make a read-only alias for the caller's lvalue. This means that the function may not change the caller's variable, but must track changes to it made by other means. What is the point? It is a contrivance to illustrate how the variable can be changed by other means, and requires a global variable, the same variable passed as two different parameters, or the variable and a closure that affects the variable be passed. In fact, this effect seems like something that should be warned against, not something that is touted as a feature. It complicates the passing, requiring a read-only proxy or equivalent be introduced, making the readonly parameter more complex than the rw parameter. It makes the actual access more complex, having to go through this extra layer. It prevents optimizations, since you have more plumbing to go through and you have to watch for aliasing (that's the feature!) instead of assuming the value doesn't change between accesses. In Perl 5, the @_ is a normal alias (read/write), and most parameters are copied to local variables, making it essentially pass-by-value. The local variable is pass-by-value, and looking back at the @_ is pass by reference. There is no feature like Perl 6's default readonly passing (read-only reference). So it's not for historical use. At least not as the default method! So, I ask: is there any reason to want this read-only reference as a passing method? And if so, why does that preclude having the simple pass-by-value method available also? From the typical Perl 5 usage, I would think that pass-by-value should be the default. --John
Re: Why pass by reference?
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Actually, it only looks complicated while you think only on the callee
side.
No, in general it requires introducing a read-only proxy in front of the
container. This may be optimized away when it can be tracked at
compile-time, but that's certainly not simple as compared to not
having it nor the aliased item container at all.
Because when you take the caller side, you'll note that it builds
a capture to send to the call, and the capture is always a reference, so
the signature just makes sure that references becomes read-only. To
illustrate:
my $a = 1;
foo($a);
In this case, the capture sent must contain a direct reference to the
scalar held in '$a', so both signatures with is ref or signatures with
is copy can work.
So, if foo has the signature
sub foo($a is ref) {...}
it will be able to change the scalar outside foo. If it is
sub foo($a) {...}
It will be a read-only access to that scalar
sub foo($a is rw) {...}
Works almost like is ref, but encloses immutables into a container in
order to always provide rw semantics.
No, is rw does not like immutables. It will cause autovivification to
take place, but will not accept something that is not an lvalue such as
1 or Hello literals. This was just doubled-checked with S06, S09, and
discussion with Larry in #perl6. If Ra
ruosorakudo: sub foo($a is rw) { $a += 1; say $a }; foo(1);
p6eval rakudo 77f9d7: OUTPUT«2»
that directly contradicts S06, which states Otherwise the signature
fails to bind, and this candidate routine cannot be considered for
servicing this particular call. Doing otherwise affects the semantics
of MMD for allowing overloading based on whether the parameter is an
lvalue or not.
Somebody who works with rakudo could submit a bug, if it's not in there
already?
sub foo($a is copy) {...}
Is the completely opposite to is ref, copying the actual value to a
new container.
Agreed.
So, it is not at all complicated, it's just oriented to the Capture, and
the capture provides semantics to the call that are not present in any
other language I'm aware of.
Complex or not in that sense, it complicates things in allowing the
value to be changed by another path. I think that is something we want
to avoid doing, not present as a feature. Much of my original post
concerns the actual meaning, not whether it is considered simple.
Since then, I see that it is useful for plural containers. We don't
want to copy them! But for items, why do we not even _have_ pass by
value? The compiler must assume the worst and can't optimize as well.
--John
Re: Array rotate
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Fri, Jun 12, 2009 at 10:02 AM, yarynot@gmail.com wrote: I am tickled pink to see an Array rotate method in the settings spec S032, as I was thinking of writing up a little discussion on the very topic. Has there been discussion on using array rotate on multi-dimensional arrays? Being able to pass in a vector as the amount to rotate would be useful. With a multi-dimensional array, a number of transforms can be considered: * you can rearrange the elements along a given dimension (e.g., rotate and reverse). * you can rearrange the dimensions themselves (e.g., transpose). A short time ago, something similar came up. I think the built-in's should stay simple, and a module (or several different ones) can exist to do comprehensive features for multi-dimensional arrays. Designing that is really a separate project in itself, and it may shake out with use. So keep it out of the core spec. --John
Re: Multi-d array transforms (was Re: Array rotate)
Larry Wall larry-at-wall.org |Perl 6| wrote: We also need to consider the dimension of referentiality. I can see three levels here. Given @a.mung the .mung could return A) a modified @a (treat @a as mutable) B) a new array (treat @a as immutable) C) a remapped array whose elements refer back to @a's elements Currently .rotate is defined as A, but I could easily switch it to B, so you'd have to write @a.=rotate; Having some operation XX return a new object and using =.XX do it in place would be consistent with the way other things are shaping up. But people expect push to work like they are used to, and the exported push, called as a sub not as a method, would be copying. In void context it could give an error. push @a, $x;# what's the point? if we had a general way to decorate the sub definition to day must not use in void context. As expressed already in the synopses, the function called for @a.=push($x); can be written specially to handle the in-place case, rather than have to assign back after copying like the auto-generated case would. (What exactly define a self.push operator means needs to be clarified in S12. Is that not the normal sub syntax?) In other words, defining self.push would be the implementation that Perl 5 push is now. to rotate in place. If we did that, then we could conceivably set things up with more PDLish C semantics so that @a .= mung # A semantics @b = @a.mung # B semantics @b := @a.mung # C semantics That third one would be rather inefficient. The returned array would need to be set up as an array of binding proxies, if the original wasn't set up as an array of item containers, just in case it gets bound to something (or used as part of a larger expression) rather than assigned. I'm looking at this general issue right now (musing over it the last week actually) and although it's nowhere near done yet, you can see Figure 1 at http://www.dlugosz.com/Perl6/web/container-lvalues.html and the text that is taking shape around it. This implies, however, that the copy semantics of = are sufficiently clever to snapshot all the referenced values of @a before clobbering @a in the case of either: @a .= mung @a = @a.mung But list assignment really ought to be doing that in any case. Wow. The overarching logic for list assignment would have to compare the containers and the arguments in the capture before doing the list assignment to each container, in order to avoid cloning all the containers on the right first in the general case. It can't just copy values out because they may contain iterators or be lazy or be infinite. --John
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Larry Wall larry-at-wall.org |Perl 6| wrote: Alternately, we leave @@ (or @%) meaning ¢ and instead let some other syntax take over the pay attention to the capture's structure semantics from @@. Maybe it's another use for the zen slice: pay attention to the capture's structure is a can of worms. As things stand now in the Synopses, you get a lot of empty extra wrappers around things. You don't want to keep that exact! When you are not doing full-blown flattening, which levels in the morphology are extra due to passing though functions or grouping parens, and which are intended to be part of the final structure? Since the crazy stuff inside the capture is usually invisible, people will have a hard time using that correctly. (A literal reading of the synopses now gives us the morphology illustrated at http://www.dlugosz.com/Perl6/web/med-loop.html, and I hope to remove _some_ of those extra wrappings through refinement of the rules when I get around to studying that in detail.) My thoughts at this point is that slice context needs to *know* it is being rolled up into a final result that is a 2-dim array. The rules for that will strip out extra wrappers except where it really is significant, designed through use cases of seeing what common constructs actually produce. A shaped array knows what needs to be poured into it, so the RHS can be flattened. The single-dim array is just a special case of that; it generalizes to higher dimensions just fine, as seen in languages like APL. A smart shaped assignment, to handle containers with * in other than the highest position, can be supplied as part of a multi-dim array Module, designed separately along with a coherent set of features such as general vector-driven transposes etc. --John
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: So, how do I deal with a multidim array? Well, TIMTOWTDI... my @a = 1,[2,[3,4]]; say @a[1][1][1]; say @a[1;1;1]; # I'm not sure this is correct I think that it should be. That is, multi-dim subscript is always the same as chained subscripts, regardless of whether the morphology is an array stored as an element, or a multi-dim container, or any mixture of that as you drill through them. I've not written out a full formalism yet, but I've thought about it. The multi-dim subscript would return a sub-array if there were fewer parameters than dimensions, an element if exact match, and recursively apply the remaining subscripts to the element if too many. Or.. (I'm using the proposed capture sigil here, which has '@%a' as its expanded form) my ¢a = 1,(2,(3,4); say ¢a[1][1][1]; say ¢a[1;1;1]; I think that makes the semantics of the API more clear... daniel The plain Array would work too, in the nested morphology: my @a = 1,[2,[3,4]]; @a has 2 elements, the second of which is type Array. say @a[1][1][1]; naturally. say @a[1;1;1]; means the same thing, intentionally. say @a[1][1;1]; say @a[1;1][1]; ditto. --John
Re: Multi-d array transforms (was Re: Array rotate)
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: In addition, the current @a.shift is useful because it returns the element that was removed from the array, so you can do something with it: The change to the library synopses was checked in before you posted that, if I recall the delta correctly. But you bring up a point: that is indeed the common idiom from Perl 5. That brings up the following radical idea: Have no method named shift at all. Shift etc. will be a non-member sub brought in through use legacy; and designed to work just like Perl 5, for that express purpose. The P6 way of doing it would be to not do that: use iterators rather than destructivly going through the array, or use decomposition to do things in a more functional way, or use the more general syntax to delete one element from the beginning, in-place or copy as indicated. --John
Re: Multi-d array transforms (was Re: Array rotate)
Larry Wall larry-at-wall.org |Perl 6| wrote: On Sat, Jun 13, 2009 at 02:49:10PM -0500, John M. Dlugosz wrote: Wow. The overarching logic for list assignment would have to compare the containers and the arguments in the capture before doing the list assignment to each container, in order to avoid cloning all the containers on the right first in the general case. It can't just copy values out because they may contain iterators or be lazy or be infinite. Well, that's not really a problem, as long as the same semantics are preserved. All you need to do is cut loose the contents of the container completely to the mercy of GC, build a new one with the appropriate structure, then copy values in from the assignment's RHS. The only reason Perl 5 couldn't do it this way is that the idiot who wrote it prematurely optimized values on the stack so that they didn't need to be reference counted. :) Larry I agree, if the contents include the iterators and code blocks and whatnot that make up the concrete types of the things on the right. But if it's not a built-in standard type, it might require a call to the general shallow-copy clone of the object. my @A is CustomContainer; my @B[7]; # fixed size ... @B,@A,@C = @A,@B; The compiler doesn't know how to juggle the internals of @A because it is not a standard type. This needs to become: my @temp1 = @A.clone; my @temp2 = @B.clone; @B,@A,@C = @temp1,@temp2; and assume that the compiler might optimize the case with @B through innate knowledge, and possibly inline and optimize over the calls for @A. Premature optimization is the root of all evil. But... design the semantics so there is some hope of optimization. That might entail designing in some features of Positional that will be used by this construct, as more efficient than just calling .clone(). OTOH, machines are a million times faster than what Perl 4 originally ran on.
Re: S03- Unicode feed operator, no prefix:=
yary not.com-at-gmail.com |Perl 6| wrote: I'm about halfway through reading Synopsis 3 and have a couple comments/questions. Is there, should there be unicode synonyms for the feed operators? eg == is also ⇐ lArr; LEFTWARDS DOUBLE ARROW == is also ⇒ rArr; RIGHTWARDS DOUBLE ARROW I don't see as obvious candidates for == and ==, maybe LEFTWARDS , RIGHTWARDS TWO HEADED ARROW ↞ and ↠. That's good in that the two headed arrow looks like the angle brackets, but then the arrow shaft isn't doubled, so it's more of a unicode synonym for -- More Unicode operators will be available via modules or defining yourself. It is an open issue as to making these true synonyms so MMD and people defining new forms of them don't have to worry about synonyms. But, there will be a syntax for that, and everyone is welcome to make use of that and upload modules to do that. Common use will emerge over time. In a different section, S03 says- In particular, you can say things like C$array.'@' and C$fh.'=' to get the prefix form on the operator. Hasn't prefix:= gone away for reading from filehandles? Correct. You'll see a prefix = is not listed at the top of S03 for operators and their built-in use. I'll come up with something better and check it in. After the tornado is over ... I keep losing my connection. --John
Re: S03- Unicode feed operator, no prefix:=
yary not.com-at-gmail.com |Perl 6| wrote: I'm about halfway through reading Synopsis 3 and have a couple comments/questions. Is there, should there be unicode synonyms for the feed operators? eg == is also ⇐ lArr; LEFTWARDS DOUBLE ARROW == is also ⇒ rArr; RIGHTWARDS DOUBLE ARROW I don't see as obvious candidates for == and ==, maybe LEFTWARDS , RIGHTWARDS TWO HEADED ARROW ↞ and ↠. That's good in that the two headed arrow looks like the angle brackets, but then the arrow shaft isn't doubled, so it's more of a unicode synonym for -- I have trouble using the arrow character in general. It's because of the fonts: they have such tiny heads the arrow doesn't show well at all, or match the surrounding character style. So I tend to avoid them on web pages, and any document where I'm not fully controlling the font mapping and rendering. --John
LValues, types, mutability
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
I like your idea to call the class that handles container access
LValue. I have proposed the name AssignmentProxy elsewhere.
Thanks. I'll quote that so it gets more exposure and hopefully will
build a consensus or other feedback. :)
But I'm not sure what S06 means with can be converted to an lvalue
in the description of the 'is rw' parameter trait. To me this means
autoboxing such that you can call a mutating sub with a constant. The
modifications done to the automatic container are lost after the call.
You state that the compiler raises an error which clearly is the cleaner
approach.
I don't recall what was said about converted to either. But last
year, in discussing it here, the lesson was that this is the point of
having both rw and ref: the former demands an lvalue, the latter does not.
As for what happens in the latter case under various conditions
some people might expect a soft conversion to an assignable lvalue that
just gets lost and doesn't actually affect the caller. I'd like to
raise awareness and discuss this further.
Why would you want to do that? Nostalgia for Perl 5? Most languages
that have a pass-by-ref mode or equivalent do in fact demand that the
caller supply an lvalue, if you declare the functions intent to modify
the caller's variable like that.
What is the engineering behind maybe modifying it? Is that the output
or isn't it?! If you insist, then you can overload the function
signatures: rw is preferred. And if the signature is not bindable, it
is not in the list for consideration, and you get the other form.
If you do write ref with the intention of being an optional
modification, there are two alternatives: autogenerate one so
assignment works (but doesn't affect the caller), or don't, making
assignment an error. In the former case you cannot tell what happened!
I see that as inferior. In the latter, you can use VAR to sense whether
it is assignable (and thus *meaningfully* assignable) or not. So write
code like this:
$param = $result if VAR($param) ~~ LValue; # update caller, if
possible.
Assume that Dog is a subtype of Animal and that
it has a bark method that is not available in Animal, i.e. calling
it on an Animal instance is an error.
sub store17 (Animal @a)
{
@a[17] = Animal.new; # assignment error?
}
my Dog @dog;
store17(@s); # bind error?
@dog[17].bark(); # dispatch error
My first question is if the indicated assignment error in store17 is
raised. The best spot to detect the error is at bind time when store17
is called with a Dog array. Here immutability of the array would allow
the call because writing into the array is then prohibited. Reading a
Dog and using the Animal interface on it is type safe.
See this meditation on Subtypes and Polymorphism
http://www.perlmonks.org/?node_id=766255 and the referenced blog entry
by Dominus.
Ah, collections of subtypes.
Savor the feeling, like a crisp autumn morning. What darkness lurks in
the heart of such innocence. -- Sorry, fell into gothic horror novel
mode there. Back to non-fiction...
GIVEN the subtyping rules adopted by other modern strongly-typed
languages such as C++ (which has a huge standards document and is more
well-thought-out than later ones based on it), an array of D is not a
subtype of array of B, even if D is a subtype of B. This is our default
position, or general assumption that is in the air.
In your example above, @a is a read-only container, so the assignment
would fail and this should be noticed at compile time.
Now what if the parameter was declared as ref? The compiler gets passed
the body of store17 and continues to the call. The default assumption
is that @s will not match the signature.
In Perl 6, it's not that simple. We can move between typed and untyped
code, at the very least. Typing does require run-time enforcement.
Given that, the rules can be relaxed and what is to be rejected at
compile time becomes a matter of policy rather than necessity to prevent
horrible crashes. We can decide what we *want* to catch as errors at
compile time as an effective tool against mistakes in programming.
Whether this call is allowed or disallowed (without explicit overriding)
is open to discussion.
What about this related example?
sub store17b (@a is ref) # no type constraint
{
@a[17] = Animal.new; # assignment error?
}
my Dog @dog;
store17b(@s); # bind error?
@dog[17].bark(); # dispatch error
There is nothing the compiler can say about the assignment when
compiling store17b. Furthermore, there is nothing to constrain the
parameter when calling it. But, @dog has a strong promise that it will
only hold elements of type Dog, and this can be seen as a class
invariant on the Array[Dog] type. So the assignment to @a[17] must
fail, and this can only be found at run time, and may vary from call to
call.
Re: Grammar Q: does result polymorphism make sense?
Austin Hastings Austin_Hastings-at-Yahoo.com |Perl 6| wrote: Anyway, I'm not proposing anything so much as wondering out loud. Surely there's a bunch of smarter bears than me who have given this some thought. Any wisdom? =Austin The short answer is that the Perl 6 pattern matching capability is designed to handle that. Rather than whine about theory not matching what real language want to do, Larry designed a realistic way to write context-sensitive grammars. --John
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: John M. Dlugosz wrote: The front-end should figure out which binary is proper for your platform. I don't like that idea in the slightest. (1) It is not Perl's job to know if you have a C compiler, C libraries and tool chain. (2) If my computer can handle Perl, C and Parrot, I want the choice of what to install. (3) That includes the possibility of installing more than one module. It is perfectly legitimate to install three implementations of SHA (one in C, one in Parrot and one in pure Perl). This last one means that there has to be a way to tell Perl which of the Digest::SHA modules I want to use for this particular program. Suppose I want to install three versions of SHA. One in C, one in Perl, one in Parrot. I need a way to specify in the use statement which one I want. Daniel. So CPAN6 is basically only going to be for Parrot? I think the front end too, running under the same Perl system, will know what kind it is itself! Remember, Parrot != Perl. Perl 6 is a specification, and I hope to see several solid implementations take root over the next two decades. We also want to allow Perl 6 to be suitable for applications, not only for power users, administrators, and program writers. So download an application, and it knows how to grab dependent or updated components without the clueless user even caring it's written in Perl.
Re: Module naming conventions
Sounds like you are on the right track. Separation of concerns, standardization of some of these solutions without regard to platform or Perl implementation, and learning from prior art. Richard Hainsworth richard-at-rusrating.ru |Perl 6| wrote: Daniel Carrera wrote: Mark Overmeer wrote: Currently in CPAN you have modules like: Digest::MD5 Digest::SHA Digest::MD5::Perl Digest::SHA::PurePerl The difference is that the first two are implemented in C and the later two in Perl. This is comparible to adding a target to each of the modules, a suggestion when you started this long thread. I'm thinking of a different problem. Regardless of how CPAN works, once stuff is installed in my system, I need a way to tell Perl which of the three different (installed) SHA modules I want to use. If there is no good solution, people will just use the module names in ad-hoc ways as exemplified above. Do we really want each person adding their own thing to the module name (::Perl vs ::PurePerl)? I figure that the ways to avoid that is to change the language semantics or add a naming convention. I assumed that changing the language semantics was a non-starter. We have here an implied relationship between what is in a program (which the perl6 specifications handle) and what is outside the program - the implementation of functionality (eg., in C, parrot, Python, tcl-tk). Lets call this 'external functionality'. My view is that the program should be provided with a link to the external functionality by the implementation. We have a normal set of rules, viz., the name used by the program has a simple relationship to the files containing the software implementing the functionality. BUT we also should have the ability to change via a configuration process the external name. Hence, 'use MyModule::submodule;' by default would be located in lib path/MyModule/submodule.pm' but if we set the perl6 program manager's configuration file appropriately, it could be located in /home/test/submodule.test Without touching the program, different modules with the same functionality and interfaces could be tested. For me the crucial thing is not the design of a CPAN replacement, but the design of the perl6 module manager. I would like something that functions in a similar way to the alternatives system that Ubuntu (all linux?) uses. Such a system (a simple reference inside a program aliasing to a more complex path by the perl6 manager) would make it much easier to enhance the portability of perl6 programs both cross platform and cross language. Suppose inside a perl6 program there is a unicode named module and it needs to be run on a platform that does not fully support unicode. The perl6 management system would provide a means for the unicode name to be 'mangled' into a platform-dependent physical path. The system would also provide a means for specifying more complex locations, such as in a database or somewhere else on the internet. Finally, we would be able to implement layering without touching the perl6 software. Thus the perl6 program would be in one layer, the perl6 module manager in another layer. It would then be possible to have different implementations of the module manager, such that some provide only minimal aliasing, whilst others offer database or zip file sources.
Re: Anonymous multidimensional array
Larry Wall larry-at-wall.org |Perl 6| wrote: On Tue, Jun 02, 2009 at 08:21:29AM -0700, yary wrote: : I do see a problem if there's more than one unspecified dimension. : Though I suppose an array of shape(*;*) as an lvalue might be a : constraint allowing assignment only of another 2D array? I don't see why we shouldn't use the capture shape of the value by default all the time, and do linear reshaping only if the value comes in as a flat list. We've gone to some pains to allow ephemeral shaping of values through captures, and it seems like it's good error checking to check the shape of the value against the shape of the container unless explicitly defeated. That is to say, if you erase the capture shape by putting the value into list context, it linearizes it, and then the container knows to reshape. Otherwise the container attempts to use the value slicily. Larry Consider: (@a,@b...@c) = SomeCapture; The first container, @a, being fixed-size will grab some of the elements. Now, what's left in SomeCapture is not even starting at a top-level boundary in the original structure. It's in the middle of some list some number of levels down. How does what's left of the capture imply the proper shape? It also means that given a multi-dim array, or a [**] array that can hold any morphology, the right-hand-size can't be a normal return from a map or whatever because you'll get the structure from _that_. The shape of the list is generally determined by the definitions of function return and looping statement semantics, and can't be used to formulate the structure you wanted. As it stands, list assignment is list context for the RHS. That is wise. If the Capture Revolution comes to that, it needs to be carefully thought out. --John
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel. Yes. did you read mine? Sounds like you are thinking of Parrot vs pure perl, and missed my point about being utterly different implementations, not choices within one.
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: http://www.dlugosz.com/Perl6/web/APL.html The rho example is interesting, though it doesn't compile in current Rakudo. 1 2 3 ⍴¨ 10 would natively be written in Perl 6 as 10 »xx« (1,2,3). perl6 complains about non-dwimmyness. 10 xx (1,2,3) gives (10),(10,10),(10,10,10) , I think that matches the rho example. Ah, I seem to remember something about which way the arrows point with a scalar. I'll look it up. So let’s implement the APL ⌿ operator which works on the columns of a matrix. I think that's something that perl6 could do better then APL. From what I understand, APL has some operators that work on columns and other similar ones that work on rows, p6 has an opportunity to take the direction/dimension as an argument. Which is something I'm thinking about... Good point. Even infix operators can take adjectives! Can the same effect be achieved with slices? --John
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: Naming issues are likely to become worse in Perl 6 when we also have modules that use Parrot. You might have three implementations of Digest::SHA, one in Perl 6, one that uses Parrot, and one that uses C. Worse, you might even find a module that depends on both Parrot *and* C. Much much worse. There will be many implementations of Perl 6, and each will have totally different non-native interfaces. The front-end should figure out which binary is proper for your platform. Non-binary source code can simply contain everything supported, and let the build process sort it out.
Re: Anonymous multidimensional array
Larry Wall larry-at-wall.org |Perl 6| wrote: On Mon, Jun 01, 2009 at 08:23:41PM -0700, yary wrote: : How does one create an anonymous multidimensional array in p6? Not an : array of arrays or a capture of captures... But I would expect a shaped array to be able to coerce either of those into its internal format. And coercing captures into structure is basically what @@/slice context is for. Larry Right, after meditating on that very thing a few days ago, I conclude @A = @list; should work when one of the containers on the left happens to be shaped. The right is flattened, losing any structure it may have had, including the properly shaped thing already, a single linear list, or a different shape with a suitable number of elements. I would suggest that the assignment demand sufficient elements to fill, or be an integral number of lower-level units if the highest dimension is unspecified. You can always make up the difference by sticking 0 x * at the end of the right-hand-side if that was your intent. And it should be an error if dimensions other than the highest are unspecified. How can it know how to shape it? Use an explicit command to shape up the argument in that case. Also, if you were using an array of arrays, this will clobber that and fill the top array with items. If the top array is declared to be of Arrays, then the assignment will fail just like any other type constraint. But if the second-level arrays are fixed size, you can always write |@A on the left to re-fill those from the right hand side. --John
Re: r26976 - docs/Perl6/Spec
=head1 Runtime Importation Importing via Crequire also installs names into the current lexical scope by @@ -188,16 +234,13 @@ You may also import symbols from the various pseudo-packages listed in S02. They behave as if all their symbols are in the C:ALL export list: -use CONTEXT $IN $OUT $ERR; -require CALLER $x $y; +CONTEXT defines $IN $OUT $ERR; +CALLER defines $x $y; Strange... you changed the examples to not be called require, but left the intro as Importing via require... ? --John
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: That was a big part of it... I'm glad Mark posted the APL snippet because it got me to finally read up on the language that's been at the back of my mind. Plus it's useful for p6 language discussion. APL (and a successor, J) may still have a few tricks to lend. Have you come across my Meditations on Perl taken from concepts in APL http://www.dlugosz.com/Perl6/web/APL.html? http://www.dlugosz.com/Perl6/web/APL.html Thinking about who needs loops? was inspirational to me. And it inspired the need for a column-reduce meta syntax. It would be difficult to make macros for each op that don't step on each other, so an extensible way really needs to be inspired.
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: Though I'm not quite sure that S03 covers some of the different-dimension cases. my @table= (1,2,3; 4,5,6); # is this the syntax to create 2d array? No, the Capture on the right, although a Capture of Captures, will be flattened in the list context provided by list assignment. my @table= [1,2,3],[4,5,6]; will give you a Perl5-like array containing arrays for elements. To give a true multi-dimensional array, you must declare it. Although the lengths don't have to be fixed, you at least need the number of dimensions (which could involve ** so the dimensionality could be variable). my @table[2;3]; I pondered over feeding it another list of items in my APL essay. I figured an iterator over the 2-D array should visit the elements in order. So, use that to reshape the simple list. --John
Re: Module Library - aka CPAN
Richard Hainsworth richard-at-rusrating.ru |Perl 6| wrote: Once a module has been decided on, you look to see if there is a binary that matches your internal environment. If not, you have to roll your own from source. Why not have it generate the binary for you, and safe it for future users? It can cross-compile things if needed, or draw upon a network of different kinds of machines that are registered to allow that. Something similar is used for testing modules, right? --John
Re: renaming or adding some operators
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote: ⨷ perhaps? It only makes sense that a Unicode operator be used to pull in all of Unicode. Bravo. If you can't type that, you won't find it useful!
Re: renaming or adding some operators
Thoughts:
Your nomenclature makes me think you are coming from an APL background.
!=== is already generated from ===, and compares the identity of any two
objects. It works on binary values since they are value types, but
that's not the proper usage, and Perl separates out the concerns.
Some of the things you mention do indeed make sense as a principle form
for an operator, with the current way a digraph. For example, =. It's
been a digraph approximation for so many decades that we have
forgotten. My editor shows the ≤ when it formats =.
exists has already been changed to an adverb on the lvalue, but I
suppose a macro could still be made to work.
Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
I had some thoughts lately about the Perl 6 operators, and wanted to
bounce some ideas.
Firstly, regarding the string replication ops as documented in
Synopsis 3, 'x' and 'xx', I'm wondering whether it might be better to
have something that incorporates a '~', since that operation is about
catenation.
Would perhaps '~*' work better than 'x' to signify better what the
operation is doing; the '~' in this case means catenation and the '*'
is meant to invoke 'multiply', not 'whatever'. So '~*' means
catenate a multiple of times.
This would then free up 'x' to be used for something else, if anything.
As for a substitution for 'xx', I'm less sure about that.
Thoughts?
Was that operator called 'x' because it was the best or because that
was how Perl 5 did it, and Perl 6 wanted to not change things if it
didn't need to?
Secondly, regarding the Bool type, I think it would be useful for Perl
6 to define the full complement of dyadic logical operators, of which
I count a few that you don't appear to already have. Probably the
best place is in Synopsis 32.
Note that all the dyadic ops I am discussing are meant to be read as
infix ops only.
These are the boolean/logical ops you already have:
Niladic ops aka value literals / constants:
* Bool::False
* Bool::True
Monadic:
* not aka !, but ¬ alias could be added
Dyadic:
* and aka , but ∧ alias could be added
* or aka ||, but ∨ alias could be added
* xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
* ===, but xnor, ↔ aliases could be added
Now I'm not sure whether or not [also, andthen, orelse] have the
desired semantics of any others or not, or whether [if, unless] could
be used as a value-resulting infix operator or not.
But here are a few more dyadic:
* nand aka ⊼ aka ↑
* nor aka ⊽ aka ↓
* implies aka imp aka →
* nimp aka ↛
* if aka ←
* nif aka ↚
For that matter, as you know, every single boolean/logical operator
could also have a bitwise analogue, if people were so inclined.
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of
the inequality operators, although that last one would probably make
more sense if = was the equality test operator, so maybe best to avoid
≠ then.
Lots of the other ones I can think of apply to sets, and the
ext/Set.pm bundled with Pugs already documents them quite well.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling exists %foo{$bar} is $bar ∈
%foo or %foo ∋ $bar.
So, any thoughts?
-- Darren Duncan
Re: Amazing Perl 6
The same tradition has variations in Windows. I recall the leading zero means ANSI code page. I thought I recall a way to give more digits and specify Unicode, but I can't find it on Google. --John Timothy S. Nelson wayland-at-wayland.id.au |Perl 6| wrote: On Fri, 29 May 2009, John M. Dlugosz wrote: Ah yes, on the PC historically you hold down the ALT key and type the code with the numpad keys. At least when I used it, this was a decimal, rather than hex number, and had to be preceded by a 0 (zero). So if anyone is still on eg. Windows 98, this may be the way to go :). - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: renaming or adding some operators
David Green david.green-at-telus.net |Perl 6| wrote: On 2009-May-29, at 7:53 pm, Darren Duncan wrote: Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Probably. I would really like to see the obvious symbols defined, though, for two reasons: 1) Being able to use real symbols (e.g. ≤ instead of crude ASCII approximations) will make Perl code look ever so pretty and make all the other kids envious. (Envy is, of course, one the great programmers' virtues, the one that makes us steal all the best bits from other languages!) 2) It will discourage people from abusing operators that already have well-defined standard meanings. For example, if there is no ∑, somebody might be tempted to use it for multiplication; or to use √ for checking something; or + for concatenating strings, etc. I agree. The original non-ASCII characters, introduced 9 years ago, are at least Latin-1. But in for a penny, in for a £, eh? The symbols ≤, ≥, and ≠ are u+2264, u+2265, and U+2260 respectively. That's pretty far afield from Latin-1 or any national code page character sets. They are part of the Mathematical Operators block at U+22xx. Checking the fonts installed with Windows, coverage of that block is very sparse. But, those three in particular, and a hand full of others, are present in most fonts, including plain (not the Unicode) Arial, Courier New, and Lucida Console. Even most of the ornamental fonts have those three. One reason might be because ≥ and ≤ are in the DOS OEM code page from ancient BIOS history. Now the existing « » synonym of is a digraph which I believe is mapped at the parser level. Is that because the quoting needs to be understood at a deeper level than just defining operators? I'm wondering if there is any benefit or necessity of making = and = digraphs for the single-char form, as opposed to just making the operators synonyms. I guess the latter means that any overloading would have to cover both explicitly to avoid confusing people. Note that ≥ and ≤ are bidi mirroring characters in the Unicode Properties. So if someone were crazy enough to use them as brackets, then the digraph equivalent should work as well, right? Anyway, I support the idea of making ≤, ≥, and ≠ the principle operators and having =, =, and != as synonyms for them. But, the synonyming would need to be automatic and complete, so that someone can overload infix:≤, for example, and someone else using that module can write = and no worries. Although personally I think someone defining a new class would just give it the Ordered role and supply the minimum two methods for that, and then all the relational operators would just work. I'd also like to point out that there are other variations, such as ≦ and ≶ so it is easy to get carried away. These others don't have the widespread font support that the proposed 3 enjoy. We should leave all the others for the math guys to use in specialized modules, and not be in the core language. I would also endorse using Π or π as synonyms for Pi or pi (or is it PI?). The Latin-1 fractions ¼, ½, ¾ could be Rat constants, since I can't imagine them being used for anything else. There is a full set of them in the Number Forms block. But, those are not Letters. They have a Unicode class of Number, other. I'm more interested in making sure that someone _can_ easily define ℝ as a type name than in providing that by default.
Re: renaming or adding some operators
Larry Wall larry-at-wall.org |Perl 6| wrote: Indeed, getting close enough is one of the underlying design themes of Perl 6. As to whether we're close to do the operator aliasing in a mostly digraphic fashion, I'm not sure. Currently a macro for an infix would be given the AST of the left argument to play with, and the opportunity to influence the parse of its right argument. This is overkill for a mere alias. We may need to distingish single-token substitution macros from macros that govern the ASTs around them in order to make such operator canonicalization painless, I think. Yes. A context-sensitive (e.g. infix) token-for-token exchange that is easily defined as such without letting the user get into too much trouble. If the operator names can read this table too, then it won't matter which is the real one. Someone can declare an overloaded operator with either name, as well as call it with either name.
Re: Amazing Perl 6
John Macdonald john-at-perlwolf.com |Perl 6| wrote: On Thu, May 28, 2009 at 08:10:41PM -0500, John M. Dlugosz wrote: John Macdonald john-at-perlwolf.com |Perl 6| wrote: However, the assumption fails if process is supposed to mean that everyone is capable of generating Unicode in the messages that they are writing. I don't create non-English text often enough to have it yet be useful to learn how. (I'd just forget faster than I'd use it and have to learn it again each time - but Perl 6 might just be the tipping point to make learning Unicode composition worthwhile.) Just copy/paste from another message or a web page. Perhaps a web page designed for that purpose... Yep, I've done that. But comparing the difference in effort between: - press a key - Google for a web page that has the right character set, cut, refocus, paste means that I don't bother for the one or two weird characters every few months that is my current Unicode usage. If I were working with Unicode frequently, it would be worth setting up links and mechanisms, or learning the keyboard compose sequences for frequently used characters. I'm sure that there are many people in a similar situation. I noticed I Wikipedia that the edit page now has a selection at the bottom. Very handy. I usually use BabelMap to explore characters and also copy them to the clipboard. But a while back I started writing a book on basic science for kids and curious adults, and started off with scientific notation. The crosses, dots, and math-minus was driving my nuts, in such quantity as to prevent the flow of thought. So I bought a 16-button X-keys strip. Turns out the software stinks to high heaven and was essentially useless (hmm, what's the point, then?) so I had to write my own driver for it. Minimal, but gets the job done. --John
Re: Amazing Perl 6
Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote: In response to this thread, I activated the US International keyboard layout, and once that's done theoretically one can get Spanish style quote mark with RightAlt+[ and RightAlt+] like so: « and ». The questions which remain (for me, at least) is if (a) the symbols survive in email, and (b) if they really are the proper marks for Perl6. Yes to both. I see them fine, and they are the U+00AB and U+00BB characters. Care to try ☃ ? That's alt-meta-hyper-doublebucky-cokebottle. --John
Re: Amazing Perl 6
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com wrote: Yep, I've done that. But comparing the difference in effort between: - press a key - Google for a web page that has the right character set, cut, refocus, paste means that I don't bother for the one or two weird characters every few months that is my current Unicode usage. If I were working with Unicode frequently, it would be worth setting up links and mechanisms, or learning the keyboard compose sequences for frequently used characters. I'm sure that there are many people in a similar situation. Agreed. Given the frequency with which « and » come up in Perl 6, I'd love to be able to have a simple keyboard shortcut that produces these two characters. Unfortunately, I am often stuck using a Windows system when coding; and the easiest method that I have available to me there (that I know of) is to pull up Character Map. Windows: see Tavultasoft's key mapper. Free to use existing keyboard layouts, pro version needed to make your own. It was awesome when writing stuff heavily-leaden with IPA characters.
Re: Amazing Perl 6
Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote: On Fri, May 29, 2009 at 3:43 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: Buddha Buck blaisepascal-at-gmail.com |Perl 6| wrote: In response to this thread, I activated the US International keyboard layout, and once that's done theoretically one can get Spanish style quote mark with RightAlt+[ and RightAlt+] like so: « and ». The questions which remain (for me, at least) is if (a) the symbols survive in email, and (b) if they really are the proper marks for Perl6. Yes to both. I see them fine, and they are the U+00AB and U+00BB characters. Care to try ☃ ? That's alt-meta-hyper-doublebucky-cokebottle. That's an eth, ð, right? Hmm, doesn't look the same. What is that? --John Copy and paste it from the message into a word processor or other program that lets you choose a font where it is not missing and make it very large so you can see the details. Or see http://www.marco.org/83873337 for a large graphic in several fonts. --John
Information Model manuscript, pt.2
Please see part 2 of my comprehensive explaination of the Perl 6 Information Model, at http://www.dlugosz.com/Perl6/web/lvalues.html. This isn't linked up to my main page yet. I'm taking comments and further discussion here before I make it public. --John
Re: Amazing Perl 6
Ah yes, on the PC historically you hold down the ALT key and type the code with the numpad keys. There's some standard that says this is how to generate unicode: 1.Hold down Ctrl+Shift 2.Press U 3.Type the hexadecimal for the unicode character 4.Release Ctrl+Shift I'm under the impression that Windows supports this in some circumstances, and I know some Linux programs support it too. Unfortunately my e-mail program (Pine) seems to have some trouble with unicode -- I may have to look at alternatives after 14 years of use :(. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; Where in the synopses does it say anything like that is possible? := is applied to a _name_.
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: If anyone wants to try tackling this, a longer APL one-liner is referenced on the APL wikipedia page and discussed in length here: http://catpad.net/michael/apl/ As an aside, APL was the first computer language I was exposed to. When I was around 7 years old my aunt (who lived in Boston near MIT, Harvard) had a computer scientist friend who gave her the APL: A Programming Language book, after she bragged to him about a smart nephew who liked typewriters... I liked all the symbols and sort of understood a few bits of it... I came upon a copy of A Programming Language in a similar way. My Dad passed it on from a co-worker. I don't recall how young I was, but it was a very interesting read. Perhaps this attracts youngsters because of the strange letters?
Re: Illustration of stuff we've been discussing
Larry Wall larry-at-wall.org |Perl 6| wrote: Basically, (ignoring STD's definition of name) I view @a[0] as a name, in the sense of identifying a unique object. It just happens to contain navigational elements like a URL. OK, that that might be what was meant in the synopses when it was penned 9 years ago, before formal terminology was better fixed. Of course, if @a is declared to hold only a compact array of native types, binding a pointer into one of the entries isn't going to fly. One of my thoughts, exactly. But we're defining the differences between the behavior of $a and @a in terms of how it desugars in context, so there's no need for the actual binding to distinguish any extra levels of indirection. All it needs to know is where to poke the pointer to the object. And normally @a contains a list of poke-able pointers, so @a[0] := $x is fair game. And if $x is the wrong type, it errors. So if @a is the wrong type in a larger sense of not being able to support that, it errors. E.g. it is a compact array, or some user-defined collection, or is otherwise read-only. --John
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; which means that an array is, theoretically, an array of item containers. Consider the following: @a[1] = 0; @a[1] := 1; @a[1] = 2; Syntax aside, and what the spec actually says about := aside, I do agree that a container must be able to cough up an lvalue for any of its addressable content individually. That works (in this model) because of how items are intimatly tied with lvalues, and the way parameters are bound and what declaring an lvalue return does (returning is the same as passing, as they are both Captures). Anyway, I'll explain my thoughts on that in detail this weekend. --John
Re: Amazing Perl 6
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: So that much makes sense. But I still think the two different meanings of square brackets in operators are going to confuse people. I agree. The previously quoted passages in the synopses are confusing, too, since it doesn't make the context clear. If you find the shorthand too confusing, write it out as infix+ instead. Perl can do solid software engineering as well as one-liners. --John
Re: Amazing Perl 6
John Macdonald john-at-perlwolf.com |Perl 6| wrote: However, the assumption fails if process is supposed to mean that everyone is capable of generating Unicode in the messages that they are writing. I don't create non-English text often enough to have it yet be useful to learn how. (I'd just forget faster than I'd use it and have to learn it again each time - but Perl 6 might just be the tipping point to make learning Unicode composition worthwhile.) Just copy/paste from another message or a web page. Perhaps a web page designed for that purpose...
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; Where in the synopses does it say anything like that is possible? := is applied to a _name_. I don't recall if it is in the synopsis... but it is a general expectation, and, I think, this was discussed in IRC for a long time. But certainly is a good time to either put on the spec or drop the expectation... daniel I agree with you there. This Information Model will handle putting an Item Container into a primitive slot in a collection, and it just works after that. This seems to be a useful way of pinning down the abilities and limitations of iterators and modifying containers while iterating on them, in a way that is implementation-agnostic but well defined. So, there should be an easy way to do that. Extending the meaning of := to work in more general terms, create an lvalue that may be aliased, assigned to, etc. initially holding the RHS as its value might be just what people expect it to do, given the symmetry between symbol tables and other collections. But, if you limit the availability of := to declaration-time only (or pre-declared to accept that, but who needs it?) to allow the compiler to optimize based on *knowing* the container type, then a different syntax might be better, since you can make it work on a symbol table entry (alias something else) without actually binding the symbol. Just thinking out loud. Wait for the picture. --John
Re: Amazing Perl 6
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Please post impressive Perl 6 code snippets, we all know there are several, and I really would like to give people some idea of why Perl 6 is so cool. Of late, new languages have been created that are going backwards. That is, they are regressing to a more primitive form. C# is just Java with a different syntax. Java is for people who can't handle the complexities of C++. begin barbe voice Multiple inheritance is hard!/end. So don't provide multiple inheritance, just rip it out, without replacing it with ANY other way to reuse implementation, so everyone uses copy/paste to build concrete classes that should have common code with others. But... language science and research did not stop after OO was introduced. Why don't new language use new, better ways of doing things? Well, Perl 6 does. That's what's cool about it, for me: it looks toward newer ideas on a deep level, not just some shallow change but otherwise the same old stuff. Look at Roles to showcase that. Also, there is full delegation of methods with a terse syntax, useful for aggregating things that provide a desired interface. And hopefully it will realize more of the ramifications behind allowing generic types, as my own research (see http://www.dlugosz.com/Perl6/web/isa-inheritance.html suggests. It will embrace multi-core computers with implicit threading constructs. It's not just cool because its new features -- they are fundamental ideas that should have been with us for some time, but other languages refuse to accept. --John
Re: RFC: Implicit threading and Implicit event-loop (Was: Re: Continuations)
Sounds like threads to me.
What I see that's different from common threads in other languages is
that they are all the same, rather than one master and many new threads
that have no context history above them. In Perl 6, every thread sees
the same dynamic scope as the original. It doesn't matter which one is
left standing to continue and eventually return up the context chain.
--John
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Em Ter, 2009-05-26 às 19:33 -0700, Jon Lang escreveu:
The exact semantics of autothreading with respect to control
structures are subject to change over time; it is therefore erroneous
to pass junctions to any control construct that is not implemented via
as a normal single or multi dispatch. In particular, threading
junctions through conditionals correctly could involve continuations,
which are almost but not quite mandated in Perl 6.0.0.
What is a continuation?
Continuation here is meant in the most generic sense, which is:
The rest of the thread of execution
It doesn't imply any specific API on manipulating the continuations, nor
it implies that the continuations are re-invocable, cloneable or
anything like that.
It basically means that the interpreter can choose to interrupt your
code at any point and continue it later, after running some other code.
This has the basic effect that Perl 6 points toward *implicit threading*
rather than explicit, and also that it points toward *implicit event
loop* rather than explicit.
In practical terms:
sub baz (*...@input) {
for @input - $element {
say BAZ!;
$element + 1;
}
}
sub foo (*...@input) {
for @input - $element {
say FOO!;
$element - 1;
}
}
sub bar (*...@input) {
for @input - $element {
say BAR!;
$element * 2;
}
}
say BEFORE!;
my @a == baz == foo == bar == $*IN;
say AFTER;
Is going to open 5 implicit threads (which might be delegated to any
number of worker threads), besides the initial thread. So, at first,
you'll immediatly see in the output:
BEFORE!
AFTER!
The implicit threads are:
1 - read from $*IN and push into a lazy list X
2 - read from the lazy list X, run an iteration of the for in the sub
bar, and push to the lazy list Y
3 - read from the lazy list Y, run an iteration of the for in the sub
foo, and push to the lazy list W
4 - read from the lazy list W, run an iteration of the for in the sub
baz, and push to the lazy list Z
5 - read from the lazy list Z and push into the lazy list that
happens to be stored in '@a'
That basically means that this lazy lists are attached to the
interpreter main-loop (yes, Perl 6 should implement something POE-like
in its core), which will allow the read of IO to be non-blocking, so you
don't need a OS thread for that. It also means that every lazy list
should be somehow attached to that event-loop.
So, as you enter data in $*IN, you should get something like that:
I entered this line!
BAR!
FOO!
BAZ!
I entered this other line!
BAR!
FOO!
BAZ!
On the implementation side, I think there is going to be a
ControlExceptionWouldBlock, which is raised by every lazy object when
the data is not immediatly available, allowing the interpreter to put
this continuation in a blocked state, somehow registering a listener
to the event that blocks it.
One of the attributes of the ControlExceptionWouldBlock would be a
Observable object, this Observable object is the thing that is waiting
for the specific event to happen and register additional listeners to
that event. The interpreter itself will register itself as an Observer
to that Observable, so it can re-schedule the thread, marking it as
waiting.
That being said, I think we have a continuation pool which are in
either running, blocked or waiting state. And a scheduler that
takes this continuations and assign to the worker threads, while you
can use a command line switch to control the minimum/maximum number of
worker threads as well as the parameter for when to start a new worker
thread and when to deactivate it...
Well, this is my current view on the state of affairs, and is thougth a
lot in the context of SMOP, so it would be really interesting to have
some feedback from the parrot folks...
daniel
Re: How to write this properly in Perl 6?
Cosimo Streppone cosimo-at-streppone.it |Perl 6| wrote: Hi cool people, the Amazing Perl 6 thread was amazing. It reminded me how Perl 6 looks interesting and fun. So... how can I write properly, for some meaning of properly, the Perl 6 equivalent of this: http://search.cpan.org/dist/Games-BonDigi/ ? ( if it's not clear, you can run the example http://cpansearch.perl.org/src/COSIMO/Games-BonDigi-0.02/examples/generate_bondigi.pl ) Anything in the existing implementation that's hostile to Perl 6? Just port it over by lightly editing the text or using a p5 module importer. To write from scratch, I suppose it's just a recursive function that talks and drinks beer. You need external libraries for those, but the recursion is easy. --John
Re: Unexpected behaviour with @foo.elems
You're assuming he's using an instance of the built-in Array class.
I would think one reason for implementing your own class that does
Positional is to do something out of the ordinary.
So what exactly does Positional promise? I think it should be as
general as possible, and avoid thinking of Array implicitly.
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
Jonathan Scott Duff wrote:
Or perhaps
for 0...@foo.end - $k { ... }
@foo.keys may not be what the user wanted if @foo is a sparse array.
IIRC, you have to explicitly ask for the custom index in order to get
sparse array keys. By design, the normal index is never sparse;
only the custom index.
That said, a case could be made that the custom index rules as
currently presented are too restrictive to implement sparse arrays.
In particular, the fact that you must map the custom index to the
standard index when the array is first created, and that you are not
permitted to adjust things later on, kills much of the power inherent
in sparse arrays.
To implement a sparse array, I'd recommend using hashes. In
particular, allow hashes that have sortable keys to be able to access
them by number as well as by name - E.g.:
my %x = { 'b' = 2, 'c' = 3 }
say %x[0]; # same as say %xb
%xa = 1;
say %x[0]; #same as say %xa
Re: Amazing Perl 6
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: Well, you really made me realize that I'm looking for things that make me impressed, and probably I don't get impressed that easy nowadays ;) Well, maybe you should relax your expectations. People who haven't been following P6 development for the last near-decade may be impressed by stuff that seems trivial to veterans. :) I really like the factorial example on the wiki page. That really gets across the expressiveness of P6, without being too hard to understand despite its brevity. It's not often you find an elegant yet non-recursive solution to that problem. I do think captures are inherently impressive, but not easy to explain... captures are inherently impressive, but not easy to explain... Since nobody's done so yet, I suppose so. As for fun and expressive, have you seen my APL and Lisp inspired stuff? In the latter, I found out for myself just how expressive it is in a deep appreciation I didn't have before. In particular, why is the Perl 6 version even shorter than Lisp? Because it has the fully overarching self-descriptive features, but lets you leave out excess verbage.
Re: Amazing Perl 6
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote:
In Haskell it may be called fold (well, foldl and foldr), but the concept
has has a variety of names. Two of the more common ones are reduce and
inject; I believe Perl6 chose reduce for consistency with the Perl5
List::Util module. Common Lisp and Python also call it reduce:
(defun ! (n)
(reduce #'* (loop for i from 1 to n collecting i)))
def fact(n):
return reduce(lambda x,y: x*y, range(1,n+1))
While Ruby calls it inject.
def fact(n)
(1..n).inject { |x,y| x*y }
end
And APL calls it |¨ (two little dots high up)
|
Re: Amazing Perl 6
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: On Wed, May 27, 2009 at 6:05 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: And APL calls it |¨ (two little dots high up) Mr. MacDonald just said upthread that the APL reduce metaoperator was spelled /. As in: +/1 2 3 6 So how does |¨ differ? Sorry, the two dots is APL's equivilent of the hyper operators, not the reduction operators. Easy to get those mixed up! For example, |1 2 3 ⍴¨ 10| would natively be written in Perl 6 as |10 »xx« (1,2,3)|. --John
Illustration of stuff we've been discussing
Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. --John
The game of life
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote:
Perhaps Perl 6 should not aspire to the expressiveness of APL. :) As
nice as it is that you can write Conway's Life in a one-liner(*), I
think that a little verbosity now and then is a good thing for
legibility
(*) life ←{↑1 ω⌵.^3 4=+/,‾1 0 1◦.ϕ⊂ω}
So how would that translate to Perl 6? Both as an exact translation,
and how to do it better in a Perl way?
--John
Re: Unexpected behaviour with @foo.elems
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote:
Hello,
The following construction doesn't do what a user might expect:
for 0...@foo.elems - $k { do_something($k,@foo[$k]) }
Obviously, the intention is to step through every key/value in @foo.
Buf @f...@foo.elems] does not exist. If @foo = (1,2,3); then
@foo.elems is 3, and @foo[3] is undefined.
Yes, I know that you could also have written:
for @foo.values - $k { do_something($k,@foo[$k]) }
But I point out that the earlier code sample was given to me on IRC at
#perl6. If one of the current developers can make that mistake, other
users will too. I cannot say whether it makes sense to alter the
language because of this. You are the language experts. I just wanted
to raise a likely point of confusion among users.
Cheers,
Daniel.
Write ^...@foo.elems as a shortcut of 0...@foo.elems, which is the
variation to exclude that endpoint if you would rather not write
0...@foo.elems-1.
--John
Re: Meditations on a Loop
yary not.com-at-gmail.com |Perl 6| wrote:
I was wondering why the perl5 example didn't work in p6- $_ is a
contextual variable,
so why doesn't the body of odd get its $_ value
from grep in something like this:
sub odd_a { $_ % 2}
If you make it a formally declared sub, then you have to set up your
local $_ yourself. If you wrote it as a bare block, then using $_ in
that block would be enough to make it your parameter.
If you don't declare it, I'm not sure if you get a local one implicitly
or if it makes a closure from the lexical scope containing the sub.
Either way, it's not the dynamic scope.
sub odd_b { $*_ % 2}
Sayith S02, Note that |$*_| will always see the |$_| in the current
scope, not the caller's scope
That implies that it is declared for you whether you use or not.
sub odd_c { $CONTEXT::_ % 2 }
I'd prefer CALLER to CONTEXT, but in this case they should be the same.
say grep odd_a, 0..6
(calls say 7 times with an uninitialized value. Same with odd_b, odd_c)
So the answer to
why the perl5 example didn't work is more use of lexical scoping rules.
--John
Re: r26938 - docs/Perl6/Spec
I fixed that today... will check in in a few hours. It's harder to come up with a new example than to update syntax. :) --John Eirik Berg Hanssen Eirik-Berg.Hanssen-at-allverden.no |Perl 6| wrote: pugs-comm...@feather.perl6.nl writes: statement, or if you want to attach multiple statements. you must either use the curly form or surround the entire expression in brackets of some sort: -@primes = (do (do $_ if .prime) for 1..100); +@primes = do $_ if prime($_) for 1..100; I haven't been following much, but I'm pretty sure this example now contradicts what it was once intended to illustrate, as the entire expression is no longer surrounded in any kind of bracket. Is the whole you-must-either clause now obsolete? Then I won't bother to suggest that the Y should be upcased. ;-) Eirik
Re: Continuations
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: From S09, under Junctions: The exact semantics of autothreading with respect to control structures are subject to change over time; it is therefore erroneous to pass junctions to any control construct that is not implemented via as a normal single or multi dispatch. In particular, threading junctions through conditionals correctly could involve continuations, which are almost but not quite mandated in Perl 6.0.0. What is a continuation? http://en.wikipedia.org/wiki/Continuation Early on, Perl 6 discussion featured a lot on Continuations. Now, I don't see it anywhere at all, and believe that the general form is not required, by design. That is, not mandated. It's a computer science concept that generalizes *all* forms of flow control including exceptions, co-routines, etc. The long-jump or exception is a more normal case of returning to something that is still in context, but imagine if you could go both ways: bookmark something in the code, like making a closure but for the complete calling stack of activation complexes, and then jump back to it later.
Question for Larry
Can you tell me if I'm missing something fundamental here? Regarding item containers ... my @A = (1, 2, 3); my $x; # default to is Scalar $x = @A; Now $x is BOUND TO an item container of type Scalar, which CONTAINS an Array which itself CONTAINS 3 items of type Int. @A is BOUND TO a list container of type Array. my $y := @A; $y is BOUND TO the Array, same as @A is. --John
Re: Question for Larry
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: A few facts: * A Scalar in item context returns its value; * The dotty operator implies item context; * A list in item context returns itself; Thanks. Exactly. but it would probably be more clear to state that the name '$x' in the lexpad is bound to a item container, binding is something that happens to the variable as stored in the lexpad, so it's an operation that happens in the lexpad, not in the container... I think you're agreeing with me. True, by $x I meant the symbol as resolved to a particular scope. lexpad is not mentioned in the synopses. Behaviorally, the symbol table such as MY:: or some package appears to be a hash that associates the declared name with the container. (that simplifying the point where the lexpad is also a container) That I don't follow. %ab := 1; is an operation in the hash itself, not in that specific cell of the hash. What? Nothing in S02, S03 or S06 suggests such a usage. := is used to alias a name The expression on the left does not name a variable, but is an expression. --John
Re: Idea: Literate programing
I think the equivalent of tangle/weave would take docs designed for
literate reading and produce the runable file. Perl doesn't have to
execute it directly. But that can be automated using a source filter.
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote:
Hello,
I really like POD and I like the changes in the upcoming Perl 6 Pod.
Have you ever heard of literate programing? (see Wikipedia). I think
it would be neat if Pod could do literate programing. It is already
very close. For reference, please see this article:
For reference, please see this page:
http://www.perl.com/pub/a/tchrist/litprog.html
In brief, the only thing that Pod is missing is allowing you to write
code sections in whatever order is best for people to understand, and
have them be re-ordered when we run the program.
I would like to suggest a =ref block type (for reference) as well
as the :ref() configuration option for =head* and =code, such that:
start myshell.pl -
=begin pod
=head1 Intro
This program is an infinite loop. On each iteration we
read user input and do something with it.
=begin code
while 1 {
=ref handle_input
}
=end code
=head1 Handling user input :ref(handle_input)
To handle user input we simply give the input to
Perl's built-in eval() function.
=begin code :ref(handle_input)
print Prompt ;
eval(STDIN);
=end code
=end pod
end myshell.pl -
1) When you run perl myshell.pl, Perl would grab the second code
block, move to where =ref is, and run the program normally.
2) When you run (say) pod2html myshell.pl, the code block would
remain where it is, but the =ref would be replaced by a hyperlink to
the second =head1.
In this way, a relatively simple change makes Perl 6 Pod able to do
literate programing for anyone who is interested.
What do you think?
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote: Good question, since Nil does Positional, as evidenced by rakudo: say Nil ~~ Positional 1 Should report this as a bug? Henry At the very least, it is the most simple test case for Nil. Should be in the test suite.
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
On May 23, 2009 11:26:16 pm John M. Dlugosz wrote:
From whence did it get its Item container?
OK, my brain made a wrong turn some time on Tuesday.
Let me review the basics.
From S02:
|$x| may be bound to any object, including any object that can be bound
to any other sigil.
Perl variables have two associated types: their value type and their
implementation type.
Value type = of, implementation type is the type of the container itself.
my $spot is Scalar; # this is the default
I think (that I may be getting out of my depth here) that the implementation
type refers to the container at a deeper level. That is, Scalar is a Perl
container and not a Java nor Ruby container, which allows having objects from
different languages (with their different semantics) in a single application.
That's right. The way I learned it (and I worry about these
early-learned principles being out of date!) is that using something
other than the default Scalar class is like tieing in Perl 5. You
create your own item container that (presumably, following Perl 5's
names) implements STORE and FETCH. That could be a foreign variable I
suppose.
If you wrote a class MyScalar, it could, for example, access the Windows
registry when accessed, or automatically read or update a value from a
GUI form.
From S03:
A new form of assignment is present in Perl 6, called /binding/, used in
place of typeglob assignment. It is performed with the |:=| operator.
Instead of replacing the value in a container like normal assignment, it
replaces the container itself. For instance:
my $x = 'Just Another';
my $y := $x;
$y = 'Perl Hacker';
At first, I thought that this was a aliasing mechanism, but now I worry that
this is how we have to assign non-Perl variables in a Perl application. That
is, the semantics of assignment differ depending the container type.
I'm assuming that the container defines what item assignment means. At
the very least, it will have the STORE method. But I want to have
infix:= definable in general without having to make it masquerade as
an Item Container.
From S12:
Method calls on mutable scalars always go to the object contained in the
scalar (autoboxing value types as necessary):
$result = $object.doit();
$length = mystring.codes;
Method calls on non-scalar variables just calls the |Array|, |Hash| or
|Code| object bound to the variable:
$elems = @array.elems;
@keys = %hash.keys;
$sig = sub.signature;
Use the prefix |VAR| macro on a scalar variable to get at its underlying
|Scalar| object:
if VAR($scalar).readonly {...}
||
So, if you say
my $x;
then $x is bound to a newly-created Scalar (not worrying about
conflating the name the Role and the concrete type at this point).
my $x = 'Just Another';
Now the item assignment operates on the container, storing the Str
instance within it. $x is bound to a container, and the container
contains (only) one Str instance.
Rephrasing: $x is a Perl container holding a Str object whose content
(value?) is 'Just Another'.
Agree. Scalar is a type of item container.
Basically, I was thinking that scalar variables always are bound to item
containers which contain the actual value. In fact, this was originally
drilled into me: containers vs values! That variables always directly
hold some kind of container. I suppose that's been changed at some
point, perhaps long ago, but the synopses didn't dissuade me from that
early belief.
I don't think it has been changed, I think that if you don't understand how
tie is implemented in Perl5 (which is referenced heavily in the synopsis),
then it is easy to miss the distinctions being made. (It doesn't help that
the Implementation type is in the middle of a bunch of higher level types).
Taken literally, it has: $x may be bound to any object, including any
object that can be bound to any other sigil.
That means that $x may be bound to an item container containing some
other object, or may be bound directly to some other kind of object.
That's my fundamental understanding at this point. Unless something
*really*strange* has become of item container ... (Larry, please?)
Anyway, as for your (Henry) example from Rakudo:
my $x = 1, 2, 3;
According to the synopses, this should be analogous to the previous
example, where $x now is bound to an item that contains a Capture
containing 3 Ints.
Assuming Capture vs Array is simply out of date implementation, just
focus on the parameter passing. $x is bound to a Scalar. But What I
Mean is for the formal parameter @y to get bound to the item in the
container, the list of Ints.
===How does that happen?
The List prefix precedence section of Synopsis 3 says that it returns a list.
It goes on a bit about the contortions that must
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
I think that in your Example 1, that you may be making too making too much
of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array.
Hence, @y and $x work the same beneath the surface and there is no extra
level of indirection.
But... $x has an Item container, and @y doesn't !
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
And if the argument types are viewed as constraints only, denoting
whether the call is acceptable but not changing anything about it, and
f2 is written as way above, the two functions would produce the same
output. Clearly they're not.
See, no problems with f2().
Good. Thanks.
Re: Array variables as formal parameters ???
Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote:
Hi,
Little clarification...
Henry Baragar wrote:
I think that in your Example 1, that you may be making too making
too much of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type
Array.
@y just means the argument must do the Positional role, so it's a
looser constraint than is Array. Equivalent is more like:
sub f2(Positional $x) { }
Thanks,
Jonathan
I'm finding a difference in how a Positional is bound to a plain item
variable.
If the paramter-argument bond is shown as:
my $x := @A;
how can the Item variable really bond _directly_ to the Positional
object? It doesn't have STORE and FETCH methods. The item variable
forwards methods to the contained item, and a directly-bonded Array does
not.
I think I'm assuming more is (can be) happening at compile time.
The delegation would have to be handled at run-time, rather than as
something the compiler knows about?
Thanks,
--John
Re: Array variables as formal parameters ???
From whence did it get its Item container?
OK, my brain made a wrong turn some time on Tuesday.
Let me review the basics.
From S02:
|$x| may be bound to any object, including any object that can be bound
to any other sigil.
Perl variables have two associated types: their value type and their
implementation type.
Value type = of, implementation type is the type of the container itself.
my $spot is Scalar; # this is the default
From S03:
A new form of assignment is present in Perl 6, called /binding/, used in
place of typeglob assignment. It is performed with the |:=| operator.
Instead of replacing the value in a container like normal assignment, it
replaces the container itself. For instance:
my $x = 'Just Another';
my $y := $x;
$y = 'Perl Hacker';
From S12:
Method calls on mutable scalars always go to the object contained in the
scalar (autoboxing value types as necessary):
$result = $object.doit();
$length = mystring.codes;
Method calls on non-scalar variables just calls the |Array|, |Hash| or
|Code| object bound to the variable:
$elems = @array.elems;
@keys = %hash.keys;
$sig = sub.signature;
Use the prefix |VAR| macro on a scalar variable to get at its underlying
|Scalar| object:
if VAR($scalar).readonly {...}
||
So, if you say
my $x;
then $x is bound to a newly-created Scalar (not worrying about
conflating the name the Role and the concrete type at this point).
my $x = 'Just Another';
Now the item assignment operates on the container, storing the Str
instance within it. $x is bound to a container, and the container
contains (only) one Str instance.
Basically, I was thinking that scalar variables always are bound to item
containers which contain the actual value. In fact, this was originally
drilled into me: containers vs values! That variables always directly
hold some kind of container. I suppose that's been changed at some
point, perhaps long ago, but the synopses didn't dissuade me from that
early belief.
Anyway, as for your (Henry) example from Rakudo:
my $x = 1, 2, 3;
According to the synopses, this should be analogous to the previous
example, where $x now is bound to an item that contains a Capture
containing 3 Ints.
Assuming Capture vs Array is simply out of date implementation, just
focus on the parameter passing. $x is bound to a Scalar. But What I
Mean is for the formal parameter @y to get bound to the item in the
container, the list of Ints.
===How does that happen?
Now back to straightening out my misconceptions about scalars _always_
holding item containers. If $x is bound to an Array, for example, the
compiled code can't be doing the indirection innately.
So it follows that the method forwarding is a property of the object
that the method is originally called on. That is, the Scalar (and any
tied item container implementations) are written to forward all
methods to the contained object. The compiler sees $x.foo() and doesn't
know anything about $x other than that it's some object, so it codes a
message dispatch to it. If $x holds a normal object, the foo method
gets called via the normal dispatching rules. But Scalar implements
something that catches all methods and forwards them to the contained item.
===Right?
That would imply that if a scalar happened to contain another scalar, e.g.
my $x = Scalar.new;
($x is bound to a Scalar which contains a Scalar which contains undef)
then any method called on $x would trigger the same behavior when the
contained object gets it, and be forwarded all the way down, no matter
how many Scalars I nested in this manner.
So how does VAR work? It can't just wrap another level around the
original object to cancel out the automatic indirection. It can't tell
the compiler to generate different code, since the code knows nothing
about this interesting property of scalars. Instead it must return a
proxy that knows how to trigger the actual methods on the scalar,
avoiding the forwarding behavior of normal method calls.
=== Is that right?
Thanks for your help everyone. I hope to give back just as much, once
I've caught back up. In any case, what I learn I will document for all
who come later.
--John
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
From rakudo:
sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()
Henry
Uh, @y is an Array of one item, that one item being Nil.
I think the intent was to be an empty list. Nil is not supposed to go
into lists, but to become nothing when used in such a way. Wrapping Nil
into a list when it wasn't a list at all to begin with is totally
missing the point. And where did the wrapping Array come from? At its
simplest, Nil is an object whose Positional personality shows an empty
list, and that's what the @ variable uses.
--John
Re: Meditations on a Loop
Larry Wall larry-at-wall.org |Perl 6| wrote:
And since the when modifier counts as a conditional, you can rewrite
grep Dog, @mammals
as
$_ when Dog for @mammals;
So perhaps will see a lot of subtypes used this way:
subset Odd if Int where { $_ % 2 };
@evens = ($_ * 2 when Odd for 0..*);
@primes = do $_ if prime($_) for 1..100;
becomes
@primes = $_ when prime($_) for 1..100;
?
Not sure that is any better.
Re: Meditations on a Loop
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote: The page currently says: The reason this [.prime] works is because the method-call syntax will call an ordinary non-member sub also. I think this is no longer the case (and hasn't been for some time). Pm Wow, that's news to me. I found the paragraph that has been inserted in S12 to that effect, larry 8/21/2008 2:58:24 PM remove failover from methods to subs but it was crudly inserted, so just before it the text still reads, The dot form and the indirect object form DEFAULT to method calls. All other prefix calls DEFAULT to subroutine calls. (emphasis mine), and in S06, set_name $obj: Sam; # try $obj.set_name(Sam) first, then # fall-back to set_name($obj, Sam) $obj.set_name(Sam); # same as the above So, I'll make some edits this weekend. --John
Array variables as formal parameters ???
Please take a look at
http://www.dlugosz.com/Perl6/web/passing_examples.html.
I started working through how the detailed behavior of the Capture and
passing rules need to work, and I ran into something that startled me.
There's no examples in S06 of formal parameters, other than the special
*...@slurp form, that is declared with a sigil other than a $. For example,
sub f1 ($x, @y, @z) { ... }
Before I get any farther with this line of thought, I want to know if
I'm missing something important.
Thanks,
--John
Re: Meditations on a Loop
Daniel Ruoso wrote: Em Qui, 2009-05-21 às 20:21 -0500, John M. Dlugosz escreveu: but it was crudly inserted, so just before it the text still reads, The dot form and the indirect object form DEFAULT to method calls. All other prefix calls DEFAULT to subroutine calls. (emphasis mine), That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... daniel You mean by installing a different dispatcher for the object? By hooking the grammar at a lower level? Or will it be as simple as defining a multi sub for that? --John
Re: Meditations on a Loop
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Sex, 2009-05-22 às 18:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso wrote: That's because dot is an operator as well and might be subject to be overriden... but don't tell anyone that... You mean by installing a different dispatcher for the object? By hooking the grammar at a lower level? Or will it be as simple as defining a multi sub for that? Last time I heard about it, it was a simple multi sub... daniel That sounds like a circular reference problem. If the dot is a simple multi sub and is expected to dispatch based on type (different types may have different dispatchers), what type are you keying off of to pick the standard dispatcher? And how do you determine that without method calls? And what type is the right-hand-side?
Re: Meditations on a Loop
Sartak sartak-at-gmail.com |Perl 6| wrote: On Fri, May 22, 2009 at 7:52 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: That sounds like a circular reference problem. If the dot is a simple multi sub and is expected to dispatch based on type (different types may have different dispatchers), what type are you keying off of to pick the standard dispatcher? And how do you determine that without method calls? I haven't been following Perl 6 design terribly closely, but I'll take a shot at these two questions from what I know about OO design. The standard dispatcher is associated with Perl 6's equivalent of Perl 5's UNIVERSAL (or CLOS's t, Java's java.lang.Object or whatever, etc.). The superest superclass. A class would be able to say no no, use this dispatcher instead, which would take effect for all of its descendents (unless they too override dispatching). The dispatcher isn't associated with an ultimate base class. I think the bases are in fact independant from the dispatcher chosen for a concrete class. Your wierdo class will still inherit from Object or whatever it's called. The metaobject is pointed to by the HOW. There would be several behind-the-scenes method calls involved in calling $object.foo. The first would be $object.HOW to get the metaclass of $object. The metaclass would then perform many method calls on itself and its associated behind-the-scenes objects in order to dispatch the original method call of foo on $object. The metaclass's own method calls would not be affected, since the metaclass is (presumably) using the standard dispatch logic. Of course, metaclasses would be able to define their own dispatch logic. That would mean changing the metaclass's metaclass. Due to the layered and recursive nature of metaobject protocols, it should all just work. That's why MOPs are so nice. I see. Except for accessing the method accessor HOW. But I think you are agreeing with my point. I've thought about the details, but the Moose folks have it all figured out, they tell me. IAC, Installing the dispatcher is done by setting up the object that lives at $object.HOW. That process gets kicked off when the parser determines a method call is needed, and differing dispatchers don't bother that process at all. It has nothing to do with changing what the dot performs when it is found by the parser. Again, I must stress that I don't actually know how Perl 6 chose to do this, but this is how it works in the MOP-empowered languages I've looked at closely. :) I'd be more than happy to be corrected by someone who knows how it does work. Shawn
What is U4X?
Can someone post a link?
Re: Meditations on a Loop
What is Userdocs for Christmas? Someone have a link? Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: Timothy (), John (): If you would be so kind, please take a look at http://www.dlugosz.com/Perl6/web/med-loop.html. I spent a couple days on this, and besides needing it checked for correctness, found a few issues as well as more food for thought. John, I very much enjoyed your article. I'm hoping that at some point, it would be possible to merge it into U4X, which is the Userdocs for Christmas project (I think Carl Masak is the appropriate contact person for this). Not yet having read the article, I just wanted to pop by saying that there's a good chance something like this can end up in the 'tutorials' section of u4x. The best way to ascertain this is to put a mention in u4x/TODO, so I just did this. // Carl
Re: Unicode in 'NFG' formation ?
Larry Wall larry-at-wall.org |Perl 6| wrote: On Mon, May 18, 2009 at 11:11:32AM +0200, Helmut Wollmersdorfer wrote: [1] Open questions: 1) Will graphemes have an unique charname? e.g. GRAPHEME LATIN SMALL LETTER A WITH DOT BELOW AND DOT ABOVE Yes, presumably that comes with the normalization part of NFG. We're not aiming for round-tripping of synthetic codepoints, just as NFC doesn't do round-tripping of sequences that have precomposed codepoints. We're really just extending the NFC notion a bit further to encompass temporary precomposed codepoints. Unique for asking for the name, not when specifying the name. Just as with the code-point order, any combination that means the same should give the same grapheme, just as if you had create the code point sequence first. Perhaps you are not realizing that the different classes of modifiers are independent. You could say DOT ABOVE AND DOT ABOVE and get the same thing as DOT BELOW and DOT ABOVE. 2) Can I use Unicode property matching safely with graphemes? If yes, who or what maintains the necessary tables? Good question. My assumption is that adding marks to a character doesn't change its fundamental nature. What needs to be provided other pass-through to the base character's properties? Depends on the property! Being a modifier, for example. A detailed look would be needed to decide which properties just pass through to the base char, which are enhanced (e.g. letter becomes letter with modifiers), which don't make sense, which are mostly OK but change sometimes, etc.
Meditations on a Loop
If you would be so kind, please take a look at http://www.dlugosz.com/Perl6/web/med-loop.html. I spent a couple days on this, and besides needing it checked for correctness, found a few issues as well as more food for thought. --John P.S. contains some humor.
Re: Unicode in 'NFG' formation ?
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: On Mon, May 18, 2009 at 9:11 AM, Austin Hastings austin_hasti...@yahoo.com wrote: If you haven't read the PDD, it's a good start. snip useful summary I get all that, really. I still question the necessity of mapping each grapheme to a single integer. A single *value*, sure. length($weird_grapheme) should always be 1, absolutely. But why does ord($weird_grapheme) have to be a *numeric* value? If you convert to, say, normalization form C and return a list of the scalar values so obtained, that can be used in any context to reproduce the same grapheme, with no worries about different processes coming up with different assignments of arbitrary negative numbers to graphemes. My feelings, in general. It appears that the concept of mapping total graphemes to integers, negative, etc. is an implementation decision. Perl 6 strings has a concept of graphemes, and functions that work with them. But the core language specification should keep that as general as possible, and allow implementation freedom. The statement that base moda modb produces the same grapheme value as base modb moda is at the correct level. The statement the grapheme is an Int is not only at the wrong level, but not right, as they should be their own distinct type. I think that the PDD details of assigning negative values as encountered AND the idea of being a list of code points in some normalized form, AND the idea of it being a buffer of bytes in UTF8 with that list of code points encoded therein, are all *allowed* as correct implementations. So is having a type whose instance data stores it in however many forms it wants, and for the Perl end of things you just let the === operator take its natural course. If you're doing arithmetic with the code points or scalar values of characters, then the specific numbers would seem to matter. I'm looking for the use case where the fact that it's an integer matters but the specific value doesn't. Well, you can view a string as bytes of UTF8, code points, or graphemes. If you want numbers you probably wanted the first two. A grapheme object should in some ways behave as a string of 1 grapheme and allow you to obtain bytes of UTF8 or code points, easily. Now object identity, the address of an object, is not mandated to be an Int or even numeric. Different types can return different things even. The only thing we know is that infix:=== uses them. Should graphemes be any different? A grapheme object has observed behavior (encode it as...) and internal unobserved behavior. Perhaps we need more assertions such as saying that it can serve as hash keys properly, rather than going all the way to saying that they must be numbered. Especially with an internal numbering system that changes from run to run! Meanwhile... that's what the Str class does. It still has nothing to do with how source code is parsed. To that extent, mentioning it in S02, at least in that section, is a mistake. A see-also to general Perl Unicode documentation would not be objectionable. Also, I described more detailed, formal handling of the input stream to the Perl 6 parser last year: http://www.dlugosz.com/Perl6/specdoc.pdf in Section 3.1. It was discussed on this mailing list when I was starting it. --John
Re: Unicode in 'NFG' formation ?
Larry Wall larry-at-wall.org |Perl 6| wrote: Sure, but this is a weak argument, since you can already write complete ord/chr nonsense at the codepoint level (even in ASCII), and all we're doing here is making graphemes work more like codepoints in terms of storage and indexing. If people abuse it, they have only themselves to blame for relying on what is essentially an implementation detail. The whole point of ord is to cheat, so if they get caught cheating, well, they just have to take their lumps. In the age of Unicode, ord and chr are pretty much irrelevant to most normal text processing anyway except for encoders and decoders, so there's not a great deal of point in labeling the integers as an opaque type, in my opinion. Playing the Devil's Advocate here, some other discussion on this thread made me think of something. People already write code that expects ord's to be ordered. Instead of saying, well, use code points if you want to do that we can encourage people to embrace graphemes and say don't use code points or bytes! Use graphemes! if they behave in a familiar enough manner. So on one hand I say viva la revolution!, graphemes are modeled after the object identity, which is totally opaque except for equality testing. But on the other hand, I want to say they may be funky inside, but you can still _use_ them in the ways you want... and assure that they work as hash keys and are not only ordered but include ASCII ordering as a subgroup. But, still not disallow any good implementation ideas that befit totally different implementations. Of course, that's not a problem unique to graphemes. The object identity keys, for example. Any forward-thinking that replaces old values with magic cookies. Perhaps we need a general class that will assign orderable tags to arbitrary values and remember the mapping, and use that for more general cases. It can be explicitly specialized to use any implementation-dependent ordering that actually exists on that type, and the general case would just be to memo-ize an int mapping. --John
Re: Unicode in 'NFG' formation ?
Larry Wall larry-at-wall.org |Perl 6| wrote: into *uint16 as long as they don't synthesize codepoints. And we can always resort to *uint32 and *int32 knowing that the Unicode consortium isn't going to use the top bit any time in the foreseeable future. (Unless, of course, they endorse something resembling NFG. :) No, a few million code points in the Unicode standard can produce an arbitrary number of unique grapheme clusters, since you can apply as many modifiers as you like to each different base character. If you allow multiples, the total is unbounded. A small program, which ought to go into the test suite g, can generate 4G distinct grapheme clusters, one at a time. How many implementations will that break? If they want fixed size, 64-bits should do for now. Also, if the spec doesn't list a requirement for a minimum implement ion limit, *any* fixed-size implementation will be incorrect even if untestable as such. --John
Unicode in 'NFG' formation ?
I was going over S02, and found it opens with, By default Perl presents Unicode in NFG formation, where each grapheme counts as one character. I looked up NFG, and found it to be an invention of this group, but didn't find any details when I tried to chase down the links. This opens a whole bunch of questions for me. If you mean that the default for what the individual items in a string are is graphemes, OK, but what does that have to do with parsing source code? Even so, that's not something that would be called a Normalization Form. Character set encodings and stuff is one of my strengths. I'd like to straighten this out, and can certainly straighten out the wording, but first need to know what you meant by that. Can someone catch me up on the particulars? --John
Re: Right place for discussions?
Larry Wall larry-at-wall.org |Perl 6| wrote: On Fri, May 15, 2009 at 07:21:38PM -0500, John M. Dlugosz wrote: Looking at recent traffic, there is more on tickets and checkins, so any actual forum messages are lost among them. Should discussion be separate? Generally discussion of specs should be on perl6-langauge, though of course, having a wider audience there, the s2n ratio tends to be a bit lower. This mailing list is certainly still appropriate for abstract discussions of exactly how a particular feature might be implemented, despite the flood of automated traffic. Larry Hmm., I seem to have gotten my wires crossed. I just re-subscribed to change my email address, and did so by copy/paste the address in the Welcome message I had before. How odd. I'll switch back to -language. I must have been subcribed to both, or a consolidation feed, before. --John
Re: Contextual Variables
Larry Wall larry-at-wall.org |Perl 6| wrote: On Fri, May 15, 2009 at 07:16:45PM -0500, John M. Dlugosz wrote: Reading through S02, I see that contextual variables has changed in the last year. It appears that contextual and global variables have been unified. So, the + twigil is no more? I assume the point is that any supposed global can be overridden in dynamic context, rather than having to know which you planned to and which you didn't. Normal code should use $*x, not $GLOBAL::x or whatever. Is that it, or is there more I need to be filled in on? That's it, you've nailed it in one. Though perhaps we could mention here that part of the motivation is to push context info down the dynamic stack to the point where we minimize shared state between threads. And also, knowing whether a particular context var is rw or not means we know whether we can just make a copy into our current thread with value semantics, or we have to manage a lock around the shared container. Well, that's the hope... Larry Hmm, so being read-only implies it won't change and can be cached locally, as opposed to YOU can't change it along this access path. Don't we have separate readonly and rw variables aliasing the same underlying value now? I think you're confusing const and volatile. --John
Re: Subroutine parameter with trait and default.
PS Incidentally, it seems silly to have is rw but not is ro. I keep writing is ro. The synopses says readonly. But now that it is possible, I nominate changing a hyphen. I'm not opposed to having it be ro, but wonder why he didn't call it that in the first place, so there must be a reason. It should be possible to alias it in your own scope easily. --John
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote: It should be possible to alias it in your own scope easily. Every time someone replies to a Perl 6 language design nit with but you can change the grammar *I* kill a kitten. *meowmmmf* That would not be a change in the grammar. Merely deciding for yourself which names should be short based on your own usage. Since readonly is a class name, the equivalent of a typedef would be used. I think that should be my ::ro ::= readonly; but I have some technical points that still need to be addressed/worked out. --John
Re: Why no is ro? (Re: Subroutine parameter with trait and default.)
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote: John M. Dlugosz wrote: I'm not opposed to having it be ro, but wonder why he didn't call it that in the first place, so there must be a reason. Nobody's perfect? My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable declarations. The verbosity (which a hyphen would only make worse) discourages const-ing, as they say in C. Perhaps he was thinking that 'constant' would be used there. But I agree, it's not the same thing. In C++ I often use const for things that are in 'auto' scope and initialized in the normal flow sequence. Anyway, was 'ro' rejected for some good reason, $Larry, or was it simply considerate as not to waste a short word on a rare use since that's the default (for parameters)? I agree that knowing 'rw', and that being common, if I wanted the other one and didn't use it every day, I would =guess= that it should be called 'ro' to match. --John
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: So again the question: are back refs from the value to the containers required to implement Perl 6? I guess not. If I understand what you are saying, I agree. You can only go from some container to a value, not the opposite direction, and can't tell if the object is held by more than one container.
Re: Should $.foo attributes without is rw be writable from within the class
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
class A
{
has $.foo = A;
has $!bar = A;
method blahh()
{
say $.foo ~ $!foo ~ $!bar;
}
}
class B is A
{
has $.foo = B;
has $!bar = B;
}
my $a = A.new;
my $b = B.new;
say $a.blahh; # prints AAA
say $b.blahh; # prints BAA, right?
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor? And of course the example shows that $!foo in
blahh is not derivation friendly. Or am I getting things wrong and
there can be only one $!foo and $!bar in the namespace of the objects
created from A and B? That is the declarations in B are superfluous
if not outright wrong? Well, or they only affect the generated
constructor and the storage location is shared? The latter would
nicely contrast them to non twigil attributes in the form 'has $foo'.
A::!foo will be distinct from B::!foo. The accessor in B will override
the accessor from A. I would not mind a warning, since the
implementation knows what is going on being auto-generated. But in
general, if you write methods that are accessors, separate from the
backing data, the compiler can't tell what you meant and won't give any
warning.
--John
Re: Should $.foo attributes without is rw be writable from within the class
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: May I pose three more questions? 1. I guess that even using $!A::bar in methods of B is an access violation, right? I.e. A needs to trust B for that to be allowed. Correct. 2. The object has to carry $!A::bar and $!B::bar separately, right? Correct. 3. How are attribute storage locations handled in multiple inheritance? Are all base classes virtual and hence their slots appear only once in the object's storage? The slots are direct in that class. The accessor functions are virtual, though. It is not specified anywhere, nor even discussed that I've found, whether base classes are virtual (merged) in the C++ sense. I have this flagged as an open design question. Since you have roles, perhaps you don't need virtual base classes. I think no snap decision should be made, but the ramifications and use-cases explored in some detail. --John
Re: Should $.foo attributes without is rw be writable from within the class
Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: I have come to understand that this is an available possibility, yes. That doesn't mean I like it. :) My complaint could be pithily summarized as those are _my_, attributes, why can't I write to them? // Carl If the accessor were implemented to do something more interesting than just assign to the private location, then having some code call the accessor and other code access the private location directly with the same syntax would be confusing. For untyped variables, it would be difficult to determine whether something is a method call or an attribute on a type that I'm in the body of. Everything would have to be public methods, with a run-time check on the scope of the caller to see if it were allowed. Having a different syntax for private access simplifies things. I'm wondering if the strange wording concerning has $x; with no twigal is meant to take care of this case. But I don't understand what he meant in the Synopses, though I've asked about it repeatedly on this list and other places, so I largely ignore that case. It says something about making $x available as an alias in the lexical scope. In context of what you are asking, maybe that's what it is for. --John
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Reading the description there I wonder how this is supposed to work.
I don't think S29 is in any shape as a serious design specification.
Maybe you should not design it that way. Maybe the left-hand-side is
as ref so it can change the identity of the object it is called on.
our Str multi method substr (Str $string is ref: StrPos $start, Int
$length)
is rw is export
{
... compute result in a new variable
$string = $result; # ta-da!
... and what am I supposed to return? A Str-like object that is a proxy
to just
the changed substring?
}
As for your other comments in general, I think S29 is NOT in any shape
as a gospel, and going over the (very preliminary) design is a necessary
task.
--John
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: Sorry, I don't understand why you say 'no' and then explain that the resulting new string is stored in the container. The only container that could be affected by this is $string in the example. The way for a method to get access to the container is by declaring a parameter as rw. Note that this brings the discussion back to the point how rw is handled in dispatch and if an anonymous container is autovivified for a naked value. For rw yes, for ref no. Did you mean the 'no' as answer to the question if the identity of the string--i.e. its pointer--is preserved? This would violate the immutability assertion of string values. Is it generally foreseen that an object knows about the containers it is stored in? Yes. But it is not generally the case that this is the same container as the caller is holding. Detailed specifications of the meaning of 'read-only', 'rw', 'copy', and 'ref' and the binding semantics thereof need to address this, and address the concerns of efficient implementations. But off the cuff, I think it is safe to say that 'ref' parameters are guaranteed to have the same container that the caller sees, and 'copy' parameters are guaranteed not to. default (read-only) passing may or may not at the implementation's whim, but you won't change it so it doesn't matter. 'rw' may allow the value to change before binding; 'ref' never permits that. --John
Re: How to define a new value type?
Stéphane Payrard cognominal-at-gmail.com |Perl 6| wrote: I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. For a mutable object, I don't know if that copy should be immediate or deffered by a mechanism of copy on write. Probably that behavior could depend on a trait of the class that implements to be copied object. Not the best illustration, but the only one I have prepared so far: http://www.dlugosz.com/Perl6/web/assignment/assign-1.png This shows $x = $y;. The use of := (binding) would affect the leftmost column. my $z := $y; would have $z's symbol table entry point to the same Item as $y, namely #8CD9. Assignment (=) does not clone or copy the object. In the illustration, note that both Items refer to the same Dog (#A829) after assignment. With reference assignment semantics, if you want a copy or clone, you make one as an explicit step. Hence the existence of methods like deepcopy in the base Object of languages with that feature. The copy-on-write behavior you suggest is what Perl 5 does to make operator overloading appear to have value semantics. But Perl 6 does not describe this mechanism in any way. Instead, value types are immutable so it doesn't matter that the object is not cloned. --John
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: I think that mutating methods of immutable value types just have to modify the identity. The problem is how that relates to references. Take e.g. the Str type my $s = 'abc'; # $s points to 'abc' $s.reverse; where the reverse method returns a new string that somehow has to find its way into $s. That is, the method call sequence has to be different for object types and value types. The start is identical: Don't do that. Changing the identity of the object will mean that other containers pointing to the same copy will change, but other containers pointing to another physical copy (but the same id) will not. Well, or the language is explicit about the capture of the new value. Is this meant with $s.=reverse; # means $s = $s.reverse Yes. Define .reverse to return a new object, and use .= if you want it to go back into the same container. I suppose that seeing .= will make it easy for the compiler to optimize, if the object is not shared it can reuse the structure. --John
Re: How to define a new value type?
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: For an Object to be a value, it means that if you build an object with the same value, it will be seen as the same value that some other object with this value. Perl 6 formalizes this by defining a value type as one whose identity is keyed to its value. Multiple physical copies in memory (or copies without memory like numbers in registers) will test as identity-equvilent. A sane requirement for this to happen is that value objects are read-only, which is something pretty straight-forward. The thing is that, for a value object, there isn't any difference in saying: my $a := 3; or my $a := 3.clone(); Because the number '3' is a value, and you usually doesn't expect a value to change its value at a distance, that's why Int is Immutable. Yes, with immutable objects you don't have to clone it. Multiple copies can be shared. By making value types as described above also immutable, it formally removes all distinction between reference assignment and value assignment.
Offerings - edits pending
This is just a reminder that I have files posted at http://www.dlugosz.com/Perl6/offerings/ waiting for someone in authority to inspect and merge.
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: Taking only the lhs into account doesn't work in Patrick's code because he has untyped variables. The Dog is only on the rhs. This is why I think we need a binary dispatch. I don't see much use for the type of the LHS, though. C++ dispatches assignment on the declared type of the container on the LHS. This hardly makes sense in Perl 6. I agree. I'm in the middle of a deep meditation on this, and will post later ... maybe in a few days, maybe tonight, depending on my muse. --John
Re: How to define a new value type?
Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
So, how does one get an object to pretend to be a value type for
purposes of assignment?
Currently if I do the following
class Dog { ... }
my $a = Dog.new;
my $b = $a;
then $a and $b both refer to the same Dog object. How would I
define Dog such that it acts like a value type -- i.e., so that
$b would be a copy of $a and future changes to the object in $a don't
affect $b.
I have been under the impression that value types are supposed to
define immutable objects, or at least objects that pretend to be
immutable; any operators on them would produce new objects rather than
mutating existing ones. Therefore assignment can actually work the
same way for all types, whether value types or not, by making the LHS
container just hold an additional reference to what the RHS container
holds. Since the value types are effectively immutable, there is no
harm to them not being copied by default, and in fact this would be a
feature, making it simpler to avoid unnecessary work.
If you are wanting to actually mutate a Dog in a user-visible way
rather than deriving another Dog, then I don't think that calling Dog
a value type is appropriate.
I agree. A value type is immutable, where the identity is keyed to
the value. Making a value type that can mutate can cause confusion.
I'm now thinking that the normal = you write should always give
reference assignment semantics. In the case of value types, assuming
they are indeed immutable, it does not matter whether they have value or
reference assignment semantics, since the same value will give the same
identity, regardless of memory (or in-register) representation.
Furthermore, just because you CAN write an infix:= for some types that
give value assignment semantics, you SHOULDN'T do that, any more than
you should write an infix:= to do addition. We want to avoid the Java
et.al. mess, and the ideas behind value types in Perl 6, and the
conceptual separation already present in comparison operators, gives the
natural solution:
You don't have value types a'la Java that behave differently with
respect to assignment. Just like you can TEST for identity or value
equality by your choice of === or 'eqv', you can specify reference
assignment or value assignment (if available) by your choice of
operator. To match the testing operators and existing meaning for '=',
I suggest that '=' ALWAYS be reference assignment and not be overloaded
to do something else, and the word 'assign' (to go with words being used
for value tests: 'eqv', 'before', 'after') be a method that mutates the
object to become 'eqv' the argument. And, if you want to get fancy,
define ← as an infix operator for that meaning.
--John
Re: How to define a new value type?
TSa (Thomas Sandlaß) thomas-at-sandlass.de |Perl 6| wrote: I think a straight forward approach is to overload the assignment operator on the actual types of the lhs and rhs. The dispatch target than clones the value to be stored in the lhs container after being checked against the container's constraint. Regards, TSa. Since infix:= is an operator called on the value of the left-hand-side, the semantics are naturally value semantics, as in C++. It would be difficult to write it otherwise: take the LHS by ref and call STORE on the container.
Re: Iterator semantics
My take on it:
The 'for' loop does bind $_ to alias each item of the list in turn.
But, the list is not synonymous with the variable named @a. However,
the = operator operates on the list itself, not the container,
replacing the elements in the existing Array (or whatever) object. So,
the first iteration through the loop would indeed replace all the
elements in the object being iterated over.
The semantics of the 'for' loop are sequential. It is a
programming-flow construct, not a data-manipulation construct. So
laziness within the list is not an issue. If some elements are
delayed-evaluation, they get overwritten so that evaluation is never done.
The follow-up question is more interesting. The operation of @a,@b
makes a new List object. Just like =after= calling $c=$a+$b it does not
matter if you change $a. Imagine + being lazy with thousand-digit
numbers so it might avoid actually doing it 'till you needed (if ever)
the answer. It would be unacceptable if it appeared to bind to the
original arguments indefinitely.
If the comma concatenation is lazy it needs to be on a deeper level so
it does not seem to depend on the arguments not changing afterwards. It
might, in particular, copy all the primitive components out of @b which
includes range objects and other lazy lists, or arrange a copy-on-write
sharing with @b. I've done this kind of stuff with my C++ classes, so
I'm familiar with the scenario. That is, give the outward appearance of
value semantics but share storage or defer work internally. @a,@b
produces a well-defined value.
So, the first example prints 1 only, and the second prints 1 through 8.
--John
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote:
I think my question can be best understood by example -- what
does the following produce?
my @a = 1,2,3,4,5;
for @a { .say; @a = (); }
My question is whether the change to @a inside the for loop
affects the iterator created at the beginning of the for loop.
In other words, would the above produce 1\n2\n3\n4\n5\n or
1\n ?
My followup question is then:
my @a = 1,2,3,4,5;
my @b = 6,7,8;
for @a,@b { .say; @b = (); }
I have more examples involving various aspects of list and
iterator semantics, but the answers to the above will help guide
my questions.
Pm
Re: Iterator semantics
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Since Larry said that single assignment semantics is the ideal
we should strive for, I would opt for the iterator being unaffected
by the assignment to @a. When this happens the singly assigned
former content of @a is snaphot by the iterator.
That's what my C++ vararray class does with iterators. That way they
don't go stale if you manipulate the array during iteration.
Iterators are independent objects in Perl 6 that can be used in other
ways. I think it vaguly specifies in the synopses that the for loop
will use the default iterator for that List, provided by a member for
that purpose.
You can have different iterator types that work in different ways. You
can create which ever kind you need for the purpose.
The synopses does not specify the details of iterators. But you can
logically deduce that the default iterator needs to provide for rw (not
ref?) binding, since the for loop is documented to do that, if the for
loop uses the default iterator. The meta-law is that things work like
in Perl 5 unless specified otherwise, so the for loop needs to continue
to track the changing contents of the List object.
But I imagine you can create an iterator with various options: snapshot
or tracking, rw, readonly, or ref, and other attributes.
So if you really wanted to depend on those semantics, you could write
something like
my $it = @a.iterator(:snapshot);
while =$it - { body-of-loop }
You could allow adverbs on the 'for' loop to pass through to the call to
iterator(), but that is probably too much syntactic sugar for the value
it gives.
--John
insight into laziness, background processing, etc.
While pondering whether or not the 'map' function is lazy, I had a flash
of insight.
Let's assume that it is, and go with an example of
@results = map { process_item($_) } @files;
Now ponder the questions of how independent are the iterations of the
block. Must it compute each one in order? Can it use multiple threads?
Can it use cooperative coroutines but only run one at a time?
All those issues can be applied to the realization of a lazy list, after
it has been specified, and regardless of what construct was used to
produce the lazy list. We already know 'eager' and 'hyper'.
Without committing to any specifics, let's just suppose that there are
various methods available on a lazy list, for demanding and/or
controlling the realization of the list. You can have as many such
commands as you need, with as many options as you can think of. It is
open-ended and extensible as technology moves on.
So, given @results as a potential work list, I could tell it to
proceed to work on those items in the background, on multiple cores,
with a specified priority. Or, I could tell it to work on one at a
time, but it's OK to block in the middle on IO and work on another one
in the meantime. Or, realize them all NOW and don't return until they
are done, or on the first error. Designing the list of such methods and
their options will be a task, but for now just suppose that such methods
will exist.
The default for a lazy list is to compute each item the first time it is
read. The default for a sequential iterator is to allow it to work
ahead as far as it likes, batching the calls.
But, you can change the settings in some detail, and you can command it
to do work now other than by reading from a single value. 'eager' is
equivalent to reading each value, using the current settings for that
list object.
--John
Re: What happened to err operator?
TSa (Thomas Sandlaß) thomas-at-sandlass.de |Perl 6| wrote:
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
No, I think code in the CATCH could look at its context/callers and
issue a return from the proper one, that is the call to a().
In particular, it can be done using only the conceptual primitives.
Adding an easy way is just library code, not more primitive concepts
that need to be supported.
In particular, I'd like to have an easy way to get that particularly
interesting context (a special word used for the smart match syntax in
the existing context/caller mechanism) and a fail-as-return method on $!
that encapsulates all that, but always works right and efficiently even
in the face of optimization.
--John
