Re: .method == $self.method or $_.method?
At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically.
At some point, adding another thing people have to remember in order to
save one character gets a bit self-defeating, surely.
The good thing about $_.method is that it is familiar, quite compact
anyways by virtue of using $_, and nobody is going to be surprised by it.
Personally (and I'm admittedly leaning towards simplicity lately) I'd
even throw a warning for using .method when there is an explicitly named
invocant as well.
# Good
sub foo {
.bar;
}
# Possibly confusing, throw a warning or forbid under strict?
sub foo ($self:) {
.bar;
}
# More obvious
sub foo ($self:) {
$self.bar;
}
of course, since it is still preferable to be symmetrical, if $.attr is
legal (and no warning) with a named invocant, then so should .method be.
Adam K
Re: Perl 6 Summary for 2005-03-07 through 2005-03-22
[EMAIL PROTECTED] wrote: pugs too lazy Miroslav Silovic noticed that closing a file handle in pugs did not force all the thunks associated with the file. While this was a bug in pugs, it led to conversation about whether = should be lazy or eager. Larry thinks that it will be safer to start eager and become lazy then vice versa. http://xrl.us/fijd Accused of the original burst of insight, pleading not guilty! ;) The original post was to perl6-compiler by Andrew Savige. http://groups-beta.google.com/group/perl.perl6.compiler/browse_frm/thread/2aca524a1203cd41/912bea4d0d05554a?q=surprised#912bea4d0d05554a Miro
Re: New S29 draft up
On Mon, 21 Mar 2005 08:41:27 -0800, Larry Wall wrote:
Okay, I've come around to liking it, but I think we have to say that
0x, 0d, 0o, 0b, and whatever else we come up with are just setting
the default radix. If a string comes in with an explicit 0x, 0d, 0o,
or 0b, we believe that in preference to the operator.
Don't we trust the programmer more than the data? I want this code to
produce 4660, 22136, 2832, 3394; not 4660, 22136, 4, 42.
for '1234','5678','0b10','0d42' {
say 0x $_;
}
--
Peter Haworth [EMAIL PROTECTED]
It's not a can of worms, it's a tank of shai-hulud.
-- Jarkko Hietaniemi
Currying positionals
Hola... I've spend some time these last few days slowly getting
currying to work in pugs.
LS06/Currying states: takes a series of named arguments
The way binding is implemented in pugs does not seem to require
limiting that usage case. We have 2 functions, that operate on a
subroutine (which knows it's params):
bind some params
finalize bindings
bind some params will return a derived subroutine, with some params
prebound. assuming does just this.
finalize bindings will bind defaults to optionals, and check that we
have enough invocants and requireds bound, and return a derived
subroutine, with all params bound.
This is passed to the code that applies the sub.
The algorithmic approach to binding some params:
bind invocants
bind named parameters, and keep leftover pairs for %_
treat nonpairs as positionals, and bind them sequentially. Left
over nonpairs get put in @_
if we have slurpy params, they act as %_ and @_.
package a sub with the bindings, and the unbound params, and
return it.
and, well... that's it.
This has some funny properties, like:
foo ($x) { ... }
foo(x = 1, x = 2); # yields $x = 1, %_x = 2
foo(1, x = 2); # $x = 2, @_[0] = 1
(foo.assuming(1))(x = 2); # $x = 1, %_x = 1
Are these bugs? I could live with them, but they are a bit
perl5-ish.
I think we need a little more guidance, as the exact semantics of
currying are not that well defined.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgpE3lXT1h65V.pgp
Description: PGP signature
Re: New S29 draft up
On Wed, Mar 23, 2005 at 03:28:31PM +, Peter Haworth wrote:
: On Mon, 21 Mar 2005 08:41:27 -0800, Larry Wall wrote:
: Okay, I've come around to liking it, but I think we have to say that
: 0x, 0d, 0o, 0b, and whatever else we come up with are just setting
: the default radix. If a string comes in with an explicit 0x, 0d, 0o,
: or 0b, we believe that in preference to the operator.
:
: Don't we trust the programmer more than the data? I want this code to
: produce 4660, 22136, 2832, 3394; not 4660, 22136, 4, 42.
:
: for '1234','5678','0b10','0d42' {
: say 0x $_;
: }
Er, yes. Sorry--I forgot b and d were valid hex, sigh. Fortunately,
my extended brain caught it. :-)
But maybe that means that the 0b and 0d notations are bad, and we
shouldn't be trying to generalize the 0x pattern that way. We could
keep 0x for old times sake, but generalize it some other way. With all
the use we've made of my colon, we haven't actually used up :digit
yet, so we could go with
:16feedfaceddeadbeef
:84711
:21000_
:101_000_000
:120123456789te
Interestingly, that gives us a :16($x) operator for free.
Since the notation encompasses slices, it also gives us a method
of distinguishing exponents from mantissas for notations where e
is ambiguous:
:16feedfaceddeadbeef 8
About the only thing it doesn't give us is
:$radix$input
I suppose we could make Pairs interpret their right arg in numeric
context to let
$radix = $input
do the general thing, but that's getting a little out there.
Still, what other numeric interpretation might you want to give to a
pair object? The main problem with commandeering pair notation for
that is simply that it's not obvious, and for such a rare operation
you should use something huffmanly obvious. So we should probably
have a generalized radix_to_dec($radix,$input) function out there
somewhere instead.
But for literals and input values with a fixed radix, I kinda like
the : notation.
Larry
Re: Precedence of where (of, is, will)?
Larry Wall wrote:
my @array of Int;
is really short for
my @array is Array of Int;
How does 'is' relate to 'does'? I mean is the above @array
ready for operation? Whilst
my @array does Array of Int;
still needs a compatible object to be put into @array?
Like so:
class Blubber does Array of Int {...}
@array = Blubber.new; # or with := ?
BTW, does
my Int $value;
expand to
my $value is Ref of Int;
or the often mentioned
my $value is Scalar of Int;
and what is the difference between the two, if any?
What exactly does the 'is shape' syntax expand to?
I guess it is some parser gymnastics that somehow
puts more aguments into the Array class closure.
Which brings me to the question: how does this parameter
list look like?.
class Array[ ::ContentType, List of List $shape ] {...}
And yet another one: when is the resulting expansion of
such a class template or whatever it is performed? Or does
the implementor of the class have to revert to blessing in
the constructor? Wouldn't this prevent static type checking
unless the compiler would call the constructor in some
hypotheticality mode to produce type information.
Regards,
--
TSa (Thomas Sandlaß)
Re: New S29 draft up
On Wed, 2005-03-23 at 12:58, Larry Wall wrote: :21000_ :101_000_000 Two things: 1. Just a note that Pugs doesn't yet do _ in numbers, but should 2. I'd really like to see a warning on non-standard _ breaks, e.g; 1_00_000 should issue a warning. Interestingly, that gives us a :16($x) operator for free. Is that a function? E.g. is this valid? $x += :16($y) ? About the only thing it doesn't give us is :$radix$input $input.radix($radix) ? I'd suggest that this be a universal virtual method that strings get a definition for. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Currying positionals
On Wed, Mar 23, 2005 at 17:43:52 +0200, Yuval Kogman wrote: Hola... I've spend some time these last few days slowly getting currying to work in pugs. It should also be mentioned that I made magical $?SUB et al unbind the sub. In a curried sub, should that happen? It looks more consistent for me, because a sub shouldn't know it's curried, but you never know in p6 ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpPofLsZmRD0.pgp Description: PGP signature
Re: New S29 draft up
Larry Wall wrote:
So we should probably
have a generalized radix_to_dec($radix,$input) function out there
somewhere instead.
Why not shift it onto the type system:
my Int $i = $input as Str[$radix] as Int;
A bit lengthy but quite clear.
And easy to extend e.g. to roman numerals:
say VII as Str[Roman] as Int; # prints 7
Of course then we need
class Str[ uint $radix where { $radix 1 } ]
{...}
class Str[ ::T does StringNumification ]
{...}
But for literals and input values with a fixed radix, I kinda like
the : notation.
Yes, it's cool and very general!
--
TSa (Thomas Sandlaß)
Re: Questions regarding s/// and subst?
On Wed, Mar 23, 2005 at 11:14:16AM -0500, Stevan Little wrote:
: Is subst an object/type?
: Or is it a method of the Str object?
I suspect it's just a method, and the ~~ binding of s/// is merely
syntactic sugar for the method call.
: If it is an object ...
:
: Does s/// produce a subst object?
: Does a subst object .hasa rule object(s)?
: If so can we extract those rule object(s) from it?
: What exactly does a subst object do?
: How does a subst object stringify?
: Etc. etc. etc.
I think if you want to objectify a subst, you have to put it in a closure.
: If it is a method ...
:
: How would a method on the right hand side of ~~ work exactly?
: Is
: ~~ s:perl5:g/a/b/
: the same as
: ~~ .subst(rx:perl5/a/, b)
: or
: ~~ .subst(rx:perl5/a/, {b})
This is very much bound up in the meaning of .foo in various contexts,
which we haven't actually nailed down yet. For the moment I would
recommend writing all code with explicit $self.foo or $_.foo until
we figure that out. I rather suspect that .foo is going to end up
always meaning the current invocant rather than current topic.
It's also vaguely possible certain kinds of {...} constructs could
be construed as methods rather than subs so that $_ ends up being
the invocant in that scope. There are problems with that, though.
The solution might turn out to be unary ~~ instead, where ~~subst()
binds the current topic to subst in some kind of topically appropriate
fashion which may or may not involve the first argument depending on
the declaration of subst, which might or might not degenerate to a
method call of the form $_.subst() if there's no other obvious binding
to $_.
[Followups to p6l.]
Please be a little patient--I'm still dripping this whole mess through
my Pooh filter, which clogs easily.
Larry
Re: New S29 draft up
On Wed, Mar 23, 2005 at 07:33:43PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: So we should probably
: have a generalized radix_to_dec($radix,$input) function out there
: somewhere instead.
:
: Why not shift it onto the type system:
:
: my Int $i = $input as Str[$radix] as Int;
:
: A bit lengthy but quite clear.
: And easy to extend e.g. to roman numerals:
:
: say VII as Str[Roman] as Int; # prints 7
I'm not sure most people want to think that way. In fact, I'm slightly
sure most people don't.
: Of course then we need
:
: class Str[ uint $radix where { $radix 1 } ]
: {...}
: class Str[ ::T does StringNumification ]
: {...}
And then, based only on what you've written there, we need to teach
people all about classes, parameterized types, representational types,
constraints, formal type parameters, and roles before they can begin
to write the radix_to_dec() function they actually wanted...
Larry
Re: Currying positionals
On Wed, Mar 23, 2005 at 05:43:52PM +0200, Yuval Kogman wrote:
: The algorithmic approach to binding some params:
:
: bind invocants
:
: bind named parameters, and keep leftover pairs for %_
:
: treat nonpairs as positionals, and bind them sequentially. Left
: over nonpairs get put in @_
This seems a little backwards--I think all positionals should be bound
before you start binding named pairs, if currying is to be consistent with
ordinary binding. Otherwise you can't catch binding explicitly to
a positional Pair argument. I also think doing it the other way leads
to weird situations where the first two positional arguments can
bind to, say, the first and third formal parameters, which is a situation
I'm trying to avoid. I'd like the transition from positional to named
processing to be irrevocable, at least in the case of ordinary binding.
But it's possible that .assuming() should be allowed to violate this,
if we let it do positionals at all. It would be a convenience to
allow positionals, but for a known function, you can get the same
behavior with named arguments.
: if we have slurpy params, they act as %_ and @_.
:
: package a sub with the bindings, and the unbound params, and
: return it.
: and, well... that's it.
:
: This has some funny properties, like:
:
: foo ($x) { ... }
:
: foo(x = 1, x = 2); # yields $x = 1, %_x = 2
I think that should probably be an error for a sub because it doesn't
have a signature that enables %_.
: foo(1, x = 2); # $x = 2, @_[0] = 1
There's where your scheme comes out backwards to me. I think it should
absolutely bind the 1 to $x, and then the x turns out to be extra, an
error in the case of a sub, and put into %_ in the case of a method.
But we can't have the situation of a positional argument being bound
to anything but the next positional parameter.
: (foo.assuming(1))(x = 2); # $x = 1, %_x = 1
Would also be illegal for a sub, and put x=2 into %_ for methods.
: Are these bugs? I could live with them, but they are a bit
: perl5-ish.
:
: I think we need a little more guidance, as the exact semantics of
: currying are not that well defined.
Another thing to think about is whether you allow application of
.assuming to a generic multimethod before it is dispatched. It would
be nice to be able to do that, and I can see that if multis don't
name their first parameters consistently, currying on position would
allow a dispatch that named currying wouldn't be able to express.
But more than anything I want to be able to curry a module or class.
And that's probably almost exclusively a named-argument thing,
unless you just happen to define every sub in your module to have a
consistent first argument type. But maybe, as with partial binding,
it's just sort of a partial dispatch, so say, if you curry a class with
an object as the first argument, it would curry the instance methods
but not the class methods. This seems pretty dwimmy to a human being.
(Or it could curry the class methods too if an object is allowed to
play the role of its class.)
Larry
Re: New S29 draft up
HaloO Larry,
you wrote:
: class Str[ ::T does StringNumification ]
: {...}
And then, based only on what you've written there, we need to teach
people all about classes, parameterized types, representational types,
constraints, formal type parameters, and roles before they can begin
to write the radix_to_dec() function they actually wanted...
Sorry for that. I think in the end it boils down to specifying
what role StringNumification does. I didn't manage to think of
a better name. It basically contains unary + which is at
the very heart of Perl 6, isn't it? I hope explaining roles is not
much harder than explaining tied variables.
Regards,
--
TSa (Thomas Sandlaß)
Re: Currying positionals
On Wed, Mar 23, 2005 at 11:53:06 -0800, Larry Wall wrote: On Wed, Mar 23, 2005 at 05:43:52PM +0200, Yuval Kogman wrote: : The algorithmic approach to binding some params: : : bind invocants : : bind named parameters, and keep leftover pairs for %_ : : treat nonpairs as positionals, and bind them sequentially. Left : over nonpairs get put in @_ This seems a little backwards--I think all positionals should be bound before you start binding named pairs, if currying is to be consistent with ordinary binding. Currying and ordinary binding are implemented in the same function... =P Otherwise you can't catch binding explicitly to a positional Pair argument. soo... how would you diambiguate that in the general case? Can I pass a named for an optional? or is that always a positionally bound pair? I'm reading through S06 a bit more in detail, and I see Arguments destined for positional parameters must come before those bound to named parameters. Do pairs get slurped until there are no more required positionals to fill in? In that case, how do you actually assign by name? Can you mix positional and named params? Going down further, I see: sub formalize($text, +$case, +$justify) This can we name text = foo? or will $text actually contain that pair, as bound positionally? I also think doing it the other way leads to weird situations where the first two positional arguments can bind to, say, the first and third formal parameters, which is a situation I'm trying to avoid. Yeah, that's why I raised this stuff here. Once I managed to actually read Autrijus's code (not his fault!) I got thinking, and wasn't sure the way it was done is the good way, since it seemed to work, but was not really strechable to corner cases. But it's possible that .assuming() should be allowed to violate this, if we let it do positionals at all. It would be a convenience to allow positionals, but for a known function, you can get the same behavior with named arguments. Since we have .arity, why don't we make this a little more introspectable too? : foo(x = 1, x = 2); # yields $x = 1, %_x = 2 I think that should probably be an error for a sub because it doesn't have a signature that enables %_. And if it had a slurpy hash? : foo(1, x = 2); # $x = 2, @_[0] = 1 There's where your scheme comes out backwards to me. I think it should absolutely bind the 1 to $x, and then the x turns out to be extra, an error in the case of a sub, and put into %_ in the case of a method. But we can't have the situation of a positional argument being bound to anything but the next positional parameter. So again, how do we unambiguously tell apart a positional from a named, when it's a pair? What's not yet bound? where we are in the binding? I think some concrete examples would be very good for me. : (foo.assuming(1))(x = 2); # $x = 1, %_x = 1 Would also be illegal for a sub, and put x=2 into %_ for methods. Ok. that's the consistency i want to attain. By that I mean: foo( ) is the same as (foo.assuming .).(...) .. .. (foo.assuming(.).assuming(.).assuming(.)).(.) etc, given any syntax in '.' that stays the same. But more than anything I want to be able to curry a module or class. And that's probably almost exclusively a named-argument thing, unless you just happen to define every sub in your module to have a consistent first argument type. But maybe, as with partial binding, it's just sort of a partial dispatch, so say, if you curry a class with an object as the first argument, it would curry the instance methods but not the class methods. This seems pretty dwimmy to a human being. (Or it could curry the class methods too if an object is allowed to play the role of its class.) I sort of agree with that, but i'm not sure... what if a named param is missing? is it slurped? if we go that far, perhaps positionals are the same? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgpdT5mwSdamj.pgp Description: PGP signature
Re: Currying positionals
More! can you have several slurpy params, of the same type, which are assigned contiguous sequences of the thing they can slurp? foo([EMAIL PROTECTED], *%a, [EMAIL PROTECTED]) foo(1, 2, 3, a = b, c = d, 4, 5, 6); for me that makes sense for slurpy blocks, but not anything else -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpPp0zr5P5Yv.pgp Description: PGP signature
