Re: lazy list syntax?
On Thu, Jul 28, 2005 at 19:58:16 -0300, Flavio S. Glock wrote:
> 2005/7/28, Yuval Kogman <[EMAIL PROTECTED]>:
> >
> > I think unary = is what you want:
> >
> > my @a = $span.lazy;
> >
> > for [EMAIL PROTECTED] -> $item {
> > ...
> > }
> >
> > Ofcourse, my @a = $span.lazy will have to be fixed, but what you
> > tried should be working.
>
> Is "for =" only for filehandles? I tried:
>
> pugs> say for =1
> *** cannot cast from VInt 1 to Handle (VHandle)
Hmmm... That's odd. I may be out of date, but I thought that unary =
is the complement of unary **.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgpupSNmZSHix.pgp
Description: PGP signature
Re: lazy list syntax?
2005/7/28, Yuval Kogman <[EMAIL PROTECTED]>:
>
> I think unary = is what you want:
>
> my @a = $span.lazy;
>
> for [EMAIL PROTECTED] -> $item {
> ...
> }
>
> Ofcourse, my @a = $span.lazy will have to be fixed, but what you
> tried should be working.
Is "for =" only for filehandles? I tried:
pugs> say for =1
*** cannot cast from VInt 1 to Handle (VHandle)
- Flavio S. Glock
Re: Garbage Collector API
On Thu, 28 Jul 2005 16:22:19 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote:
[...]
> On Thu, Jul 28, 2005 at 01:08:13 -, David Formosa (aka ? the Platypus) =
> wrote:
[...]
>> my Bigobjet $big is GC::timely =3D Bigobect; # Request timely
>> # destruction of $big. Usefull for filehandels and network
>> # resources.
>
> I like this approach the most: it let's users specify what they
> need, not how they need it done.
I can see advantages to both approches. All GC systems have a hit
when they run, in some situations it would be nice to shift the hit to
times when it doesn't mattor that much. For example a GUI app may
delay the GC till when the user has been idle for a while.
> Every GC has slightly different semantics. If we have a generational
> GC that has delays, or a reference counting scheme that does
> occasional reachability tests, it doesn't really matter.
Yes thats why I was saying "hints". Not all hints are going to be
that meaningfull.
> What we want is features:
>
> some object needs to die appropriately, because i'm using
> DESTROY to manage resources, or trigger an action
Which I'm calling the timely trait.
> And we can also open the door to optimizations:
>
> some object is cheap to store, you can collect it later than
> usual
Sort of an anty timely? GC::tardy
> everything under this object belongs to it, and only to it (that
> is, you can cleanup the whole tree when cleaning this up)
GC::tombstone;
[...]
> We do need this applying to:
>
> roles and classes:
> class Moose is GC::timely { ... }
Yep (and yes to all your other suggestions).
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: Elimination of Item|Pair and Any|Junction
On Fri, Jul 29, 2005 at 05:59:43AM +0800, Autrijus Tang wrote:
> I can see marking things explicitly for named bindings:
>
> foo(:literal);
> foo(*%nameds);
> foo(*$pair);
> foo([EMAIL PROTECTED]);
Er, sorry, the last one should be
foo(*%{ hash @list_of_pairs });
Thanks,
/Autrijus/
pgpBLMrCD5fBT.pgp
Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
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. 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. :-) http://scala.epfl.ch/docu/files/api/index.html > And I'm still not entirely sure I believe the "not-yet-bound-ness" of > Pairs is all that different from the not-yet-bound-ness of Junctions > to the extent that a different type level is warranted. Junctive autothreading are "outside" bindings -- they can be viewed as a two-phase exception handling from parameter type mismatches that fires away more function applications. Pairs on the other hand are bound normally; they just have a preferred zone unless overriden by the parameter signature; this resolution is strictly within the same one-step binding. I think there may be more types to come that has its preferred binding semantic, than outside-the-box devices like Junctions. > I guess I still think there ought to be a way of marking Pairs on the > call end as to whether they're intended for named args or not, without > warping the whole top-level type system to that end. I can see marking things explicitly for named bindings: foo(:literal); foo(*%nameds); foo(*$pair); foo([EMAIL PROTECTED]); That will mean that foo($pair) will always be positional. Thanks, /Autrijus/ pgpcAv844aT1u.pgp Description: PGP signature
Some thoughts on PIL
On Thu, Jul 28, 2005 at 06:31:34PM +0200, "TSa (Thomas Sandla�)" wrote: > BTW, where can I read about PIL, other then in Parrot/Pugs svn? (Cc'ing in P6C.) The current type-indexed design of PIL is going away, because it is closely tied to the PIR/Parrot model, to the disadvantage of our Perl5/JavaScript backends. Also it does not capture any notion of rank-n types, and relies on the VM for a semantics for container types, which is prone to trouble. In the past few weeks I've been reading up on F<:, Fw, CoC, vObj, as well as intersectional and split types for object calculi, in the hope of revamping PIL -- Pugs's new internal language -- that can alleviate backend author's pain and improve type-directed translation. Perl 6's uniqueness is that it relies on runtime-rebindable package objects for its type system, but at the same time carries the vague promise of partial static analysis for the part of the closed world via toplevel `use optimize`. The semantic of type annotations remains unresolved; I reflected this in the recent `the meaning of "returns"` thread. It would be far easier if we concede that Perl 6 is essentially untyped, and all type annotations are merely storage hints, that will still always require runtime coercion. This coincide with Parrot's current idea of never checking subroutine parameter's PMC types (except for MMD), and always resolve method calls as late as possible, exactly as Perl 5 did. Under that view, the only use of type annotation at compile time is speeding up property/method lookup for typed variables, so they can be looked up by number instead of names, provided new fields always go toward the end. Other than that, they can only serve as runtime assertions, leading to the curious effect that well-typed programs can run slower than the unannotated counterpart. However, my intuition is that a soft-typed system, with clearly defined dynamic parts translated to runtime coerce and dependent types, that can work exactly as Perl 5 did at first, but provide sensible inferencing and compile-time diagnostics as you gradually provide annotations, is really the way forward. Under soft typing, Parrot's role would become a fast implementation for the object space and primitives, but the soundness of large-scale programs and the standard library will be provided by the compiler, not the runtime. This plays well with Pugs's -- not neccessarily Perl 6's -- goal of keeping the language retargettable. This may not be popular view, as evidented by the relative lack of research and real-world interest to bridge the gap of static/dynamic languages, so it would take a while to come up with a suitable formal treatment. I'm currently trying to express this idea under the F<: framework for the new PIL, and I'll keep p6c posted as it goes forward, and cotinue to reflect design issues to p6l. Thanks, /Autrijus/ pgpfrcPpbJfiu.pgp Description: PGP signature
$value.confess()
While trying to track down a type error in a Pugs program today, I thought of what could be a handy debugging feature. I would like Perl 6 values to capture the call stack when they're created and store them into a property called "confess" (Autrijus's name). $value.confess would then return an array of Caller objects, which could be inspected to determine where a value came from. It might even be wise to have it capture the call stack each time the value is mutated. Since this would likely be expensive, I suspect it should be optional and turned off by default; however, this would probably be a global setting, not a lexical one. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: Type::Class::Haskell does Role
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: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 05:31:46AM +0800, Autrijus Tang wrote: : On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote: : > Hrm. I thought the original motivation of forcing people to write : > : > Any|Junction : > : > was precisely to discourage people from accidentally write : > : > sub foo (Any $x) : > : > and have $x accept a Junction. In other words, any() should not be of : > type Any. Hence it still feels natural for me that Any occurs at the : > position of Mumble. : : FWIW, if Any is to be ruled to be the top type and includes Junction, : then I support Darren's proposal of "Single", and maybe the Object type : can be simply eliminated to Any: There is something to be said for avoiding "Object" as a word with too much existing baggage from other cultures. : Any - Item - Single :- Pair : - Junction : - int, num, str : : This also means that will fit to Any via autoboxing. Which makes "Any" mean "anything that can act like an Object" rather than the stricter "anything that 'isa' Object". Hmm... Item could take over the 'isa' role of Object, I suppose. That does imply that Junctions (and any other syntactic lazinesses we throw into that slot) aren't really objects. Maybe we can deal with that. 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. Certainly some of Thomas's recombining relations should be viewed as role composition rather than MI. And you can view the whole autoboxing issue as an implementation detail of constrained subtypes, where the constraint happens to be a restriction on the set of values that can fit into a particular representation. And I'm still not entirely sure I believe the "not-yet-bound-ness" of Pairs is all that different from the not-yet-bound-ness of Junctions to the extent that a different type level is warranted. I guess I still think there ought to be a way of marking Pairs on the call end as to whether they're intended for named args or not, without warping the whole top-level type system to that end. Larry
Re: lazy list syntax?
On Wed, Jul 27, 2005 at 20:17:41 -0300, Flavio S. Glock wrote:
> I have an object representing the sequence "1..Inf".
> I tried creating a Coroutine, and then assigning the Coroutine to an
> Array, but it only yielded "1":
>
> my @a = $span.lazy; # "1"
>
> The coroutine worked fine in a "while" loop, but it didn't work in a "for"
> loop.
I think unary = is what you want:
my @a = $span.lazy;
for [EMAIL PROTECTED] -> $item {
...
}
Ofcourse, my @a = $span.lazy will have to be fixed, but what you
tried should be working.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgpK6nQnSPM5Y.pgp
Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 00:26:27 +0800, Autrijus Tang wrote: > Er, but Junctions take methods, the same way Objects do, so if there is > an Object in the type hierarchy, Junction probably belongs to it. Maybe there is a role called 'Junctive'? I think junctions are orthogonal to other types, except when people try to deal with them explicitly... The all encompassing type is not really a type, but more of a shortcut. My take: Any Object Item Atom ... Pair Junction int, str, ... where any of these can also 'do' Junctive. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me tips over a cow: neeyah!! pgpvvnhW5imFv.pgp Description: PGP signature
Re: The meaning of "returns"
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: execution platform object? gestalt?
On Wed, Jul 27, 2005 at 08:59:53 -0700, Larry Wall wrote:
> So in this particular case it might be better to just say
>
> if exists &get_javascript_class {...}
Eeep... That reminds me of how you check between versions of perl.
I think I want something else:
$?RUNTIME
this is a common interface to an object that does all this.
It's lexical because the same bit of code might run on a hybrid
platform if we're getting carried away.
It let's you ask mostly about roles:
if ($?RUNTIME ~~ /IsDomishBrowser/){
# the browser runtime has the window class in the dom, we
# can get it, and it doesn't matter if we're running on
# javascript or parrot embedded in mozilla
}
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
pgptwCHvfWSVG.pgp
Description: PGP signature
Re: Garbage Collector API
On Thu, Jul 28, 2005 at 01:08:13 -, David Formosa (aka ? the Platypus)
wrote:
> On 26 Jul 2005 05:18:05 -, David Formosa )
> <[EMAIL PROTECTED]> wrote:
>
> > We are should have an API to talk to the GC and give it hints about when it
> > should run, and tweek the verious paramitors for its running.
> >
> > For example
>
> [...]
>
> Also
>
> my Bigobjet $big is GC::timely = Bigobect; # Request timely
> # destruction of $big. Usefull for filehandels and network
> # resources.
I like this approach the most: it let's users specify what they
need, not how they need it done.
Every GC has slightly different semantics. If we have a generational
GC that has delays, or a reference counting scheme that does
occasional reachability tests, it doesn't really matter.
What we want is features:
some object needs to die appropriately, because i'm using
DESTROY to manage resources, or trigger an action
And we can also open the door to optimizations:
some object is cheap to store, you can collect it later than
usual
everything under this object belongs to it, and only to it (that
is, you can cleanup the whole tree when cleaning this up)
and so on and so forth.
We do need this applying to:
roles and classes:
class Moose is GC::timely { ... }
a policy for attributes of objects:
class Moose {
has $. handles "method" is GC::timely; # not good enough, i
# want to be able to say "all children", and I want this to
# be inheritable... A class property, i guess
}
instances:
# your syntax is per container
my $big = $something but GC::timely; # do we have runtime 'does'? I
keep forgetting
contained elements within a container
my @a is Array of (Item is GC::timely);
and containers themselves without respect to their contained:
my @a is Array is GC::timely
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpIYCYY9JrLG.pgp
Description: PGP signature
Re: An idea for doing pack.
I have a fundamental disagreement with what pack used to be - it's too stringish... =) the printf and unpack syntaxes always bothered me because they are akin to 'eval'ing, more than they are to quasi quoting. I like your Pack object - that is the parsed template, but I'd also like to be able to generate these templates with a programmatic interface that isn't string concatenation... Is it just a simple data structure? Or do you have anything in mind? Will we have more powerful nesting? I think this is in order nowadays. Actually, to be really wicked, I think that packing is just applying rules in reverse (this is tricky and indeterminate, since there are no alternatives or options in unpacking/packing), and unpacking is the opposite, with two exceptions: captures are converted by looking at the binary data and interpreting it, not just stuffing it in a string the syntax is different Anywho, I like your proposal, but i'd like some even fresher ideas into pack and unpack, so i'm just trying to kick the thread around... -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me kicks %s on the nose: neeyah! pgpPzVO2omGkV.pgp Description: PGP signature
Re: Messing with the type heirarchy
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: Messing with the type heirarchy
On Wed, 27 Jul 2005, [ISO-8859-1] "TSa (Thomas Sandla?)" 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". Michele -- Might I suggest you take nice strong draught of hemlock before you post again? I think we'll all be much better off... You are besmearing the memory of Sokrates. - David Kastrup in comp.text.tex, "Re: Is Kastrup..."
Re: Garbage Collector API
On 26 Jul 2005 05:18:05 -, David Formosa ) <[EMAIL PROTECTED]> wrote: > We are should have an API to talk to the GC and give it hints about when it > should run, and tweek the verious paramitors for its running. > > For example [...] Also my Bigobjet $big is GC::timely = Bigobect; # Request timely # destruction of $big. Usefull for filehandels and network # resources. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Inferring (Foo of Int).does(Foo of Any)
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
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!
