Re: A6: Signature zones and such
Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? brad
Huffman coding (Was: Re: A6: Strict signature checking - was: Complex Parameter Types)
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote: By distinguishing a parameter that *requires* a particular type, from a parameter that *ensures* a particular type (by coercion if necessary). I've suggested that using Cis copy semantics should indicate make whatever I'm actually given into one of these, if you can, whereas reference semantics say this must already be one of these (by their very nature, since an aliased parameter *is* the argument). It looks like a lot of people is going to use is copy a lot. Correct me if I am wrong, but I see the default is constant trait largely as a speed optimization. Would not it be more correct from the point of view of good Huffman coding, that is copy is made the default, and let the module authors and large project implementors to bother with is constant when they deem it necessary? After all, this will be a small added burden for folks who go the type and trait everything route. An extra bonus of making is copy the default would be the ability to modify a parameter locally (Huffman coding again here for short program writers). =Anton.
Re: AW: P6FC
[EMAIL PROTECTED] (Aldo Calpini) writes: any (possibly meaningful) feedback will be very appreciated. I think Type should be called Value, and that arrays should possibly be a mixin of lists, but apart from that it looks fine. Oh, and you missed out Grammars; and I don't know if macros are actually objects and can be tossed around, or if they're just part of the compilation process. -- Sauvin Remember: amateurs built the Ark; _professionals_ built the Titantic.
Re: A6: Signature zones and such
Brad Hughes [EMAIL PROTECTED] writes: Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? Dunno. But I'm merely expressing a preference. TPF can do with it what they will. -- Piers
AW: AW: P6FC
[snip] PS: But before reinventing a wheel, i would like to suggest to adopt the .NET/Java object hierarchy. uhm. either I am completely wrong or you are totally out of track. I really don't understand what you're talking about :-) Urgs. Hopefully i didn't trapped into a dunghill ? But let me dig deeper into it. Here an example class Hashtable from .NET Framework Class Library: System.Collections Namespace Classes Class Description HashtableRepresents a collection of key-and-value pairs that are organized based on the hash code of the key. [C#] public class Hashtable : IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback, ICloneable anyway, on http://dada.perl.it/p6fc.html you find now a pretty GraphViz image accompanied by the XML data source (I'm Let me grab your suggestion for the example Hash: Hash isa Type Type isa Object What i intended is to go and copy the .NET/Java object/interface/inheritance hierarchy (s.a.). So Hash isa IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback, ICloneable etc.. digging up the references right now) and the script I used to produce the diagram. any (possibly meaningful) feedback will be very appreciated. cheers, Aldo Murat
Re: A6: Signature zones and such
At 3:07 PM + 3/14/03, Piers Cawley wrote: Brad Hughes [EMAIL PROTECTED] writes: Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? Dunno. But I'm merely expressing a preference. TPF can do with it what they will. Earmarked contributions are apparently somewhat dodgy from an IRS perspective--they don't want folks setting up a 503(c)(3) to do payroll stuff as a way to avoid taxes. (Rather than have an employee you have a grantee of a charity, thus the money you use to pay that person becomes a tax deduction, or something like that) The TPF's grant fund stuff's OK, though. It's just a matter of getting a grantee for this year... (Working on that) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A6: Signature zones and such
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 3:07 PM + 3/14/03, Piers Cawley wrote: Brad Hughes [EMAIL PROTECTED] writes: Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? Dunno. But I'm merely expressing a preference. TPF can do with it what they will. Earmarked contributions are apparently somewhat dodgy from an IRS perspective--they don't want folks setting up a 503(c)(3) to do payroll stuff as a way to avoid taxes. (Rather than have an employee you have a grantee of a charity, thus the money you use to pay that person becomes a tax deduction, or something like that) The TPF's grant fund stuff's OK, though. It's just a matter of getting a grantee for this year... (Working on that) This doesn't seem right. The United Way runs directed drives all the time, in which they raise money for a particular cause. (And tap me on the shoulder...) There's no reason the TPF couldn't run a Fund P6 drive. =Austin
A6: objects and/or types (was: P6FC)
Simon Cozens wrote:
...and I don't know if macros are actually objects and can be tossed
around, or if they're just part of the compilation process.
they have their proper place in the diagram Larry put in A6.
furthermore, he says:
These syntactic forms correspond the various Routine types in the
Code type hierarchy
so Macro seems to be at least a type. which leads me to the question:
is Macro also a class? and which is the difference between a type
and a class? hm, I guess this will be answered in A12, so I'll
probably have to wait on this.
I also have another question (probably related, and probably also for
later). consider this:
sub mygrep( Code block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Block block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Routine block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Sub block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Method block, [EMAIL PROTECTED] is rw ) {...};
is something like this allowed? and what is the meaning then? if logic
serves me correctly, this shouldn't work:
sub mygrep( Routine block, [EMAIL PROTECTED] is rw ) {...};
mygrep { $_ 2 }, 1, 2, 3;
because { $_ 2 } is a Block, not a Routine! it should be written
like this:
sub smaller_than_two ($value) { return $value 2 }
mygrep smaller_than_two, 1, 2, 3;
but this doesn't seem to make much sense. one should probably have
said 'Code block' (or 'block' alone, which I suppose is just the
same), but then what's the use of 'Routine', 'Sub', 'Method' etc. as
types?
also, it's not clear to me the distinction between isa-relationship
and namespace. I see that 'Rule' (and I presume 'Sub', 'Routine',
'Code', etc.) are all type names, but I wonder if 'Bare' is a type of
its own -- or it is 'Block::Bare'? the latter sounds much better :-)
in my class hierarchy I mixed 'probable' isa-relationships (eg. Sub
isa Routine isa Code) with 'probable' proper namespace hierarchy (eg.
Exception::Control::return, not return isa Control isa Exception).
and this is probably very, very wrong.
or maybe I'm just playing with dangerous toys that aren't intended for
a little kid like me :-)
I think Type should be called Value, and that arrays should possibly
be a mixin of lists, but apart from that it looks fine. Oh, and you
missed out Grammars; ...
thanks, applied :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: A6: overloading multis on constness of parameters
On Fri, Mar 14, 2003 at 01:45:56PM +1100, Damian Conway wrote: : Oh, and I was wrong to originally write: Cmulti *isa ... Sorry, you're not even wrong. :-) : Multimethods live in their own namespace. No * required. Alternately, we require the C* in order to accurately document their scope. And I do think they live in C*. Otherwise we need to come up with yet another name for the global scope that happens to contain multimethods. An argument can also be made that we should do that anyway on the grounds that we might someday have scoped multi-methods of some kind or other. I suppose can allow a Csub * in the same scope as Cmulti * for the case that you want a global override of all the multimethods. It just looks for the sub first. If that sub then wants to redispatch to the multimethods, it'd have to use some special multimethod syntax that doesn't look like a sub invocation, such as the notional ($a,$b,$c) forwhich foo() we talked about in Sebastopol, however we end up spelling forwhich. It's really a kind of postpositional topicalizer for the following predicate. English doesn't really have any good ones of those. If I were Japanese, I'd spell it wa or ga or no. Well, okay, I'd actually spell it or or if I were *really* Japanese. :-) Larry
Re: Huffman coding (Was: Re: A6: Strict signature checking - was: Complex Parameter Types)
On Thu, Mar 13, 2003 at 10:52:04PM +0100, Anton Berezin wrote: : On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote: : : By distinguishing a parameter that *requires* a particular type, from : a parameter that *ensures* a particular type (by coercion if : necessary). I've suggested that using Cis copy semantics should : indicate make whatever I'm actually given into one of these, if you : can, whereas reference semantics say this must already be one of : these (by their very nature, since an aliased parameter *is* the : argument). : : It looks like a lot of people is going to use is copy a lot. Correct : me if I am wrong, but I see the default is constant trait largely as a : speed optimization. Would not it be more correct from the point of view : of good Huffman coding, that is copy is made the default, and let the : module authors and large project implementors to bother with is : constant when they deem it necessary? After all, this will be a small : added burden for folks who go the type and trait everything route. An : extra bonus of making is copy the default would be the ability to : modify a parameter locally (Huffman coding again here for short program : writers). Well, at minimum there could certainly be a use sig copy pragma or some such. But I don't think is copy will be used all that much if we set up is constant with the right semantics in the first place, which is that it can do a copy of basic types if it feels like it. It's only is rw or is ref that really require reference semantics, and then we're talking proxies if we want any coercion. Larry
Re: another response to apo6 transfinite semantics challenge
On Thu, Mar 13, 2003 at 10:37:36PM -0600, david nicol wrote: : : However, if you access the last element using the length of the array, : it may try to flatten, and fail: : : my @flat = (1..Inf, 1..10); : $last = @[EMAIL PROTECTED] - 1]; # Kaboom! : : How about negative indices? We have negative indices in the slice() : semantics; what if : : $last = @array[-1] : : always worked? I don't see a problem with that. That's why I specifically said using the length of the array. The negative notation doesn't have to use the length of the array. It only has to know how to *find* the end and count back from there. It's an accident of implementation if finding the end involves calculating the length. Mind you, Perl 6.0.0 may well implement it that way accidentally, and it wouldn't bother me a bit. We can always relax the constraint later. Larry
Re: A6: Strict signature checking - was: Complex Parameter Types
On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote: : I think that there should be two types of arg typing[1]: 'strict' and : 'loose'. Strict arg typing doesn't coerce, except to turn subclasses : into superclasses; loose arg typing, on the other hand, coerces whenever : possible. The mechanism for choosing between strict and loose arg : typing should be under the caller's control, not the callee's. (The : callee decides what types they want, and the caller decides how to : create those types. This seems consistent with Perl's philosophy of : being flexible and making BD optional.) Precisely. The parameter types are completely invariant for the callee. They are optionally invariant for the caller depending on some kind of stricture. But I darn well want the naive user to be able to pass a Scalar to an Int parameter and have it DWTM without them knowing a blessed thing about these mysterious entities called classes. We've got to keep the entry ramp low, or Perl is no longer Perl. The real question is whether this particular stricture is part of the default use strict that classes and modules assume. There are decent arguments on both sides of that one, but just to mollify Damian I'm inclined to come down on the strict side for that. This week. :-) Larry
[SUMMARY] A6: Type Inference (was Re: A6: Strict signature checking)
OK, divide conquer. We seem to be spasming about this and trying to
talk about N things at once, so here's an issue summary. We're talking
about at least two separate cases, (1) inferring type where none has
been specified, and (2) coercing a typed value into another type.
Let's take these separately, first one first:
[ISSUE: Type Inference]
Consider the following example:
class MyClass {...}
sub foo(MyClass $c) {...}
my MyClass $a = MyClass.new;
my $b = $a;
foo($a);# OK
foo($b);# ERROR!
The issue here is that the variable C$b has not been typed -- or more
accurately, it has been given a default type of CScalar. So $b can
store a MyClass, but it has not been _guaranteed_ to contain a MyClass,
violating the typed signature of Cfoo.
This is potentially significant because for quick-and-dirty scripts,
some programmers would prefer to not explicitly type every single
variable they declare, but they would still like to be able to use
modules that have been written to be type-aware.
NOTE that this issue only comes up when passing untyped vars like
Cmy $b, Cmy @b, or Cmy %b. If a type _has_ been explicitly
given, it's not type inference, it's type coercion, which should be
considered separately.
[POSSIBLE APPROACHES]
1) If an untyped var is used for a typed parameter, it's a
compile-time error. Broadly speaking, if you use type-aware subs, you
must use type awareness everywhere.
The advantage of this approach is that in assures there will be no
hidden runtime costs; if you want to take advantage of the *huge* speed
increases of using strictly typed vars, you can just do it. The
disadvantage is that you'd pretty much have to use types *everywhere*
in your program, or *nowhere*, because the edge between them always
introduces compile-time errors. This is especially troublesome when
using library modules, for example.
2) If an untyped var is used for a typed parameter, invoke runtime
type checking, either with or without a warning (according to a pragma?)
The advantage of this approach is that it will silently work; the
disadvantage is that it could introduce *very* expensive runtime
penalties if accidentally invoked, essentially nullifying the speed
gains of typing.
3) If an untyped var is used for a typed parameter, a simple dataflow
analysis is used to determine whether the compiler can guarantee that,
at that point, an untyped var will _always_ contain values of a
known, specific type. If so, the type is inferred (silently or with a
warning, according to pragma?) Otherwise, it is a compile-time error.
The advantage is that it will silently work, and will present no
runtime speed penalties. The disadvantage is that different
implementations of Perl might have different levels of dataflow
analysis, causing one-off code that was acceptable under a smarter
analysis to be invalid if moved to a dumber analysis -- meaning
either this has to be acceptable behavior of an implementation, or that
we need to specify, as part of the language spec, the precise smartness
of the analysis.
---
AFAICT, these are the *only* possible solutions to the problem. At
last count, Larry was leaning towards #2. Damian was countering with
#1. Some Lowly Grubs were suggesting #3. Am I missing anything?
I think we can decide _this_ issue independently of coercion issues,
yes?
MikeL
Re: [SUMMARY] A6: Type Inference (was Re: A6: Strict signature checking)
Friday 14 March 2003 20:06, Michael Lazzaro wrote: 3) If an untyped var is used for a typed parameter, a simple dataflow analysis is used to determine whether the compiler can guarantee that, at that point, an untyped var will _always_ contain values of a known, specific type. If so, the type is inferred (silently or with a warning, according to pragma?) Otherwise, it is a compile-time error. Uhh.. I am emphatically against this. We cannot depend on the compiler data-flow analysis because: - It won't be very good (because of perl's ultra-dynamism) - It may improve as we put more effort on the compiler, so some program that works in perl6.4 may fail on perl6.2 - It may degrade as we add more (evil) features on the language. (Or otherwise it may prevent us from adding more (evil) features in the language in some future without breaking BC) - It's hard to predict. I would rather have an allways-complain or an allways-forgive policy, than to have a complain-or-forgive-depending-on-the-weather- -in-Canary-Islands policy. -angel
Re: A6: objects and/or types (was: P6FC)
On Fri, Mar 14, 2003 at 05:21:46PM +0100, Aldo Calpini wrote:
: Simon Cozens wrote:
: ...and I don't know if macros are actually objects and can be tossed
: around, or if they're just part of the compilation process.
:
: they have their proper place in the diagram Larry put in A6.
: furthermore, he says:
:
: These syntactic forms correspond the various Routine types in the
: Code type hierarchy
:
: so Macro seems to be at least a type. which leads me to the question:
: is Macro also a class? and which is the difference between a type
: and a class? hm, I guess this will be answered in A12, so I'll
: probably have to wait on this.
Well, I'm using the terms type and class pretty much interchangeably
there, so don't put too much weight on that. But Perl 6 may well
distinguish classes from types. Classical classes can only add
capabilities when you derive (yes, you can redefine methods to do less,
but the interface is still there). When I think of types, I'm thinking
of parameterizing a class with some constraints. In the Ada world,
that's called subtyping. Whether these contraints are mathematical
(must be an even number) or structural (must have dimensions
(3,3,3)), they still cut down on the allowed set of values for the
base type.
It's possible to get along with just classes, if you say that subtyping
is done only by setting various attributes (such as the dimensions of
the array) on each individual object. But even if subtyping ends up
implemented that way under the hood, it's a very convenient way to
abstract a set of potential values and operations in the user's head,
and to communicate the exact intent to whoever has to maintain the
code later. You may know that this Int has to be an even number, but
it helps to be able to declare it as Even. And to the extent that
the computer can help you enforce the constraints, you get better
invariants.
If you say
$foo.isa(Even)
it doesn't just check to see if $foo is a member of class Int,
but it also checks the constraints on type Even, and returns false
unless $foo is an even integer.
We could still call Even a class if we wanted to, but it seems useful
to me to distinguish classes that work right from classes that
engage in hanky-panky. I think of types as being semi-instantiated.
In a sense, this is currying of classes.
: I also have another question (probably related, and probably also for
: later). consider this:
:
: sub mygrep( Code block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Block block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Routine block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Sub block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Method block, [EMAIL PROTECTED] is rw ) {...};
:
: is something like this allowed? and what is the meaning then? if logic
: serves me correctly, this shouldn't work:
:
: sub mygrep( Routine block, [EMAIL PROTECTED] is rw ) {...};
: mygrep { $_ 2 }, 1, 2, 3;
:
: because { $_ 2 } is a Block, not a Routine! it should be written
: like this:
:
: sub smaller_than_two ($value) { return $value 2 }
: mygrep smaller_than_two, 1, 2, 3;
:
: but this doesn't seem to make much sense. one should probably have
: said 'Code block' (or 'block' alone, which I suppose is just the
: same), but then what's the use of 'Routine', 'Sub', 'Method' etc. as
: types?
Those types are mostly for dynamic activities like chasing up your
call stack and doing smart matching.
: also, it's not clear to me the distinction between isa-relationship
: and namespace. I see that 'Rule' (and I presume 'Sub', 'Routine',
: 'Code', etc.) are all type names, but I wonder if 'Bare' is a type of
: its own -- or it is 'Block::Bare'? the latter sounds much better :-)
No, they're derived classes, not inner packages.
: in my class hierarchy I mixed 'probable' isa-relationships (eg. Sub
: isa Routine isa Code) with 'probable' proper namespace hierarchy (eg.
: Exception::Control::return, not return isa Control isa Exception).
: and this is probably very, very wrong.
Whether derived classes should be hidden within their base class is
not a simple question. It really depends on Huffman to some extent.
Most control exception types aren't used all that often, at least
not explicitly. In contrast, the Code classes are likely to be used
frequently in signatures.
: or maybe I'm just playing with dangerous toys that aren't intended for
: a little kid like me :-)
The Code classes are likely to be MISused frequently in signatures. :-)
Larry
Re: A6: Assignment Overloading
On Fri, Mar 14, 2003 at 01:20:28PM +1100, Damian Conway wrote: : Luke Palmer wrote: : : So, now that we have binding, is it possible to overload the : assignment operator? : : Not really. The problem is that Cinfix:= is really an operator on : *containers*, not on *values*. So, in order to overload C=, you'll still : need to define an appropriate CSTORE method on the appropriate : implementation class for the container. Whether CSTORE can also be : spelled Cinfix:= is another question. : : : Does the assignment operator mean value copy : instead of reference copy? : : The assignment operator means copy rhs's value into lhs's container. : The binding operator means copy (reference to) rhs's container into lhs's : symbol table entry. Note that assignment is a very shallow copy in any event. Intrinsic types are copied by default, plus any objects with a .copy method. In other words, Scalar has a .copy method by default, and anything else is your own doing. Int, Num, Str, and Ref inherit the .copy interface from Scalar. In particular, a Ref only copies itself unless it refers to something with a .copy method. In other words, the .copy method defines it as an intrinsic scalar type. That's exactly how it works, bearing in mind that any or all of the details might be wrong. Larry
A6 Type Inference
I apologize for not including a previous message thread -- I
fumble-fingered myself out of all the relevant ones
Still, I'd just like to cast my tiny vote regarding inferences.
I'd like to be able to write classes that can take advantage of
screaming speed, and types contribute.
I'd like to be able to tell my main script that it is required to pass
exact types, so that it gets those advantages. (I'd like something like
use strict; without specifying strict what to default to strict
everything.)
I'd still like to be able to use my module in quick one-off's without
having it break and die if I just pass it whatever default variable I
can manage not to declare.
Wouldn't I be able to do that by writing my module with something like
multi foo (Int $i){...}
multi foo (Scalar $s) {...}
???
Yes, I realize most people don't want to write seven versions of every
sub; but most of the time, my module is either going to be generic
enough that I'm not really as interested in the screaming end of speed,
or specific enough that I don't expect to use it for many one-off's, or
worth a little extra code.
Still, as a best-case, I'd like for the strict()-ness of my main
program to drive the determinance. If it's a slopjob quickie, I don't
*CARE* about greatspeed. Just DWIM and gimme what I want. If I want
fast code it's worth being careful, so I'll use strict and expect it to
gripe and expire if I didn't do something quite right.
So, my vote is, do the run-time checking if not strict; restrict me to
compile-time compliance under the strict pragma.
To be honest, I'd also kinda like to see a coerce-it-if-you-can
behavior, but I'd rather have that as a pragma as well. If it's worth
all the extra work to find an appropriate coersion, it's worth a few
extra keystrokes. but I could live without all that quite happily.
Am I off base?
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: [SUMMARY] A6: Type Inference
On Friday, March 14, 2003, at 11:06 AM, Michael Lazzaro wrote: AFAICT, these are the *only* possible solutions to the problem. At last count, Larry was leaning towards #2. Damian was countering with #1. Some Lowly Grubs were suggesting #3. Am I missing anything? Whoops! That needs correcting. Larry sayeth: The real question is whether this particular stricture is part of the default use strict that classes and modules assume. There are decent arguments on both sides of that one, but just to mollify Damian I'm inclined to come down on the strict side for that. E.G. use strict invokes #1, otherwise it's #2. Sorry for the repost, but if something says SUMMARY it'd be best for it not to be obsolete after the first 5 min... MikeL
Re: [SUMMARY] A6: Type Inference (was Re: A6: Strict signature checking)
Michael Lazzaro wrote: 3) If an untyped var is used for a typed parameter, a simple dataflow analysis is used to determine whether the compiler can guarantee that, at that point, an untyped var will _always_ contain values of a known, specific type. If so, the type is inferred (silently or with a warning, according to pragma?) Otherwise, it is a compile-time error. I was suggesting something slightly more subtle: * If the dataflow says its definitely wrong, then its an error * If the dataflow says its definitely OK, it is OK -- no warning, nor error, nor run-time check * Otherwise (silently or with warning), defer to run-time check The coercsion aspect makes it slightly more complex, but not significantly so.
Re: A6: Signature zones and such
At 8:07 AM -0800 3/14/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 3:07 PM + 3/14/03, Piers Cawley wrote: Brad Hughes [EMAIL PROTECTED] writes: Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? Dunno. But I'm merely expressing a preference. TPF can do with it what they will. Earmarked contributions are apparently somewhat dodgy from an IRS perspective--they don't want folks setting up a 503(c)(3) to do payroll stuff as a way to avoid taxes. (Rather than have an employee you have a grantee of a charity, thus the money you use to pay that person becomes a tax deduction, or something like that) The TPF's grant fund stuff's OK, though. It's just a matter of getting a grantee for this year... (Working on that) This doesn't seem right. The United Way runs directed drives all the time, in which they raise money for a particular cause. (And tap me on the shoulder...) There's no reason the TPF couldn't run a Fund P6 drive. There's a difference between Fund project X and Fund person X. Funding a project, and having one person suitable to do the project, is OK, generally speaking. (Though I expect the feds still peer pretty closely) Funding a specific person is dodgier. That means that TPF's perl development grant fund is fine to donate to, and if there's only enough cash for one grantee, and Larry's the best candidate, that's keen. Setting up a Fund Larry Wall fund is where things get much less easy. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
A6: Dispatch rules
In the tradition of Mr. Lazzaro, a chart:
For origin of the AUTOLOAD/DISPATCH stuff, see:
http://groups.google.com/groups?hl=enselm=3E6E853D.9090604%40conway.org
Does this make sense as far as the Rules of Dispatch? Ive included a
few suggestions where capability or sequence was unclear.
Given:
package pkg;
use Xclass qw(foo);
my $x = returns_an_Xclass();
foo $x; # Function-style
$x.foo; # Method-style
foo $x:;# Invocant-style (Is the colon needed?)
The dispatcher looks for:
(FM = Function-style or Method/Invocant-style, only)
##| FM DeclarationNote
==+===
A1|my macro foo
A2|macro pkg::foo See note 0, below
A3|macro *foo
B-|Only for method, invocant styles.
B1| M submethod Xclass::DISPATCH May be at runtime
B2| M method Xclass::DISPATCH
B3| M method SUPER::DISPATCH (SUPER meaning inherited)
C1|my sub DISPATCH
C2|sub pkg::DISPATCH
C3|sub *DISPATCH
D1|multi DISPATCH What's the signature required?
E1|my submethod fooDoes this make sense?
E2|submethod pkg::foo Or this?
E3|submethod Xclass::foo Only method, invocant styles.
E4|submethod *foo See note 1, below.
F1| M my method|rule Xclass::foo See note 2, below.
F2| M my method|rule foo See note 2, below.
F3| M method|rule Xclass::foo
F4| M method|rule SUPER::foo (SUPER meaning inherited)
F5| M method|rule *fooSee note 3, below.
G1| F my sub foo See note 4, below.
G2| F sub pkg::foo
G3| F sub *foo
H1|my multi foo See note 5.
H2|multi pkg::foo See note 5.
H3|multi *foo Requires compatible signature.
I1| M my submethod Xclass::AUTOLOAD
I2| M my method|rule Xclass::AUTOLOAD
I3| M submethod Xclass::AUTOLOAD
I4| M method Xclass::AUTOLOAD
J1| F? my sub AUTOLOAD
J2| F? sub pkg::AUTOLOAD
J3| F? sub *AUTOLOAD
K1| F? my multi AUTOLOAD See note 5.
K2| F? multi pkg::AUTOLOAD See note 5.
K3| F? multi *AUTOLOAD Requires compatible signature.
NOTES
=
Note 0: macro pkg::foo -- There's no forward declaring macros, because
of the need to modify the behavior of the parser. But can macros be
package scoped? I assume yes, because the act of doing use pkg;
causes pkg to maybe get parsed, and if pkg defines macro foo, then
macro foo pollutes the namespace of the user if it doesn't have package
scope. From this, I assume that leaving and re-entering the package
scope should reactivate the macro. Is this also true?
pkg p1;
macro foo ...
pkg p2;
foo; # Doesn't invoke macro
pkg p1;
foo; # Invokes macro.
Note 1: submethod *foo -- Submethods are a little weird, since the
intent is (from A6) a non-inheritable method. Defining Csubmethod
*foo sort of implies defining a non-inheritable method for all objects
(which makes it essentially inherited, although things like SUPER won't
invoke it). This seems like the sort of bizarre, hideously dangerous
thing that was common in p4/5. Is it desired/supported? (I can think of
no use for it.)
Note 2: my method foo -- This is essentially method with lexical
scope, which boggles my mind. But then it occurred to me that in the
right context (e.g. Cclass X { my method foo()...} this might be the
way to do submethods. Is it? Alternatively, is saying Cmy method
Xclass::foo a legal way to wrench control from the Xclass?
Note 3: method *foo -- This is speculation. A6 says, Methods and
submethods are ordinarily package scoped. So I'm inclined to wonder
about extraordinary methods. Is this another useless cul-de-sac, or
does the design team have something concrete in mind here?
Note 4: subs named foo, regardless of signature -- My interpretation
of subs is that there's no multidispatch once the name is matched.
Thus, if a sub with no signature exists in scope, it catches all calls
to that name. While if a sub with a signature exists in scope, it
catches calls to that name with matching signature. Some of Damian's
posts have seemed to me to imply that calls that don't match the
signature of the sub will FAIL, rather than dispatch on multimethods.
This needs clarification.
Note 5: my multi foo -- Another clarification is needed. A6 says, 'You
can declare scoped subroutines by explicitly putting a my or our on
the front of the declaration'. The implication of the following
examples is of Csub declarations, strengthened by the explicit
mention of defining scoped macros using Cmy. But, in the interest of
being a pain in the neck, I figured I should request clarification: Can
I define a scoped multi? If so, how? If not, why not? (The if not is
somewhat important, given that a huge number of built-ins are going to
become multis. If I can't scope them, how about C.wraping them? Will
wrappers be scoped?)
Re: [SUMMARY] A6: Type Inference
On Friday, March 14, 2003, at 12:21 PM, Dave Whipp wrote: Michael Lazzaro wrote: 3) If an untyped var is used for a typed parameter, a simple dataflow analysis is used to determine whether the compiler can guarantee that, at that point, an untyped var will _always_ contain values of a known, specific type. If so, the type is inferred (silently or with a warning, according to pragma?) Otherwise, it is a compile-time error. I was suggesting something slightly more subtle: * If the dataflow says its definitely wrong, then its an error * If the dataflow says its definitely OK, it is OK -- no warning, nor error, nor run-time check * Otherwise (silently or with warning), defer to run-time check The coercsion aspect makes it slightly more complex, but not significantly so. Sorry -- I agree 100% with that. As a language feature, it has problems, as Luke Angel both pointed out. As a mere optimization of case #2, it's fine, and there's not really any language implications. In tight loops, etc., it would probably speed up the runtime quite a bit, in fact. The optional warning if it falls through to the runtime check is important, IMO, because even lazy one-off scripts sometimes need to be fast. :-/ It would still mean that, in 'non-strict' mode, you might get different deferring to runtime typechecking warnings on different versions of P6, but I don't see that as a big issue, if it's just an optional warning. MikeL
nested named subs
on boston.pm a thread arose about having named subs inside subs. of
course perl5 can do it but they don't do anything useful but they do
have some odd implemenation defined closure behavior.
someone brought up lisp and scheme and how they do it (differently from
each other).
well, i want to dredge up how PL/I did it and i think it makes for a
useful concept.
my $c ;
sub foo {
my $a ;
my $b ;
blah
bar() ;
sub bar {
$b = $a + $c ;
}
}
first point is that bar is NOT a closure. it makes no copies of $a and
$b into a pad. bar uses the actual $a and $b of foo on the stack. it
should do work the same for foo's params.
the lexical scope of foo covers bar so it will only see outside vars if
foo doesn't declare them. bar sees the outer $c just fine. bar can't be
seen outside of foo as well.
internally all that is needed (and this is how we did in in PL/I) is to
pass a stack frame reference as a hidden argument to bar(). bar will
need to be declared with this hidden extra var or the internals will have to
pass it some nonstandard way.
bar can be recursive and it will not get fresh copies of $a and $b. it
can declare its own lexicals and they DWYM in recursion.
so there is basically no syntax changes at all. just a compiler feature
to recognize internal named subs and use those semantics.
also we can say child subs can't have child subs inside them but that
isn't required. i am sure one of you can come up with a coding need for
that. :)
any thoughts?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: nested named subs
on boston.pm a thread arose about having named subs inside subs. of
course perl5 can do it but they don't do anything useful but they do
have some odd implemenation defined closure behavior.
someone brought up lisp and scheme and how they do it (differently from
each other).
well, i want to dredge up how PL/I did it and i think it makes for a
useful concept.
my $c ;
sub foo {
my $a ;
my $b ;
blah
bar() ;
sub bar {
$b = $a + $c ;
}
}
first point is that bar is NOT a closure. it makes no copies of $a and
$b into a pad. bar uses the actual $a and $b of foo on the stack. it
should do work the same for foo's params.
I might be misunderstanding you, but how is this different
(semantically) from a lexical named closure?
my $c;
sub foo() {
my $a;
my $b;
my sub bar() {
$b = $a + $c;
}
bar();
}
Bar can be recursive. $a and $b still refer to foo()'s $a and $b.
Bar can even trivially have nested subs. bar() can't be seen from
outside foo. I don't see the difference. Perhaps you could give a
better example in how this differs?
Luke
A6: Named vs. Variadic Parameters
A simple question, I hope...
From A6, Calling Subroutines, comes the following:
multi push(@array, +$how, [EMAIL PROTECTED]) {...}
push(@a, how = 'rapidly', 1,2,3); # OK
push(@a, 1,2,3); # WRONG, $how == 1!
Oops! What you really wanted to say was:
multi push(@array, [EMAIL PROTECTED], +$how) {...}
push(@a, how = 'rapidly', 1,2,3); # OK
push(@a, 1,2,3); # OK
Note the gotcha part... if you want to use both named arguments and a
variadic list, you must declare the parameters in the signature in a
different order than they must appear when actually calling the sub.
If you put the signatured params and the actual arguments in the _same_
order, it will break. The reason for this is because, in the first
example, the slurpy array has been placed in the named-only zone, _not_
the positional zone.
Clearly, it's going to be a newbie problem, and I guess I'm not
understanding why we can't enforce What They Really Meant.
When calling a sub that has both named params and a slurpy list, the
slurpy list should always come last. If a sub has both a slurpy hash
and a slurpy list, the slurpy list should still always come last. You
simply can't credibly have anything after the slurpy list, or it'll be
slurped. So args/params must ALWAYS come in this exact order, if they
are to be useful:
sub foo(
$x,# required positional
?$y,# optional positional
+$k,# optional named
*%h,# optional slurpy hash
*$s,# optional slurpy scalar
[EMAIL PROTECTED],# optional slurpy array
) {...}
I guess what I'm not understanding is why you would _EVER_ want [EMAIL PROTECTED]
to be in the named-only zone, and presuming you never would, why we
can't syntactically / semantically fix the above gotcha so that the
params always appear in the calling order?
MikeL
Re: A6: Named vs. Variadic Parameters
When calling a sub that has both named params and a slurpy list, the
slurpy list should always come last. If a sub has both a slurpy hash
and a slurpy list, the slurpy list should still always come last. You
simply can't credibly have anything after the slurpy list, or it'll be
slurped. So args/params must ALWAYS come in this exact order, if they
are to be useful:
sub foo(
$x,# required positional
?$y,# optional positional
+$k,# optional named
*%h,# optional slurpy hash
*$s,# optional slurpy scalar
[EMAIL PROTECTED],# optional slurpy array
) {...}
I guess what I'm not understanding is why you would _EVER_ want [EMAIL PROTECTED]
to be in the named-only zone, and presuming you never would, why we
can't syntactically / semantically fix the above gotcha so that the
params always appear in the calling order?
The idea is that positional parameters are always a contiguous
sequence in the argument list. If it looked like this:
sub foo($x, ?$y, +$k, [EMAIL PROTECTED]) {...}
Then one might presume to call it like:
foo($x, $y, $k, 1, 2, 3);
Which they can't. So it makes sense to have everything positional up
front, while things that can go anywhere (but must be labeled) in the
back.
Your method makes sense, too. To me, they both make a lot of sense,
but they aren't orthogonal. So you have to pick one. I'm happy with
the current way.
Luke
Re: A6: Strict signature checking - was: Complex Parameter Types
-- On Fri, 14 Mar 2003 10:08:15 Larry Wall wrote: On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote: : I think that there should be two types of arg typing[1]: 'strict' and : 'loose'. Strict arg typing doesn't coerce, except to turn subclasses : into superclasses; loose arg typing, on the other hand, coerces whenever : possible. The mechanism for choosing between strict and loose arg : typing should be under the caller's control, not the callee's. (The : callee decides what types they want, and the caller decides how to : create those types. This seems consistent with Perl's philosophy of : being flexible and making BD optional.) Precisely. The parameter types are completely invariant for the callee. They are optionally invariant for the caller depending on some kind of stricture. But I darn well want the naive user to be able to pass a Scalar to an Int parameter and have it DWTM without them knowing a blessed thing about these mysterious entities called classes. We've got to keep the entry ramp low, or Perl is no longer Perl. The real question is whether this particular stricture is part of the default use strict that classes and modules assume. There are decent arguments on both sides of that one, but just to mollify Damian I'm inclined to come down on the strict side for that. I'll put my vote down on strictness (as in complain about mismatch as soon as possible) by default. But just as prototypes are ignored when we prepend in Perl 5 can't some similar frobobnitz say But on this here call, wait till runtime and coerce if needed? After all, it's not the kind of thing a callee should dictate, but the caller. This week. :-) I'm easy. -Erik Larry Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
