Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Thomas Sandla wrote:
Int|Str : Str Str : Int|Str Int|Str : Int Int : Int|Str
holds.
Uhh, I hardly believe that it was me writing that last night!
Int|Str is of course a proper supertype of Int and Str respectively.
So we really have: Str : Str|Int Int : Str|Int, which warps us
back to the co-/contravar problem of polymorphic rw containers.
And that doesn't help very much in achieving high flexibility under
the benevolence of strong typing.
Given an even more complex Any type that encompasses the general
purpose types of Perl6---namely Str, Int, Num, Bool and Refs thereof---
the lazy Perl6 programmer gets what Perl5 did all the time. This is
what is called Render the Illusion of Simplicity.
The solution is to make the juntive supertype on the polymorphic array
itself, which actually is much clearer:
class Array does Array of Str | Array of Int | ...
{ ... }
I'm not saying that this is easy to implement, but I'd appreciate
if it were part of Perl6 for a comprehensive set of types. I would
also expect some work on the side of new classes/types to participate
in this rw Array scheme.
--
TSa (Thomas Sandla)
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote:
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: How can you have a level independent position?
By not confusing positions with numbers. They're just pointers into
a particular string.
I'm not the Unicode guru but my understanding is that all composition
sequences are finite and stateless with respect to everything before
and after them in the string. Which brings me to the question if these
positions are defined like positions in Emacs as lying *between* the
chars? Then the set of positions of a higher level is a subset of the
positions of lower levels.
With defining position as between chars many operations on strings are
downwards compatible between levels, e.g. splitting. If one determines
e.g. an insert position on a higher level there's no problem in letting
the actual insertion beeing handled by a lower level. With fractional
positions on higher levels some degree of upward or tunneling
compatibility can be achieved.
BTW, will bidirectionality be supported? Does it make sense to reflect
it in the StrPos type such that $pos_start $pos_end means a non-empty
left to right string, $pos_start $pos_end is a non-empty right to left
string and $pos_start == $pos_end delimit an empty (sub)string? As a
natural consequence the sign indicates direction with negative length
beeing right to left. And that leads to two times two types of iterators:
left to right, right to left, start to end and end to start.
All the above leads me to rant about an array like type. Please forgive
me if the following is not proper Perl6. My point is to illustrate how
I imagine the future communication between implementor and user of such
a class. Actually some POD support for extracting the type information
into the documentation would be great, too!
And yes, the :analyse should be made lazy. The distinction between the
first and second index method could be even more specific by using
type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
information that indexing with a list of one element doesn't result
in a List of Str but a plain Str. OTOH this will incur a performance
penalty and violate the intuitive notion list in, list out.
class StrPosArray does Array where { ::Index does StrPos }
{
has Str$:data;
has StrPos @:pos;
multi method postcircumfix:[ ]
(: Index $i ) returns Str {...}
multi method postcircumfix:[ ]
(: List of Index $i ) returns List of Str {...}
multi method postcircumfix:[ ]
(: Range of Index $i ) returns List of Str {...}
multi method postcircumfix:[ ]
(:Int $i ) returns Str {...}
# more stuff here for push, pop, shift etc.
method infix:= (: Str $rhs ) returns ::?CLASS
{
$:data = $rhs;
:analyse;
}
method :analyse ()
{
# scan $:data for all between char positions
# and store them into @:pos
}
}
Question:
does the compiler go over this source in multiple passes
such that the declaration of :analyse is known before its
usage in infix:=?
--
TSa (Thomas Sandlaß)
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
[EMAIL PROTECTED] wrote:
Er, isn't that not just the wrong way around? The point is to do the
bookkeeping that an object is needed that does .meth() and that it
is stored in $a, and to complain when that is not the case when it
should be. The earlier the better.
I don't understand why writing 'my X $a' needs at least a declaration
of X, but then '$a.meth()' does not consider '.meth' as a bare method
that needs a declaration in X?
Because you can do
sub infect(X $a is rw)
{
role bla {
method meth() {...}
}
$a does bla;
}
my X $a;
infect($a);
a.meth();
Remember, you can even change the class of instanced objects using
'does' (or 'but', but it'll at least copy the object). And as the
example above shows, this is statically intractable - it can happen in a
sub in a different autoloaded module.
Also, what do you want to do if you actually want $a.meth() to throw a
catchable exception if $a doesn't implement meth? It's what many OO
languages do. In fact, I can't recall a single OO language that isn't
derived from C++ that does /not/ just throw a runtime exception on
unknown method.
Miro
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Miroslav Silovic wrote:
Remember, you can even change the class of instanced objects using
'does' (or 'but', but it'll at least copy the object). And as the
example above shows, this is statically intractable - it can happen in a
sub in a different autoloaded module.
Sorry this is a well established fact in this thread. If unspecificity
is what you want than you use 'my $a;' and the compiler happily parses
'$a.meth()' purely syntactically and generates code for dynamic lookup
and potential exception throwing.
Aaron's and my point is the reverse: what do we gain if the same applies
when we kindly announce that $a should do X'ish things only. That of course
includes late bound fancy versions of methods from the interface of X. If
there's no difference why bother to make declarations?
This whole thread is about semantics close to syntax. I mean we know that
everything with a dot is a method which syntactically makes dot the infix
method sigil or some such. But I want the compiler to do a bit more than
just extracting the string after the dot from my source code and stash it
in some namespace when I requested the constraint X.
Is typing optional in the sense that it is no syntax error but
otherwise ignored? To me this is pain but no gain :(
BTW, is 'my ::X $a;' introducing X as unspecific as it could be?
Just occupying the syntactic slot of a type? That could be usefull
to start in an explorational style and eventually use the PTE
(P(arrot|erl6) Type Engine) to infer what X should look like.
I really see the PTE as the twin of the PGE---and no Perl hacker
disavows the power of regular expressions and parsers ;)
Also, what do you want to do if you actually want $a.meth() to throw a
catchable exception if $a doesn't implement meth? It's what many OO
languages do. In fact, I can't recall a single OO language that isn't
derived from C++ that does /not/ just throw a runtime exception on
unknown method.
Well that would just be role X { method meth() {...} } by virtue of
the nada operator---whatever exception it throws and how much it tells
about X::meth().
--
TSa (Thomas Sandlaß)
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
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. One additional wrinkle is that *anyone* is allowed to declare a class non-cooperative (open or non-final) during *any* part of the compilation, so your method existence checking cannot be done at reduction time, but must be done as a separate pass from a CHECK block at the end of whatever lexical scope requested cooperation. CHECK blocks are construed to be the end of normal compilation; Perl 6 very much follows the Perl 5 model here. I hope this clears things up a little. Larry
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Thu, 2005-03-31 at 11:51, Larry Wall wrote: 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. So let me try to unpeel that (I'm not trying to be difficult, it's just that this is a difficult topic as evidenced by the mountain of documentation on the topic by languages that try to be only HALF as flexible). If you declare a variable to be of a type (let's even say a class to be specific), then you have hinted to the compiler as to the nature of that variable, but nothing is certain. That is to say that the compiler cannot: * Make any type-massaging choices yet on (implicit or explicit) method invocations * Issue any errors based on signature miss-matches Ok? Now we move on to the idea of finalization. Please correct me where I conflate finalization and openness. I'm not sure I understand the difference at all (no, I'm certain I don't). We assert (don't have the docs handy, but I'll just arm-wave the syntax) that the class is now finalized. This means any attempt to re-define the interface of the class is a compile-time error, correct? What about changing the internals of the class (e.g. changing the code associated with a method without re-defining the signature)? Next, what are the conditions under which a class can be finalized? * Can we finalize a class which has non-finalized ancestors? * What if it has method parameters/return values or member variables whose types are not finalized? * What if it applies roles which are not finalized? Obviously each one of these questions comes with a host of what happens if questions given a yes answer Another question: how does finalization interact with a class's metaclass? Does the metaclass become a const? Is the type of a metaclass itself a finalized class? If not, can it be finalized by user code? One additional wrinkle is that *anyone* is allowed to declare a class non-cooperative (open or non-final) during *any* part of the compilation ... even after it is declared final? Will core types be finalized by default? I hope this clears things up a little. Clear that's a word ;-) Yes, your message helped. I can sense your exasperation, but it is my hope that asking stupid questions now means that we'll have smart answers by the time P6 is released. If I'm overly slowing the process, please say so, and I'll stop asking. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote: I can't answer most of these well. However... One additional wrinkle is that *anyone* is allowed to declare a class non-cooperative (open or non-final) during *any* part of the compilation ... even after it is declared final? I hope so. Will core types be finalized by default? I hope not, but if so, I hope they include all of the behavior anyone could ever possibly want from them so that no one will ever have to decorate them to add that one little important missing feature. Open-Closed is a great idea until the most natural and easiest way to do something is to to redefine a little bit of the world. -- c
Documentary annotations: $what docwhy
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
Open Source is not an excuse to write fun code
then leave the actual work to others.
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
I'm no expert, but here's my take: On Thu, Mar 31, 2005 at 01:11:37PM -0500, Aaron Sherman wrote: If you declare a variable to be of a type (let's even say a class to be specific), then you have hinted to the compiler as to the nature of that variable, but nothing is certain. That is to say that the compiler cannot: * Make any type-massaging choices yet on (implicit or explicit) method invocations * Issue any errors based on signature miss-matches Ok? I don't quite know what you mean by type massaging choices, but sure the compiler *can* issue errors on signature mismatch. When you say my X $a; the compiler has to treat $a like an X even if it doesn't know everything there is to know about X (X may not even be defined yet). So if you pass $a to a routine that's expecting a Y, then the compiler can and will carp. If, by type massaging choices you mean deciding whether or not to accept a variable in a signature slot based on its type (i.e., if the parameter is declared as a super-type of X, do we accept a X for this parameter), then I think the compiler can do that as well. Now we move on to the idea of finalization. Please correct me where I conflate finalization and openness. I'm not sure I understand the difference at all (no, I'm certain I don't). final classes can not be derived from, non-final can. closed classes can not have new methods added to them later on, open classes can. We assert (don't have the docs handy, but I'll just arm-wave the syntax) that the class is now finalized. This means any attempt to re-define the interface of the class is a compile-time error, correct? What about changing the internals of the class (e.g. changing the code associated with a method without re-defining the signature)? If I assume you're talking about closed classes here (as it seems), then I'd say that you can not redefine the interface or change it's internals. If you really do mean finalized classes, then I'd think that you *can* change the interface or the internals. Next, what are the conditions under which a class can be finalized? * Can we finalize a class which has non-finalized ancestors? Certainly. Even if you meant can we close a class which has non-closed ancestors, I think you can do both. Not sure though. * What if it has method parameters/return values or member variables whose types are not finalized? Finalization and closing is not something you do to instances, but rather classes. * What if it applies roles which are not finalized? I don't think you can finalize roles (it doesn't make sense to me to be able to do so anyway) Closing roles, I think you can do though. Also, according to http://dev.perl.org/perl6/synopsis/S12.html#Open_vs_Closed_Classes There is no syntax for declaring individual classes closed or final. The application may only request that the optimizer close and finalize unmarked classes. So you would have a default policy of closed/final and then open/unfinalize individual classes, or have a default policy of open/non-final and have no way to close/finalize individual classes. Another question: how does finalization interact with a class's metaclass? I don't think it does, except that that may be the hook by which we obtain no dreviatives allowed on implementation. (i.e. the meta-classes enforces the restrictions placed upon the class) Does the metaclass become a const? Is the type of a metaclass itself a finalized class? If not, can it be finalized by user code? You've strayed beyond my idea-space here :-) One additional wrinkle is that *anyone* is allowed to declare a class non-cooperative (open or non-final) during *any* part of the compilation ... even after it is declared final? Sure. Will core types be finalized by default? No. It would be very un-perl-like to have such an unasked for restriction IMHO. Caveat lector, I'm not of the cabal. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Thu, 2005-03-31 at 15:25, chromatic wrote: On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote: I can't answer most of these well. However... Open-Closed is a great idea until the most natural and easiest way to do something is to to redefine a little bit of the world. You seemed to have answered my questions on the basis of a piece of information which I asked for, but you did not include... I took the liberty of re-reading S12 and A12 to find it, and got two answers which are almost the same. After having found the bit on open vs. final, I'm even more at a loss, but I have some answers... let me start trying to put them together for others to scrutinize (I'm not taking a pro or con position on any of this yet, just trying to get the details worked out). S12 sayeth: By default, all classes in Perl are non-final, which means you can derive from them. Ok, so this answers a few of my questions. Namely, you can't do anything particularly useful by finalizing your class (and A12 tells us you can't really anyway). You would have to finalize EVERYTHING in your class's inheritance chain up to, but not including it, and then close your own class in order to allow compile-time error detection and type massaging. Also note that A12 says: Likewise, a final class (to use the Java term) is one that you know will never be derived from, let alone mucked with internally. which subtly contradicts (or at least expands on in an unexpected way) S12 by implying that final implies closed does it? S12 then goes on to say: They are also open, which means you can add more methods to them, though you have to be explicit that that is what you're doing: This is far too limited, isn't it? What can we normally do to a class? In conversations here, we've previously arm-waved that we'd be able to do damn near anything we pleased through the metaclass... but perhaps that's not true? I think that's pretty much what I know and don't know as of now... anyone want to take a shot? -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Documentary annotations: $what docwhy
Chip Salzenberg writes:
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
Well, first you need an `is` somewhere in there. And after that I think
you'll need to do it in doc('stuff') form. If we did allow doc, then
this:
is docConvert degrees F to degrees C
Would mean:
is doc('Convert', 'degrees', 'F', 'to', 'degrees', 'C')
Which I expect is not what you intended. But if we start allowing that
everywhere, then I think that we'd have to do it for subs, too:
sub foo([EMAIL PROTECTED]) {...}
fooa b c d e
And that isn't an implausible thing to do, but it forbids what might be
a common practice:
$foo.hash{'a'}
Replacing it with the more convoluted:
$foo.hash(){'a'}
And it essentially wouldn't allow objects that could be treated as both
subs and hashes... not that that's a huge loss. Anyway, I think you'll
have to stick with is doc('...').
Luke
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
Open Source is not an excuse to write fun code
then leave the actual work to others.
Re: Documentary annotations: $what docwhy
On Thu, 31 Mar 2005, Luke Palmer wrote:
Chip Salzenberg writes:
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
Well, first you need an `is` somewhere in there. And after that I think
you'll need to do it in doc('stuff') form. If we did allow doc, then
this:
is docConvert degrees F to degrees C
But if you are going to use doc('') in a million places, can you not also
make doc a trait_verb and save a little typing? So:
role doc{
sub *trait_verb:doc($container: $string) {
...
}
}
But what do I apply the role to? perhaps
class Object does doc
Now
sub f2c (Num $temp doc Temperature in degrees F) {...}
works(I think): trait_verb:doc is a sub, not a method, and so parens are
not needed.
It works, but that doesn't read too well. We do need a verb there. docs,
perhaps? Or gloss, which is both a noun and a verb?
--abhijit
Re: Documentary annotations: $what docwhy
Make is polymorphic :D
Michael
On Thu, 31 Mar 2005 21:24:52 -0500 (EST), Abhijit Mahabal
[EMAIL PROTECTED] wrote:
On Thu, 31 Mar 2005, Luke Palmer wrote:
Chip Salzenberg writes:
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
Well, first you need an `is` somewhere in there. And after that I think
you'll need to do it in doc('stuff') form. If we did allow doc, then
this:
is docConvert degrees F to degrees C
But if you are going to use doc('') in a million places, can you not also
make doc a trait_verb and save a little typing? So:
role doc{
sub *trait_verb:doc($container: $string) {
...
}
}
But what do I apply the role to? perhaps
class Object does doc
Now
sub f2c (Num $temp doc Temperature in degrees F) {...}
works(I think): trait_verb:doc is a sub, not a method, and so parens are
not needed.
It works, but that doesn't read too well. We do need a verb there. docs,
perhaps? Or gloss, which is both a noun and a verb?
--abhijit
Re: Documentary annotations: $what docwhy
Chip Salzenberg writes:
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
Perhaps you spell it 'annotated' and add a few shortcuts?
Num $temp is annotated('Temperature in degrees F')
Num @temp is an('Array of temperatures in degrees F')
Dog $spot is a('Good Dog!')
Ashley Winters
identity tests and comparing two references
As I continue porting code to Perl 6, I found something else that the
synopsis don't seem to explain clearly.
What I want to be able to do is compare two references to see if they
point to the same thing, in this case an object, but in other cases
perhaps some other type of thing.
In synopsis 3, under the 'Binding' section, the =:= operator
description is vague to the point that I don't know whether it
applies to my problem or not. All I know for sure is that '$x =:=
$y' will return true if previously '$y := $x', and I think that is a
different situation than my pair of references.
In Perl 5, a standard string compare just so happened to work for
comparing two object refs, but that was inelegant. In Perl 6 I need
something better than comparing stringified ('eq') or numified ('==')
versions of the objects.
The ref compare should have its own operator.
Now I seem to remember reading somewhere that '===' will do what I
want, but I'm now having trouble finding any mention of it.
So, what is the operator for reference comparison?
Thank you. -- Darren Duncan
Re: identity tests and comparing two references
Darren Duncan wrote:
Now I seem to remember reading somewhere that '===' will do what I want,
but I'm now having trouble finding any mention of it.
So, what is the operator for reference comparison?
As someone who wrote a tool that uses refaddr() and 0+ in Perl 5 to
achieve the same thing, I agree with the need for such an operator.
I think that =:= compares *lexical* identity is fairly clearly spelled
out in S03. However, we need a way to compare *value* /identity/ (not
equality or equivalence), without being subject to overloading etc.
Of course, actually comparing two `ref' or `Ref' objects for pointing
to the same place is achieved via `==' (or, if === is used, ${$ref1} ===
${$ref2} or the P6 equivalent :) )
Sam.
