Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful

[TSa (Thomas Sandlaß)]

On Tuesday, 9. November 2010 01:45:52 Mason Kramer wrote:
> I have to disagree here.  Arrays and Hashes may be about storage (I don't
> think they are, though, since you can change the (storage) implemenation of
> an Array or Hash via its metaclass and it can still remain an Array or
> Hash).

What I mean with storage is that you put some data into a numbered slot
in an array and a keyed slot into a hash. With the same index or key you
can retrieve your data at any time. This is the case irrespective of the
underlying implementation. A set is not about storage in this sense, because
there is no way of retrieving an element. The only operation is a membership
test which is of boolean nature like number comparison.


> The most important part of the @ sigil, and the reason I preferred it over
> $, is that @ "flattens" (moritz++'s word), when used in a list context such
> as for @blah,
> map {...}, @blah.

I wonder if it is not possible to bind flattening to Iterable. This of course
has the drawback that it is not syntactically distinguished. But doesn't

   my $x = (1,2,3);
   my $y = map {$^x * $^x}, $x;

result in $y containing the list (1,4,9)? And if $x happens to be a scalar
isn't it just squared? In the end we just need &map:( &closure, Set $data --> 
Set) as an overload. Or perhaps &map:( &closure, Iterable ::T $data --> T).


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: Bag / Set ideas - making them substitutable for Arrays makes them more useful

[TSa (Thomas Sandlaß)]

On Monday, 8. November 2010 17:20:43 Jon Lang wrote:
> Solomon Foster wrote:
> > Well, hyperoperators work fine on Hashes, they operate on the values,
> > paired up by key if needed.  (That is, %hash>>++ doesn't care about
> > the keys, %hash1 >>+<< %hash2 sums based on keys.)  I would assume
> > that Bag should work in the exact same way.  Dunno how Set should work
> > in this context, though.
>
> I would hope that Bags would not work the same way.  If they do, then
> you get things like:
>
> Bag(1, 3, 2, 1) >>+<< Bag(2, 3, 1, 2) # same as Bag(1, 1, 1, 2, 2, 2,
> 3, 3)

Hyper-plus is not Bag-union. If there is a result at all I would expect
Bag(2, 6, 4, 2) because for every element in order on the left there
exists the same element on the right and vice versa. The four results
of addition are collected into a new Bag. But this fails in other cases:
Bag(1,2,3) >>+<< (Bag(4,5,6) has at least the same number of elemnts on
both sides but an undefined pairing.

The proper set operators are either some Unicode characters or IIRC an
operator with parens:

   Bag(1, 3, 2, 1) (+) Bag(2, 3, 1, 2)

or better (&).

I'm generally very happy with the choice of sigil for Sets and Bags
because this is what they are: scalars as far as storage is concerned.
More important is to have the right set of operators that automatically
imply Bags:  (1,2,3,4) (&) (2,3) === Bag(1,2,2,3,3,4).

Arrays and Hashes are about storage. In the abstract the memory of a computer
is one big array! Sets and Bags are about operations on them like the numeric
operations are on numbers or the string operators on strings. So it is very
important to keep the domains nicely separated by means of disjoint operators.
This is why we have ~ for concatenation and not overloaded +.

It makes of course sense to iterate a Bag. But indexing it doesn't. We are
also not indexing into strings: "blah"[2] is not 'a'.


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: Smart match isn't on Bool

[TSa (Thomas Sandlaß)]

HaloO,

On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
> On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington  
wrote:
> > No, given-when is smart-matching. The RHS of a smart-match decides what
> > happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going
> > to do +True and thus match.
>
> OK, but what about 0 ~~ True?  That's what started this thread,
> extricated from the complicating trappings of given/when.  Right now,
> (anything ~~ True) is true, and IMHO that's a misfeature; it's at
> least surprising.  I'd expect (anything ~~ True) to be synonymous with
> ?(anything): true only if the LHS boolifies to true. By the same
> token, (anything ~~ False) would be synonymous with !?(anything).

Note also that ($anything ~~ foo()) just throws away $anything. I would
opt for a regularization of the smart match table. First of all the
generic scalar rule should coerce the LHS to the type of the RHS and
then use === on them. This is how the Any ~~ Set case is specced. The
cases Stringy and Numeric fall out naturally from this definition. The
Bool case should become a special case just like Stringy and Numeric. The
auto-invocation of Callable is a good thing but the fact that the return
value is not subject to the generic scalar case is a misfeature. That is
we loose:

   given 42
   {
  when foo() {...}
  when bar() {...}
  when baz() {...}
   }

which could mean to execute that block whose controlling sub complies
with the given and not the one that returns True first. Note that this
style is particularly usefull with given True. But then we sort of have
the coercing the wrong way around because the idea is to check the
return value in boolean context not coercing the True to whatever the
type of the return value is. BTW, how is the case with a unary sub written?


Could someone please give a rational for the interspersing technique

   given $anything
   {
  when $one {...}
  when two() {...}
  when $three {...}
   }

where two() returning a true value prevents the case $three. And if it
is considered usefull I support the whenever proposal because different
things should look different. BTW, would

   given $anything
   {
   when $one {...}
   if two() {...}
   else { when $three {...} }
   }

still smart match $anything with $three? Or is the topic the return
value of two() at that point?


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: Smart match isn't on Bool

[TSa (Thomas Sandlaß)]

HaloO,

On Saturday, 31. July 2010 20:47:49 Patrick R. Michaud wrote:
> On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
> > It's not unreasonable, especially if that's what you expect.
> > But it's even more reasonable to expect this to work:
> > given $something {
> > when True { say "That's the truth!" }
> > when 42 { say "Good answer!" }
> > when "viaduct" { say "You guessed the secret word!" }
> > }
>
> I'm not so sure about this.  There's an argument to be made that
> the C and C cases should never be reachable,
> since both C<42> and C<"viaduct"> are considered "true" values...

Sorry, I don't understand this possible argument. Isn't the intent
of a given/when to select one alternative by means of the given?
This is what a switch statement does. Perl 6 allows non-constants
after when, so it's reasonable to have the constant in the given
and to see e.g. which function returns it. Of course the first actually
doing this determines the switch.


> ... unless you want C to do a value-and-type check,
> in which case it doesn't exactly follow the pattern for smartmatching
> of the other builtin types (which only check value equivalence,
> not type equivalence).

This is true only if you want to distinguish 1 and True which are the
same value. But 42 should be distinct from this. Same goes for "viaduct".
So these three should be a valid disjoint set of choices that can be
made given $something.


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: Smart match isn't on Bool

[TSa (Thomas Sandlaß)]

HaloO,

On Saturday, 31. July 2010 18:56:47 David Green wrote:
> On 2010-07-31, at 1:33 am, Moritz Lenz wrote:
> > sub test() { True };
> > given 0 { when test() { say "OH NOEZ" } }
> > I don't think it's unreasonable to expect the output to be "OH NOEZ".

How does this relate the given to the when? If I get you right the
given is completely ignored and the truth of test() gives "OH NOEZ".
I think the given must determine the result.

> It's not unreasonable, especially if that's what you expect.  But it's even
> more reasonable to expect this to work: given $something {
>   when True { say "That's the truth!" }
>   when 42 { say "Good answer!" }
>   when "viaduct" { say "You guessed the secret word!" }
>   }

Here I expect the $something to *select* one of the alternatives.
It can't be that a literal True ignores the given and just executes
the block.


> In both these examples, the intent is fairly clear from the context.  It's
> easier to forget that Bools behave differently from other types when you
> only have some variable that could be any type: if $guess ~~ $answer { say
> "Correct!" }  # hope your question wasn't T/F!
>
> Maybe we can't please everyone, but we can at least try not to displease
> anyone.  Perl is awfully clever at keeping your eaten ponies, and there is
> a way we can have both the "helpful" syntax and the "consistent" one:
>
>   given $who-knows-what {
>   when True { say "It's a true thing!" }
>   when 42 { say "It's numbery!" }
>   whenever timeout() { say "Who cares what you say, time's up!" }
>   whenever $override { say "Whatever, switching to automatic 
> override" }
>   }

Am I getting your intention to be that when honors the given and whenever just
checks truth? Couldn't we use if for this? That would avoid the new keyword.

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: Suggested magic for "a" .. "b"

[TSa (Thomas Sandlaß)]

On Wednesday, 28. July 2010 05:12:52 Michael Zedeler wrote:
> Writing ($a .. $b).reverse doesn't make any sense if the result were a
> new Range, since Ranges should then only be used for inclusion tests (so
> swapping endpoints doesn't have any meaningful interpretation), but
> applying .reverse could result in a coercion to Sequence.

Swapping the endpoints could mean swapping inside test to outside
test. The only thing that is needed is to swap from && to ||:

   $a .. $b   # means  $a <= $_ && $_ <= $b  if $a < $b
   $b .. $a   # means  $b <= $_ || $_ <= $a  if $a < $b

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: Type system for Perl 6

[TSa (Thomas Sandlaß)]

HaloO Mr Castagna,

On Friday, 5. February 2010 23:13:25 you wrote:
> Actually I noticed an old post you did on this list 5 years ago. It
> contained the following drawing

Yeah it's a long time. And I've sort of lost interest in type theory.
But then I tried to persuade the list of a sophisticated type system.
But since I couldn't hack it myself nothing has happend. And Audrey
Tang is gone. He/She was a big fan of a type system as well and hacking
Pugs in Haskell.

>
>   A|B lub (lowest upper bound)
>  /   \
> / \
>A   0   B
>   / \ / \
>  /   \   /   \
> / A&B \   glb (greatest lower bound)
>/  1  /   \  2  \
>   / /  3  \ \
>
> and it is the only reference I found to intersection types (since A&B is
> the intersection of A and B (if you consider a class type as the set of all
> its instances) that is it contains all objects that are instance both of A
> and of B.
>
> Is this notation (or the general idea of intersection types) has been
> abandoned since then (I was not able to find it in the synopsis)

Yes, Larry never liked the idea of a type lattice and intermediate types
like A|B or A&B. The syntax is now used to simply mean doing A or B.

I've also proposed to have a constraint language in the where clause of
subset declarations that is usable for type checking. But the where clause
is now only a closure that is called when needed. So { $_ < 10 } is not a
subtype of { $_ < 20 }. So no predicate dispatch either.

Someone should explain the dispatch algorithm to you. I don't remember
exactly how the voting there works. This would explain what type narrowness
in the spec means.


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: Type system for Perl 6

[TSa (Thomas Sandlaß)]

HaloO Mr Castagna

On Friday, 5. February 2010 16:43:26 you wrote:
> I see I'm going out of the scope of this list. I apologize for spamming,
> but please continue to post here or send me by PM every information about
> Perls 6 types.

I'm delighted to have you interested in Perl 6. I know your book and
articles and have argued for a type system of Perl 6 here on the list
for quite a while. Unfortunately I'm not able to implement one for
Parrot or so. But if you are willing to port the CDuce code this is
a great thing!

There is no formally defined subtype relation or rules for subsumption.
A type is called narrower without details what that means. And the
odering in dispatch is not a type lattice as in Cecil but a topological
ordering. Again I've no clue what that means. It is possible for one
role to do another as in

   role A does B {...}

and all objects that do A are also B doers. So one could infer that we
have A <: B. But note that this subtype relation is not enforced in the
body of the role or in the class it is composed into. The spec says nothing
about class inheritance and type narrowness. Parametric roles are covariant
on their type parameter irrespective of its use. E.g. you can declare a
read/write attribute of that type.


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: How does List.map: { .say } work?

[TSa (Thomas Sandlaß)]

HaloO,

On Tuesday, 3. November 2009 17:13:22 Carl Mäsak wrote:
> That would make statement modifier for loops less useful. For those,
> there's nowhere to put the lambda arrow.
>
>   ++$_ for @things;

I think this is resolved with the is ref binding which
implies that the thingy that is bound to $_ is a cell
accessor of an array that provides a STORE method.

BTW, the situation of STORE and FETCH methods in classes
is kind of funny. While an object is stored in a container
the respective methods of the container are called. Only
in an is ref binding assignment affects the object directly.
That is, in the scope of the binding the object goes kind of
naked.

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: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)

[TSa (Thomas Sandlaß)]

HaloO,

On Friday, 23. October 2009 02:27:00 Darren Duncan wrote:
> Thinking further, my interpretation of what you said above is that the
> Rational role is now basically saying that a number is represented in terms
> of numerator/denominator and that certain operators are supported, but now
> it is sounding like the details of whether the operators will produce
> Rational results or Num results is now determinable on a per-class basis,
> so we may end up working with types like "Rat32", "Rat64", "BigRat" (just
> this one being unlimited precision), etc after all.

I believe that the thing people that don't care about the precision
should use in sigs and variable declarations is the Rat role. That is
I think that Rat should be the role that is currently named Rational.
More specific instantiations of that role are then written in my proposed
type signature invocant slot syntax as Rat[Rat64:]. Note that this is
no problem because e.g. 'my Rat $x = 3/4' doesn't require Rat to be an
instantiable class. Actually the class that implements Rat is chosen
by the compiler to be e.g. Rat64. Then there need to be installation time
defaults, command line switches and lexical pragmas to influence this
choice. The second thing that needs to be hookable to different classes
is the handling of overflow and underflow of e.g. Rat64 to either upgrade
to BigRat or wrap the offending value back into Rat64 or switch over
to Num. Then there is the problem of mixed precision cases etc.


> Presumably then with the Integer role we'll also have types like "Int32",
> "Int64", "BigInt" that do the role and also convert to a Num when their
> bounds are exceeded?
>
> Does that sound about right?

Yes. I think there should be an Int role and classes implementing it.
The Int role must be a subrole of Rat. E.g. it adds the bit manipulation
operators which are difficult to define for rationals if not outright
meaningless. This subroling is needed for calling Rat routines with an
Int, of course.

From a Huffman POV the roles for generic integers and rationals must be
short, so the Numeric and Rational roles in S32 are going in the wrong
direction.


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: role invocant slot in type sig (was: unusual invocants)

[TSa (Thomas Sandlaß)]

HaloO,

On Thursday, 22. October 2009 20:58:15 I wrote:
> The class Dogwood however might be written as
>
>class Dogwood does Dog[Dogwood:] does Wood[Dogwood:]
>{
>method Dog {...}
>method Wood {...}
>method bark {...}
>}

On #perl there was the question if any type could be put
into the brackets, e.g. 'class C does B[A:]'. But this is
a semantic error like using a role in an is clause or a
class in a does clause. However I see this as a weakness
of my proposal. So we could actually use 'class Dogwood
does Dog:self does Wood:self' as alternative. This is
hopefully closer to the point.


> where the explicit invocant type prevents the creation of the
> subclass relations between Dogwood and Dog and Wood. So in an
> environment which requests plain Dog a Dogwood instance is only
> applicable after the call of the coercion routine which could
> setup things so that Dog::bark is dispatched to. Environments
> that want Dogwood::bark need to explicitly coerce Dogwood instances
> to Dog[Dogwood:] which actually is a no-op. But then other non-Dogwood
> Dog doers are excluded unless they have a Dogwood coercion routine.
> Or they use the Dogwood class directly.

While pondering the consequences of my proposal it occurred to me
that the use of a juxtaposed type Dog Wood should not mean Dog[Dog:]
Wood[Wood:]. That is each with its role as invocant, because this
would force an ambiguous type conversion on Dogwood. So I change the
proposal such that a juxtaposition means Dog[::T:] Wood[T] which
nicely gives the Dogwood implementation of bark as requested by the
two roles.


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: unusual invocants

[TSa (Thomas Sandlaß)]

HaloO,

On Sunday, 25. October 2009 01:38:21 Martin D Kealey wrote:
> Sounds like going back to static typing -- which does sometimes have some
> advantages.

Well, you can also consider it dynamic. The important point is
that it is a constraint on allowed types e.g. in the sig of a sub
or on a variable. In my proposal they are handled through conversion
on class level.


> One way to implement at would be to use proxy objects, which only do
> one of the roles (by passing them through to the appropriate methods on the
> original object).

Do I understand you right that you propose to have a Dogwood class
and two auxiliary proxy classes for the Dog and Wood roles? Isn't that
too much effort? OTOH, a conversion routine could indeed return such
a proxy if the original shall be kept unchanged.


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

role invocant slot in type sig (was: unusual invocants)

[TSa (Thomas Sandlaß)]

HaloO,

On Thursday, 22. October 2009 18:31:16 I wrote:
> The invocant slot of the role signature is sort of implied in the spec
> already! I also like this because a type in Perl 6 is then always
> written as SomeRole[SomeClass:]. Classes without explicit roles are
> Any[SomeClass:] and untyped is Any[Object:]. Note that a class C doing
> multiple roles spawns several types R1[C:], R2[C:], etc and the class
> name is a short form of their juxtaposition.

Here is an improvement of the concept that also allows to settle the
Dogwood case in the Dogwood class. The change is that plain Foo does
not mean Foo[Object:] but denotes the F-bound fixpoint type Foo[Foo:].
A class Bar doing Foo still creates the type Foo[Bar:] but also enters
the subclass relation between Bar and Foo so that Foo[Bar:] <: Foo[Foo:]
makes Bar instances applicable where Foo is required.

The class Dogwood however might be written as

   class Dogwood does Dog[Dogwood:] does Wood[Dogwood:]
   {
   method Dog {...}
   method Wood {...}
   method bark {...}
   }

where the explicit invocant type prevents the creation of the
subclass relations between Dogwood and Dog and Wood. So in an
environment which requests plain Dog a Dogwood instance is only
applicable after the call of the coercion routine which could
setup things so that Dog::bark is dispatched to. Environments
that want Dogwood::bark need to explicitly coerce Dogwood instances
to Dog[Dogwood:] which actually is a no-op. But then other non-Dogwood
Dog doers are excluded unless they have a Dogwood coercion routine.
Or they use the Dogwood class directly.


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: unusual invocants

[TSa (Thomas Sandlaß)]

HaloO,

On Wednesday, 21. October 2009 12:40:06 Mark J. Reed wrote:
> Rather than disallow the composition, I'd say that any class, role, or
> object that does both roles must override the method in question.

The problem that Ovid posed needs to be resolved in the dispatch
tables seen in certain methods of a class. So the solution is not
overriding the offending method x but the calls to it in methods
foo and bar! The interesting thing is that you have to dig that
information out from the source of the roles T1 and T2. I doubt
that a programmer making the dependency mistake also documents it ;)
I've never seen a call graph of a library in any documentation.


> Which takes us back to Jon's branch of the thread: it would be nice to
> be able to declare such an override in a general way that will apply
> to any such composition that doesn't otherwise override it locally.
> But what should that declaration look like?

Here is a direct syntax for the freeze feature of the paper:

  class C does T1 does T2
  {
  freeze T1::x for foo;
  freeze T2::x for bar;
  method x {...} # for all other methods
  }

The implementation is strait forward: on entry to foo and bar
the dispatch table of the invocant is temporarily patched to
contain the right x. After the call the original is restored.

Heretic question: would it make sense to have a method registry
for roles in CPAN? At least for a set of 'standard' modules that
then allow arbitrary role combinations without conflict.


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: unusual invocants

[TSa (Thomas Sandlaß)]

HaloO,

On Tuesday, 20. October 2009 18:35:36 David Green wrote:
> >> So what the OP wants to do is declare a method that is available on
> >> all those invocants - and only those invocatnts - which do all of
> >> roles X, Y, and Z.  Granted, you can declare a new role XandYandZ
> >> that does X, Y, and Z, and define the method there, but that won't
> >> work on $foo unless you declare explicitly  '$foo does
> >> XandYandZ' .  The goal is to have the method show up no matter how
> >> $foo comes to do all three roles.
>
> Right.

I have difficulty seeing the need for a method here. The distinguishing
feature of a method is the access to the private data of an object that
can hardly be granted by doing the three roles X, Y and Z. After all
there's no unique implementation of these roles!

Perl 6 is a hybrid language as far as dispatch is concerned. There is
the class based method dispatch that I call slot dispatch because the
usual implementation is to have the objects carry a ref to a slot table.
The other dispatch is the type based MMD. Unfortunately this also
goes by the name of method. This is because other languages use classes
as types and conflate the two dispatch regimes that Perl 6 clearly
separates. There used to be fail-over from class dispatch to MMD but
this didn't work---even though I forgot what the exact problems were ;)

So in the end the only problem is that the calling conventions of
$object.method versus method($object) are not interchangeable. But
it makes the priority clear. In the $object.method case the object
is the primary concept. We think of it as the object doing something.
In many cases to its own state. In the method($object) case the method
is the primary concept. The object influences how it is done or what
is the output. The method can of course call mutating methods on the
object but this is a secondary concern.


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: Freezing role methods

[TSa (Thomas Sandlaß)]

HaloO,

On Wednesday, 14. October 2009 12:18:30 Ovid wrote:
> You *could* (this wasn't explained in the paper) extract those
> methods into C::x(), check your callers and dispatch as appropriate, but
> that would get very problematic, particularly with roles composed of other
> roles.

I consider the dependence of T1 and T2 on their respective public
method implementation a design flaw of these methods. They should
each have a private service routine that in turn is called by the
public x method. But here is how this can be worked around in C:

  role T1
  {
 method foo { self.x }
 method x { say "T1" }
  }
  role T2
  {
 method bar { self.x }
 method x { say "T2" }
  }
  class C does T1 does T2
  {
 enum Source 
 has Source $!source = other;

 method foo { self!source = from_foo; T1::foo }
 method bar { self!source = from_bar; T2::bar }
 method x
 {
given self!source
{
   when from_foo { T1::x; self!source = other }
   when from_bar { T2::x; self!source = other }
   default { say "C" }
}
 }
   }

I admit that this is clumsy. So we need an automatic procedure
and some nice syntax. But it looks to me as code analysis of T1
and T2 is needed to generate the wrappers in C.

One point I don't like in the paper is that freezing methods
can be used to erase methods from a role. This is diametrically
opposed to the intent of roles to make a guaranty to provide
an interface.


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: Synopsis 02: Range objects

[TSa (Thomas Sandlaß)]

On Thursday, 27. August 2009 23:58:51 Jon Lang wrote:
> It might also be nice to have a stringifying version; perhaps 'be',
> using the same "everything's an acronym" naming convention used by
> other stringifying operators (e.g., 'lt' is "less than", 'le' is 'less
> than or equal to', 'leg' is "less than, equal to, greater than") - in
> this case, 'be' would be 'beginning to end'.  At the very least, this
> would avoid the inevitable questions about why there isn't a
> stringifying version. :)  That said, it may not be good for much more
> than that.

Yeah, sometimes orthogonality of features is too much of a good thing!


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: On Sets (Was: Re: On Junctions)

[TSa (Thomas Sandlaß)]

HaloO,

On Friday, 27. March 2009 12:57:49 Daniel Ruoso wrote:
> 1 - multi infix:<+>(Set $set, Num $a)
> This would return another set, with each value of $set summed with $a.

I think that this mixed case should numify the set to
the number of elements to comply with array semantics.
infix:<+> should remain a numeric operator and numify
other operant types. This operator orientation is a
strong feature of Perl 6 and should not be diluted by
overloads with non-numeric meanings.


> 2 - multi infix:<+>(Set $a, Set $b)
> This would return another set, with $a.values X+ $b.values, already
> removing duplicated values, as expected from a set.

Even the homogeneous case should adhere to numeric semantics.
Set operations are with parens. So disjoint union creation
is (+). We could try to get a meta parens so that (X+) is
conceivably auto-generated. OTOH it collides with (+) visually.


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: Logo considerations

[TSa (Thomas Sandlaß)]

On Tuesday, 24. March 2009 05:47:12 Darren Duncan wrote:
> If you're going for sciencey or mathey illustrations, then I think its
> important to include something that speaks quantum physics in there, since
> quantum superpositions aka Junctions are one of the big central user
> features that Perl 6 provides which is relatively new to languages in
> general.

The concept of superimposed shapes is very well done in the Trisquirclehedron.
See http://lucacardelli.name/Topics/TheoryOfObjects/ObjectSubject.html

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: a junction or not

[TSa (Thomas Sandlaß)]

HaloO,

On Tuesday, 17. March 2009 10:25:27 David Green wrote:
> > That is, it would return a Junction of Str, not a Str.  So the
> > question is how to get something that returns an expression to the
> > effect of:
> > 'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
>
> say $choice.perl
>
> ...which will ultimately call (junction-of-.perl's).Str, and
> Str(Junction:) is what produces the "any(XXX)" string.  [Unless it
> ends up being implemented some other way, of course!]

Note that this contradicts Larry's statement that .perl
autothreads. I think it can't autothread because we expect
it to put the junction constructor in front of the values
or the right operator as infix. So .perl is junction aware!
But it threads the .perl method through the eigenstates,
of course.


> > The other question is: given $choice as defined above, how do I find
> > out which type of junction it is?
>
> I guess really Junctions need two public methods: .eigenstates for the
> values, and, er, .eigenop(?!) to return how they're joined -- I'm
> thinking it would return a code ref, i.e. &any, &all, etc.

A simple solution is to have subtypes of Junction like AnyJunction,
AllJunction, OneJunction and NoneJunction or perhaps like Junction::Any,
Junction::All, Junction::One and Junction::None.


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: Range and continuous intervals

[TSa (Thomas Sandlaß)]

On Friday, 27. February 2009 07:42:17 Darren Duncan wrote:
> I was thinking that Perl 6 ought to have a generic interval type that is
> conceptually like Range, in that it is defined using a pair of values of an
> ordered type and includes all the values between those, but unlike Range
> that type is not expected to have discrete consecutive values that can be
> iterated over.

Hmm, it might not be a bad idea to make Interval a subtype of Range
and allow for iteration if that is requested. This allows an Interval
where Range is expected.

The benefit of a dedicated Interval type comes from supporting set
operations (&), (|) etc. which are still unmentioned in S03. BTW,
what does (1..^5).max return? I think it should be 4 because this
is the last value in the Range. Only in 4.7 ~~ 1..^5 does the five
matter. How does ~~ retrieve that information? For open intervals
the .min and .max methods should return the bound outside. Or better,
we should introduce infimum and supremum as .inf and .sup respectively.


> I'm thinking of a Range-alike that one could use with Rat|Num or Instant
> etc, and not just Int etc.  There would be operators to test membership of
> a value in the interval, and set-like operators to compare or combine
> intervals, such as is_inside, is_subset, is_overlap, union, intersection,
> etc.  Such an interval would be what you use for inexact matching and would
> be the result of a ± infix operator or % postfix operator.  Also, as Range
> has a .. constructor, this other type should have something.

Since the Interval type shall be an addition to the Set subsystem I
propose the (..) Interval creation operator together with the open
versions. Admittedly that leaves (^..^) at a lengthy six chars. But
Jon's proposal of setting the by to zero isn't any shorter. Note that
the open versions are more important for Interval than they are for Range
because for Range you can always write it without ^ at the ends.


> Barring a better name coming along, I suggest calling the type "Interval",
> and it would be immutable.

The only other name that comes to mind is RangeSet. But I prefer Interval
because this is the name of the concept in math.


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: Comparing inexact values (was "Re: Temporal changes")

[TSa (Thomas Sandlaß)]

On Tuesday, 24. February 2009 17:59:31 Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
> $x ~~ $y within $epsilon

This is a pretty add-on to smartmatch but I still think
we are wasting a valueable slot in the smartmatch table
by making numeric $x ~~ $y simply mean $x == $y. What
is the benefit?


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: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[TSa (Thomas Sandlaß)]

On Tuesday, 24. February 2009 07:30:05 Carl Mäsak wrote:
> >    my $foo is limited(100..200);
> >    $foo = 5;                       # really does $foo = 100
>
> Sounds like a good idea for a CPAN module. You can already do
> something similar with the subset keyword, though:
>
>  subset Percentage of Int where { 0 <= $^perc <= 100 };
>
>  sub set_percentage(Percentage $perc is rw, Int $value) {
>try {
>  return $perc = $value;
>  CATCH {
>return $perc = 0 if $value < 0;
>return $perc = 100
>  }
>}
>  };
>
>  my Percentage $p;
>  say set_percentage($p, 50);
>  say set_percentage($p, 101)

I would use a parametric role to implement that:

   role Limited[Order ::Type, Order $lower, Order $upper]
   {
  multi sub infix:<=> (Limited $lhs is rw, Type $rhs --> Type)
  {
 if $rhs before $lower { $lhs.STORE($lower) }
 elsif $rhs after $upper { $lhs.STORE($upper) }
 else { $lhs.STORE($rhs) }
 return $rhs; # provide original for outer scope
  }
   }

   my Limited[Int,0,100] $p;

   $p = 50; # assigns 50
   $p = 101; # assigns 100

This is an interesting example of a role that can be instanciated
without a class unless one regards the generated multi target an
instance of a code class. I used STORE to avoid an infinite recursion
in dispatch of infix:<=>. I could also have called infix:<=>:(Type is rw,
Type --> Type) explicitly. This is necessary if it is overloaded as
well.

I'm unsure if parametric roles work like that, especially the use of
Limited inside the sub.

This role should be an easy candidate for inline expansion by the
compiler. Also the 'is rw' on the first parameter enforces an exact
match so there's no need for dynamic dispatch. I assume that an
'is rw' actually dispatches on the declared container type of the
lhs.


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: References to parts of declared packages

[TSa (Thomas Sandlaß)]

On Friday, 13. February 2009 20:30:24 Larry Wall wrote:
> While taking a shower I refined the design somewhat in my head,
> thinking about the ambiguities in package names when you're redefining.
> By my previous message, it's not clear whether the intent of
>
> multi package Foo::Bar {...}
>
> is to overload an existing package Foo::Bar in some namespace that
> we search for packages, or to be the prototype of a new Foo::Bar
> in the current package.  In the former case, we should complain if
> an existing name is not found, but in the latter case we shouldn't.
> So those cases must be differentiated.

Sorry, you lost me. I thought that classes are for implementation
and therefore need to allow re-definition in the sense of open classes.
But aren't packages/modules just for holding names? As such they always
make sure that there is exactly one entity in the scope with a unique
name?

So I would advocate a clear split between the functionality of packages
on the one hand and the implementation orientated classes, roles and
subs on the other. The latter have dispatch and overwriting, the former
are just for uniqueness of names. I know that the current design involves
dispatch to packages but I think that blurs the distinction between
packages and classes. If they are all the same anyway then why have the
module, package and class keywords? This is a bit too much redundancy for
me.


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: returning one or several values from a routine

[TSa (Thomas Sandlaß)]

On Tuesday, 6. January 2009 22:01:36 Jon Lang wrote:
>   item($x) # Dwimmey use of item context.

IIRC this is the same as $$x, right? Or does that
extract the invocant slot without dwimmery?

>   list($x) # Dwimmey use of list context.
>   hash($x) # Dwimmey use of hash context.
>   $x._ # the Capture object's invocant, as an item.

How about $x.() here? That looks symmetric to the other
postfix operators and should be regarded as a method
dispatched on the invocant or some such.

>   $x.[] # the Capture object's positional parameters, as a list.
>   $x.{} # the Capture object's named parameters, as a hash.


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: Smooth numeric upgrades?

[TSa (Thomas Sandlaß)]

HaloO,

On Sunday, 5. October 2008 04:23:42 Darren Duncan wrote:
> Note that just as integers are naturally radix independent, the unlimited
> rationals should be too, and the latter can compactly represent all
> rationals as a triple of integers corresponding roughly to a (normalized)
> [mantissa, radix, exponent] triple; with that approach you also get 
> unlimited floats for free, so no reason to make floats an exception where
> they aren't unlimited where integers and other rationals are; after all,
> what is a float or scientific notation than just another notation for a
> rational value literal.

I want to stress this last point. We have the three types Int, Rat and Num.
What exactly is the purpose of Num? The IEEE formats will be handled
by num64 and the like. Is it just there for holding properties? Or does
it do some more advanced numeric stuff?

Another matter is how to represent irrationals. With IEEE floats which are
basically non-uniformly spaced integers imprecession is involved anyway.
But sqrt(2) is a ratio of two infinite integers. How is that handled? Here
I see a way for Num to shine as a type that also involves lazy approximations.
But then we need a way for the programmer to specify how these approximations
shall be handled. 


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: [svn:perl6-synopsis] r14585 - doc/trunk/design/syn

[TSa (Thomas Sandlaß)]

On Wednesday, 1. October 2008 21:54:12 [EMAIL PROTECTED] wrote:
>  If you apply an assignment operator to a protoobject, it is assumed that
>  you are implementing some kind of notional "reduction" to an accumulator
> -variable.  To that end, the base operator is dropped and a simple
> -assignment is done instead.  Hence you may correctly write:
> +variable.  To that end, the operation is defined in terms
> +of the corresponding reduction operator, where the protoobject
> +becomes the operator's identify value.  So if you say:
> +
> +$x -= 1;
> +
> +it is more or less equivalent to:
> +
> +$x = [-]() unless defined $x;# 0 for [-]()
> +$x = $x - 1;
> +
> +and $x ends up with -1 in it, as expected.

Can't we have that as a general feature of all operators?
That is:

   my ($x, $y);

   say $x * $y; # prints 1
   say $x + $y; # prints 0

It is a cleaver idea to make the operator choose an appropriate
value for a Nothing value. Why having that only for meta operators?


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: How to define a new value type?

[TSa (Thomas Sandlaß)]

On Sunday, 14. September 2008 16:08:19 Patrick R. Michaud wrote:
> So, how does one get an object to pretend to be a value type for
> purposes of assignment?

I think a straight forward approach is to overload the
assignment operator on the actual types of the lhs and
rhs. The dispatch target than clones the value to be stored
in the lhs container after being checked against the
container's constraint.

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: What happened to "err" operator?

[TSa (Thomas Sandlaß)]

HaloO,

On Thursday, 4. September 2008 03:39:20 Larry Wall wrote:
> Another potential issue is that CATCH doesn't distinguish exceptions
> coming from the current block from those coming from the subcall to a().
> So it could end up returning Failure from the current block when
> you intended to force return of Failure from a().  Not sure what
> to do about that...

I don't understand this issue. I think we have the fact that
*every* operator is at least conceptually dispatched and as
such everything in a block is at least one level down in the
call chain just as a() as a sub call is. This is why a CATCH
block inside the block is so natural to me.

If I understand your intention correctly you want to be able
to force a thrown exception from a() into a returned value
and proceed where this return value is supposed to show up
in the current block, right? The simplest solution that comes
to my mind is some form of goto to that position. Or is that
too inelegant? The point is how the CATCH block knows from
which subordinate scope the exception originates.

   a() proceed: orelse b();
   CATCH
   {
  ... # make $! into return value
  goto proceed;
   }

This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?


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: arrayref/hashref in spectest suite

[TSa (Thomas Sandlaß)]

On Monday, 18. August 2008 20:38:05 Patrick R. Michaud wrote:
> I would somewhat expect
> a reference to be instead handled using a statement like
>
> $foo[1] := $bar;
>
> Comments and clarifications appreciated.

I would also opt for copy semantics whenever = is used
for assignment. But it seems to be the case that this
is not deep, just like captures are only one level deep
readonly. So, I would also expect $foo[1] = \$bar to
result in 24.


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: Allowing '-' in identifiers: what's the motivation?

[TSa (Thomas Sandlaß)]

On Monday, 11. August 2008 05:35:03 John M. Dlugosz wrote:
> E.g. see  :
>
> sub bar {
>  return 100;
> }
> sub foo { 50;}
> sub foo-bar {
>return  rand(50);
>}
> if (foo - bar != foo-bar) {
>print "Haha!\n";
> }

Actually I can even imagine allowing almost all chars
in the middle of identifiers. The price is that *all*
infix operators need spaces. This seems to be the trend
right now. See e.g. the disambiguation of meta reduce
and array constructors or adverbs versus nouns in the
call syntax.

So, how simple would a tokenizer become when whitespace
separates almost all tokens? Noteable exceptions would be
the pre- and postfix operators.


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: Some details of function return captures

[TSa (Thomas Sandlaß)]

HaloO,

On Saturday, 9. August 2008 01:32:35 John M. Dlugosz wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
> > If such a ReturnCapture could also be
> > preliminary of some kind, then lvalue subs could be lazily resumed when
> > the rvalue comes in.
>
> Can you elaborate on that?  I don't follow.

The fundamental problem with lvalue methods is that some
of them want to have control *after* they returned
their value. One ugly way to achieve this is how it is
usually done in C++ or Java: the rvalue is a parameter
of the method. So instead of

$obj.foo(1,2) = 3; #1

one writes

$obj.foo(1,2,3); #2

which doesn't look like an lvalue method at all. And you can't
use it in rvalue context as the former:

my $x = $obj.foo(1,2); #3

Here the ReturnCapture collapses right away. But in #1 it could
be resumed with rvalue 3. That is the invocation of .foo(1,2)
resumes after the statement that produced the ReturnCapture.
In the assignable mutators thread I proposed to call that
statement 'yield'. To the function it behaves like the declaration
of a variable that receives the value that is assigned later.
To the outside it is the preliminary rvalue. If no assignment
takes place no resumption is made. The new thing here is that
one needs to write

my $x = |$obj.foo(1,2); #4

to keep the ReturnCapture, and call it later either explicitly

$x.resume(3);

or implicitly

$x = 3;


Hope that helps, 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: Differential Subscripts

[TSa (Thomas Sandlaß)]

On Saturday, 9. August 2008 04:41:46 John M. Dlugosz wrote:
> Is this magic known to the parser at a low level, or is it possible to
> define your own postcircumfix operators that interact with the
> interpretation of the argument?

My interpretation is that there is a Whatever type that
most of the time behaves like Int. So to handle it, you
define postcircumfix:<[ ]>:(Whatever $slice) or so. The
interesting question is what plain * returns because that
is destined to mean the full slice. IMHO, this should be
written ^*, which if the array becomes known becomes
[EMAIL PROTECTED]


> Is it possible to write:
>   @i = (1, 3, *-1);
>   say @data[$i];
> and get the same meaning as
>   say @data[1, 3, *-1]?

I hope so. The type of the slice is Seq[Int,Int,Whatever].


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

meta_postfix:<*>

[TSa (Thomas Sandlaß)]

HaloO,

I know that the hot phase of the operator discussions are over.
But here's a little orthogonalizing idea from my side. The observation
is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5
and ** as repeated multiplication. Now imagine having a meta_postfix:<*>
that gives +* as multiplication (perhaps abbreviated as *) and ** as
(integer) exponentiation. We can then continue with replication as ~*
for strings and ,* for lists thus freeing x and xx as some generic
multiplication operators.

The meta * also is useful e.g. as (1,2) Z* 3 === (1,1,1),(2,2,2). Also
when we apply it to unary postfix as well: $x++* 3 === $x++.++.++ which
is useful when $x is of some class with overloaded ++ where the single
steps are important. The meta postfix * could also be stacked and tetration
falls out naturally as ***.

With + as the default case for meta_postfix:<*> we win the advantage that
we have +* and * as multiplication operators with the latter being a special
form of the former. But for Vectors +* would automatically yield the scalar
multiplication infix:<+*>:(Vector,Num) when infix:<+>:(Vector,Vector) is
defined as expected.


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: Rakudo test miscellanea

[TSa (Thomas Sandlaß)]

HaloO,

On Thursday, 26. June 2008 18:46:25 Larry Wall wrote:
> Neither "is" nor "does" is quite right here, because the mathematicians
> have seen fit to confuse representation semantics with value semantics.  :)

Hmm, but the uppercase types should hide the representation type.
IOW, there's only one Int but int8 to int64 or so. Same with Num
and num32 to num128 and perhaps num8 and num16 in the OpenGL world.


> I think what we want is something more like
>
> Int as Rat
> Rat as Num
> Num as Complex

So, how does this auto-coercion interact with dispatch? And
how do these in turn interact with generic function/type
instanciation?

I imagine a first round of dispatch then some well defined
second attempt after "standard" coercions. Note that there
might be coercion conflicts if several paths of conversion
are available. Then we need some concept of "coercion distance"
that favors more direct paths over longer ones and less lossy
ones over lossier ones. The tricky part then becomes the interaction
of coercion with dispatch. E.g. if there is an Int arg and two
dispatch targets for Rat and Num and two conversions Int as Rat
(lossless) and Int as Num (lossy?).  

OTOH, I regard Complex as a structural type like e.g. Vector
or Matrix that is built on top of other numeric types. That is we
have Complex[Int] as the Gaussian Integers and Complex[Rat] and
Complex[Num] in the same coercive relations as the underlying Rat
and Num.


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: fallback semantics of list methods

[TSa (Thomas Sandlaß)]

HaloO,

On Saturday, 14. June 2008 18:43:05 Daniel Ruoso wrote:
> Moritz convinced me that there's actually no real reason to support
>
>   $nonlist.listmethod

I wouldn´t do that either. But I come to that conclusion from the
line of thought that it is generally a bad idea to block an Any
slot in a multi for a mere casting operation. The whole point of
type based dispatch is to name the intended type in the first place.
That is, a programmer choosing the item sigil $ in combination with
a list operation should be punished with a dispatch error if he doesn´t
know for sure that everything he sticks in the variable is a list
anyway. Note that the other way around is bloody easy in Perl 6. A
@ variable can handle items just fine!

I´m aware that this makes me opt for solution three, the dropping of
fallback from method to sub dispatch. But I consider that a good
thing. They are nicely distinct syntactically, so why mix them
semantically?


> And if we stop, and think for more two seconds, we realise that
> supporting that could end up having a lot of non-interesting side
> effects, because an exported sub with the signature :(Any, Str) is most
> likely to have a lot of false hits.

Technically there are no false hits on an Any slot ;)
In the case at hand it listifies the item and re-dispatches.
IOW, the false hits will be surprises for unaware programmers
who get unexpected dispatches silently.

BTW, there´s the same problem with stringification of the separator.
Combining that with  the listification would end up blocking &*join:(Any,Any)
globally.


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: constraint imperative programming (CIP)

[TSa (Thomas Sandlaß)]

HaloO,

On Monday, 16. June 2008 10:03:13 Ovid wrote:
> --- TSa <[EMAIL PROTECTED]> wrote:
> ... why do you think that
> > the way to get at the constraint programming paradigm are the subset
> > type definitions?
>
> Because I can't think of any other way to do it :)

So I´ll try to come up with some creative thoughts =8()


> Now it's my turn to say that I can't follow that statement.

I hope the asymmetry in standard Perl 6 ´$x = $y´ is obvious.
By contrast in constraint programming (CP) ala Oz translated to Perl 6
we have

   $x = $y; # 1
   42 = $y; # 2
   say $x;  # 3 (prints 42)

where line 1 just stores the equality of $x and $y in the constraint
store and goes ahead. Line 2 binds 42 to $y directly and by constraint
solving to $x as well. That is what I call symmetric and which causes
fundamental troubles in implanting CP into imperative Perl 6. Thanks, btw
for the ref to the Kaleidoscope paper, it always amazing how many languages
I haven´t heard about ;)

Now we need a way to express constraint enforcement---called CIP in the
paper. My idea is that it naturally belongs to the variable subsystem. I.e.
we need declarations that declare constraints between variables. My first
attempt is simply

sub move_vertical_line (Line $line, Event $event)
{
   constrain $start := $line.start.x, $end := $line.end.x to
   {
  always $start == $end; # constraint
  SOLVE # enforcer
  {
  $end = $start; # normal assignment through bound vars
  }
   }
   my Event $motion;
   while ($motion = get_next_event()) ~~ ButtonMotion
   {
  $line.start.x = $motion.x; # $line.end.x is enforced
   }
   if $motion ~~ ButtonUp  # last event application
   {
  $line.start.x = $motion.x; # $line.end.x is enforced
   }
}

This is the value constraint from the paper. I would call the other
types almost as in the paper: identity, type and structure constraints.
A type constraint comes closest to the subset type constraints that
are not enforced and hopefully side-effect free. So a global definition
might look like

   constrain PosInt of Int to
   {
  always $_ > 0;
  SOLVE { $_ = 1 }
   }

   my PosInt $x;

   $x = -17; # invokes SOLVE block
   say $x; # prints 1
 
The SOLVE closure needs beefing up, like e.g. if you have more than
one constraint it has to topicalize the constraint somehow:

   constrain $x, $y, $z to
   {
   always $x + $y == $z;
   SOLVE
   {
  when $x changed { $y = $z - $x; }
  when $y changed { $x = $z - $y; } 
  when $z changed { $x = $Z / 2; } # calls first when
   }
   }


Comments?
-- 
"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: Google index and subsets (two topics for the price of one!)

[Thomas Sandlaß]

HaloO,

On Monday, 16. June 2008 10:11:49 Ovid wrote:
> For example, should the pre/postfix '++' be
> listed as having a side-effect?

I think so. But the scope where these side-effects take
place is important as well. In your second example below
the side-effect is restrained to the subs scope. That
should be considered harmless. The more global a
side-effect takes place, the more you get into spooky
action at a distance and unpredictable behavior.

>   sub side_effect{ return $_[0]++ }
>   sub no_side_effect { my $x = shift; return $x++ }
>
> In Perl 6, since arguments to subs would have to be specifically
> written as 'is rw', we might be able to minimize this issue, but I
> don't know if we can stop it.

I would think that it should be possible to enforce methods that
don´t modify the invocant mostly at compile time. The rest could
use a STORE instrumentation on MOP level that fails on any modification.
Then a where clause could temporarily install that for the evaluation
of its body. Also access to outer namespaces can easily be blocked
or restricted.


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: Perl 6 Meta Object Protocols and $object.meta.isa(?)

[TSa (Thomas Sandlaß)]

HaloO,

Stevan Little wrote:
Here is a 10,000 ft view of the metamodel prototype I sketched  
out the other day  
(http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/ 
10_000_ft_view.pod). It should shed a little light on this discussion.


There you have

i(Foo) - instance of Foo
Foo- the user-level Foo class
class(Foo) - the instance of Perl6::Class named "Foo"
meta(Foo)  - the instance of Perl6::MetaClass which describes Foo

The thing which is clear to everybody---even including stupid me---is that
there is a 1:n relation between Foo and i(Foo). But then comes a three part
referential chain Foo -> class(Foo) --> meta(Foo) that to me is conceptually
*one* thing. The levels of indirection are implementation details, right?
The next level where a 1:n relation exists is below meta(Foo) to pure meta.

So, for two user classes Foo and Bar we get in top/down view:

   meta
   __|___
  | ||
   meta(Foo) meta(Bar)  ...
  | |
  class(Foo)class(Bar)
  | |
 Foo   Bar
__|_  __|_
   |  | ||  | |
 i(Foo) i(Foo) ... i(Bar) i(Bar) ...

Am I missing something? Conceptually I see *one* MetaClass which manages
its class instances which in turn manage their object instances. OK, it's
slightly more complicated because classes can have class instances and
there is multiple inheritance that adds edges into the tree which transform
it into a DAG. And I see also classless objects.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Container model - pictures and questions

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

If I'm mistaken, please let me know, preferably by suggesting
new arrangements on the diagram. :-)


Without judging your mistakes, here are my comments to the
container picture.

1) I would move the ::name to the Pad level. The idea is
   that ::name is some less specific supertype of the
   Fantastique Four ($&@%) if more than one of them exists
   on the container level.

2) I don't understand why you need two levels of indirection
   firstly the container and then the cell. Not to mention
   the third one to the tied thingy.

3) Why is the link from the container labeled with :=
   but the link between the cell and the value with =?
   I would consistently dispatch *all* operators including
   :=, = and =:=. Preferably at compile/check time. Container
   types are then on the same level as any other parametric
   type. This "naturally" explains why your "is IType" can
   be changed like underwear. For the type system it is just
   another mutator. Whatever it does to the tied object takes
   effect only by changing the type and hence the methods which
   are applicable.
--
::TSa.greeting := "HaloO"; # mind the echo!

Re: Elimination of Item|Pair and Any|Junction

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote:


Or maybe Any really does mean "Object" and we're just viewing our
hierarchy too strictly if we make every relationship "isa".  That's one
thing that neither this formulation nor Thomas's are making very
clear--which type relations are really subclassing, which are role
composition, and which are subtype constraints.


Well I would make all types predicate based. The isa relation of
an object to the class it was instanciated from is just one amongst
many others like doing a role or object structure. And the inheritance
hierarchy is mostly irrelevant for typing an object. This is one of
the difficulties I have with the metric MMD which relies completely
on the count of class derivation levels.

I currently have the following model in mind. The compiler collects
type information from so-called special forms and stores it in a
strictly tree shaped repository called the name space. User code
can query this structure by means of the :: forms. The type lattice
is then build at CHECK time on top of or from this information. In
particular I don't make a distintion between subtype, role, class,
sub or method special forms. This implies that where clauses are
restricted in the contructs allowed in them and the referential
environment accessible to them.



FWIW, I've been reading up on Scala's formulation of trait/class/delegation
hierarchy, and I feel a bit like flipping through a puzzle book to look
at the hints, if not answers. :-)


The Scala type hierarchy splits from the Any root into the two realms
of value types and referential types in good tradition with Java.
This split is located in my type lattice below the $Item type
where \Ref, Value, Undef, Inf and Junction lie nicely parallel to
each other.
--
TSa

Re: Complete type inferencing

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

Yes, I'm aware of Theta's static where clauses, but Perl 6's where
clause is much more dynamic and almost always undecidable.


I know, but what does that buy the programmer? I see a type system
as support of a declarative programming style. Thus the dynamic part
of the type system, that is method dispatch and type instanciation,
has to play in a frame set by the programmer. This is very similar to
regular expressions and grammars. They declare the interpretation of
a string/stream of chars/data. The type system goes on from there to
watch over constraints while this data is processed.



In Litvinov's paper, where clauses are determinisitic at compile time,
as a way to encode structural subtyping (aka duck typing).


Huch, who has coined 'duck typing'? I never heard that before.



The important difference is that the .can() call in Perl 6 would be a
runtime call.  It has to be that way, because .can is not a special
form; it's just a normal method returning a boolean.  If you really
want static treatment, that needs a special form:

sub foo (
$obj can bar:(() returns Int)
) returns Int {
$obj.bar();
}

It will allow constructs such as this:

my subtype Duck
has $.half_life
can doom:()
can quake:(() returns Wolfenstein);


Yes, I like that. I also proposed an object special form for
classless instances in namespace.


# Automagically satisfied iff $obj's interface is compatible
$obj.does(Duck);

Such implicitly-declared Roles is certainly powerful, and we can apply
the same inferencing treatment as for nominal subtyping violations --
fatal error under closed/finalized, raise warning by default.

I think it's cute, and adds real power of row polymorphism to the


What is 'row polymorphism'?


language, iff Perl 6 indeed adopts a compile-time inferencing engine.  


I would call it a bit different, but yes please! My idea is, that the
programmer of Perl 6 can 'store' a lot of information in name/type space
that is later---even at runtime---used by the code generation, class
composition, type instanciation and dispatch system without forcing the
programmer to rummage in the guts, which might actually be very difficult
to do platform independently if not even Parrot is fixed as the underlying
VM!

BTW, is 'special form' a fixed term? I just started using it to decribe
things like sub, class, role, etc. declarations/definitions.
--
$TSa.greeting := "HaloO"; # mind the echo!

TSa's Perl 6 type lattice version 1.0

[TSa (Thomas Sandlaß)]

HaloO,

in case someone might be interested, here is my more or less complete
idea of the Perl 6 type lattice as ASCII art.

Enjoy. Comments welcome.


::Any
...| ...
   ___:___/|\:_:
  |   :| :  |  |   static type :
   Package:| : Void  ?Bool   = context :
  |   :| :__|__|   :
Module:|/:.:
   ___|___:|
  |   |   :|
Class Grammar :|
  |___|   :|
  |   :|
 Role : Object Record =::= Frame =::= Dictionary
  :|
  : __/ \_
  with:|  || ||   |
  invocant(s) :  &Code  $Item%Hash Frame@Array Tuple
  :|  ||_||___|
  block owner : topic  |  |   |
   $/ : $_ |  |   |
  :___/ \_ ___|   |
 |:  |\   |   ||  | |  |  |
  .Method : Sub\  ->Block   \Ref Value  Undef  Inf  Junction  |
/|:  |\ \ ||  |
   / |:  | \ \  __||_ |
Rule |:  | Macro  \/  ||   |   | ||
 |:_/|Ref[Code]   |  :Pair  /Match/  ~Str  +Num   |
 |:  |||   | ||
   Multi  :  |||   |Int   |
..:  |||   |   / ||
 ||___  ___|   Enum  ||
 ||   \/ |   ||
 ||  Entry[::T.does(Hash)]  Bit  ||
_|__  |___  _||
   || |   \/  |
   =Iterator  *List   |  Pos[::T.does(Str|Array)] |
| |   |
|_   _|___|
   |  | ||\ / |
..Range  Pipe  Lazy  **Eager  Ref[Array|Hash] |
   |__|_||   _|
  \ /
   (to | all leafes)
  \|/
::All
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Do slurpy parameters auto-flatten arrays?

[TSa (Thomas Sandlaß)]

HaloO,

Piers Cawley wrote:

By the way, if flattening that way, what's the prototype for zip? We can after
all do:

   zip @ary1, @ary2, @ary3, ... @aryn


How about

   sub zip( List [EMAIL PROTECTED] ) {...}

a slurpy List of Array of List. The return value is a
not yet iterated Code object that knows how to produce
tuples from the outer lists. This implies that zip(@array)
basically returns an unstarted iterator on @array.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: zip with ()

[TSa (Thomas Sandlaß)]

HaloO,

Luke Palmer wrote:

On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:


In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], 
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)



I think that's right.  However, it might be a good idea not to
auto-enreference such bare lists:


I don't like this notion of auto enreference/dereference at all.
Either the type system manages to dispatch things correctly or
you get an error. For the List versus Array problem this dispatch
is IMHO decideable at compile time by strictly typing @ vars as
Array and subtypes thereof. The List type to me is a Code subtype
and as such travels in & vars. I'm only unsure how easily such
variables should enter name space, that is how they behave without
sigil.


sub foo ($x) {...}
foo (1,2,3,4,5);   # foo gets called with [1,2,3,4,5]


Yes, the $x makes foo an Item or even Value taker of arity 1.
The call foo (1,2,3,4,5) OTOH calls it with a List. This should
result in a type error. But sub foo (&x) might then work for a List
but not for an Item|Value call foo(1).

Since I think that * in a signature is for extending the arity of
the sub to infinity I wonder if it is possible to capture the caller's
list into a single *$arg?

   sub foo (*$x) {...}
   foo (1,2,3,4,5); # type of $x is now Ref of List of Int?

But with an additional array the slurpy item gets at most one value.

   sub foo (*$x, [EMAIL PROTECTED]) {...}
   foo (1,2,3,4,5); # $x == 1; [EMAIL PROTECTED] == 4
   foo @array; # type of $x is now Ref of Array; @a is undef



When you could just as easily have said:

foo [1,2,3,4,5];

And we'll probably catch a lot of Perl 5 switchers that way.  That
actually makes a lot of sense to me.  The statement:

my $x = (1,2,3,4,5);

Looks like an error more than anything else.


Yep. I opt for type error "Can't assign List to Item".
By the same token I would disallow

  my @a = 3; # type error "Can't assign Item to Array".

It should be

  my @a = *3;

or

  my @a = (3,);

Hmm, wasn't there a nullary *?

  my @a = *;
  say [EMAIL PROTECTED];  # prints 0



 That's the "scalar
comma", which has been specified to return a list.  But maybe it
should be an error.


Sorry, I don't understand this.  I thought comma just is *the*
List constructor per se. Parens required to lift precedence :)
Same applies to semi-colon. (1,2,3;4,5,6) is a List of List of Int.



 The main reason that we've kept a scalar comma is
for:

loop (my $x = 0, my $y = 0; $x*$y <= 16; $x++, $y++)
{...}

However, I think we can afford to hack around that.  Make the first
and last arguments to loop take lists and just throw them away.


My interpretation of the loop block controler special form is that
it gets a 4-tupel (Block,Block,Block,Block). The last one is of course
the loop's body. The first is the initializer that is executed in a
scope outside the body. The second and third are the condition and
the stepper and also scoped outside the body.

Now to the comma. It should be parsed as List of Block. In your example
the argument type of loop is (List of Block,Block,List of Block,Block).
The loop instanciates an Iterator[List of Block] and uses it to
execute the Blocks one at a time. The only special case is in the
condition which evaluates only the last Block from the List of Block
for truth and the others in Void context.

Is loop supposed to be a topicalizer? Does it bind the block owner?
Does a pointy body block make sense?

   loop (my $x = 0; $x < 10; $x++) -> {...}  # current count in $_?
   loop (my $x = 0; $x < 10; $x++){...}  # $_ unchanged from outside?

   loop (my $x = 0; $x < 10; $x++)
   {
   .blubber   # what is the invocant?
   }

Can the last Block also be separated with semi-colon? I guess not.
How about a Code var?

  loop my $x = 0; $x < 10; $x++; say $x;  # works?

  loop my $x = 0; $x < 10; $x++; &foo; # works?

  loop( my $x = 0; $x < 10; $x++; &foo ) # perhaps as function call?

  loop
 my $x = 0;
 $x < 10;
 $x++;

  say $x; # still the loop body? Or does it need { say $x }?

  loop foo; bar; blubb ->
  {
  say  # prints return value of blubb while bar returns true
   # first iteration prints return value of foo
  }


 Can
anyone think of any other common uses of the scalar comma?


Not me. It's a C relict.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Do slurpy parameters auto-flatten arrays?

[TSa (Thomas Sandlaß)]

HaloO,

Luke Palmer wrote:

On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote:


On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote:


So how *do* I pass an unflattened array to a function with a slurpy parameter?


Good question.  I would have thought that one of the major gains from
turning arrays and hashes into references in scalar context is the
ability to specify an unflattened array or a hash in a sub call
without any special syntax...


I thought that the obsoletion of special syntax stems from the
type system. Piers seems to have the same view. See his example
of &map in his parallel reply.



Well, you can, usually.  This is particularly in the flattening
context.  In most cases, for instance:

sub foo ($a, $b) { say $a }
my @a = (1,2,3);
foo(@a, "3");

Passes the array into $a.  If nothing flattened by default, then you'd
have to say, for example:

map {...} [EMAIL PROTECTED];

And even:

for [EMAIL PROTECTED] -> $x {...}

Which I'm not sure people want.  


Ups, I thought the for special form would work as follows.

0. the syntax: for expression &block
1. determine (return) type of expression
2. create an iterator for that type
3. Use the iterator until it runs out (is that when it returns undef?)
4. bind the block owner to successive return values of the iterator
   and call the block; if the block is pointy bind its environment as
   well.

With the above

  for @a -> $x {...}  # use Iterator of Array

and

  for [EMAIL PROTECTED] -> $x {...}  # use Iterator of List

produc the same sequence of values in $x but through different
paths in type space. As long as no user defined types are involved,
I dought they are distinguishable at all.

Here's an idea how a sub becomes its own iterator:

   sub foo() does Iterator[foo]
   {
   random;
   }

   for foo() -> $x { say }   # endless loop of random output

How are roles/types composed into Code subtypes?



And the way you pass an array in slurpy context as a single reference
is to backwhack it.  What it comes down to is that either you're
backwhacking things a lot or you're flattening things a lot.  Perl
currently solves it by making the common case the default in each
"zone" of parameters.


I would be interested to hear arguments to the contrary, however. 


OK, I gave my 0.02.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: If topicalization

[TSa (Thomas Sandlaß)]

HaloO,

Luke Palmer wrote:

I vaguely recall that we went over this already, but I forgot the
conclusion if we did.


I have a proposal about block owner and block topic pending.
But I guess no one noticed it, ...



In Damian and Larry's talk here at OSCON, I saw the example:

if foo() -> $foo {
# use $foo
}

How can that possibly work?  If a bare closure { } is equivalent to ->
?$_ is rw { }, then the normal:

if foo() {...}

Turns into:

if foo() -> ?$_ is rw { }

And every if topicalizes! I'm sure we don't want that.


I think of -> as the binder of the referential environment of the
block/closure that follows. Without it the non block-owning special
form if doesn't touch $_. It just flows into the block from outside.
The other forms like for, while, given, etc. should behave the same.

I would also require an explicit '-> $_ is rw' if you want the block
to write to the caller's environment. Perhaps '-> :rw' is an abbreviation
for a rw topic. This is the same logic as \:rw for rw ref creation.
I like the very nicely huffmanized rw. It's short if you need/want it.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Eliminating &{} and *{}

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

All this led us to think about whether (my &foo) can be merely treated
the same as (my Code $foo).  The mutable form will enable convenient
notations such as:


I think (my Code $foo) should be an error on the same reason as
(my Array $foo) is an error. A $var can only contain explicit
Ref types like (my Ref of Array $foo) or (my Ref of Code $foo).

But the following should be allowed

  my &pi = 3.14;

  if $num == pi {...}



&foo = sub { ... };

So instead of having to explain to newcomers that you cannot assign
to a &-sigil symbol, it would all just work.  Under this view, &{$x}
would be eliminated with *{}.


I think *{1,2,3} is valid syntax which means listify the code literal.
But it's no special form. In particular * {1,2,3} is the same because
* is a normal prefix op.



Another idea is to treat (my &foo) the same way (my Code $foo is constant).
That will discourage people into assigning into functions, and enable
the compiler to detect function variables at lvalue position as errors,
but on the whole I don't think it's worth the complexity.

Does this make sense?


Yes. I think of the (fantastic) four sigils as referential expressions
that are somehow bound to 'real' data. When and how that binding takes
place is another matter. But in particular I like my idea that the 
corresponding dot twigils are firstly applicable only in methods and

are secondly then bound through the invocant. E.g. &.action calls the
action slot of the current invocant---method level block owner aka
$?SELF. This is basically the vtbl dispatch. Note that &. slots are
auto-generated accessor "methods" if not explicitly given by the class
implementor. A method special form is *not* a slot method by a 'free'
method specialized on the surrounding class.

PS: could someone give a summary which sigil forms are still in effect.
E.g. ${}, $(), etc.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: sub foo ($x) returns ref($x)

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

On Mon, Aug 01, 2005 at 03:16:50PM +0200, "TSa (Thomas Sandla�)" wrote:


  sub equitype ( ::a $x, a $y) { ... }



That's not a bad idea at all.  I rather like it.  I'd just still like an
explicit type-unifying parens around ::a, just so people won't say


I try to maintain the 'parens only group' point of view. But it
seems to be violated elsewhere, too.



sub foo (::Int $x) { ... }

and accidentally rebind Int.


Why so shy? It would rebind foo::Int with respect to the inside
of &foo. Of course the funny effect is that for a call foo( "blahh" )
foo::Int means Str :)

I guess this is why $Larry wants a role wrapped around such type parameter
instanciators:

  role Foo[::Int] # hides *Int
  {
 sub foo (Int $x) { ... }
  }

and explicit instanciation

  use Foo[Int]; # or some such
  use Foo[Str];
  use Foo[Num];

But I don't know if he also wants to carry that on to the actual calls:

  Foo[Int]::foo(42);
  Foo[Str]::foo('42');
  Foo[Num]::foo(3.14);

OTOH, one has to use *::Int or *Int to surely get the standard Int,
anyway. And for getting guaranteed type locality inside &foo a

  sub foo( MY::Int $x ) {...}

might be needed, too. This nicely fits other pseudo namespaces:

  sub foo(  Int $x ) {...}  # whatever Int is in effect
# at compile time
  sub foo(::Int $x ) {...}  # deferred lookup to CHECK time
  sub foo(  MY::Int $x ) {...}  # dynamically from $x
  sub foo( foo::Int $x ) {...}  # same for all invocations? error?
  sub foo( OUR::Int $x ) {...}  # from package

How usefull OUTER::, CALLER::, etc. are I have no idea. Perhaps it's
a good idea to reserve single capital letter barewords for type params.
Or a twigil if we think of '::' beeing s sigil:

  sub foo( ::^a $x ) {...}

This saves one character compared to your (::a) which is the
same length as MY::a.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: sub foo ($x) returns ref($x)

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:

[..] For example, assuming argument types are unified in a single
phase, the example below does nothing useful:

sub equitype ((::a) $x, (::a) $y) { ... }

It won't not help even if we replace the implicit "does" with "of":

sub equitype ($x of (::a), $y of (::a)) { ... }

The reason, in Luke Palmer's words:

"The trouble with this is that it doesn't provide any type safety.
 In the case of a type conflict, "a" just degenerates to the Any type."
 (cf. pugs/docs/notes/recursive_polymorphism_and_type)


Luke's analysis is indeed correct. And describes what can be inferred
from the caller side. And I wouldn't introduce the subtlety that the
first ::a is bound to the exact type of $x in the call environment, while
the second is a constraint on $y's type. But I would prescribe exactly
this as the meaning if you use plain 'a' as the type of $y. Thus I opt
for:

   sub equitype ( ::a $x, a $y) { ... }

which is the same behaviour as for the value of $x which can be used
immediately for subsequent parameter bindings. Hmm, how do coderefs behave
in that respect?

   sub codeparam ( &foo, ?$val = foo ) {...}

Does this invoke a &bar argument once for the call codeparam( &bar )
and capture the result in $codeparam::val while the call
codeparam( &bar, 42 ) stores 42 without invoking &bar through
&codeparam::foo? And in which exact environment does a call to
&bar take place when needed to bind $val? Purely ::CALLER? Signature
as bound so far? ::OUTER of the use'er of the package which contains
&codeparam? Or the ::OUTER of the 'real' package file?

The other remark I have for the form with double ::a is that there's
also an inside view of that type. All type information inferred can
be stored as constraints on ::equitype::a in the ::equitype Code class.
Interesting is how the syntax for a more explicit form reads:

   sub equitype( ::a $x, ::a $y ) where { a.does(SomeRole) }
   {...}


This fact, coupled with the unappealing (::a) syntax,


I like the syntax. BTW, does it have to have parens?
I would actually promote :: to a very fundamental operator/token.
Even if that costs some parens for the ternary ( ?? :: ).


leads me to look
for a more Perlish representation.  Adopting an idea from Odersky's
"Nested Types" paper, we can let terms occur at type variant position,
by introducing a "ref" form for types:

sub equitype ($x, $y of ref($x)) { ... }
sub subtype  ($x, $y does ref($x)) { ... }
sub identity ($x) returns ref($x) { ... }


Uhh, please make that sig read ($x, type($x) $y) or at least
($x, $y.does($x.type) or something else with 'type' in it.
Ref is way to overloaded with meanings in Perl6 which are not
easy to unify away because of mismatches on the levels of
abstraction involved. E.g. the sub identity looks like an
alias for \ which it isn't from the type perspective.



This reads like Perl, and can be guarded with trivial compile time
and runtime checks.  We can also use type selectors to check
that &pick can always return Int from an Array[of => Int]:

sub pick (@x) returns ref(@x).of { ... }

The only problem I can find is that the possible confusion between the
ref() operator and the unboxed basic type "ref".  Another thought is to
simply use ::() as a special "ref" form:

sub pick (@x) returns ::(@x).of { ... }

But that can confuse with the symbolic dereference syntax.  All in all


Uhh, could we agree to call ::(symbolic) the symbolic lookup form and
::bareword the bareword, pre-runtime lookup form?
Let's not add another referencial thing to the 'Many Refs of Perl6'.
In the end we'll need a dedicated reference manual :)
I guess it would be S08.

Since I opt for ::pick beeing the innermost namespace immediately
after its introduction with 'sub pick' ::x could refer to @x from
the signature. Note that if there are &x, $x, @x and %x in the
signature a simple ::x is typed as their supertype Object.
Disambiguation would go as ::x::Code, ::x::Item, ::x::Array and
::x::Hash respectively. And of course you can further descent into
these namespaces as in pick::x::Array::of. Descending along multiple
pathes essentially means any'ing the types together ::x::*::of.
Well, in some namespaces things are all'ed together :)
The supertype of all array entries is of course pick::x::Array::values::*
and single items show up numerically under pick::x::Array::values::
e.g. pick::x::Array::values::8. Note that this is *not* a symbolic
form but well defined. It might evaluate to undef though.

Finally the .of method might just be syntactic sugar for the above:

   sub pick( @x ) returns @x.of {...}

or just

   sub pick( @x ) returns x.of {...}

or

   sub pick( @x ) returns x::of {...}


I'm more happy with ref(), but better suggestions welcome.


I suggest type(), tie() or soul()---the latter is from
'.bless() my .soul()'---if none of the above pleases @Larry.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: zip with ()

[TSa (Thomas Sandlaß)]

HaloO,

Andrew Shitov wrote:

TTS> BTW, you didn't mean originally:

TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?

That is exactly like with similar printing result of sub() call:

 print sqrt (16), 5; # shout print 45.


That all hinges on the type of the symbol. I guess &sqrt
is a unary prefix. Then

   print sqrt 16, 5; # should print 45 as well.

The point is, to not let &sqrt 'swallow' the 5 unless
it is declared listop.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: zip with ()

[TSa (Thomas Sandlaß)]

HaloO,

Ingo Blechschmidt wrote:

Whitespace is significant:

say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even);   # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even);  # &zip gets only one argument, the flattened
# list (@odd, @even), containing the


Why flattened? Shouldn't that be *(@odd, @even)?



# elements (1,3,5,7,2,4,6,8). Then &zip


Why not ([1,3,5,7],[2,4,6,8]) list of two array refs?

# tries to zip this one list, resulting in 
# 13572468.


If the list of two array refs is not flattened, the result should be
12345678 because how should &zip distinguish it from the other cases?

The crux of the first case not requiring parens is that &zip is declared
as listop and as such consumes the @even after the , which otherwise would
be left for &say. And if &say weren't declared/assumed listop, the @even
would be evaluated in Void context and not appear in the print at all.

Or do I miss something important? E.g. has () become a circumfix deref op?
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: zip with ()

[TSa (Thomas Sandlaß)]

HaloO,

Andrew Shitov wrote:

Is it possible to avoid significance of whitespaces?


Yes, with:

  say zip .(@odd, @even);

Looks like a method and *is* a method in my eyes.
First &zip is looked-up and then bound as block owner.
Arguments are of course two array refs to @odd and @even
respectively.

BTW, you didn't mean originally:

  say zip (@odd), (@even); # prints 13572468 or 12345678?

Does &zip now interleave two array refs instead
of flattened arrays?


I think, such an aspect of Perl 6 would be awful.



IB> Whitespace is significant:

IB> say zip(@odd, @even);
IB> say zip (@odd, @even);

--
$TSa.greeting := "HaloO"; # mind the echo!

Re: [S29] Mutating map and grep

[TSa (Thomas Sandlaß)]

HaloO,

Ingo Blechschmidt wrote:
Is this a bug in S29 or will this be feature removed from Perl 6 
and you'll have to say (for example) 
 
  use listops :mutating; 
  my @result = map { $_++; 42 } @array;  # works now 


Why not just

my @result = map -> $_ is rw { $_++; 42 } @array;  # works now

which could be abbreviated as

my @result = map:rw { $_++; 42 } @array;  # works now

And as usual the :rw binding needs the confirmation of @array.

BTW, would the following be parseable in an extreme interpretation of
optionality of block owner and block topic:

   my @result = map:rw{ .++; 42 } @array; # ++ as method on owner
   my @result = map:rw -> {  ++; 42 } @array; # ++ as sub with topic
   my @result = map:rw -> { .++; 42 } @array; # both:  $/.++($_)
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)

[TSa (Thomas Sandlaß)]

HaloO,

Adriano Ferreira wrote:

Only

sub foobar (@args) { push @args, 42 }

would change @some_array in

foobar @some_array;

That is how I undestood that. Can someone confirm this belief?


I share your belief. It's up to others to confirm it. I just
want to add that I further believe that the push call is dispatched
on the type of the array and only succeeds if @array.does(Pushable).
I guess a default array does this or another role that implies it.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Type::Class::Haskell does Role

[TSa (Thomas Sandlaß)]

HaloO Luke,

you wrote:

All in all, generic equality and comparison is something that Perl 5
did really poorly.  Some people overloaded eq, some overloaded ==,
some wrote a ->equal method, and there was no way to shift between the
different paradigms smoothly.  This is one of the times where we have
to choose for them.


My ideas run more along a role that defines an ordering on a type.
Such a role might require slot/infrastructure methods

  .EQUAL
  .LESSER

and compose other ops from these with "namespace assignment":

  ::.<= ::= any( .==, .< )

  ::Str ::= Item where .value.does(Order[eq, lt])
  ::Num ::= Item where .value.does(Order[==, <])

Actual syntax might be more convoluted :)
The point is that the 'generic' comparator is a method junction.
More like: "Ahm, what did the operants say their comparator was?"

BTW, where can I read about PIL, other then in Parrot/Pugs svn?
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: The meaning of "returns"

[TSa (Thomas Sandlaß)]

HaloO Autrijus,

you wrote:

 D) Make the return type observe both #2 and #3 at compile time,
using type variables:

   sub id ( (::T) $x ) returns ::T { return($x) }



And this is a natural extension to guide the inferencer so it won't be
totally giving up on polymorphic functions such as &id.  C) and D) can
be taken together, resulting to a powerful soft typed language.


This is my preference. The only known issue with parametric typing is
the proliferation of params as soon as you want to stay away from
unpecificity.



However, if we take the view that type annotation are merely storage
allocation hints and runtime coercers, then A) is probably the way to go.


Please no. Or at least not exclusively. I see your "storage allocation
hints" as a data environment needed to implement the type.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Messing with the type heirarchy

[TSa (Thomas Sandlaß)]

HaloO Michele,

you wrote:

On Wed, 27 Jul 2005, [ISO-8859-1] TSa wrote:


value to carry on a useless imaginary part. And
Complex should consistently return undef when compared
to other Nums or Complexes. And the Compare role



My 0.02+0.01i: in mathematics it is commonly used to write e.g. z<3 to 
mean "z is real AND as a real number is less than 3".


Which in Perl6 is written as

   Complex where { .imaginary =:= 0|Undef } does Num;

somewhere in the Complex package. This would make your
intensions possible by dispatching to &infix:{'<'}:(Num,Num)
but still preventing the general case.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Inferring (Foo of Int).does(Foo of Any)

[TSa (Thomas Sandlaß)]

HaloO,

Autrijus Tang wrote:
[..much better explaination of the co/contra prob then mine skipped..]

Hence, my proposal is that Perl 6's generics should infer its variancy,
based on the signature of its methods, and derive subtyping relationships
accordingly.


Yes!! That would be great. But I would restrict it to the onboard methods
or however we call them. Outside/free methods specialized on the generic
type are firstly referential in nature, and as such bind their $.attr,
@.array, %.hash and &.code referential expressions through the invocant.
They form a mediator layer between unrelated code and the code
implementing the type's guts.



The other alternative is do as Java does, which is assume invariancy by
default, then force users to write variancy annotations, but I think
that is considerably less attractive.  There may be a case for inferring
by default, but overridable by the user; if so there needs to be a
syntax for that.


Well, that pivots around how refs behave. I would opt for them beeing
const unless explicitly allowed :rw by the instance owner. Is the syntax
for that actually \$x:rw? Or even plain \$x if we assume that every sigil
expression *always* means implicit const ref? And thus needs a
dereferencer, e.g. $x()? Then

   $x  = $y; # means dispatch to op =
   $x := $y; # same, but op := requires $x to be writeable
  \$x  = $y; # same as := ?  I prefer \$x:rw which might fail
 #   depending on where $x refs to
  \$x := $y; # ???

Consider

   $x = [EMAIL PROTECTED]; # assume there's no slot 42, then the array could
 # hand-out a \.[42]:rw and allow subsequent
 # assignment
   # but

   $x = [EMAIL PROTECTED]; # assume .[23] is filled, then the array returns
 # a const ref

Such an array would be typed Array of ::T^Ref:rw[Undef of ::T]
and as such a hot candidate for the default array :)
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Elimination of Item|Pair and Any|Junction

[TSa (Thomas Sandlaß)]

Larry Wall wrote:

On Wed, Jul 27, 2005 at 06:28:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.

That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking.  We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to -> $x {...}.  Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions.  (And if that's the wrong way to think about it,
please tell us why.)


Sorry, here's the patch:

  :   &Code @Array   %Hash $Item
  : | // |
  with: |   TupleRecord  |
  invocant(s) : ||
  :/ \__  ___|_
 |:  | |\|| |  |
  .Method : Sub  Block   |Value  Inf  Undef  Junction
/|:  |\  |   |
   / |:  | \Ref[Code]|
   Rule  |:  |  Macro|
 |:_/|__/|\___
 |:  |   | | | |  |
   Multi  :  | ~Str  +Num  \Ref  :Pair  /Match/

Now the Junction is nicely constraint with the upper bound Item (less 
specific) and a lower bound Value (more specific). This also reads

nice if you want to (explicitly) allow both:

 sub ( Value|Junction $val_junc )

What sub ( $any ) should default to, I don't know. My $Item indicates
Item, but could also be $Value. Or unspecific $(Item|Value).
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Elimination of Item|Pair and Any|Junction

[TSa (Thomas Sandlaß)]

HaloO,

Larry Wall wrote:

Yes.  The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom.  Then maybe swap Item with Atom,
since in colloquial English you can say "that pair of people are
an item."


Since we are in type hierachies these days, here's my from ::Any
towards ::All version. The "bottom" part where everything finds
together is missing for this installment.

 ::Any
... | ..
   ___:_|_:static type :
  |   : | :  | | = context :
   Package: | : Void  Bool :
  |   : | :.
Module: |
   ___|___: |
  |   |   : |
Class Grammar : |
  |___|   : |
  |   : |
 Role :   Object
  : |
  : | || |
  :   &Code @Array   %Hash $Item
  : | // |
  with: |   TupleRecord  |
  invocant(s) : ||
  :/ \__   __|_
 |:  | |\ /  || |  |   |
  .Method : Sub  Block   |   |   Inf  Undef  Match  Junction
/|:  |\  |   |
   / |:  | \Ref[Code]|
   Rule  |:  |  Macro|
 |:_/|__/|\
 |:  |   | | | |
   Multi  :  | ~Str  +Num  \Ref  :Pair
..:  |   | | |\|
 |   |Int| \   |
 ___/|   | | |  Entry[::T where T.does(Hash)]
| |  |   |/|\|
  *List  Pipe =Iterator Enum ?Bit  Pos[::T where T.does(Str|Array)]
|\___
|  | |
 **Eager  Lazy  Ref[Array|Hash]


any() == lub( all ---> any ) == glb( any --> all )   lesser --> greater
all() == glb( all ---> any ) == lub( any --> all )

Some operators and prefixes are added in to show their
relation to the corresponding type. I hope it looks familiar.

Here is some pseudo code that describes a bare minimum data layout
required to support the respective types.

type Item[::T]
{
  has $.value of T;
}

type Pair[::T]
{
  has $.key;
  has $.value of T;
}

type Tuple[::T where T does lub( @.values )]  # lub = least upper bound
{
  has @.values of T;
  has $.value ::= @.values; # auto-enreference for Item subtyping
  has T $.head ::= @.values[0];
  has T $.tail ::= @.values[-1];
}

type Record[::T where T does lub( @.values )]
{
  has @.keys;
  has @.values of Pair[T];
  has @.pairs ::= { zip @.keys, @.values };
  has $.value ::= @.pairs;
}

type Code
{
  has %.MY;# lexical scratchpad
  has &.block;
  has $.value ::= { use %.MY; &.block() }; # coderef literal
}

type Junction[::T where enum ]
{
  has @.values;
  has Junction $.value ::= { @.values as Junction[T] };
  has &.evaluate ::= &::JUNCTION_MAGIC; # what's the exact type of this?
}
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: execution platform object? gestalt?

[TSa (Thomas Sandlaß)]

Randal L. Schwartz wrote:

This is similar to the OS-9's "gestalt" tables, which got smarter as
the operating system had more features, but was a consistent way to
ask "do we have a color monitor here?".

Is something like this already planned?


From my bubble in the Perl6 Universe this thing is an unbound
symbolic reference $::("to The Type System").

Welche Gestalt es bisher angenommen hat weiss ich nicht.

But it should be capable to appear in any(@form) to help
all(@us) where {any(@us) != ::United::States of America}. :)
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Messing with the type heirarchy

[TSa (Thomas Sandlaß)]

HaloO,

Ingo Blechschmidt wrote:

I've probably misunderstood you, but...:

role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?


My 0.02: Complex should provide e.g. a + that, when
called with two Nums, doesn't bother the return
value to carry on a useless imaginary part. And
Complex should consistently return undef when compared
to other Nums or Complexes. And the Compare role
shouldn't treat undef == false but as any(true|false).
Otherwise funny things can happen  (as was observered
correctly in another thread about != applied to any
Juntions). In code:

   if $c < 3 { die if $c.does(Complex) }

This is the Perl6 representation of the following
sentence: "If Any::$c is less then Int::3 then
die if this $c does behave like a Complex." I hope
$Larry likes it. BTW, is their a plain english output
module planned, that would produce the above automatically?

Don't question (Light ::= Particle|Wave) with a double
slit! At least not if you want a deterministic answer
where it actually passed.


Imagine a Casino that hands out ties to players
who don't have one even though the Casino is
a tied area. If a Num playing in the Casino likes
the imaginary standard tie it can keep it. But
among Nums this imaginary tie is no differentiator.
Actually other Num methods will say: "A tie? I see
no tie. Must be an imaginary one." In simple
environments the tie might not even be applicable
imaginarily. Thus it's stripped off or entrance is
denied. Under all cicumstances the Num may decide
how to deal with this tieing.

fun: d(en)ie(d) == die in the end :)


The only question is how much effort all this is for
(1) the implementor of Complex
(2) the implementor of Num
(3) the user of either one in isolation
(4) when they come together

In particular the user in (4) should be able to
state his expectations in a form that is checkable
by the VM. Which basically means that (1) and (2)
have to state their assumptions to the VM in the
same form/syntax.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Exposing the Garbage Collector (Iterating the live set)

[TSa (Thomas Sandlaß)]

Luke Palmer wrote:

On 7/26/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:


Piers Cawley wrote:


I would like to be able to iterate over all the
objects in the live set.


My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.

  for ::Namespace -> $instance
  {
 if +$instance != 0 { reconfigure $instance }
  }



Oh, so a namespace can behave as an array then.  Well, to avoid
auto-flattening problems in other, more common places, we ought to
make that:

for *::Namespace -> $instance {...}


Well, even more huffmanized would be

  for Namespace -> {...; use $_}

might be what you expect after

  my @array = (0,1,2,3);
  ::Namespace ::= @array;



However, this is very huffmanly incorrect.  First of all, what you're
doing may take a quarter of a second or more for a large program
(which isn't a short amount of time by any means).  Second, the fact
that you're using it means you're doing something evil.  Third, only a
fraction of 1/omega perl programmers will be using this feature. 
Therefore, it should probably look like:


use introspection;
for introspection::ALL_INSTANCES(::Namespace) -> $instance {...}


This is why I wonder how writeable the namespace is, and when.
On some platforms it might actually not even be readable because
it was compiled away or stripped from the excecutable ;)
All that remains then is the possible behaviour as it is constrained
by the types of souls/daemons the creator happened to *choose*.
I guess you should re-read $Luke::Bible or watch the 
$*::Movies::WarnerBrothers::Matrix again :))

If both refs are undef in your namespace, go and bind them!

If the above is insulting, feel free to invoke my &.apologize with
you as topic. You know, I'm the $/ of this $email.



And it might even be platform-specific, given the constraints of some
of our targets.


The platform is yet another restriction on Space::Search::Solution.
Interestingly namespace lookup is big endian...
--
$Language::Perl6::TSa.greeting
(somehow we are all part of it or was that $_?)

block owner, topic and the referential environment

[TSa (Thomas Sandlaß)]

This is another spin-off from the 'Exposing the Garbage Collector'
thread. Here is an enhanced version.

I wonder how the generic, lexically scoped invocant/owner is called.
I propose to call it $/ (other option is to call it $&)and let the
former topicalizer become block owners and $_ the block topic that flows
into blocks from further outside if not explicitly bound with -> like:

   $topic := Some.new;
   $_ := $topic;
   for @objects { .action } # call on $/ from @objects with $_ := $topic
# in all loops

   @objects».action;  # same for single action syntax


   # but
   for @objects -> { .action } # means $/.action($/) because
   # $_ bound to dynamic block owner;
   # but usefull for methods that don't
   # use the topic, in particular accessors
   # and mutators
   # same as sub call
   for @objects -> { action }  # means action($/) because $_ := $/
   # but $/ is there if action is of
   # type Method

   # but the $. @. %. and &. are bound through $?SELF
   # in particular
   for @objects -> { &.action } # subref curried on invocant

This implies that a .action means name lookup of 'action' while
&.action is an onboard method of $?SELF. This latter case is
typically implemented with a vtbl lookup.

The only drawback I see is, that the careless method programmer could be
caugth in an endless .action loop if .action invokes .action explicitly
on $_ where $_ := $/ from the outside. The same endless loop could of
course be achieved with a free standing .action but that looks more like
intention.

With the lurking pitfalls an occasional check of $_ =:= $?SELF and
$/ =:= $_ seems advisable and indicates that the invocant wasn't
exchanged midway :)

Same with other block topicalizers/owners

  given $x{...}  # topic untouched, but $/ := $x
  given $x -> {...}  # $_ := $x as well

But

  if $x{...}   # $/ and $_ untouched
  if $x -> {...}   # $_ := $x (non boolean value)

One more interessting thing is that in exception handlers all three
variables $!, $/ and $_ are in scope. This might allow to resume where
the exception occurred after the cause was fixed e.g. by loading or
generating some code, some revamping or other &DEEP_MAGIC. Hmm, debug
exceptions come to mind...
--
TSa (Thomas Sandlaß)

Re: Do slurpy parameters auto-flatten arrays?

[TSa (Thomas Sandlaß)]

Ingo Blechschmidt wrote:

Hi,


ReHi,



are the following assumptions correct?


I don't know in general. But see my assumptions below
for comparison. They are derived from my type theoretic
approach and as such might collide with Perl6's referential
semantics. In particular with the auto-ref/deref and how
far it follows links.



  sub foo ([EMAIL PROTECTED]) { @args[0] }

  say ~foo("a", "b", "c"); # "a"


foo( List of Str )


  my @array = ;
  say ~foo(@array);# "a b c d" (or "a"?)


foo( Ref of Array )  # @args[0] derefs the array ref
 # I guess you need @args[0][0] to get "a"

But I don't like this level of reference preservation.
E.g. one then needs to know how far out the flat array
resides, to use the right number of dereferencers. Here
type theory doesn't constrain the definitional freedom
because both interpretations are compatible with [EMAIL PROTECTED]

Actually that unspecificity could be preserved, see below.



  say ~foo(@array, "z");   # "a b c d" (or "a"?)


foo( Ref of Array, Str )  # @args[0] as above

Here typing constrains the interpretation to be the
one that needs @args[0][0] to get at "a". This is slightly
untrue. The problem is actually shifted to the question:
"How does comma handle a Ref of Array?".



  say ~foo([EMAIL PROTECTED]);   # "a"


foo( List of Str build from Array of Str)



  say ~foo(*(@array, "z"));# "a"
 


  sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] }

  say bar(1,2,3);  # 3
  say bar(@array); # 1 (or 4?)


Type theory actually should come up with any(1|4) :)
And yes, any(1|4) is a type literal and any($x,$y)
is a parametric type which is fixed whenever $x and
$y are.

Side node: A nice test for hidden assumptions in
code is to replace functions which return Any to
behave randomly.

A Vogon optimizer OTOH, might blow away a complete
planet and return 42 everywhere :)

For this very reason the default signature of the
ideal sub is of course ::Any --> ::All where All is
pure specificity. And---even thow I should start a
'type theory foundations of Perl6' thread, I mention it
here---the ideal method is

  ::All . ::Any --> ::All

A multi sub/method is in that view a *metric* dispatcher
on the middle ::Any between the selector before the dot
and the return type after the arrow.



  say bar(@array, "z");# 2 (or 5?)


I opt for 2.


  say bar([EMAIL PROTECTED]);# 4


Yep.
--
TSa (Thomas Sandlaß)

Re: Exposing the Garbage Collector (Iterating the live set)

[TSa (Thomas Sandlaß)]

HaloO Jonathan,

you wrote: (why off-list?)

H, and the current actor/owner is $/ which gives the expanded
method call syntax:

  .method   #  really means:   $/.method($_)



You mean $?SELF rather than $/.  $/ is now the match object used in
rules.


I would say *for* rules/methods. $?SELF is a variable that is bound for
the body of the rule/method once. But I'm talking about the outside
general environment. I'm unsure about the rule syntax but wasn't it like

grammar Foo
{
   rule alpha {...}
   rule beta {...}
   rule blahh { <{ if .alpha { say "letters $/" } }>  }
} #   ^^^

I wonder how the generic, lexically scoped invocant/owner is called.
I propose to call it $/ and let the former topicalizer become
block owners and $_ the block topic that flows into blocks from
further outside if not explicitly bound with -> like:

   $topic := Some.new;
   $_ := $topic;
   for @objects { .action } # call on $/ from @objects with $_ := $topic
# in all loops

   @objects».action;  # same for single action syntax


   # but
   for @objects -> { .action } # means $/.action($/) because
   # $_ bound to dynamic block owner;
   # but usefull for methods that don't
   # use the topic, in particular accessors
   # and mutators
   # same as sub call
   for @objects -> { action }  # means action($/) because $_ := $/
   # but $/ is there if action is of
   # type Method

The only drawback I see is, that the careless method programmer could be
caugth in an endless .action loop if .action invokes .action explicitly
on $_ where $_ := $/ from the outside. The same endless loop could of
course be achieved with a free standing .action but that looks more like
intention.

With the lurking pitfalls an occasional check of $_ =:= $?SELF and
$/ =:= $_ seems advisable and indicates that the invocant wasn't
exchanged midway :)

Same with other topicalizers

  given $x{...}  # topic untouched, but $/ := $x
  given $x -> {...}  # $_ := $x as well

But

  if $x{...}   # $/ and $_ untouched
  if $x -> {...}   # $_ := $x (non boolean value)

One more interessting thing is that in exception handlers all three
variables $!, $/ and $_ are in scope. This might allow to resume where
the exception occurred after the cause was fixed e.g. by loading or
generating some code, some revamping or other &DEEP_MAGIC.



Always needs parens?  Even in the simple cases?

my $foo = $cond ?? $alpha :: $beta;


People who know the parsers better than I do, correct me but I want
this to tokenize as (my $foo = $cond)??($alpha)::($beta) and then
given to the current match state of the parser seperately to produce a
"name lookup" resulting in the above case in three code snippets.
This e.g. allows to define the boolean "type" as

  *::false ::= *::bit::0;
  *::true  ::= *::bit::$_??$_::*false;

or so. And whitespace around ?? and :: doesn't matter!
?? just means skip next lookup if "lookup" fails.

Regards,
--
TSa (Thomas Sandlaß)

Re: Exposing the Garbage Collector (Iterating the live set)

[TSa (Thomas Sandlaß)]

Piers Cawley wrote:

I would like to be able to iterate over all the
objects in the live set.


My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.

  for ::Namespace -> $instance
  {
 if +$instance != 0 { reconfigure $instance }
  }

Hmm, how would that be written inside the owning class?

  for :: -> $instance {...} # or perhaps ::_ or ::0

H, and the current actor/owner is $/ which gives the expanded
method call syntax:

   .method   #  really means:   $/.method($_)

Then we need to distinguish between the owner of a block and
the topic of the block. In methods the owner is called invocant,
of course. This also nicely unifies rules and methods. But with
the drawback that the brawl then shifts from topic versus invocant
to rules and method competing for ownership :)



ISTM that exposing the Garbage Collector at the
Language level is the neatest way of doing this (or coming up with something
like Ruby's ObjectSpace, but conceptually I reckon the GC is the right place to
hang it).


To me the GC is an implementation detail for rendering the
illussion of infinite memory :)

For example +::Int could return the number of instances in use
not the potential Inf many ones. Adding the infix namespace wildcard
could allow to retrieve attributes as arrays indexed by object id:

  @instvalues = ::SomeClass::*::attr;

The access control on a level behooves its owner/origin that
is ::NameSpace::0. This gives in the end a virtual tree of all
static information. As a fallout, structured rule matches can also
be queried with :: and as such nicely blend strings into the
type system. E.g. after successfull recognition an object could
be "created" by simply reparenting it from the rule to its class/owner.

The referential fabric and the call chains are hang-off this
structure somehow, as well. Everything else is basically garbage.

Too far off the mark? If not, I've ideas for ?? and :: beeing
top precedence namespace query ops. Only effect is that the
current meaning needs parens like ($condition ?? $value :: $other)
for preventing strange tokenization. OTOH would the barebone
structure of Perl6 revolve around ?? :: ::= () ; and namespace lookup.
--
TSa (Thomas Sandlaß)

Re: Exposing the Garbage Collector

[TSa (Thomas Sandlaß)]

I wrote:

   class Example
   {
  my %private_data;
  my sub source {...};

  has %.data;

  has &.blahh = { %.data };


Should read $.blahh, &. would indicate codehood.



  # and how about syntactic sugar for this:
  has &.blubber from %.data;


Here also $.blubber. Sorry, that I got the sigil typing wrong.
But I was to much thinking in terms of code implementing slots
then the type of the slot under definition.


  # private slot
  has &.hidden from %private_data is rw;
  has $.hidden := &.hidden;


This also is actually too verbose. Should be condensed to:
has $.hidden is rw from %private_data;

BTW, I would like to coin the term 'onboard method' for a
code slot of type Method.



  # initialized from class
  has $.cache is rw from source;

  # virtual per instance
  has $.value from {...};
   }

--
TSa (Thomas Sandlaß)

Re: Exposing the Garbage Collector

[TSa (Thomas Sandlaß)]

Piers Cawley wrote:

Let's say I have a class, call it Foo which has a bunch of attributes, and I've
created a few of them. Then, at runtime I do:

   eval 'class Foo { has $.a_new_attribute is :default<10> }';

Assuming I've got the syntax right for defaulting an attribute,


I think you need a 'class Foo is extended' to re-open the class.
Otherwise you produce a redefinition error if the scope you call
eval in already contains---or is that extains because of the name
search beeing *outwards*---one you start from scratch.


and lets assume
I have, the Perl runtime needs to chase down every instance of Foo or its
subclasses and add an attribute slot (adding a method to a class is nowhere
near as interesting, because every instance of the class shares a single class
object). 


One way to do this is for a class to keep track of all its instances, which is
all very well until you start subclassing because subclasses have to both keep
track of their instances and inform their superclasses about any new instances,


Sorry, I thought the instances of a class fall into the two categories:
instances and subclasses. A generic implementation of Perl-OO just blesses
a reference into its immediate parent. When accessing attributes the type
system knows two things: (1) the actual data of the object, (2) the class
who did the blessing. A read access of an attribute that is not found in
the object is delegated to the class. A write access to a slot which is
not present in the object triggers a request to the class asking if such a
request is part of the attribute set. If yes, the slot is vivified on
the object and available there for future accesses. A deletion of the slot
reverts to the inherited-value lookup.

You might object that this sounds like an object as a (pseudo)hash,
and I will say it is exactly this, but in a more convenient form then
under Perl5 where the language spec didn't prescribe the default 
implementation and nothing observed it at runtime.


Hmm, and when does P6Opaque enter the scene? Well, I guess there will
be a ringing of the bell(s) and then the above fully dynamic lookup
can be compiled into a fixed index per attribute packed array per object
implementation or some such. And I guess this freezing can be thawed when
needed e.g. for eval and friends. But I wouldn't expect it to be a
cheap operation!

The freeze/thaw can in an additional installment compiled into an
unthawable form that can run without a full-blown VM. But eval and
friends will be simple exception throwers in that environment.

The attentive reader might interject that the delegation to (super)class
breaks down under multiple inheritance. And this is of course correct!
It simply means the programmer has to say something about it in the
definition of the class.

Here is a list of incidents in ascending order of severity:

0: type identity of the slot, identical default value.
   effect => dynamic lookup ends here and yields this default value

1: type identity of the slot, different default value.
   effect => class has to specify default value

2: type compatibility of the slot.
   effect => class has to disambiguate

3: type incompatibility of the slot.
   effect => class has to implement the slot

And yes, I believe a slot accessor looks as follows:

   class Example
   {
  my %private_data;
  my sub source {...};

  has %.data;

  has &.blahh = { %.data };

  # and how about syntactic sugar for this:
  has &.blubber from %.data;

  # private slot
  has &.hidden from %private_data is rw;
  has $.hidden := &.hidden;

  # initialized from class
  has $.cache is rw from source;

  # virtual per instance
  has $.value from {...};
   }

But as usual, all the above is the opinion of a casual participant
on this list without authority.

But it's not my private opinion anymore ;)

By posting it, it has become part of our @opinions since
this $email does ::Perl6::Language :)

BTW, this also gives us: my @twodim has shape(2);
--
TSa (Thomas Sandlaß)

Re: Do I need "has $.foo;" for accessor-only virtual attributes?

[TSa (Thomas Sandlaß)]

Larry Wall wrote:

$x is visible only in the rest of the lexical scope.  In contrast,
$_y would presumably still be visible if the class were reopened.


Which brings me to the question how the name information is told
to a prospective user if the source code of the the first definition
shall not be disclosed. I mean of course there is the documentation
but I thought more of a machine readable form. Some kind of a interface
definition of a package.



:   # or does class scope mean shared by all instances
:   # and lexically scopes per instance?

Class scope is basically package scope.  For instance attributes and
methods the package contains proxies representing the slots in the
actual instance.


Sorry, this proxy is the invocant, right? And the type system ensures
compatibility to the methods expectations. This is to me the whole point
in the method call procedure: to bind the invocant to the variables of
the method with respect to the invocant. Since variables in Perl6 code
bear one of the four sigils &Code, $Item, @Array and %Hash this binding
to the invocant is simply indicated by the . twigil and supervised by
the type system.



Sure, if you want to declare an attribute containing a code reference.
But & doesn't have much to do with the call syntax in any event,
whether you're calling subs or methods.  You can declare an attribute
as &.foo and call it as $.foo without a problem, since it's just
$?SELF.foo() either way, and the accessor methods are not associated
with sigils.  I think $.foo and &.foo are synonymous as attributes,
except insofar as we can probably deduce that &.foo is dealing with
a sub ref and not just any old scalar value.


Sorry, I meant the & sigil as generic Code type markup which includes
in particular methods on behalf of the invocant. Actually I see no
point in assuming sub ref for &. but a ref to a method with the
invocant type as specializer. The type information for an object that
is blessed into a type comes of course from just the artifact from
the blessing, however it is retrieved from the invocant.

So with these two things at hand a method invocation can be spawned:
1) the invocant ref
2) a method ref
All referential expressions in the code block of the method are
bound according to the runtime representation of the object in that
moment.



: >* All roles can write completely private $x attributes that are not
: >	visible outside their lexical scope but are nevertheless 
: >	per-instance.
: 
: I understand that correctly, that $x in
: 
:role Foo { has $x = 7; method foo { $x++ } }
: 
: denotes a reference to an Item from the data environment of the object

: that foo is invoked on.

I don't know what you mean by "data environment".  The second
occurrence of $x denotes the generic proxy declared by the "has"
that represents an eventual slot in the actual instance.  This slot
presumably has no other obvious name to any other role or to the
class that composes this role, though presumably there's an internal
way to get back from a particular slot to the slot's metadata, which
presumably knows which role supplied the definition.


With "data environment" I mean the stuff reachable through the invocant.
The actual type of the invocant and the method's formal invocant type
specify what is available through the link as long as the invocation
persists.



: The type of the $?SELF that Foo is composed into
: obviously is a subtype of Foo. What happens with this hidden payload if
: the object changes its type such that it is no Foo anymore? E.g. by
: undefining the slot &.Foo::foo?

Um, people who undefine functions that are going to be called later get
what they deserve.  As for what happens to $x's slot in the absence
of the lexical reference from &Foo::foo, I expect the metadata would
still have pointers to it so it wouldn't necessarily be reclaimed
unless you told the object that is "undoes" Foo.  Or to look at it
another way, all the objects that "do" Foo have a closure over that
$x proxy, so it's not going to go away until everyone forgets about
the Foo role itself.


Ups, I hoped that the type system would find out mismatches of the
objects actual structure and the methods expectations of it. Essentially
rendering the method in question not applicable to the object anymore.
BTW, what is the inverse operation of bless? Expel?
--
TSa (Thomas Sandlaß)

Re: Do I need "has $.foo;" for accessor-only virtual attributes?

[TSa (Thomas Sandlaß)]

Larry Wall wrote:

The problem I have with "is private" is that, while there may very
well be a trait of that name that you can interrogate, I really
want people to think of the private methods as being in a different
namespace so that there's no confusion about the fact that you can
have a private method and a public method of the same name.  And the
reason I want that is because I strongly believe that private methods
must be absolutely invisible to the public interface, and confusing
the namespaces puts you in a situation where adding a private method
can clobber public inheritance of the same name.

Even worse, it clobbers your private interface.  As soon as you say

method foo() is private {...}

then you can't call $?SELF.foo() and expect to get the public .foo method.
Putting the difference as part of the name forces people to distinguish

$?SELF.foo()
$?SELF._foo()

on the call end.  And the _ has the advantage of being *perceived* as
part of the name.


I start to understand the problem I have with perceiving this.

You think of the name ::foo beeing looked up somehow *in* the object
you want to call on, while I always assumed that the name ::foo is
looked up first. In a method invocation expression this lookup has
to yield a method implementation that has got an invocant type that
is compatible with the one the caller wants to put in.

If ::foo shall not be visible why not arrange for the lookup to fail?
Failing *look*up and invisibility are---linguistically spoken---very
related concepts, or not?

This method-first approach has the added benefit that anyone can place
a compatible method into a lexically closer scope than the one they want
to overwrite. If the closeness still prevents the call because of lacking
specificity a simple

  temp $object does MyStuff;

and a method in scope that is specialized on .does(MyStuff) hardly leaves
outsiders a chance to prevent the dispatch! The same thing without temp
might be construed as anti-social by whomever gave you $object ;)

The otherway round should look more like $?SELF<&foo>() or SELF::foo().
Hmm, and nullary .<&foo> performs the lookup on $_ or some such. Honestly
I don't understand why the vtbl implementation detail of e.g. C++ is
taken as template for Perl6 SMD OO.

Private methods of an object come into play because the dispatch of
a publicly visible method is called. The private method must be in
scope there. The only requirement on the name is to not leak out into
public namespace.



 The problem with

$?SELF.:foo()

is that people see that as a .: operator on the foo method.


Which is a *BIG* problem in an Operator Oriented Language!
--
TSa (Thomas Sandlaß)

Re: Do I need "has $.foo;" for accessor-only virtual attributes?

[TSa (Thomas Sandlaß)]

Larry Wall wrote:

has $x; # private rw, no accessors, not virtual, name lexically scoped

has $_x;# private rw, rw _x accessor, not virtual, name class scoped


Even if I come across as intellectually handicapped but could
someone help me over this mental bridge: What is the difference
between these two scopes?

class Foo
{
#class scope starts here

  has $x;  # where does this go if not Foo::x

  has $_y; # this goes into Foo::_y

  # both $x and $_y can be used in code from here on
  # and refer to the same two things respectively, right?

  # or does class scope mean shared by all instances
  # and lexically scopes per instance?

#class scope ends here
}




Other thinkings:

* Any self method can be called via $.x(@args) syntax, short for
$?SELF.x(@args).


Isn't & the code sigil?




* All roles can write completely private $x attributes that are not
visible outside their lexical scope but are nevertheless per-instance.


I understand that correctly, that $x in

   role Foo { has $x = 7; method foo { $x++ } }

denotes a reference to an Item from the data environment of the object
that foo is invoked on. The type of the $?SELF that Foo is composed into
obviously is a subtype of Foo. What happens with this hidden payload if
the object changes its type such that it is no Foo anymore? E.g. by
undefining the slot &.Foo::foo?


Regards,
--
TSa (Thomas Sandlaß)

Re: Do I need "has $.foo;" for accessor-only virtual attributes?

[TSa (Thomas Sandlaß)]

HaloO Sam,

you wrote:

This in turn implies that the $.foo syntax is, in general, bad
practice!


Yup.


I claim the opposit. But I might have a very different meaning in mind
when I say that. So it's opposit in an orthogonal direction :)



Not very huffmanised, is it?


The syntax is just right for the statefull, imperative programming style.
If that is not your thing, so be it.


Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute 
$.SUPER::foo


Hmm? Isn't a $ sigil expression a single scalar typed, referential
expression anymore? The secondary . sigil is in my eyes just perfect
to express self reference! If I use %.arm to scratch %.leg
it is pretty much clear which particular parts of my body are involved.
And if I give a rw reference to $.guts to a surgeon method it is just one
possible result that some parts have become undefined or look funny ;)

And yes, this means a *dynamic* change of self type! E.g. a changing
$.belly_circumference could change a man from .does(LeightWeight) to
.does(HeavyWeight).

What I do *not* understand is what or where $.SUPER::brain should
refer to. If Perl6 avoids the problem of 'schizophrenic self reference'
where some methods make false assumptions about the object layout
or have access to hidden parts then all methods which shall be applicable 
to the object's referential environment must be type sound. This means for
example that the type system prevents dispatches to base class methods 
even though the invocant is instanciated from a derived class. This is a

typical example where Rotweiler instances are *not* a subtype of Dog
instances---at least not as far as playing is concerned.

The example with the $.collar in the Rotweiler class could be
solved by forcing the slot into outside constness which has
the side-effects that the Pet::loose_collar method is not applicable
and thus the $?SELF.lose_collar() call in Dog::play has to dispatch 
elsewhere or fail! In other words: Rotweiler.does(Dog::play) is false!

A strong type system can find that out, a weaker one let's the code
die in Pet::loose_collar on const assignment.


Then we could even sneak in making $.foo(bar) a not-so-offensive 
./foo(bar),

with ($.foo)(bar) meaning what $.foo(bar) currently means.  But that really
is a seperate issue, and speculation of it meaningless if we retain the
current specified behaviour.


I'm seeking a solution along the ideas of homogenious self reference
as outlined above. This would e.g. allow the &.foo code ref to mean
a ref to the most specific method applicable to the self type unless
the programmer has arranged that something else is stored there.
As long as the method requires arguments there is just the one char
inconvenience of typing &.foo(1,2) instead of .foo(1,2) or whatever
syntax implicitly derefs and calls &.foo with $?SELF as the invocant.

Then there is also room for some dwimmery for dispatching .foo through
$?SELF when the type of $_ would fail the dispatch. So from a certain
point of view I like $Larry's ruling that the compiler has to statically
insure that the self type puts the invocant into a fair position for the
dispatch at hand. Perl6 is (type)strong in the source ;)


Another thing I do not understand from a typing point of view is how
perlkind expects a simple .foo expression in the lexical scope of a
class which defines a method foo to be usefull on a random $_ with a
type that is incompatible with the $?SELF type of the invocant of the
method that this .foo call happens to be written. An example:

   class FooDefiner
   {
  has $.text = 'FooDefiner hit';

  method foo { say $.text }

  method foocaller
  {
 for 1..3 { .foo } # 1
 for 1..3 {  foo } # 2
  }
   }

I think compile time name lookup in both lines resolves to
&FooDefiner::foo which requires a self type of ::FooDefiner
and I think that Int.does(FooDefiner::foo) is false. So an
invocation of &FooDefiner::foocaller would simply produce
a type error or six warnings and no printout if the foo calls
are dispatched over $_, right?


Regards,
--
TSa (Thomas Sandlaß)

Re: Referring to package variables in the default namespace in p6

[TSa (Thomas Sandlaß)]

HaloO Matthew,

you wrote:
I wasn't getting hung up on whether $::($varname) should somehow be 
cached to avoid a dynamic lookup based on the current value of $varname 
every time.  And I assume that if $*Main::foo hadn't been created, 
assigning to $::($varname) would create it as expected (again, without 
any caching of $varname).


Here your expectations might be disappointed, sorry.

The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.

Unfortunately I'm unsure how the runtime interface to
making dynamic namespace entries looks like. Note that
the operator ::= acts at compile time, too.

My guess is that the compiler collects all potential data
items and arranges for auto-vivification and/or autoloading
and even on-the-fly instance composition and such like things.
But for symbolics this is your task.


My confusion initially stemmed from chat on #perl6 about $::Foo and 
$::('Foo') being Very Different Things - and the fact that there was 
ever any confusion over whether $::foo was your 'closest' $foo variable 
or something else.


So to conclude, for reading they amount to the same result but through
different paths. But since the symbolic lookup might result in undef
the behaviour for writing is indeed a Very Different Thing.


@Larry, please correct if I gave wrong advice.
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

chromatic wrote:

Why would a class not also define a type?


It does. A class is an instance generator. So all instances
share the same property of 'beeing instanciated from SomeClass'.
This can be used to type them. Question is where this type is
placed in the type lattice and how it compares to the type of
structurally/semantically identical objects beeing instanciated
from another class.

My proposal is to hang the type off the top, most unspecific
type Any or actually a bit further down, under Object
which excludes Package, Module, Class, Grammar and Role.

The name of the class is inserted in the appropriate place into
the namespace and is available as type parameter for the Ref[::T]
role.

It is actually quite interesting that there is no special form
for compile time object instantiation with the keyword object.

   class Point
   {
  has Num $.x;
  has Num $.y;
   }

   object center of Point  # without of we get classless objects
   {
  .x = 23;
  .y = 42;
   }

   object pi of Num = 3.14;

   our Int object answer = 42;

   say answer;  # prints 42
   say center.x # prints 23

   # and even more

   our Array object some_values = (1,2,3,4,5);

   for some_values { say }

Hmm, looks somewhat unperlish :))
--
TSa (Thomas Sandlaß)

Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)

[TSa (Thomas Sandlaß)]

chromatic wrote:

On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:

I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of

class   Foo {...}
roleFoo {...}
sub Foo {...}
method  Foo {...}
subtype Foo of Any where {...}

in the same scope should be a simple redefinition/redeclaration error.



I don't understand this.  What does a scope have to do with a namespace?


I meant a scope of source code, basically everything delimited by braces.
And that nesting of braces *is* the namespace, or not? Well, at least the
compile time view of it.

The Perl6 namespace is available at runtime as well. But it is beyond me
how much these differ. But for the specification of the language only the
source code aspect is relevant.



Why does a code object constitute a type?


Is this more a 'how do function types work' question or
are you doughting the usefullness of this concept for Perl6?

The sort function e.g. takes a parameter of type Comparator
which is a code type describing instances that accept two parameters
of the type that is to be sorted and return a value of a type
that describes the relative order implemented by the comparator.

Actually the Comparator is usually a parametric type, that is
instanciated with concrete types and thus forming a non-parametric
code type. The invokation of such a type are the instances of the
type. During a sort run many of these instances are created.



I can understand there being separate types, perhaps, for Method,
Submethod, MultiSub, MultiMethod, and so on,


... and subtypes thereof.


but I don't understand the
purpose of sharing a namespace between types and function names,


What should 'mysubtype' in the following signature

  sub blah ( mysubtype &sref )
  {
  my Int $x = sref( "Str", 23, Foo.new );
  }

mean if not a constraint of the type of &sref?
Above it is used as a function that accepts (Str, Int, Object)
and returns Int. Depending on the definition of ::mysubtype
this usage is erroneous or not. I ask myself---or @Larry---how
the same effect could be achieved without the indirection through
a name. Perhaps:

  sub blah( Code[Str, Int, Object --> Int] &sref )  {...}

The same question arises when ::subtype shall be declared:

  subtype mysubtype of Code[Str, Int, Object --> Int];

  subtype mysubtype of Code:(Str, Int, Object) returns Int;



nor of
having funcitons declare/define/denote/de-whatever types.


Here's an attempt of code joke around foo (ignore at will)

class foo
{
   submethod postfix:{'( )'} ( $x ) { say $x }
}

sub foo( &foo ) { say foo }

sub bar ( foo $foo, foo &foo )
{
   $_ = foo.new;
   my foo $f = \foo;
   my foo &f = \foo;
   my foo @f = foo;
   say foo(23);
   say .(42);
}
--
TSa (Thomas Sandlaß)

Re: Referring to package variables in the default namespace in p6

[TSa (Thomas Sandlaß)]

Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have 
been better at illustrating my point - which was that if $::($Foo) 
searches outwards through namespace for a variable whose name is held in 
$Foo, then $::Foo should end up referring to the same variable.


Let me restate that in my own words. You mean that a symbolic runtime
lookup $::($Foo) with the value of $Foo at that time shall be cached
in the immediatly surrounding namespace and that cached ref is then
accessable through the syntax $::Foo?

My understanding is that the expression $::($Foo) is *always* triggering
dynamic lookup with the then current value of $Foo. If this is not what
you want then say so with one of these:

my$FooCache := $::($Foo); # everytime when dynamic scope is entered
state $FooCache := $::($Foo); # once and for all

Otherwise

   for ("blahh", "fasel", "blubber") -> $name
   {
$::($name) = 42;
   }

wouldn't be really usefull. BTW, I wonder if $::() means $::($_) :)

Otherwise the two $::... forms would be horribly confusingly different 


Sorry, they are the same thing: namespace lookup. But without ::() the
compiler does it at compile time for bareword resolving. Without a sigil
in front the result can be used where a type is expected:

   for ("blahh", "fasel", "blubber") -> $name
   {
::($name).new;
   }

We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
I dought that assigning two different meanings just because their
are two syntactical forms is a good idea.

in their behaviour, and I (and other future legions of newbies) would 
despair. :)


You consider yourself a 'legion of newbies' ;)
--
TSa (Thomas Sandlaß)

Re: Referring to package variables in the default namespace in p6

[TSa (Thomas Sandlaß)]

Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for 
$::Foo. Is that the leaf name variable Foo in your current (innermost) 
namespace?


It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost names to
their body:

sub foo ( $param )
{
   say $::param; # prints argument bound to $param
   say $param;   # same

   say $OUTER::param;  # prints value of result of a lookup
   # that starts outside of sub foo

# but
   my ::param $x = ::param.new; # look for param type info

   # The above compiles preliminarily but eventually needs
   # a type param. If the only name that is in scope is the
   # formal param then I presume a late compile error occurs.
   # Well, or the runtime *value* of $param is taken as the
   # type which essentially renders $x a constant.

# and
   my param $y = param.new; # works only if param pre-declared.

# Also
  say  param(); # requires a code type to be in scope
  say ¶m(); # same with late binding
  say .param(); # late binding with method sigil
}

Interesting question is how the last two lines above behave depending
on whether ¶m.does(Sub) or ¶m.does(Method) and what light
that sheds on the $?SELF.method problem :)



Or is it an attempt to dereference the disambiguated type Foo?


What is the use of reference to a type? The compiler, dispatcher
and class and object composer need type information to do their
job, of course. And they might handle this information through
refererences. But when this happens the source is already digested.

In other words you just can't use a sigiled expression where a type
is expected: my $::Foo $x; is just a syntax error. This is why I regard
the sigils as type mark-up. That means writing $Foo or $::Foo just
tells the compiler that you want to handle the item Foo.



 Or is it like perl5, shorthand for $*Main::Foo?


This is clearly specified as not beeing the case.


Is there any reason why $::Foo could not do both, and not start by 
searching your current namespace for a variable called $Foo... and then 
start searching your current namespace hierarchy for a type called Foo 
and try to dereference it (whatever that does)?


This is my position if I read the double negation correctly.
Sorry if that wasn't clear initially. But I hope the above rants
clarify what I mean.


Presumably it should behave in precisely the same way that $::('Foo') 
does for sanity - does that search the current namespace for just types 
or variables or both?


Not for sanity. $::Foo is just syntactic sugar for $::('Foo') because
'Foo' is a compile time constant. But $::( some_calculated_name ) might
not in general be evaluateable at compile time and thus forces the
compiler to generate symbolic lookup code which
1) calls some_calculated_value
2) starts lookup with the stringified return value

Note that because of the $ sigil it looks for something that does the
Scalar/Item role! We can consider the sigils as lookup filters.

Regards,
--
TSa (Thomas Sandlaß)

Re: Referring to package variables in the default namespace in p6

[TSa (Thomas Sandlaß)]

Matthew Hodgson wrote:

On Tue, 19 Jul 2005, Larry Wall wrote:

The * looks like a twigil but it isn't really.  It's short for "*::",


Is *:: going up to the outermost Perl6 bubble or to the interpreter
that handles it? I mean where do gateways to other languages show
up: parallel to *::Perl6 like *::Python, *::Ruby or one below that?
Actually both might make sense. The pure *::Language goes for Parrot
level barebone inter language while *::Perl6::Language goes through
Perl6 wrappers/adapters.

Or would the differentiation between

  $*Foo#  $*::Perl6::Foo

and

  $*::Foo  #  start at interpreter level

be too subtle? Hmm, it might be needed to disambiguate *foo
which could mean 'call outermost foo' or 'call innermost foo and
cast return value to list'. Well, or the prefix ops * and **
need whitespace then: * *foo; ** *foo;



where the * is a wildcard package name, so in theory we could have
$=*foo, meaning the $=foo in the *:: package.  (But most of the
twigils imply a scope that is immiscible with package scope.)


I still consider sigils/twigils as minimum type mark-up---or make-up :)


I'm very surprised that package variables end up in OUR::, however - 
because surely they're not necessarily lexically scoped - and the whole 
point of 'our' was lexical global scoping, right? :/


Sorry, what is 'lexical global scoping' e.g. compared to
non-global lexical scoping? Is it not so, that conceptually
a program that is loaded from several files can be seen as
a complete nesting of all used packages, modules, classes
etc. where the file scopes are replaced by pairs of braces?
The care takers of OUR:: are the package, module, class and
role meta classes while MY:: is handled by everything in braces
basically.

This at least is how I think of lexical scoping.
Correct me if I'm wrong, please!


I've tried to wrap my head around all these behaviours of :: and 
summarize them here for future readers: inevitable corrections more than 
welcome ;)


::Foo  # leading sigil: disambiguates Foo as being in type space
$Foo::bar  # trailing sigil: indicates preceding term is in type space

> $Foo::Baz::bar # separator: type space hierarchy separator


::($foo)   # special case leading form which behaves more like the
   # trailing sigil & separator form for building up type
   # terms from expressions, as ($foo):: would be ambiguous.


Isn't it easier to say that :: is a unary/binary, right associative
pseudo operator with the following properties:

1) whitespace around :: is not allowed
   -> whitespace to the left stops outwards scanning
   -> this allows ?? ::

2) its rhs is the leaf name you want to refer to

3) the lhs is the namespace path to that leaf

4) a * wildcard starts lookup from the root
   (for details of *Foo versus *::Foo see above)

5) parentheses cause symbolic runtime lookup, otherwise
   the lookup is at compile time and needs pre-declared
   names because there are no barewords

6) a sigil determines the type you want to refer to:
   ->  no sigil means autoderefed---that is called---Code
   ->  whitespace means a type (if more than one leaf
   matches because the name is overloaded the least
   upper bound (lub = any type junction) supertype is
   returned.

   Question: how are sigil and name lookup prioritized? I mean
 does a matching sigil type further outwards, and
 when a path is used from there inwards, overwrite
 a closer type mismatch? My guess is: 'sigil rules'.

   Question: does .::Foo::bar parse and does that also work
 for private data access in class scope like .:::Foo::bar
 or .::Foo:::bar? In the first case :Foo is a trusting
 private sibbling whose .bar method shall be called.
 In the second example the private method .:bar from the
 one-outwards scope Foo shall be called.


I assume that I am correctly following your lead in referring to 
package/module/class namespaces as 'type space' here...


Hmm, if that is the name for nameespace now, so be it. But to me
it is still the plain old strictly tree-structured name space
lookup. The point is that what you---or actually the compiler---
get from there is *type* information!


As regards $::foo, making a special case for it being a synonym for 
$*Main::foo be yet another complication entirely without precedent in 
the current behaviour.  But then again, using $::x in the past as a 
quick way to disambiguate between lexical & package variables in simple 
package-less scripts was quite handy...


The question that nags me is where autovivified variables go to
and when. I think the compiler has the information about all lexicals
and could put them in the right place in the name space tree *before*
execution. Would that be at CHECK or INIT time?
--
TSa (Thomas Sandlaß)

Re: User-defined behaviour of hashes in list context

[TSa (Thomas Sandlaß)]

HaloO Ingo,

you wrote:

according to Damian [1]...:

my %hash  = (a => 1, b => 2);
my @array = %hash;
say @array[0].isa(Pair);  # true

How can I override this behaviour?

class MyHash is Hash {
# Please fill in here


  # my idea is to overload &*infix:<=>

  multi method infix:{'='} ( Array @a, MyHash +%h )
  {
  # your stuff here ...
  # in particular you have access to your private attrs
  # and methods
  }

}

my %hash is MyHash = (a => 1, b => 2);
my @array  = %hash;   # should call my own routine


I hope the initialisation in my also calls the overloaded
operator. But why shouldn't it?
--
TSa (Thomas Sandlaß)

Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)

[TSa (Thomas Sandlaß)]

HaloO chromatic,

you wrote:

Have I mentioned before that I think you should be able to say:

class Foo
{
method foo { ... }
method more_foo { ... }
}

class Bar does Foo
{
method foo { ... }
}

... probably get a compile-time error that Bar doesn't support
more_foo()?


We've discussed that when I was ranting about the type lattice
and co- and contravariance...

I'm not sure what my position back then was but now I agree
because I see CLASS as a subtype of ROLE. The only problem
is that $Larry said that he doesn't want parametric classes.


I see a reason to differentiate between roles and classes on the 
metalevel, but the argument is not as strong on the user-level.



I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).


I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of

class   Foo {...}
roleFoo {...}
sub Foo {...}
method  Foo {...}
subtype Foo of Any where {...}

in the same scope should be a simple redefinition/redeclaration error.
OK, sub and method can escape from this fate by means of the keyword
multi and different sigs.

Since sigils somehow define references &Foo could mean e.g. a classref
while ::Foo could be a Code type. If we then also promote . to a primary
sigil for Method... hmm have to think about that!
--
TSa (Thomas Sandlaß)

Re: How do subroutines check types?

[TSa (Thomas Sandlaß)]

Ingo Blechschmidt wrote:
How do I have to annotate the type specification in the 
declaration of the subroutine to not include the class Foo, but 
only allow instances of Foo? 


My understanding is that Foo.does(Foo) is false and sub params
are checked with .does(). This automatically excludes class args.
That is you have to explicitly order them:

sub blarb (Foo|Class[Foo] $foo, $arg) # or with CLASS[Foo] ?
{
   ...;   # Do something with instance or class $foo
}

Foo|Class[Foo] is a supertype of Foo and Class[Foo] and as
such allows its subtypes Foo and the Class[Foo] parametric
role instanciation. Note that Foo|Class allows calls like
blarb( Int, "HaHa" ).

Actually I'm not convinced that class Foo should automatically
constitute a (proper) type other than Any. But since .does falls
back to .isa it comes out the same since the only way here to get
a Foo doer is by instanciating the class Foo.
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

rather than
dwimmyness*.  A module author who /inserts/ a type in the standard
hierarchy can change the semantics of things that aren't aware that
that type even exists.  If you're going to go messing with the
standard types, you'd better be clear about your abstractions, and if
you're not, the program deserves to die, not "dwim" around it.


I second this. The dwimminess would lead to half-cooked handling
if the dispatch doesn't hit the most specific handler. Or in other
words the bar is raised higher for modules that want to add types
to the standard hierarchy.


That *might* be an argument that builtins ought to do "pure ordering" 
dispatch, but it isn't an argument in the more general case. Most people 
won't be futzing around with the standard type hierarchy, except at the 
leaves, where it doesn't matter. Most people will be using MMD for 
applications development, on their own type hierarchies. Someone who's 
(for example) building an image processing library wants to be able to 
add/merge/mask any two image types using the most specific available 
method. Adding a new image type (or supertype) might change which method 
is most specific, but won't change the image processor's desire. Indeed, 
changing the dispatch to a now more-specific method *is* the image 
processor's desire.


Ohh, no. Take e.g. alpha blending. If you add that to a former
implementation that handled monochrome and RGB one doesn't want to
be unsure if it happens or not just because three Grays outperformed
one Alpha in the style of 0+1+1+1 > 1+0+0+0. Changes to the type
hierarchy *are* major changes. A type declares *what* is done while
a class defines *how* it is done. And with roles it is quite easy to
get more than one class implementing the same type.


So, in counter-conclusion, Pure Ordering MMD maximizes ambiguity and 
thereby imposes extra development costs to achieve (generally) the same 
effect as Manhattan MMD achieves automatically. Both schemes can be made 
to detect ambiguities, and under both schemes those ambiguities can be 
resolved by the judicious addition of either variants or interim 
classes. However, by default, when POMMD detects an ambiguity, it just 
gives up and makes that ambiguity fatal, whereas MMMD always 
automatically resolves ambiguities in a plausible manner. I know which 
approach I'd prefer.


That sounds to me like the easier approach of C's implicit type
conversions where C++ requires at least a brutal cast to get it
through the compiler. Also CLOS and Dylans approch to MMD by means
of class precedence lists is not considered a success by many.
Unfortunately I have no large project, long term experience with
these languages.

Well MMMD also gives up if there is more than one target
with the same distance. Would you also argue in favour of
secondary disambiguation? E.g. by averaging over the summands
such that 2+2+2 is better than 1+1+4?


I think we should discuss the intentions of classes, roles and
constraints and how they relate to the type system.

If Perl6 wants to live up to the claim of (optional) strong typing
then the dispatch must be first on the type lattice and then on the
class hierarchy. The folks who don't want to adhere to typing might
avoid the type dispatch and appear to the type dispatchers as Anys
or some scoped package or module type.

Regards,
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

HaloO Larry,

you wrote:

Implicit is that role distance is N + the distance to the nearest
class that incorporates that role for small values of N.

If class Dog does role Bark and also does role Wag, then passing a
Dog to

multi (Bark $x)
multi (Wag $x)

should result in ambiguity.  The interesting question is whether N should
be 0 or 1 (or possibly epsilon).  If we have

multi (Bark $x)
multi (Dog $x)

arguably Dog is more specialized than Bark, which says N maybe
shouldn't be 0.  Whether it should be epsilon or 1 depends on how
you think of role composition, and whether you think of roles more
like immediate parent classes or generic paste-ins.  You can think
of them as immediate parent classes, but in that case they're actually
closer than a real parent class that would have distance 1, since
role methods override parent class methods.  That argues for N < 1.


Sorry, has Perl6 now reverted to setting classes above types?

I would think that the programmer specifies what type a class
implements by letting it do a set of roles. This implies that
by default a class does the very unspecific Any. In your example
the type system needs the information if Dog does a supertype or
subtype. The syntax could be junctive:

class Dog does Bark | Wag {...} # union type (least upper bound)
class Dog does Bark & Wag {...} # intersection type (greatest lower bound)
class Dog does Bark , Wag {...} # same as & or typeless composition?

If Dog is made a supertype then neither multi (Bark $x) nor multi (Wag $x)
is in the applicability set. For the subtype case both are applicable
and an ambiguity type error occurs. This needs disambiguation through
defining multi (Dog $x). The question is at what time this error occurs
and what restrictions allow a compile time detection. Note that the
ambiguity doesn't go away with a metric approach because there are no
other parameters that could compensate.

Regards,
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

HaloO Damian,

thank you very much for your explaination. I just want to hint the
Perl6 community to the fact that there exists a US patent on geometric
MMD:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=ferragina.INZZ.&OS=IN/ferragina&RS=IN/ferragina

I haven't check the relevance to Perl6 yet.
Has someone access to the STOC'99 paper?
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

HaloO Larry,

you wrote:

On Tue, Jul 12, 2005 at 08:13:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Actually it's a pitty, that the multi method call syntax isn't as
: rich as the single method call syntax where we have .?method, .+method
: and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo
: doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)?

It doesn't seem to make much practical sense.  Multimethods are
generally written to be exclusive of ancestral methods.  Ordinary
methods are generally written to be cumulative with ancestral methods.


Interesting that we are thinking in orthogonal ways. I was arguing
for a syntax that allows the caller to prevent 'no method' and 'method
ambiguous' errors with .?() and .+() respectively. And .*() would prevent
both. In the ambiguous case all applicable targets would be called in an
undefined order.

Is there also an answer to the odering versus metric question?
Why was the former rejected and the latter choosen?
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Mark Reed wrote:

On 2005-07-12 12:22, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]>
wrote:


I am also interested in the rationale behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which in my eyes doesn't fit type
theory. 



The geometric interpretation does bring us into somewhat philosophical
territory. Not that that's anything new on this list. :)

Let me try a concrete example.  Suppose that class Answer has subclasses
Animal, Vegetable, and Mineral, with respective subclasses Dog, Potato, and
Diamond.  There are two methods named foo in scope, neither overriding the
other.  One is declared to take (Animal, Vegetable, Mineral), the other
(Dog, Potato, Answer).  Assuming the obvious memberships, which method
should foo(Snoopy, Mr_PotatoHead, HopeDiamond) call?  And more importantly,
why do you feel that is the right answer?
 
According to Damian's metric, we have distances of 0+0+2=2 and 1+1+1=3, so
(Dog, Potato, Answer) is "closer" and would get called.  


Uhh, both targets are applicable but none is more specific on all
positions. I would like this to be an "ambiguous dispatch" error.

Actually it's a pitty, that the multi method call syntax isn't as
rich as the single method call syntax where we have .?method, .+method
and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo
doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)?
--
TSa (Thomas Sandlaß)

Re: How to write a self.pm (Re: method calls on $self)

[TSa (Thomas Sandlaß)]

Autrijus Tang wrote:

The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set.  It is not trivial, because this should work:

sub baz (&c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure

But this needs to fail:

sub baz (&c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure


I might still not understand topic, $_ or lexical vars in general.
But why does the fact that &c is called with a parameter
in the second case and without one in the first example make a
difference? Isn't $_ always coming in out of band? So .bar is always
invoked on the invocant of &foo if we think that there is an implicit
$_ := $?SELF before the call to &baz in &foo.  And I hope the binding
of $_ to $?SELF is a read-only binding!
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Damian Conway wrote:

This is a much less dwimmy solution than Yuval's or Luke's, but it has the
advantage that those eight steps reduce to eight words:

Unique least-inherited most-specialized match, or default


Do I read this correctly as dispatching partly in the class hierarchy
and partly in the type hierarchy? Or do you mean with 'least-inherited'
most specific non-where type and with 'most-specialized' the strictest
where clause? To me these two concepts are the same if you think of the
does operator as a predicate:

multi sub foo ($x where { $x.does(Num) }) {...}

beeing the same as

multi sub foo (Num $x) {...}
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Mark Reed wrote:

And one more dumb question: why is it that the L[1] metric is superior to
the L[2] metric for this purpose?


I am also interested in the rational behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which in my eyes doesn't fit type
theory.

I would join Luke and recommend 'pure' MMD. That is there has to
be exactly one target that is most specific on all positions relevant
for the dispatch. In particular do I dislike the the property of a
metric that several smaller mismatches can be compensated by a good match.
--
TSa (Thomas Sandlaß)

Re: Hackathon notes

[TSa (Thomas Sandlaß)]

Luke Palmer wrote:

Anyway, I think that once we start diving inside expressions to
measure their specificity, we've gotten too complex to be predictable.


Well, we don't have where clauses, but where closures! The former
should be a declarative sublanguge like regexps. They are evaluated
at compile time or type instanciation time or however it is called
and entered into the type constraint environment where the MMD looks
for it. For the latter a warning should be produced and they are *not*
considered for MMD other than applicability checking. They are of
course called for non-invocant params, in assignments etc.

For research on the topic see e.g.
http://www.cs.washington.edu/research/projects/cecil/www/Papers/predicate-classes.html
--
TSa (Thomas Sandlaß)

Re: Hackathon notes

[TSa (Thomas Sandlaß)]

Autrijus Tang wrote:

* deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception


That is because &postfix<++>:(Ref) doesn't exist, right?



* sub foo (?$x, ?$Inf) {}
  my $y = (x => 3); foo($y); # binds $x
  my $z = (+Inf => 3); foo($z); # binds $Inf


Isn't the lhs of => autoquoted? Why does '+Inf' as key bind $Inf?



* Constrained types in MMD position, as well as value-based MMDs, are _not_
  resolved in the type-distance phase, but compile into a huge given/when
  loop that accepts the first alternative.  So this:

multi sub foo (3) { ... }
multi sub foo (2..10) { ... }

  really means:

multi sub foo ($x where { $_ ~~ 3 }) { ... }
multi sub foo ($x where { $_ ~~ 2..10 }) { ... }

  which compiles two different long names:

# use introspection to get the constraints
&foo
&foo

  which really means this, which occurs after the type-based MMD tiebreaking
  phase:

given $x {
when 3 { &foo.goto }
when 2..10 { &foo.goto }
}
  in the type-based phase, any duplicates in MMD is rejected as ambiguous; but
  in the value-based phase, the first conforming one wins.


I hope that is a temporary "solution". Usually one would expect 3 beeing a
more specific type then 2..10 irrespective of definition sequence.



  The upshot is that these are now errors:

sub foo ($x) is rw { $x }
my $a;
foo($a) = 4;# runtime error - assign to constant


I assumed lvalue subs would implicitly return void and an
assignment goes to the function slot of the args used in the assignment
and subsequent calls with these args return exactly this value.
In that respect arrays and hashes are the prime examples of lvalue
subs. Other uses are interpolated data, Delauny Triangulation etc.


Regards,
--
TSa (Thomas Sandlaß)

Re: Type variables vs type literals

[TSa (Thomas Sandlaß)]

or "ouring" the type.
[Or at least I did want it.  I change my mind below.]

So currently the above would be a syntax error.  We don't want
::TypeRef to behave differently in

my ::T;
my ::T $foo;

They should either both declare ::T, or both refer to an existing
type literally named "T".  That's where the ::-as-a-variable-sigil
idea breaks down.

[..]

Okay, you've used ::Type as a type variable--now how do you declare
that you simply want Type treated as a forward declaration of "Type".
I'm not quibbling with the desire to bind types to type variables.
It's just we've got a conflict in the definition of what :: means
that we'll have to resolve one way or another.


I don't want value-like type variables because that would generate
a big mess if one wanted to store type refs in value vars:

my $typeref = $object.type;

my ::$typeref $same_type_object; # do we want this?
my $typeref $weird; # or even this??

The only use of type variables is in parametric types. And since
you want to restrict that to roles the need for implicit type binding
shifts onto the does operator and role instanciation. But how automatic
will your example

role FooStuff[T] {
sub foo (T $x, T $y) { }
...
}

be instanciable? I guess the explicit forms are:

   FooStuff[Int]::foo(1,2);

   &strfoo ::= (FooStuff[Str].new)::new; # from Autrijus Hackathon notes

Will re-instanciation be prevented when the latter is spelled

   &strfoo := (FooStuff[Str].new)::foo; # or with =

Actually this syntax might be wrong usage of ::.

But do I get you right that the lazy forms are

   does FooStuff; # lazy role instanciation into current scope

   foo(1,2);   # &FooStuff[Int]::foo:(Int,Int)
   foo(1,'blahh'); # type error?

Regards,
--
TSa (Thomas Sandlaß)

Re: Time::Local

[TSa (Thomas Sandlaß)]

Juerd wrote:

I think the problem one has is much bigger even if a day *number* is
ever displayed. Then beginning with 1 because that's where most humans
begin counting, is wrong. It's a technical thing, and that should be
kept as simple as possible, and as technical as possible, for easier
compatibility with existing technical things.


As a technical remark I like to point out, that you need 8 time points
to define 7 days. Every day is bounded by two such time points---which are
of course 24 hours apart. This is necessary to get the arithmetic right!
Weekday arithmetic is modulo 7. Or put differently

   $week.end() - $week.start() == $week.length == 7 days

must hold. If e.g. you start your week with Monday than this becomes

   $Sunday.end() - $Monday.start() == 7 days.

The next order of precision in calender arithmetic is the hour *within*
the day, then minutes and seconds. The weeks themselfs are subdivisions
of years. And the scheme is not completely regular in e.g. the Gregorian
calendar---but almost e.g in the Sym454 calendar which only has leap
weeks.

I think, that this type of integer with remainder arithmetic shows up
in Perl6 in other places as well. E.g. chars in strings depending on the
Unicode level and index arithmetic of arrays. Some unification of the
underlying math would be nice, indeed. And that typically involves
starting from 0 and the positive remainder pointing into the day.

Regards,
--
TSa (Thomas Sandlaß)

Re: Submethods

[TSa (Thomas Sandlaß)]

Stevan Little wrote:
You seem to indicate that submethods are not to be used on instances, 
and instead to be used on the underlying metaclass. I did not see 
anything of the sort in (Syn|Apoc)12 or in my (limited) search of the 
mailing list. Can you point me to that information?


S12 says in the section Submethods: "A submethod is called only when a 
method call is dispatched directly to the current class."


And without finding a reference I think it was said that "the invocant
of a submethod is a class object".

From this I have derived what I said. Nonetheless there seems to be
some overlap in particular in the construction process which is
characterized as involving an unitialized object. So in that case
some macro magic might make the instance available to the submethod.
But this will be a non-invocant parameter.

But mind the sig!
--
$TSa =:= all( none( @Larry ), one( @p6l ))

Re: Type variables vs type literals

[TSa (Thomas Sandlaß)]

HaloO Larry,

you wrote:

Well, there's something to be said for that, but my gut feeling says
that we should reserve the explicit generic notation for compile time
processing via roles, and then think of run-time lazy type aliasing


Could you explain what exactly 'run-time lazy type aliasing' is?
I mean what does it achieve and how does it compare to type
instanciation and parametric contraint checking?



as something a little different.  So if you really want to write
that sort of thing, I'd rather generalize roles to work as modules
containing generic subs:

role FooStuff[T] {
sub foo (T $x, T $y) { }
...
}

Otherwise people are tempted to scatter generics all over the
place, and it's probably better to encourage them to group similarly
parameterized generics in the same spot for sanity.  It also encourages
people to instantiate their generics in one spot even if they're
calling them from all over.

[..]

I think people should say "does FooStuff[Int]" and automatically alias
all the routines to the Int form so we don't have to scatter :[Int]
all over.  Or if they just say "does FooStuff", they get lazily-bound
type parameters.


I get that right, FooStuff can be instanciated without a class or object?
Something like unary operator does? Into which scope do these role 
instanciations go? Does "does *FooStuff[Int]" mean global?




: >::T $x := $obj;
: >my T $y = $x;
: 
: The prime use of that feature is to ensure type homogenity for

: temporary and loop vars in a certain scope. But the scope in the
: above syntax is not apparent enough---to me at least.

Actually, I was holding those up as bad examples of scope visibility,
so I'm agreeing with you there.  (Which is why I suggested that we
require a "my" context, even if only implied by the formal paramter list.)

: Thus I opt for an explicit
: 
:subtype T of $obj.type; # or just $obj perhaps?

:T $x := $obj;
:my T $y = $x;

Yuck.  I think that completely obscures the lazy type binding.
Plus you've managed to omit the "my", so you've created a global
subtype T.  (Unless, as I'm leaning towards, we make such bare "inner"
types illegal, and require "my", "our", or "*".)


The only thing I did was to replace the :: sigil with a subtype
declaration. Does subtype always go into global scope? I thought
that it requires a *name to go into global and our to go to the
innermost module---or was that package? I mean even non-declared
auto-vivified vars go into the immediately surrounding scope,
or am I horribly mistaken?

sub foo()
{
   if (1) { $x = 'from above' }
   if (2) { say $x }  # prints 'from above' even if no outer $x exists?

   say $x; # prints undef or 'from above' if outer $x
}


Up til now I assumed that ::T and plain T mean exactly the same if T
is pre-declared/defined. The type sigil is only needed to defer the
definition/binding. In a certain sense this is a hanging type reference
similar to &foo beeing a reference to Code. Which brings me to the
question how to bind a type reference. I mean we have

my &fooref := &foo

which allows fooref() calls, right? How are type references derefed
if not by dropping the sigil? ::TypeRef() perhaps?

my ::TypeRef; # type variable?

sub make ( ::Type, Type $value ) returns Type
{
   if (::TypeRef != ::Type)
   {
  ::TypeRef = ::Type;
   }
   my Type $x;
   $x = $value;
   return $x;
}

my $i = make(Int, 17);
my @a = make(Array, [1,2,3]); # single element array?
  # or three element array?

my $e = make(Int 'string'); # type error in &make?

With the automatic binding of a ::Type variable to the type
of it's argument the definition of &make could be shortend to

sub make ( ::Type $value ) returns Type
{ ... }

and called like this

my $i = make(17);

which at least prevents type errors ;)


Regards,
--
TSa (Thomas Sandlaß)

Re: Submethods

[TSa (Thomas Sandlaß)]

Stevan Little wrote:
The concept of non-inherited infrastructural methods is fairly simple to 
accomplish in the meta-model, by just giving submethods their own 
dispatch table inside the metaclass. However where I am somewhat 
confused is in how and when they get called.


I think the question is posed a bit confusingly. Since as you point out,
when the invocant is clear, calling the (sub)method is an easy lookup in
its vtable with subsequent call.



Take this example for instance:

class Foo {
method bar () { ... }
submethod bar () { ... }
}

Is this an error (Synopsis 12 seems to indicate it is *not* an error)?


The only inconvenience I see is that the name Foo::bar is not unique.
The sigil doesn't disambiguate because in both cases it is &Foo::bar.
Furthermore the :() is used only to distinguish different sigs, not the
Code subtype behind the name. Hmm, or is this a special cased two-entry
MMD table? One entry for &bar:(Foo) and one for &bar:(MetaClass[Foo])?


When I call bar() on an instance of Foo, which is called? The method? or 
the submethod? Is it somehow dependent upon the calling context? (called 
from within the class, or from outside the class). Take for instance, 
this example:


class Foo {
method bar () { ... }
submethod bar () { ... }

method baz ($self:) {
$self.bar() # which one does this call?
}
}


I think this is pretty clear. There is exactly one class object Foo
but many instances. The submethod can only be called on the Foo class
object which is available through the .meta method. Thus to call
the submethod one needs $self.meta.bar(). I doubt the usefullness
of falling back to submethod lookup in the class chain when an object
doesn't have the method.

There's actually no syntactical distinction possible because of:

my $object = new Foo;
my $meta = $object.meta;

$meta.bar() # calls submethod but looks like method call

I guess the type of $meta is Ref of Class or somesuch.


Regards,
--
TSa (Thomas Sandlaß)

Re: return() in pointy blocks

[TSa (Thomas Sandlaß)]

Larry Wall wrote:

On Wed, Jun 08, 2005 at 12:37:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: BTW, is -> on the 'symbolic unary' precedence level
: as its read-only companion \ ?.

No, -> introduces a term that happens to consist of a formal signature
and a block.  There are no ordinary expressions involved until you
get inside the block.  (Or set a default on one of the parameters, to
the extent that those are ordinary expressions.)


So without a block there is a syntax error?

  $x = -> $y;

Or could this be understood as a short form of

  $x = -> { $y } # $y from outer scope

I still think the pointy looks really cute as a prefix operator
for constructing rw refs. Especially if we use () to evaluate
the blockref returned. For plain variable assignment this is
not overly usefull because it amounts to the same as

  $x := $y;

but in lists it is quite nice

  %h = { foo, 'bar', blah, -> $y };

or not?

  %h = { foo => 'bar', blah => -> $y };

hmm, can the following be interpreted as spoiling pair notation?

  %h = { :foo, :blah< -> $y> }; # would blah<-> $y> parse at all?

I think not because this works

  %h = { :foo, :blah{-> $y} };

Regards,
--
TSa (Thomas Sandlaß)

Re: Type variables vs type literals

[TSa (Thomas Sandlaß)]

HaloO Larry,

you wrote:

On Thu, Jun 30, 2005 at 09:25:10AM +0800, Autrijus Tang wrote:
: Currently, does this:
: 
: sub foo (::T $x, ::T $y) { }
: 
: and this:
: 
: sub foo (T $x, T $y) { }
: 
: Means the same thing, namely
: 
:a) if the package T is defined in scope, use that as the

:   type constraint for $x and $y
: 
:b) otherwise, set ::T to be the most immediate common supertype

:   of $x and $y.
: 
: Is this understanding correct?  I'd like to disambiguate the two cases

: by making ::T in parameter list to always mean type variable (sense b),
: and the bare T always mean type name (sense a)?

I think it would be good to distinguish those, but I've been mulling
over whether ::T should be the syntax for b.  (And also whether b
is the "correct" way to think about it in Perl 6.)  The problem with
using ::T for "autovivify your type from the argument" is that ::($x)
doesn't mean that, and it looks like it should.


I think the point is that using a type variable in the signature of a sub
is too subtle for recognizing it as a type function that produces typed
subs. Thus---even if it resembles C++ templates---I suggest to put the
type parameters onto the sub:

sub foo[T] (T $x, T $y) { }

which basically constrains $x and $y to have the same type. A call
to &foo might automatically instanciate appropriate implementations.
With MMD and all methods and attributes beeing virtual this could
usually be a no-op as far as the code generation is concerned.
But the type checker has to know what constraints are in effect.


The syntax for explicit selection could be foo:(Int)('3','2') which
prevents the interpretation &foo:(Str,Str). OTOH, this might overload
the :() too much. Could we invent more colon postfix ops?
Thus the above were foo:[Int]('3','2'). And while we are at it
since () is more call-like and [] lookup-like we could reserve :()
for more complicated type literals and use :[] for formal type signatures
on subs as it is the case for roles.



 The :: does imply
indirection of some sort in either case, but it's two very different
kinds of indirection.  ::($x) can't declare a lexical alias for
some type, whereas ::T presumably could, though your formulation seems
more of a unificational approach that would require ::T everywhere.

In other words, if we do type binding like b, we would probably want to
generalize it to other binding (and assigning?) contexts to represent
the type of the bound or assigned object, and at the same time create
a lexical alias for the bare type.  So we might want to be able to say

::T $x := $obj;
my T $y = $x;


The prime use of that feature is to ensure type homogenity for
temporary and loop vars in a certain scope. But the scope in the
above syntax is not apparent enough---to me at least.
Thus I opt for an explicit

   subtype T of $obj.type; # or just $obj perhaps?
   T $x := $obj;
   my T $y = $x;

With my proposal from above the short form could be

   :[T] $x := $obj;
   my T $y = $x;

or the current form with :()

   :(T) $x := $obj;
   my T $y = $x;


Regards,
--
TSa (Thomas Sandlaß)