Re: Strongly typed containers?
Yuval Kogman wrote:
> We already have the Set class, how do we say what it contains?
> class Set {
>has $.type;
>method members returns $.type () { ... }
> }
> my Set of Int $s = Set.new; # is this how you call it?
You are describing "Higher Order" types, also called Generic Algebraic Data
Types (GADTs) in Haskell.
Please refer to the earlier discussions
Parts 1 and 2 of http://xrl.us/f9re
I also started a similar post on a related note that was "warnocked", though the post was more to demonstrate an apparent syntax
isomorphism between Haskell and Perl 6 than posing a particular question (probably why it was unanswered).
http://xrl.us/f9rg
I think there has probably been other discussions, including one where Autrijus specifically asked this question for the Set module,
but I can't find that one.
Sam.
Re: Strongly typed containers?
On Mon, May 30, 2005 at 18:51:19 +0200, "TSa (Thomas Sandla)" wrote:
> class Set does Array {...}
I don't like this... A set is just a simple example... What if I
want something sillier?
My question is really:
"How do I make sub foo returns $computable"
And how do I make this friendly to the compiler (declarable), so
that type inferrence like behavior can be enforced
> and use the corresponding sigil for variables:
>
> my @a is Set;
This works with your example, but it makes more sense if it's only a
derefernce-overload op.
A set and an array are distinct.. Sets are unordered, arrays are
ordered by definition. Sets know how to do set ops on each other,
arrays don't...
This becomes very problematic when you have several methods for
extraction - how do you distinct a method that returns the contained
type from another? An array can only be flattenned to a list, and
have subscripts extracted Other extractions are generic to list
data (grep, etc), and do not apply to things like Sets.
> My guess is that there is a Parrot level class that implements
> the level of indirection needed by Perl6 sigiled variables. If
> it weren't for Perl5 referential legacy it could easily be called
> Ref.
Please explain this idea in more detail.
>
> This container base class might just implement the basic machinery needed
> to make your Set available as container. But once again I don't know
> about the mapping to sigils and the set of supported operations.
STL (C++) has some nice ideas, if you consider templates and so
forth nice. In perl 6 I wouldn't like to see that, because it would
hinder flexibility, but basically what you do there is
typedef map FooMap; // garbage fields omitted
And then your FooMap is usable as a container of Foos. But since we
have dynamic runtime things, and much more complicated operations
with mixins, roles, MMD, and we're still trying to optimize all of
these (or rather expose the data to help parrot optimize it for us),
and more importantly help those who want safe programs (or safe
parts of programs) with a little more effort get that.
This is a hard conflict to deal with.
What we need to define is the possibility that a declaration:
my Set of Foo $set;
Affects the 'returns' trait of some methods
$set.members; # we now know it's Foo, because that's what $set is `of`
Aye?
> Hmm, the usual thing the implementation of a container requires
> is a minimal interface needed from the elements for the container
> to do what it is supposed to do.
You mean like generic methods for a container?
> In the case of a set this requirement is to check the identity of
> elements---basically like the keys of hashes.
True, but there are more complicated containers out there... =)
> Well, I think there are the concrete list types Eager and Lazy,
> so it could be a simple 'Lazy of Int'. In a signature you use the
> slurpiness indicator * which I presume is available in :() as well.
> So a list of Int might be :(*Int) and a recurring tuple type might
> be :(*(Int,Str)).
That seems pretty nice, although not aesthetically appealing.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpZ5w5VFtv0l.pgp
Description: PGP signature
class Foo does Debuggable ...
Debugging is a hard task, because either too much is hidden (this is when we want to invoke the debugger), or too much is visible (this is when we give up on tracing the problem through the debugger, and resort to print Data::Dumper::Dumper($thing) every few lines of code). Given the complexity of layering in todays programs, lets take a web app for example (search for __skip__ if you want to skip): request enters glue code to environment MVC framework builds request object controller actions dispatch, object moves around model queried, changed view dispatched request luggage data munged, or model requeried template module invoked This involves, framework code, we typically don't care about, which in turn is just glue around other frameworks and libraries: - our POOP library - on top of DBI, which we also don't care about - lots of hackery to create an OOP data view - lots of lazy accessors, doing big work under the hood - our template library - uses a bajillion plugins, probably - uses has a complex pipeline, to process a template, with caching (memory, files), translation, parsing, inlining, and outputting, like any modern system - our environment glue library - mod_perl / CGI - HTTP::Headers, etc We are also introduced with a new control flow paradgim, probably one of: - a run loop - callbacks - continuations - beh __skip__ programs that are written by the user are hard to debug. Lots of the code actually being run is far from the code that we wrote. In this day and age of complex application writing debuggers are hard to get right. Lets briefly discuss their evolution: 1. machine code dissasembly + tracing 2. source debugger ... That's where they stopped i think. The big distinction between the two is that the latter is at the user's level - it discusses the thing that the user wrote. The next step is to allow a debugger to hide library code when it's beyond what the user cares about, since although it's at the same level, it's still not what the user wrote. I think the way to do it is to make a debuggable role, which knows to provide a million and one hooks to the thing that `does` it. Aside from that, I don't really know how to think farther. The two implications I'd like to see: 1. Code ownership marked at runtime: Framework providing several levels of how to skim through control flow. Probably usually boolean (calls within a namespace omitted). Also defines a policy about instance data it filled in, and so forth. This allows the user to skim through only their code, or only some of the libraries mechanisms if that helps. 2. Data summarization Complex structures should know how to display themselves well to a debugger. Of course, for this stuff to work, it has to be part of the grand unified tracing and introspection capabilities Perl 6 will offer a debugger writer. I'd like to see this in use by N debuggers, possibly with a role like mechanism (in a graphical debugger some objects may know how to draw themselves). Also, lets remember not to hinder full transparency. Furthermore, full transparency should, again, not be all or nothing. I believe developers will be tempted to write implementations of the Debuggable role, since they will probably use these tools to debug their own code anyway ;-) Adios! -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: : neeyah! pgp6DQYqPlvr8.pgp Description: PGP signature
Re: Strongly typed containers?
Yuval Kogman wrote:
my Set of Int $s = Set.new; # is this how you call it?
This whole thing depends on how hard-wired the first level
container implementation is. There is either a loose or
very strict mapping from sigils to container types:
$ --> Scalar/Item
@ --> Array
% --> Hash
& --> Code
If things like 'my $x is Array' work, then using your set class
is straight forward. If Item, Array, Hash and Code are sigil-types
then you must compose them into your class:
class Set does Array {...}
and use the corresponding sigil for variables:
my @a is Set;
The 'of'-part might be handled by the compiler generically.
But I don't know where that type contraint is actually stored
nor how it is invoked. It might just be composed implicitly.
My guess is that there is a Parrot level class that implements
the level of indirection needed by Perl6 sigiled variables. If
it weren't for Perl5 referential legacy it could easily be called
Ref.
Or do we say
class Set is Container { # magical?
method members returns returns ... # some facility by Container?
}
This container base class might just implement the basic machinery needed
to make your Set available as container. But once again I don't know
about the mapping to sigils and the set of supported operations.
Even if the way to implement this is as thin as C++ templates, that
is, we'll have to define a container of some type, and define the
type as a complex thing, instead of defining a container of complex
things, it's still better than nothing.
Hmm, the usual thing the implementation of a container requires
is a minimal interface needed from the elements for the container
to do what it is supposed to do. In the case of a set this requirement
is to check the identity of elements---basically like the keys of hashes.
This brings me to another issue - can I say what type the elements
of a list has, without putting it into a typed array?
Well, I think there are the concrete list types Eager and Lazy,
so it could be a simple 'Lazy of Int'. In a signature you use the
slurpiness indicator * which I presume is available in :() as well.
So a list of Int might be :(*Int) and a recurring tuple type might
be :(*(Int,Str)).
--
TSa (Thomas Sandlaß)
construction clarification
I have a class that normally takes a list of named arguments.
I also want to be able to handle a single argument.
class Foo {
multi method new (Class $class: Str $date) {
return $class.bless(date => $date);
}
submethod BUILD ($.date, $.time, $.offset) {
# some error checking here
}
}
my $foo = Foo.new('2005-05-30');
#
Is this the correct way to handle my scenario?
My explicit 'new' method should only handle the case of
a single argument - otherwise the 'new' method
inherited from Class will handle a list of named
arguments.
My explicit BUILD submethod is called, regardless
of which 'new' method is called, correct?
Cheers,
Carl
Strongly typed containers?
We already have the Set class, how do we say what it contains?
class Set {
has $.type;
submethod BUILD {
# get something into $.type, using 'of' handler
}
method members returns $.type () { ... }
}
my Set of Int $s = Set.new; # is this how you call it?
Or do we say
class Set is Container { # magical?
method members returns returns ... # some facility by Container?
}
Even if the way to implement this is as thin as C++ templates, that
is, we'll have to define a container of some type, and define the
type as a complex thing, instead of defining a container of complex
things, it's still better than nothing.
This brings me to another issue - can I say what type the elements
of a list has, without putting it into a typed array?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpdjJf9XAwiE.pgp
Description: PGP signature
Re: Transparent / Opaque references = Link / Ref
"TSa (Thomas Sandlaß)" skribis 2005-05-30 8:58 (+0200): > [This is a repost, somehow it didn't get through before, sorry.] This is the fourth time it did get through to my mailbox, at least. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: mod/div
Mark Reed wrote: I would really like to see ($x div $y) be (floor($x/$y)) That is: floor( 8 / (-3) ) == floor( -2. ) == -3 Or do you want -2? and ($x mod $y) be ($x - $x div $y). Hmm, since 8 - (-3) == 11 this definition hardly works. But even with $q = floor( $x / $y ) and $r = $x - $q * $y we get 8 - (-3) * (-3) == -1 where I guess you expect -2. Looks like you want some case distinction there on the sign of $x. If the divisor is positive the modulus should be positive, no matter what the sign of the dividend. The problem is that with two numbers $x and $y you get four combinations of signs which must be considered when calculating $q and $r such that $x == $q * $y + $r holds. Avoids lots of special case code across 0 boundaries. If there is a definition that needs no special casing then it is the euclidean definition that 0 <= $r < abs $y. -- TSa (Thomas Sandlaß)
Sub call resolution
Okay, I'd like to set myself straight. Sanity check: bar($foo, $baz); # looks for subs (lexical then package), and falls back to MMD $foo.bar($baz);# looks in ref($foo), then falls back to MMD If this is correct, can we simplify the latter to mean "MMD only" ? Would there be a more symmetric MMD only form? Luke
