Re: Second use of flattening
Andrew Rodland skribis 2005-04-04 22:34 (-0400): Likewise, slurping is probably best explained as collecting. I like this. I'd be tempted to suggest scatter / gather, but that's Gather is taken. probably a bit opaque to the average reader. How about describing them as expand / collect for a matched pair? That's got a legacy in math, and some mathematically-oriented languages. It having meaning in maths is probably more a reason not to use, unless the meaning is identical enough. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Second use of flattening
On Mon, Apr 04, 2005 at 10:34:13PM -0400, Andrew Rodland wrote: : On Monday 04 April 2005 06:34 pm, Juerd wrote: : Terrence Brannon skribis 2005-04-04 18:45 (+): : So, to avoid confusion with the common understanding of flattening in : Perl, perhaps it should be called spreading or distributing. : : I agree. : : Likewise, slurping is probably best explained as collecting. : : I like this. I'd be tempted to suggest scatter / gather, but that's : probably a bit opaque to the average reader. How about describing them as : expand / collect for a matched pair? That's got a legacy in math, and : some mathematically-oriented languages. We chose slurp for several good reasons, including the fact that it isn't currently overloaded N ways from Sunday, and it has a decent adjectival form that you can talk about parameters with. And if you're going to make up a new technical term, it doesn't really need to have any legacy at all, as long as the metaphor works, and the Huffman coding is right. In fact, sometimes we intentionally go against existing legacy, like when we named roles. Sometimes we go with the legacy, such as with flatten. I don't want to discourage people from brainstorming about the terminology, but you have to recognize that the design team has been banging its collective head against these issues for years now. Damian in particular is a stickler for good terminology. So you *might* offhandedly come up with something better than we've thought of already, but please realize it's a long shot. Most of these words were rather firmly lodged into their metastable states even before the Apocalypses came out--let alone the Exegeses and Synopses--so you'll have to whack 'em pretty hard to knock any of 'em loose. Larry
Re: Pugs Bug
(Replying to p6l instead of p6c as requested.) On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: (Now that builtins are just functions out in * space, we can probably afford to throw a few more convenience functions out there for common operations like word splitting and whitespace trimming. (Specific proposals to p6l please.)) Shouldn't these be just methods? Larry -- wolverian signature.asc Description: Digital signature
Re: Pugs Bug
Shouldn't these be just methods? I guess not. This is Perl and OO is not mandatory, or even desirable all the time. Adriano.
Re: [S29] pick on other things than junctions
Hi,
Trey Harris wrote:
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)
I'd assume in all cases that pick returns an *alias*, and in the case
of hashes, an alias to the pair:
# Add entropy to your hash
for 1..$entropy_thresshold {
%hash.pick.value *= rand $scribble_factor;
}
I like that, too. So:
my @array = a b c d;
my $elem = @array.pick;
$elem = z; # $elem now z, @array unchanged
my @array = a b c d;
my $elem := @array.pick;
$elem = z; # $elem now z, @array changed
# (any(@array) eq z now true)
Same for hashes:
my %hash = (a = 1, b = 2);
my $pair = %hash.pick;
$pair = ...; # %hash unchanged
my %hash = (a = 1, b = 2),
my $pair := %hash.pick;
$pair = ...; # %hash changed
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon!|
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Larry Wall wrote:
Roles cannot be derived from, so they're always final in that sense.
We should probably consider them closed by default as well, or at least
closed after first use. If a role specifies implementation, it's always
default implementation, so overriding implementation always occurs in a class
instead.
Ohh, is the following illegal?
role Blahh does Blubber {...}
Or is that just not considered derivation but, hmm, specialisation, subtyping
subroleing or some such?
So, does the above produce the subtyping relation Blahh : Blubber?
--
TSa (Thomas Sandla)
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
HaloO Larry, you wrote: On Thu, Mar 31, 2005 at 06:35:06PM +0200, Thomas Sandlaß wrote: : Is typing optional in the sense that it is no syntax error but : otherwise ignored? To me this is pain but no gain :( Well, you guys keep ignoring the answer. Let me put it a bit more mathematically. The information in my X $a; is *necessary* but not *sufficient* to do method existence testing in standard Perl 6 at compile time. You can do it IFF you have the class information AND the classes are willing to cooperate in your scheme. In the current design, you can pragmatically request that all classes cooperate, and you will get the cooperation of all classes that haven't specifically been requested to be non-cooperative. This is what all the mumbo-jumbo about open/closed and final/non-final classes comes down to. That is clear, especially the part where you talk about necessary and sufficient. Please consider myself a disciple from now on :) Actually I'm not obsessed with the compile time checking but with the semantics. Which to me means that with the above declaration a method must come from *this X or its supertypes* in the scope of the declaration. To illustrate consider the following 4 cases: | state when $a.m() | declaration | is attempted | semantics +---+ 1) my $a; | $a doesn't m()| ignored or undef or exception 2) my $a; | $a does m() | call $a.m() 3) my X $a; | X doesn't m() | type error 4) my X $a; | X does m()| call most specific Xish $a.m() The semantics of case 1) will be augmented by pragma I guess. The above becomes more interesting if considering MMD. Then it must be ensured that there is exactly one unique, most specialized implementation available for handling type X. Note that this is a stronger constraint than that the dispatch would succed for the value of $a in question---and not achievable with a Manhattan metric. And one more: when the runtime system doesn't manage to find a matching X it could call into the compiler, class composer, type engine or however this subsystem is called and try to make an appropriate type and a class implementing it! And *that* is what I consider a dynamic language---or meta language on the Parrot level. Regards, -- TSa (Thomas Sandlaß)
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Tue, Apr 05, 2005 at 04:00:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: Roles cannot be derived from, so they're always final in that sense.
: We should probably consider them closed by default as well, or at least
: closed after first use. If a role specifies implementation, it's always
: default implementation, so overriding implementation always occurs in a
: class
: instead.
:
: Ohh, is the following illegal?
:
: role Blahh does Blubber {...}
:
: Or is that just not considered derivation but, hmm, specialisation,
: subtyping
: subroleing or some such?
It does composition.
: So, does the above produce the subtyping relation Blahh : Blubber?
It means that both .does(Blahh) and .does(Blubber) return true.
It implies that Blahh contains the Blubber interface, but does not
imply that it has the same default implementation. (It can, in fact,
advertise that it does Blubber but mangle the Blubber interface
completely if it chooses to, but that might be considered antisocial.
So the compiler might feel free to issue various warnings in that case.)
I, er, kinda fibbed above when I said that overriding implementation
only occurs in a class. What I really meant was that, once you've
declared a role, it's closed, and you can warp its meaning only via
composition into some other role or class. In isolation, a role
isn't really about subtyping--it's just a form of generic code.
But that same purity is what makes it useful for specifying subtype
relationships elsewhere. And once roles start composing other roles,
it can be construed as a form of subtyping.
So, basically, yes.
Larry
Re: [S29] pick on other things than junctions
On Tue, Apr 05, 2005 at 02:38:05PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Trey Harris wrote:
: In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
: What does pick return on hashes? Does it return a random value or a
: random pair? (I suppose returning a pair is more useful.)
:
: I'd assume in all cases that pick returns an *alias*, and in the case
: of hashes, an alias to the pair:
:
:# Add entropy to your hash
:for 1..$entropy_thresshold {
:%hash.pick.value *= rand $scribble_factor;
:}
:
: I like that, too. So:
: my @array = a b c d;
: my $elem = @array.pick;
: $elem = z; # $elem now z, @array unchanged
:
: my @array = a b c d;
: my $elem := @array.pick;
: $elem = z; # $elem now z, @array changed
:# (any(@array) eq z now true)
But what should we call pick without replacment? .peck?
Unfortunately @array.=pick isn't what you want. It would reduce the
array to one element. On the other hand, if .pick takes an argument
saying how many to pick, then maybe
@array.=pick([EMAIL PROTECTED])
gives you a random shuffle. Unfortunately,
@array.=pick(@array - 1)
won't tell you which one it left out.
: Same for hashes:
: my %hash = (a = 1, b = 2);
: my $pair = %hash.pick;
: $pair = ...; # %hash unchanged
:
: my %hash = (a = 1, b = 2),
: my $pair := %hash.pick;
: $pair = ...; # %hash changed
I'm not sure that works. We don't quite have pairs as first class
containers. Binding would try to use a pair as a named argument, and
would fail unless the key happened to be 'pair', which it isn't in this
case. However, if you were to say,
my Pair $pair := %hash.pick;
then it has a better chance of working, presuming someone has the gumption
to write .pick on hashes, which doesn't look entirely trivial to do right.
Larry
Re: Pugs Bug
On Tue, Apr 05, 2005 at 09:36:18AM +0300, wolverian wrote: : (Replying to p6l instead of p6c as requested.) : : On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: : (Now that builtins are just functions out in * space, we can probably : afford to throw a few more convenience functions out there for common : operations like word splitting and whitespace trimming. (Specific : proposals to p6l please.)) : : Shouldn't these be just methods? Depends on whether part of the convenience consists of coercing the argument to a string in the first place. In all likelihood these would be multimethods with a single definition, so that if you did add other definitions of words() or trim(), it would use MMD to try to figure out which way you probably wanted it coerced. Plus you really don't want to clutter the Str type with every little thing you might want to do with a string. foo.open() will probably work, but only because it doesn't find a Str.open and fails over to MMD dispatch, which ends up finding a filehandle constructor. But suppose words() were a singular multimethod. If you said words(@array) it would call wordsStr, which would (I hope, since arrays know about string context) coerce @array to a string with ' ' between the elements, and then split that string into words. But some people might prefer that to fail, and force people to use words([EMAIL PROTECTED]) words(@array) Maybe there's a pragma that lets you control how much coercion happens. Larry
Re: Pugs Bug
On Tue, Apr 05, 2005 at 09:21:41AM -0700, Larry Wall wrote: Plus you really don't want to clutter the Str type with every little thing you might want to do with a string. foo.open() will probably work, but only because it doesn't find a Str.open and fails over to MMD dispatch, which ends up finding a filehandle constructor. foo.open is just weird. Here I would definitely want at least a warning, if just for my sanity. words(@array) On the other hand, @array.words seems just as natural as $string.words to me. I'm not sure how to reconcile this. Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence. Maybe there's a pragma that lets you control how much coercion happens. use coercion :oppressively; # They're adverbs, after all! Larry -- wolverian signature.asc Description: Digital signature
Re: identity tests and comparing two references
Juerd wrote: Thomas Sandlaß skribis 2005-04-04 18:50 (+0200): In particular what does infix=Scalar of Ref of Ref of Int,Int do? Depends. What does it mean? :) Specifically, what is infix, what is =? Ups, a missing : warps this to a completly different meaning! Comparing a coderef infix with the comparison operator = to the word list 'Scalar of Ref of Ref of Int,Int'. I tried to ask what infix:=Scalar of Ref of Ref of Int,Int does. This is the assignment infix operator = for 'Scalar of Ref of Ref of Int' on the lhs and Int on the rhs. BTW, does the parser have a change to detect this typo? About the rest of the mail I'll try to rant tomorrow. -- TSa (Thomas Sandlaß)
Re: Pugs Bug
wolverian skribis 2005-04-05 19:31 (+0300): Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence. Yes, . is supertight. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [S29] pick on other things than junctions
Hi,
Larry Wall wrote:
: Same for hashes:
[...]
: my %hash = (a = 1, b = 2),
: my $pair := %hash.pick;
: $pair = ...; # %hash changed
I'm not sure that works. We don't quite have pairs as first class
containers. Binding would try to use a pair as a named argument, and
would fail unless the key happened to be 'pair', which it isn't in
this case.
Oh yes, of course. Others may be interested in
http://groups.google.com/groups?threadm=x7wtsvo0fs.fsf%40mail.sysarch.com.
then it has a better chance of working, presuming someone has the
gumption to write .pick on hashes, which doesn't look entirely trivial
to do right.
thinking out loudI'm sure I overlooked something, but the following
seems to be correct and is not *that* difficult :):
class Hash;
...;
method pick() is rw {
# First pick a random key.
my $key = .keys.pick;
# Then return an appropriate Proxy object:
return new Proxy:
FETCH = {
Ok. While typing the C{ here, I realized you were correct :)
It'd be reasonable simple if there was a .get_pair_by_key method
(which'd do appropriate binding and'd be Cis rw):
method pick() is rw {
my $key = .keys.pick;
my $pair := .get_pair_by_key($key);
return $pair;
}
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
Re: Pugs Bug
On Tue, Apr 05, 2005 at 07:31:40PM +0300, wolverian wrote: : Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence. That depends on whether you mean ([EMAIL PROTECTED]).words or ~(@array.words) It happens to mean the latter. A . binds tighter than a symbolic unary. In fact, it binds tigher than anything that is not a term, so that, to the first approximation, a string of things separated by . can always be thought of as a sort of term with respect to any other operators. Standard Perl 6 will never define any precedence levels between . and term. Larry
Re: identity tests and comparing two references
On Tue, Apr 05, 2005 at 06:38:43PM +0200, Thomas Sandlaß wrote: : Ups, a missing : warps this to a completly different meaning! : Comparing a coderef infix with the comparison operator = : to the word list 'Scalar of Ref of Ref of Int,Int'. : : I tried to ask what infix:=Scalar of Ref of Ref of Int,Int : does. This is the assignment infix operator = for 'Scalar of Ref : of Ref of Int' on the lhs and Int on the rhs. : : BTW, does the parser have a change to detect this typo? Yes. It should complain that = is not a valid type signature. Any foo (or foo:...) followed by ... should be parsed as a single term selecting the function that MMD would dispatch to given that type signature. Larry
Perl 6 Summary for 2005-03-22 through 2005-04-05
Perl 6 Language ceil and floor Ingo Blechschmidt wondered if ceil and floor would be in the core. Warnock applies... Although Unicode operators would let me define circumfix \lfloor \rfloor (although I only know how to make those symbols in tex...). Hmmm... using tex to right Perl 6 code... interesting idea... at least then I could figure out how to make all the special symbols. Maybe someone should make a package for that. http://xrl.us/foe7 s/// object? Stevan Little wanted to know if s/// could return some sort of magic object that could be poked or prodded. Larry explain, no. http://xrl.us/foe8 markup like features Michele Dondi asked if perl 6 would have markup like features in it. Luke Palmer asked for a more full explanation of what was meant. Warnock applies. http://xrl.us/foe9 the many moods of does Thomas Sandlaß wondered if S14 would actually be written or if tie/bless were eaten by does, enumerating the many powers of does. Larry explained that does will probably have mutated bless and then explained the contexts under which does does each of its powers. http://xrl.us/fofa the many moods of does To follow up his question about does, Thomas Sandlaß wondered about is (specifically whether it stubbed or initialized its variable). Larry explained that is would probably initiliaze its variable and explained how one could use is Ref to stub but not initiliaze something. http://xrl.us/fofb perl5 - perl6 converter Adam Kennedy dropped a line to the list about PPI 0.903, which could form a good base for a Perl 5 to Perl 6 convert. Larry explained that he was actually using PPD (the actual Perl parser) to construct such a tool. He also explained his approach on how he was going to do it. Actually it is a really cool approach for those of you who like elegant design approaches, you should check it out. I'll give you a hint, it starts by writing a glorified version of cat. http://xrl.us/fofc p5 library compatibility? Andrew Savige wondered if p6 would maintain the interface for most p5 libraries. chromatic almost died of fright from the suggestion. Juerd suggested a deprecated namespace for such things. Larry gave him a ponie instead. Later Larry thought that perhaps a special namespace for those libraries that could be automatically converted might be appropriate. http://xrl.us/fofd http://xrl.us/foff -- later importing constants and header files Song10 wondered if there was an easy way to import constants from a module and not have to specify their full scope in the includers file. Larry explained that p6 would have policy modules which would allow this. He then began to let his mind explore the possibility of allowing these modules to return a string to evaluate in the user's scope. Then he realized how nasty textual inclusion was in C and C++, and figured that a hygenic policy would be better. http://xrl.us/fofg giving lists more operators Juerd constructed a table of string, integer, and list operators. He noticed that list had blank spots where string and integer both had things. He then suggested quite a few more operators to fill these blanks... This morphed into a discussion of code complexity and reading code. http://xrl.us/fofh -- operators http://xrl.us/fofi -- complexity string pain Chip wondered what exactly set str apart from Str and the impact this had on Unicode support. Larry and Rod Adams explained that str specified a raw bytes view of strings and required explicit casts between different Unicode levels. http://xrl.us/fofj xx on CodeRefs Luke Palmer wondered if the xx operator could be overloaded to repeatedly run a coderef and slap the results together. Other liked it, but no word from on high. http://xrl.us/fofk running pugs Adam Preble had some strange problems with Pugs's make install target. Warnock applies. http://xrl.us/fofm maniplulation many dimensional hashes Zhuang Li wanted to know how to manipulated hashes of unkown dimension. Luke Palmer provided the answer. http://xrl.us/fofn Semantics of Currying Yuval Kogman has been implementing currying in PUGS. As such, he has found some of the corner cases that have not been well specified. Thus he, Larry, Luke Palmer, and Thomas Sandlaß delve into these mysteries. http://xrl.us/fofo multi paradigmatic perl 6 Someone named Eddie posted a fairly long message to p6l on the google groups interface suggesting that Perl 6 support delegation and other programming paradigms. Sadly, no one told him that it already does both of those things, because nobody got his email. Google groups does not send messages back to the list. http://xrl.us/fofp
