headers
Sam Vilain | 1 Jul 2005 03:42
Favicon
Gravatar

Re: SMD is for weenies

Yuval Kogman wrote:
> As I understand it SMD is now not much more than a mechanism to
> place a constraint on the MMD, saying that there can only be one
> method or subroutine with the same short name.
> Why is this the default?

Otherwise you lose this quite useful warning if the signatures didn't
match;

    method foo redefined at ...

I agree with you MMD is very cool, and I use it a lot.  But I don't
mind clarifying the intent with "multi"; this "overloading" is
considered by some to be surprising to new programmers.

Sam.
Permalink | Reply | 4 comments |
headers
Yuval Kogman | 1 Jul 2005 06:27
Gravatar

Re: SMD is for weenies

On Fri, Jul 01, 2005 at 13:42:34 +1200, Sam Vilain wrote:
> Yuval Kogman wrote:
> >As I understand it SMD is now not much more than a mechanism to
> >place a constraint on the MMD, saying that there can only be one
> >method or subroutine with the same short name.
> >Why is this the default?
> 
> Otherwise you lose this quite useful warning if the signatures didn't
> match;
> 
>     method foo redefined at ...

That's a good point...

I'm guessing that the default warnings should have a warning for MMD
methods which append to a short name without appearing immediately
after each other in the same file.

> I agree with you MMD is very cool, and I use it a lot.  But I don't
> mind clarifying the intent with "multi"; this "overloading" is
> considered by some to be surprising to new programmers.

Prepending 'mutli' is not a problem when I have to type it. It's a
problem when others won't type it. When 90% of the module code I'll
be using is not MMD compatible, because MMD is not the default, I
can't specialize other people's code without editing it (at runtime
or at the source level).

Overloading won't happen unless people overloading semantics are
introduced, and that's exactly what I'd like to do to other people's
(Continue reading)

Permalink | Reply | 2 comments |
headers
chromatic | 1 Jul 2005 07:35
Favicon

Re: Documentation trait / Docstring equiverlent

On Thu, 2005-06-30 at 04:33 +0000, David Formosa (aka ? the Platypus)
wrote:

> I'm just wondering if a documentation trait on subs would be usefull.
> If we are going to have something like p6explain the doc trait could
> be used as the source for the infomation for it.  p6explain would
> simply have to walk the AST reading the doc traits and pasting the
> text together. 

I certainly hope so.  Given Larry's recent work with the Perl 5
tokenizer to include this information in the optree, it's a shame for
Perl 6 to throw away potentially useful data recklessly.

-- c
Permalink | Reply | 2 comments |
headers
David Formosa (aka ? the Platypus | 1 Jul 2005 03:48
Picon

Re: Mr. Clean vs. Perl 6

On Thu, 30 Jun 2005 18:53:44 +0200, Stéphane Payrard
<stef <at> payrard.net> wrote: 
> On Thu, Jun 30, 2005 at 06:17:14AM -0000, David Formosa (aka ? the
Platypus) wrote:  

[...]

>> I would prefur this to be written.
>> 
>> use strict "types";
>> 
> 
> I suspect there will be many ways to do types stricture/inference in
> Perl6.  I expect that type modules will influence PIL generation so
> that people will have to choose the structures they want at a given
> place:
> 
>   use Types::some-type-sheme
> 
> or even
> 
>   use Types::Functional::some-sub-type-sheme
> 
> If such a typing mode gives us an haskell with some Perl6  concrete
> syntax we eventually could port the whole Haskell environment as
> Perl6. 

I'm quite sure that in time we will be able to replace the entire
typing engine, possably by walking the AST via macros.  Though I would
like the most common options to be short.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Wall | 1 Jul 2005 20:51
Picon
Gravatar

Re: Type variables vs type literals

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.  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.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Larry Wall | 1 Jul 2005 21:38
Picon
Gravatar

Re: Type variables vs type literals

On Fri, Jul 01, 2005 at 11:51:55AM -0700, Larry Wall wrote:
: So either we need a different sigil for type variables, or a syntax
: for explitly binding and declaring an autovivified type.  (Which,
: interestingly, could also be used in rvalue context.)

I neglected to provide an example of this, but it'd be something like

    $x = (my T) $y;

to declare that T is whatever type $y happens to be when evaluated.

It would have to be a special form, though, since it needs to expect
a term after it rather than an operator.  And it would require the
absence of anything following T, since (my T $x) means something
entirely different, and in fact requires an operator to follow.
I don't see a better approach offhand, unless it's [my T], which
would have to be just a special, and risks visual confusion with
lists and reduction operators.  So I'm still thinking (T)/(my T)
is the better approach.  But it could use more collective mulling.

Larry
Permalink | Reply | 0 comments |
headers
Larry Wall | 1 Jul 2005 21:52
Picon
Gravatar

Re: Type variables vs type literals

Perhaps type parameters to roles could also be written in (T) notation:

    role Tree[(Returns)] {...}

but that would imply the parameter name is "Returns" rather than
"returns".  Maybe that's okay, since it's usually a positional
parameter or a special "of" form anyway.

Larry
Permalink | Reply | 0 comments |
headers
Tim Bunce | 2 Jul 2005 02:06
Picon
Favicon

DBI v2 - The Plan and How You Can Help

Once upon a time I said:

  http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=source&hl=en

and wrote

  http://search.cpan.org/~timb/DBI/Roadmap.pod

which yielded:

  https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Details&selfund=102

(A little over $500 of that I effectively put in myself.)

My *sincere* thanks to all those who donated to the fund, especially
individuals. I had hoped for more corporate response with less from
individuals and I'm touched by the personal generosity shown.

I've not drawn any money from it yet and doubt that I will myself.
(I'm considering suggesting that the Perl Foundation make payments
from the fund to people making specific contributions to the DBI.
I'm thinking especially of work on a comprehensive test harness.
But I'll see how the developments below pan out before making
specific arrangements.)

So, that lead to:

  http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/thread/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0

Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Williams | 2 Jul 2005 18:17

Re: Documentation trait / Docstring equiverlent

On Thu, 30 Jun 2005, chromatic wrote:
> On Thu, 2005-06-30 at 04:33 +0000, David Formosa (aka ? the Platypus)
> wrote:
> > I'm just wondering if a documentation trait on subs would be usefull.
> > If we are going to have something like p6explain the doc trait could
> > be used as the source for the infomation for it.  p6explain would
> > simply have to walk the AST reading the doc traits and pasting the
> > text together.
>
> I certainly hope so.  Given Larry's recent work with the Perl 5
> tokenizer to include this information in the optree, it's a shame for
> Perl 6 to throw away potentially useful data recklessly.

There is something to be said for actually _organizing_ the documentation
too, which is why POD docs for a function are not always next to the
function itself.

That said, I hope the documentation trait on subs can optionally be a
pointer to the (section of the POD) document where the documentation
actually resides.

~ John Williams
Permalink | Reply | 1 comment |
headers
Larry Wall | 2 Jul 2005 19:13
Picon
Gravatar

Re: Documentation trait / Docstring equiverlent

On Sat, Jul 02, 2005 at 10:17:01AM -0600, John Williams wrote:
: There is something to be said for actually _organizing_ the documentation
: too, which is why POD docs for a function are not always next to the
: function itself.

I always cringe when I hear "the documentation", as if it's only one thing.

: That said, I hope the documentation trait on subs can optionally be a
: pointer to the (section of the POD) document where the documentation
: actually resides.

We'll certainly make that possible, though going that direction is
a little problematic insofar as it's pretty easy for the document to
link to a function that already has a name that is unlikely to change,
whereas it's difficult for a function to point into a document where
the section numbers are changing, unless you come up with some kind of
naming scheme for document sections, which by and large comes out to
naming the sections with the same long name as the routines.

If you store the doc info with the function, then you also have the
ability to massage it different ways and autogenerate sections of
your docs without having to have an explicit doc specifying the order
of every entry.  Of course, from the document-centric point of view
these are just slicing operations, which can be based on either rules
or enumerations.  But if we want to slice by rule, the functions have
to have at least enough associated metadata to specify the slicing
rules.

But going back to the "must have the same name" idea, names are just
keys into something, so this kinda smells to me like parallel hashes
(Continue reading)

Permalink | Reply | 0 comments |

Gmane