Re: S08 Draft questions (Captures and Signatures)
I can't comment on most of your questions, but the few that I can answer
are inline below...
Jon Lang wrote:
Yes, I know that there is no S08. I'm working on writing one,
++
* What types are you allowed to assign to an invocant?
Whatever the type constraint says. When you write
class Foo { method bar ($x, $y) }, then bar's signature gets an invocant
of type Foo implicitly. If you write ... method bar (A $s:, $x, $y),
then the type constraint is A.
* Are placeholder parameters ever considered to be part of a
function's longname? (I'm expecting that they aren't: if you want a
longname, you ought to specify it in a formal signature.)
I expect they are; to me placeholder variables are just a different way
to write a signature, spread out all over the block.
08:41 @moritz_ rakudo: say {$^a + $^b}.arity
08:41 p6eval rakudo 78cb4c: OUTPUT«2»
So they already count towards the arity (which makes sense, otherwise
map, reduce etc. couldn't work with it); why should they be omitted from
the longname then?
* does the use of placeholder parameters interfere with the use of the
slurpy parameters normally provided by the default signature (i.e.,
*...@_ and *%_)? I'm guessing not.
As far as I understand, you can only use placeholder parameters on a sub
or a block with no explicit signature. When you use them, you give them
a signature. *...@_ and *%_ are not part of that signature. (so yes, the
interfere).
Cheers,
Moritz
Re: S08 Draft questions (Captures and Signatures)
Jon Lang wrote: Invocants: * Is it illegal to specify an invocant in a sub, or is it merely nonsensical? That is, should the compiler complain, or should it silently treat the invocant as the first positional parameter? (The latter has the advantage that you don't have to worry about what the signature is being used for; it has the disadvantage of being, well, nonsensical: invocants are meaningless without the context of a method - and /maybe/ a role - to provide them meaning.) I'd think it was an error at compile time. We can easily detect it. * Likewise, if I interpolate a signature with an invocant into another signature (somewhere other than at the start), is this an error, or will the invocant be silently converted into an ordinary positional parameter? I think if the condition from above would check we are being used to define a signature for a method, that would make this case an error too. I can't immediately think of a use case for making an exception for a signature written elsewhere having one, but somebody else maybe can. * What types are you allowed to assign to an invocant? Any that you like, but you might find a lot of people yelling the word Liskov at you, or create a method that's impossible to call. ;-) * Does anyone object to roles having an invocant, and that invocant referring to the class that is doing the role? Yes; on further reflection, the ability to type that invocant raises all kinds of possible WTFs without a good enough use case. So I'd really rather we don't go down this road. Longnames: * Why are we using ;; to denote the end of a multi function's longname? I'm thinking that doubling up on the normal delimiter may make more sense - which would normally mean ,,, but would mean ;; if you're using a multidimensional argument list and the longname ends where a semicolon would normally go. Think it's probably a visual argument - ,, just doesn't stand out as there's something different going on here sufficiently. * Can any required parameter be part of the longname, or are only positional parameters allowed? (I'm expecting the latter; but I'd like confirmation.) Only positional parameters participate in multiple dispatch in Perl 6.0.0, so yes, the latter. * Are placeholder parameters ever considered to be part of a function's longname? (I'm expecting that they aren't: if you want a longname, you ought to specify it in a formal signature.) Placeholder parameters result in a signature being generated based upon them, as far as I can tell (and so far as we've implemented in Rakudo). So yes, they would all count in the long name - or at least, the positional ones. Also note that if you do have placeholder parameters it's illegal to write a signature on the block too. Starting and Ending delimiters: * Why are pointy blocks forbidden from enclosing their signatures in parentheses, or from using the :( ... ) notation? Is this a holdover from the early days, when parentheses denoted a list? Or is there still a good reason not to allow such notation? Really not sure on this one. * Why do parameterized roles use [ ... ] for their signatures instead of :( ... ) or ( ... )? RoleName(...) is a type coercion, so we can't use that. I also think it's good that parametrized types have something visually distinctive about them, though, so I think the current syntax is probably just fine. Named parameters: * Must required named parameters be defined before optional named parameters are, or are we allowed to interleave the two? As far as I know, you can mix them for named (but not, obviously, for positional). Placeholder parameters: * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. We only generate *...@_ and *%_ for subs when there is no signature; the presence of placeholder parameters generates a signature, so you'd not get them. Exception: methods, where by S12 we always add a *%_ unless the method defines its own slurpy named parameter. Hope this helps, Jonathan
Re: S08 Draft questions (Captures and Signatures)
Jonathan Worthington wrote: Jon Lang wrote: Invocants: * Does anyone object to roles having an invocant, and that invocant referring to the class that is doing the role? Yes; on further reflection, the ability to type that invocant raises all kinds of possible WTFs without a good enough use case. So I'd really rather we don't go down this road. How does this situation differ from the ability to type a method's invocant? I'm thinking that an argument might be made that you don't get to specify any invocant's type: a method's invocant would always be typed as the class to which it belongs (with the value set as the object calling it), while a role's invocant would always be typed as a type reference (i.e., the :: sigil), with the value being the class composing it. Would any significant functionality be lost in such a move? Longnames: * Are placeholder parameters ever considered to be part of a function's longname? (I'm expecting that they aren't: if you want a longname, you ought to specify it in a formal signature.) Placeholder parameters result in a signature being generated based upon them, as far as I can tell (and so far as we've implemented in Rakudo). So yes, they would all count in the long name - or at least, the positional ones. Also note that if you do have placeholder parameters it's illegal to write a signature on the block too. True: forbidding placeholder parameters from counting as part of the longname would effectively forbid functions that use placeholder parameters from _having_ a longname; and if you've explicitly asked for one (via the multi keyword), you should get one. Placeholder parameters: * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. We only generate *...@_ and *%_ for subs when there is no signature; the presence of placeholder parameters generates a signature, so you'd not get them. Exception: methods, where by S12 we always add a *%_ unless the method defines its own slurpy named parameter. Is this the desired behavior, or merely the current behavior? I can see a case for wanting the placeholder parameters to be pushed onto front of the default signature instead of replacing it. -- Jonathan Dataweaver Lang
Re: S08 Draft questions (Captures and Signatures)
Em Ter, 2009-03-31 às 22:54 -0700, Jon Lang escreveu: Yes, I know that there is no S08. I'm working on writing one, and I'd like some feedback to help me do so. ++ My draft is going to be about Signatures and Captures. Thus, my questions: Invocants: The concept of invocant only exists in terms of syntax now. In runtime the invocant is simply the first positional argument. This simplifies things a lot. * Is it illegal to specify an invocant in a sub, or is it merely nonsensical? There's nothing wrong about it. In fact, every time you do my method or our method, you end up with a sub that has an invocant in its signature. silently treat the invocant as the first positional parameter? Yes, that is basically the major side-effect on the latest capture change. As I said before, the invocant only exists in terms of syntax, it doesn't exist in terms of runtime. * Likewise, if I interpolate a signature with an invocant into another signature (somewhere other than at the start), is this an error, or will the invocant be silently converted into an ordinary positional parameter? What does interpolate a signature mean? But anyway, the invocant is the first positional argument, period. * What types are you allowed to assign to an invocant? It's just a positional argument. But I suppose that on method declarations, the type of the invocant is ::?CLASS. (Although there is some debate if it's going to make some declarations too narrow unintentionally. * Does anyone object to roles having an invocant, and that invocant referring to the class that is doing the role? You mean methods declared in a role? Yes, they have an invocant, but the invocant type in the signature could be just the role, I guess... * Why are we using ;; to denote the end of a multi function's longname? Because a capture may have more than one dimension, which would be delimited by ;. * Can any required parameter be part of the longname, or are only positional parameters allowed? (I'm expecting the latter; but I'd like confirmation.) I suspect you meant named parameter in place of required parameter. For Perl 6.0.0, it is accepted that named parameters don't take part in multi dispatch. * Are placeholder parameters ever considered to be part of a function's longname? (I'm expecting that they aren't: if you want a longname, you ought to specify it in a formal signature.) placeholder variables are just a simplified way of writing a signature, after they are compiled, the routine has a regular signature, which means that it should work as if the signature was explicit. * Must required named parameters be defined before optional named parameters are, or are we allowed to interleave the two? named parameters order are, most of the time, irrelevant. But you can have the same named parameter twice, iirc. So, I don't think you need to put mandatory named parameters before the regular ones... * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. Yes, it does. The default signature is the *default*. Having placeholder parameters imply defining a signature, one could argue that *...@_ and *%_ are still part of that generated signature, but @_ certainly won't contain the values that were in the placeholder parameters. daniel
Re: S08 Draft questions (Captures and Signatures)
On Wed, Apr 1, 2009 at 5:07 AM, Daniel Ruoso dan...@ruoso.com wrote: Em Ter, 2009-03-31 às 22:54 -0700, Jon Lang escreveu: Yes, I know that there is no S08. I'm working on writing one, and I'd like some feedback to help me do so. ++ My draft is going to be about Signatures and Captures. Thus, my questions: Invocants: The concept of invocant only exists in terms of syntax now. In runtime the invocant is simply the first positional argument. This simplifies things a lot. I think you're confusing signatures with captures here. Captures and the arguments that they, well, capture, don't care about the invocant; but signatures and the parameters that they define still do. * Likewise, if I interpolate a signature with an invocant into another signature (somewhere other than at the start), is this an error, or will the invocant be silently converted into an ordinary positional parameter? What does interpolate a signature mean? ...my bad. For some reason, I made the opposite mistake: I thought that it was possible to assemble a signature out of other signatures. * Why are we using ;; to denote the end of a multi function's longname? Because a capture may have more than one dimension, which would be delimited by ;. Note that I didn't propose ; as the longname terminator. * Can any required parameter be part of the longname, or are only positional parameters allowed? (I'm expecting the latter; but I'd like confirmation.) I suspect you meant named parameter in place of required parameter. I meant both, actually: can required named parameters be part of the longname? For Perl 6.0.0, it is accepted that named parameters don't take part in multi dispatch. OK. * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. Yes, it does. The default signature is the *default*. Having placeholder parameters imply defining a signature, one could argue that *...@_ and *%_ are still part of that generated signature, but @_ certainly won't contain the values that were in the placeholder parameters. ...nor would I expect it to. I'm just wondering if (@_, %_) _are_ still part of a placeholder-generated signature. In short, is there a way to access a slurpy array or hash in a block that uses placeholder parameters? -- Jonathan Dataweaver Lang
Re: S08 Draft questions (Captures and Signatures)
Em Qua, 2009-04-01 às 05:41 -0700, Jon Lang escreveu:
On Wed, Apr 1, 2009 at 5:07 AM, Daniel Ruoso dan...@ruoso.com wrote:
The concept of invocant only exists in terms of syntax now. In runtime
the invocant is simply the first positional argument. This simplifies
things a lot.
I think you're confusing signatures with captures here. Captures and
the arguments that they, well, capture, don't care about the invocant;
but signatures and the parameters that they define still do.
Not at all, if you declare a method with my or our, it is seen as a
sub (as with is export), but it will still have the same signature.
So, the invocant only exists in the syntax even for signatures, in
runtime, they are simply the first argument... Which, in terms of code,
means:
my method foo($b,$c) {...}
$a.foo($b,c);
foo($a,$b,$c);
In both invocations, $a is seen by foo as self, because that is how
the signature is defined.
* Why are we using ;; to denote the end of a multi function's
longname?
Because a capture may have more than one dimension, which would be
delimited by ;.
Note that I didn't propose ; as the longname terminator.
I see, but the idea of using ;; is to be something invariably stronger
than ; .
...nor would I expect it to. I'm just wondering if (@_, %_) _are_
still part of a placeholder-generated signature. In short, is there a
way to access a slurpy array or hash in a block that uses placeholder
parameters?
I'd guess not, but I think it's a plain design decision. In my head, the
default slurpy only makes sense when no signature is provided at all,
and only for some mindset compatibility with Perl 5.
In fact... cases like:
for 1,2,3,4,5,6 { say $^a, $^b }
Imply that you can't have the slurpies there, otherwise the for loop
would be run only once...
daniel
Re: S08 Draft questions (Captures and Signatures)
On Wed, Apr 01, 2009 at 09:55:37AM -0300, Daniel Ruoso wrote: Em Qua, 2009-04-01 às 05:41 -0700, Jon Lang escreveu: ...nor would I expect it to. I'm just wondering if (@_, %_) _are_ still part of a placeholder-generated signature. In short, is there a way to access a slurpy array or hash in a block that uses placeholder parameters? I'd guess not, but I think it's a plain design decision. @_ and %_ are part of a placeholder-generated signature if they're mentioned in the block. From S06:154: Note also that if the sub's block contains placeholder variables (such as C$^foo or C$:bar), those are considered to be formal parameters already, so in that case C@_ or C%_ fill the role of sopping up unmatched arguments. That is, if those containers are explicitly mentioned within the body, they are added as slurpy parameters. [...] Pm
Re: S08 Draft questions (Captures and Signatures)
HaloO,
Moritz Lenz wrote:
* What types are you allowed to assign to an invocant?
Whatever the type constraint says. When you write
class Foo { method bar ($x, $y) }, then bar's signature gets an invocant
of type Foo implicitly. If you write ... method bar (A $s:, $x, $y),
then the type constraint is A.
I would say that the class is always implicitly the type constraint on
the invocant. That is class Foo { method bar (A $s: $x, $y) } makes the
type constraint the juxtaposition of Foo and A. And $s can only access
the public interface of A.
An interesting question is if methods are allowed outside of a class
scope. That is, the type constraint of the invocant inserts it into
the class. Perhaps in a non-privileged form, i.e. without access to
private attributes and methods. Does that make sense?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: S08 Draft questions (Captures and Signatures)
On Tue, Mar 31, 2009 at 10:54:33PM -0700, Jon Lang wrote: : * Why are pointy blocks forbidden from enclosing their signatures in : parentheses, or from using the :( ... ) notation? Is this a : holdover from the early days, when parentheses denoted a list? Or is : there still a good reason not to allow such notation? Because subsignatures within a signature match a single argument with that subsignature, on the assumption that the argument is something resembling a capture. Larry
S08 Draft questions (Captures and Signatures)
Yes, I know that there is no S08. I'm working on writing one, and I'd like some feedback to help me do so. My draft is going to be about Signatures and Captures. Thus, my questions: Invocants: * Is it illegal to specify an invocant in a sub, or is it merely nonsensical? That is, should the compiler complain, or should it silently treat the invocant as the first positional parameter? (The latter has the advantage that you don't have to worry about what the signature is being used for; it has the disadvantage of being, well, nonsensical: invocants are meaningless without the context of a method - and /maybe/ a role - to provide them meaning.) * Likewise, if I interpolate a signature with an invocant into another signature (somewhere other than at the start), is this an error, or will the invocant be silently converted into an ordinary positional parameter? * What types are you allowed to assign to an invocant? * Does anyone object to roles having an invocant, and that invocant referring to the class that is doing the role? Longnames: * Why are we using ;; to denote the end of a multi function's longname? I'm thinking that doubling up on the normal delimiter may make more sense - which would normally mean ,,, but would mean ;; if you're using a multidimensional argument list and the longname ends where a semicolon would normally go. * Can any required parameter be part of the longname, or are only positional parameters allowed? (I'm expecting the latter; but I'd like confirmation.) * Are placeholder parameters ever considered to be part of a function's longname? (I'm expecting that they aren't: if you want a longname, you ought to specify it in a formal signature.) Starting and Ending delimiters: * Why are pointy blocks forbidden from enclosing their signatures in parentheses, or from using the :( ... ) notation? Is this a holdover from the early days, when parentheses denoted a list? Or is there still a good reason not to allow such notation? * Why do parameterized roles use [ ... ] for their signatures instead of :( ... ) or ( ... )? Named parameters: * Must required named parameters be defined before optional named parameters are, or are we allowed to interleave the two? Placeholder parameters: * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. -- Jonathan Dataweaver Lang
