HaloO,
Larry Wall wrote:
My gut-level feeling on this is that $! is going to end up being an
"env" variable like $_.
I just re-read about exceptions. Well, I undestand now that $! is
intented as a variable with a spectrum of meanings ranging from
1) the return value of a sub, through
2) a
HaloO,
Larry Wall wrote:
And replying to the thread in general, I'm not in favor of stricter
default rules on undef, because I want to preserve the fail-soft
aspects of Perl 5.
Also replying to the thread in general, I feel that undef as a
language concept mixes too many usefull concept into a
HaloO,
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
Ups, is that distinction needed eagerly? Wouldn't the return value
of a do-nothing code return a value that when coerced into
HaloO,
Juerd wrote:
I think it should be both.
So do I.
my $foo = {};
$foo(); # It was a sub
The postfix () is valid syntax irrespective of the former
assignment, right?
my $foo = {};
$foo = 1; # It was a hash
Would you expect the second line to work witout the firs
HaloO,
Nicholas Clark wrote:
I think that Larry is referring to slightly larger and more expensive rockets
than regular fireworks: http://www.siam.org/siamnews/general/ariane.htm
I know. But where would we put Perl 6 onto a range of programming
languages parrallel to rockets ranging from fire
HaloO,
Nicholas Clark wrote:
Well, I assume that the do-nothing sub is assigned into the variable, and
gets re-evaluated each time the variable is use. Which would mean that you'd
get a new (different) empty hash each time. Whereas an empty hash constructor
gives you a hash reference to keep. (n
HaloO Everybody,
here's a an idea from me about makeing range object a bit like
junctions. That is a range object has a $.min and $.max and the
following comparison behaviour:
str num
lt < strictly inside -+
gt > strictly outside --+ |
eq == exactly on boundary --+ | |
Ups,
I forgot to mention things like
+('a0',,'e3') == +( ,
,
,
,
)
== +( 'a0','a1','a2','a3',
'b0','b1','b2','b3',
'c0','c1','c2','c3',
HaloO,
Luke Palmer wrote:
That's an interesting idea. A "deep reference".
I also instantaniously loved the idea to dinstinguish between
the types Hash and Ref of Hash. Or Array etc.
--
HaloO,
happy new year to Everybody!
Luke Palmer wrote:
Env variables are implicitly passed up through any number of call
frames.
Interesting to note that you imagine the call chain to grow upwards
where I would say 'implicitly passed down'. Nevertheless I would
also think of upwards beeing th
HaloO,
Larry Wall wrote:
I think that deep copying is rare enough in practice that it should
be dehuffmanized to .deepcopy, perhaps with optional arguments saying
how deep.
So perhaps .copy:deep then?
Simple shallow copy is .copy, whereas .clone is a .bless
variant that will copy based on
HaloO Eric,
you wrote:
#strictly outside
($a > 3..6) === (3 > $a > 6) === (3 > $a || $a > 6)
Just looking at that hurts my head, how can $a be smaller than three
and larger than 6? That doesn't make even a little since.
To my twisted brain it does ;)
The idea is that
outside === !i
ed syntactically! But how much
the syntax there resembles the humanized forms of Perl6, I can only
guess. On the engine level the only thing that remains is MMD and
error handling.
Maybe you could make it your first Perl 6 module?
Uhh, let's see what I can do about that. Unfortunately
I'm lazy there... *$TSa :)
--
HaloO,
Austin Frank wrote:
It seems to me like these are related contexts-- arguments to a sub are
supposed to fulfill its parameter list. This makes the overloading of
prefix:<*> confusing to me.
Would an explicit type List help?
I'm pretty sure we don't need slurpiness in argument lists,
HaloO,
Luke Palmer wrote:
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
...
[1] This is one of my quibbles with junctions, too.
You mean the
HaloO,
Luke Palmer wrote:
Which "reads nicely", but it is quite opaque to the naive user.
I guess many things are opaque to naive users ;)
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him
HaloO,
Luke Palmer wrote:
Junctions are frightfully more abstract than that. They only take on
meaning when you evaluate them in boolean context. Before that, they
represent only a potential to become a boolean test.
This is very well spoken err written---except that I would use
beautifully
HaloO,
Rob Kinyon wrote:
I'm confused at the confusion. To me, junctions are just magical
values, not magical scalars. In theory, one should be able to create
junctions of arrays, hashes, or subs just as easily.
my @junc = any( @a, @b, @c );
my %junc = any( %a, %b, %c );
Hmm, and this
HaloO,
Luke Palmer wrote:
But junctions are so "special", that this abstraction wouldn't work.
Well my point is that I dought that it is tractible for the compiler
to come up with the dwimmery to pull the invocation of .values on the
return value out of toomany and leave the cardinality check
HaloO,
Jonathan Lang wrote:
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not.
So, is there a number between 0 and 1? Shades between black and white?
When is a 360 degree turn not returning a system into its initial s
HaloO,
S02 states "(Directly subscripting the type with either square brackets
or curlies is reserved for various generic type-theoretic operations. In
most other matters type names and package names are interchangeable.)"
What are these type-theoretic operations? And what do directly
attache
HaloO,
Larry Wall wrote:
Um, I always thought that "is reserved" in a spec means "we don't have
the foggiest idea what we'll do with this, but we have a suspicion
that if we let people use this particular thing right now, we'll
regret it someday."
OK, but how official is theory.pod? I mean is
HaloO,
S03 does explicitly disallow auto-reversed ranges.
And I'm not sure if the upto operator has a downto
cousin where ^-4 == (-1, -2, -3, -4) returns a list
that is suitable for indexing an array from the back.
Why is that so?
With negative ranges, negative array and list length
becomes a lo
HaloO,
[EMAIL PROTECTED] wrote:
* S02: fix the three places where the old form:
$x .(...)
needs to be replaced to the new form:
$x. (...)
-&foo.($arg1, $arg2);
+&foo. ($arg1, $arg2);
What is the reason for this change? I find the
old definition of whitespace before
HaloO,
Damian Conway wrote:
We can't. The problem is that:
foo .bar
has to mean:
foo($_.bar)
So the only way to allow whitespace in dot operations is to put it after
the dot.
The obvious alternative is to make 'foo .bar' simply mean
'call foo and dispatch .bar on the return value'
HaloO,
Larry Wall wrote:
Sure, that one might be obvious, but quick, tell me what these mean:
say .bar
say .()
say .1
when .bar
when .()
when .1
foo .bar
foo .()
foo .1
.foo .bar
.foo .()
.foo .1
I'd rather have a rule you don't have to think abo
HaloO,
I'm unsure what the outcome of the recent long dot discussions is
as far as the range operator is concerned. Since the whole point
of the long dot is to support alignment styles the following cases
shouldn't mean different things:
foobar #0 single call to foobar (OK, that is diffe
HaloO,
Larry Wall wrote:
On Tue, Apr 11, 2006 at 12:41:30PM +0200, TSa wrote:
: I'm unsure what the outcome of the recent long dot discussions is
: as far as the range operator is concerned.
.. is always the range operator. The "dot wedge" just has a discontinuity
in it there.
HaloO,
Darren Duncan wrote:
Long story shortened, if we consider the point in time where an
"immutable" object's constructor returns as being when the object is
born, then we have no problem. Any type of object is thereby immutable
if it can not be changed after its constructor returns.
My
HaloO,
Larry Wall wrote:
On Fri, Apr 28, 2006 at 04:41:41AM +, Luke Palmer wrote:
: It seems like a hash whose values are the unit type. Does Perl have a
: unit type? I suppose if it doesn't, we could define one:
:
:subtype Unit of Int where 1;
:
: (Assuming that "where" groks whatev
HaloO,
Dr.Ruud wrote:
What would be the way to define-or-set that a specific hash has
non-case-sensitive keys?
There are two things in this:
(1) The syntax to type the keys of a hash---too bad that I forgot it
and currently don't find it in the Synopsyses. Pointers welcome!
(2) A way to
HaloO,
Smylers wrote:
But why would a hash be doing equality operations at all?
I think it does so in the abstract. A concrete implementation
might use the .id method to get a hash value directly.
Assuming that
a hash is implemented efficiently, as a hash, then it needs to be able
to map d
HaloO,
Paul Hodges wrote:
so back to foo("bar"). What's the default behavior? String doesn't Num,
does it? though is does convert if the value is good
I think that Str and Num are disjoint mutually exclusive types.
If you want to get coercive behaviour you need an overloaded
&foo:(Str|Num
HaloO,
Luke Palmer wrote:
Removing abilities, counterintuitive though it may seem on the
surface, makes the type *larger*. It is not adding constraints, it is
removing them (you might not be able to call set($x) on this object
anymore).
Welcome to the co- and contra-variance problem again. We
HaloO,
Trey Harris wrote:
I do not think that C should mutate its LHS, regardless what its
RHS is.
I strongly agree. We have the mutating version
$p but= { .y = 17 };
which is just one char longer and nicely blends as a meta operator.
But are assignment ops allowed as initializer?
my $z
traints onto the
class. Do roles work like that in Perl6? I mean would the approach
of the article of using two F-bounded quantifications (see the last
formular in section 8) be a valid type model for class composition?
Regards, TSa.
--
Perl 6 hash/arrays
but are expressed in more elementary particles.
This might be very useful in future debates about these types. But
I think everything hinges on the basic Seq type.
Regards, TSa.
--
HaloO,
Miroslav Silovic wrote:
TSa wrote:
Nice usage of junctions!
But buggy - one means *exactly* one. So for an array of more than 1
element, all(@array) never equals one(@array) - if they're all the same,
it's more than 1, otherwise it's 0.
Doesn't all(1,2,3) == o
HaloO,
Sam Vilain wrote:
perl -MPerl6::Junction=one,all -le '@foo=qw(1 2 3 4); print "yes" if
(all(@foo) eq one(@foo))'
yes
But does it fail for duplicates? I guess not because junctions
eliminate duplicates and you end up testing unique values as
above. E.g. all(1,1,2) == one(1,1,2) might act
HaloO,
Luke Palmer wrote:
Woohoo! I was about to complain about this whole "capture sigil"
nonsense, but I'm guessing somebody else already did. I also like the
new [,] :-)
I'm very glad, too. Even though I would like the new operator
spelled / for aesthetic reason.
Regards,
--
HaloO,
Sam Vilain wrote:
Ah, yes, a notable omission. I understood a Seq as a list with
individual types for each element, which are applied positionally.
I can understand that the type-checker can produce this type
for immutable sequences.
The
superclass for things like Pair.
Hmm, have
HaloO,
is this subject not of interest? I just wanted to start a
discussion about the class composition process and how a
role designer can require the class to provide an equal
method and then augment it to achieve the correct behavior.
Contrast that with the need to do the same in every class
t
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bea
defined in terms of the self type and
e.g. use that as parameter type, return type and type constraints. All
of which nicely expand to the module or package type the role is
composed into!
Regards, TSa.
--
HaloO,
Brad Bowman wrote:
Sam Vilain wrote:
This will be the same as requiring that a class implements a
method, except the method's name is infix:<==>(::T $self: T $other)
or some such.
Sure. The point is, how does a role designer mix in the x and y
coordinate attributes *and* augment the no
HaloO,
Larry Wall wrote:
Basically, all types do Package whenever they need an associated
namespace.
Great! This is how I imagined things to be. And the reason why
the :: sigil is also the separator of namespaces.
And most of the Package role is simply:
method postfix:<::> () { return
HaloO,
Stevan Little wrote:
As for how the example in the OP might work, I would suspect that
"super" would not be what we are looking for here, but instead a
variant of "next METHOD".
I'm not familiar with the next METHOD syntax. How does one get the
return value from it and how are parameter
HaloO,
Stevan Little wrote:
On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist an
HaloO,
Stevan Little wrote:
I think that maybe we need to seperate the concept of roles as types
and roles as partial classes, they seem to me to be in conflict with
one another. And even they are not in conflict with one another, I
worry they will bloat the complexity of roles usage.
The bloa
HaloO,
Jonathan Lang wrote:
TSa wrote:
> Dispatch depends on a partial ordering of roles.
Could someone please give me an example to illustrate what is meant by
"partial ordering" here?
In addition to Matt Fowles explanation I would like to
give the following example lattice b
HaloO,
TSa wrote:
Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.
Actually 'next METHOD' doesn't catch all superclass interface issues.
Ther
HaloO,
Stevan Little wrote:
I do not think method combination should be the default for role
composition, it would defeat the composeability of roles because you
would never have conflicts.
I don't get that. The type system would give compile time errors.
The current spec means that in case of
HaloO,
TSa wrote:
Note that A = (A|B) & (A|C) is the intersection type of A|B and A|C.
Note further that A|B is a subtype of A and B written A|B <: A and
A|B <: B and so on. Usually the A|B|C is called Bottom or some such.
I think it is the Whatever type of Perl6. It is the glb (grea
HaloO,
Darren Duncan wrote:
Within a system that already has an underlying set-like type, the
Junction in this case, a test for uniqueness is (pardon any spelling):
all(@items).elements.size === @items.size
The all() will strip any duplicates, so if the number of elements in
all(@items) is
HaloO,
Jonathan Lang wrote:
What do you mean by "uncomposed class"?
The self always refers to the object as instance of the composed
class. Methods are therefore resolving to the outcome of the
composition process. But super in a role refers to methods from
the class definition even when the f
pecific", you'd mean "closest to the top"?
No, closer to the bottom. The join operator | of the lattice produces
subtypes with a larger interface that is more specific. It's like
the more derived class in a class hierarchy.
Regards, TSa.
--
pertype. But the typishness of roles is debated.
Regards, TSa.
--
om classes?
Is that a wise thing to do? Roles are not assigned and removed
as a regular operation. What is your use case?
Regards, TSa.
--
lem the lub Int|Str works for the first
parameter:
+- <: ---+
||
:(Int|Str,Int) :> :(Int,Int)
| |
+--- <: ---+
+ <: ---+
| |
:(Int|Str) :> :(Str)
Regards, TSa.
--
Dog&Tree --> Dog|Tree). This might just give
enough information to resolve the issues surrounding the DogTree
class.
Not sure what you mean by "the arrow types". Are you referring to
embedding a return type in the signature?
I mean arrow types as used in formal treatments of type systems.
Functions are denoted with arrows there. This is also the reason why
we have the --> in signatures.
Regards, TSa.
--
classes.
And now imagine that some classes implemented equality correctly and
some don't. With my approach the chance for this is diminished to
a correct class specific implementation that is required and used by
the role.
Regards, TSa.
--
revent comments
that choosing a method equal is not the right approach and MMD should be
used instead. But I think all of what we discussed so far stays valid if
the equal method is a multi. IIRC there is just one namespace slot for
the short name. And we are discussing how this slot is filled in the
class composition process.
BTW, why have you gone off-list?
Regards, TSa.
--
HaloO,
Jonathan Lang wrote:
> TSa wrote:
Note that I think the conflict detection of role methods prevents the
composition of the equal method through the superclass interface.
Just to make sure we're speaking the same language: by "superclass",
you're referring to cla
role when composing roles.
I see them more as a passive entity that the class composer is dealing
with. My scope is on producing a predictable result from the typing
point of view. Dispatch comes later.
Regards, TSa.
--
nless it is typed as Any, then the dynamic type is used. Right?
I know that the return type of / could be Num in "reality" but that
spoils the example. Sorry if the above is a bad example.
Regards, TSa.
--
HaloO,
TSa wrote:
I know that the return type of / could be Num in "reality" but that
spoils the example. Sorry if the above is a bad example.
Pinning the return type to Num is bad e.g. if you want multi targets
like :(Complex,Complex-->Complex). Should that also numerify comple
Num as parameter type in a sub
that does not use comparison should allow calling with a Complex even
though the nominal type is incompatible. IOW, the type inferencer
should determine a much more differentiated type than simple Num for
the parameter. How this type is then advertised I don't know.
Regards, TSa.
--
we can try
together to understand the type system of Perl 6.
Free mixins just go into the composed class unconstraint.
Do you mean "unconstrained"?
Yes, sorry for the typo.
Regards, TSa.
--
s used for parametric types. How is the latter
used?
Regards, TSa.
--
HaloO
TSa wrote:
I would like "does A & B & C" mean the intersection type of A, B and C.
That is a supertype of all three roles. In addition we might need
negation to get what Jonathan Lang envisoned for the Complex type that
does Num & !Comparable. IOW, I'm opting fo
#x27;t---at least not in compile-time class composition. And
for runtime composition you get the empty class for free!
Regards, TSa.
--
e role R3 adds a yada method that propagates down the
composition chains, classes might retroactively fail to compile!
Regards, TSa.
--
re. That means in a signature A|B would
require a more specific type and pure A or B wouldn't be admissible.
To get the old meaning of | you have to write A&B or perhaps the
juxtaposition which currently means what A|B should mean. Alternatively
the meaning of the role combination A&B could be defined to mean the
union and A|B the intersection.
Regards, TSa.
--
HaloO,
I wrote:
In fact if we decide to specify a role combination syntax then it
should be the same everywhere. That means in a signature A|B would
require a more specific type and pure A or B wouldn't be admissible.
To get the old meaning of | you have to write A&B or perhaps the
juxtaposition
x27; should return the self type ::?CLASS to
preserve as much type information as possible. Hmm, could we get
the keyword Self for that?
Have a nice weekend, TSa.
--
read as doing both interfaces.
BTW, what is set complement? Is it (!)?
Regards, TSa.
--
HaloO,
Jonathan Lang wrote:
> OK. My main dog in this race is the idea of defining new roles
> through the concepts of the intersection or difference between
> existing roles (even the union was thrown in there mainly for the sake
> of completion), with the consequent extension of the type system
role precisely to catch dispatches to this intersection, union or
another combination interface. Or you instanciate parametric roles
for the same purpose.
Note that union interfaces might need some merging of signatures as
I tried to argue elsewhere. Also, we might allow the subrole to change
signatures in accordance with the intended subtype relation.
Regards, TSa.
--
HaloO,
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A(&)B
produces a supertype
Are you sure?
Very sure ;)
In record subtyping a record is a mapping of labels to types.
In Perl 6 speak this is what a package does. One record type
is a subytpe i
d in class definitions as well?
I find it a sane thing to write
class C is (A,B,C) does (X,Y,Z) {...}
Regards, TSa.
--
p;)B producing the subtype on the
footing that this is usually called an intersection type, even though
the interfaces are merged.
Regards, TSa.
--
ature is then a requirement to
the composed class that indirectly does both roles.
Regards, TSa.
--
HaloO,
Jonathan Lang wrote:
If we make a point of highlighting the "set operations" perspective
You know that there are two sets involved. So which one do you mean?
and avoiding traditional type theory
terminology (which, as Larry pointed out and TSa demonstrated, is very
much
nt" operator to be '-', not '(-)'.
Funny. I would have hoped that the parens unequivocally indicate
set operations. The set difference should be (-) on the basis that
numeric minus should subtract their cardinalities much like it does
for arrays and hashes.
Regards, TSa.
--
oint
I'm arguing that the body be merged. I'm seeing guarantees that the type
system tries to hold up in favour of the users of roles.
Regards, TSa.
--
(which, without any
further qualifiers, is equivalent to "Array of Any"). If you must
force a more restrictive type on @array, go with "Array of (Int |
Str)" (yes, I do mean "|", not "(|)"; it's a type-matching issue, not
a container-construction issue.)
Which is another argument for choosing '(|)' to mean supertype in
role combination.
Regards, TSa.
--
HaloO,
Jonathan Lang wrote:
If you're not using "multi", then the signature is superfluous for
type-checking purposes.
I think that signatures do matter for type-checking! It is
an error to provide too few or to many positional args or
args with an incompatible type.
Regards, TSa.
--
HaloO,
TSa wrote:
When names have to be available as well, then we get an undefined
method that has to have two positionals and two named parameters such
that all four names appear to satisfy all conceivable call sites for
the two roles.
To get four names for two positional Parameters an &#x
e
formal model of this type system. E.g. what actually
constitutes a type? How are the classes related to
types? There is this fuzzy concept that a class is
also a role of the same name as far as typing is
concerned. How is the subtyping relation defined?
Regards, TSa.
--
cursive use of roles in their own definition produce F-bounds?
role A does Gen[A] {...}
or perhaps
role A where A.does(Gen[A]) {...}
Regards, TSa.
--
relax this
to allow juxtaposition of types to act like an "and" junction:"
The following example also makes it clear that a joined interface
is meant. So I think a where clause it not needed.
Regards, TSa.
--
HaloO,
I wrote:
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
Is the A&B form a legal alternative for the juxtaposition?
--
pares
the narrowness of types of the competing targets at that position.
But what information is recorded on the score cards and how is
that finally used in selecting the dispatch target?
Regards, TSa.
--
s ::?CLASS
{
has Int $.x;
has Int $.y;
method equal( ::?CLASS GenEqual: ::?CLASS $p --> Bool )
{
return call($p) and self.x == $p.x and self.y == $p.y;
}
}
Regards, TSa.
--
is a kind of pseudo-inheritance.
Regards, TSa.
--
ions (and), (or) and (not).
Well, and of course (^) and (xor) corresponding to ^^ and
xor. They all form nice mnemonics for each other.
Regards, TSa.
--
he above example is a good case for introducing the subtype
relation operator <: because we have aabb <: ab <: Str but do we
also have aabb.does(ab) and ab.does(Str)? Could we also state that
aabb (<) ab (<) Str?
Regards, TSa.
--
# M1
:(Animal;; Dog) # M2
0: QS={M1,M2} VS={M1,M2}
1: QS={M1}VS={M1,M2}
2: QS={M1}VS={M1}
This dispatches to M1.
Note that the purpose of the VS is to disqualify other
methods. Only the methods in QS remain contenders.
Regards, TSa.
--
pe
analysis be helpful here?
Regards, TSa.
--
on and is built from subtypes. For a rw parameter only exact
type match at A is type safe.
Regards, TSa.
--
101 - 200 of 657 matches
Mail list logo
