perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)
Ovid wrote: Larry pointed out that this topic is better suited for perl6-language instead of perl6-users, so I'm forwarding this along. Is there a reason perl6-users isn't fed through to nntp.perl.org ? Maybe it is but I don't know to which group?
Re: perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)
mAsterdam schreef: Ovid: Larry pointed out that this topic is better suited for perl6-language instead of perl6-users, so I'm forwarding this along. Is there a reason perl6-users isn't fed through to nntp.perl.org ? Maybe it is but I don't know to which group? news://nntp.perl.org/perl.perl6.users There is also perl.perl6.announce perl.perl6.compiler perl.perl6.documentation perl.perl6.internals perl.perl6.language -- Groet, Ruud
[svn:perl6-synopsis] r9310 - doc/trunk/design/syn
Author: larry
Date: Fri May 26 09:57:12 2006
New Revision: 9310
Modified:
doc/trunk/design/syn/S06.pod
Log:
Clarifications of inner type from sam++.
Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in.
Ref: http://www.wall.org/cgi-bin/photo/index.cgi?mode=viewalbum=/pix/Julian
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri May 26 09:57:12 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 24 May 2006
+ Last Modified: 26 May 2006
Number: 6
- Version: 36
+ Version: 37
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -1405,14 +1405,20 @@
my $spot of Dog;
In either case this sets the Cof property of the container to CDog.
-Subroutines have a variant of the Cof property, Creturns, that
-sets the Creturns property instead. The Creturns property specifies
-a constraint to be checked upon calling Creturn that, unlike the Cof
-property, is not advertized as the type of the routine:
-
-our Animal sub get_pet() {...}
-sub get_pet() returns Animal {...}
-sub get_pet() of Animal {...}
+
+Subroutines have a variant of the Cof property, Creturns, that sets
+the Creturns property instead. The Creturns property specifies a
+constraint (or perhaps coercion) to be enforced on the return value (either
+by explicit call to Creturn or by implicit fall-off-the-end return).
+This constraint, unlike the Cof property, is not advertised as the
+type of the routine. You can think of it as the implicit type signature of
+the (possibly implicit) return statement. It's therefore available for
+type inferencing within the routine but not outside it. If no inner type
+is declared, it is assumed to be the same as the Cof type, if declared.
+
+sub get_pet() of Animal {...} # of type, obviously
+our Animal sub get_pet() {...} # of type
+sub get_pet() returns Animal {...} # inner type
A value type on an array or hash specifies the type stored by each element:
@@ -1539,19 +1545,21 @@
=head2 Return types
-On a scoped subroutine, a return type can be specified before or
-after the name. We call all return types return types, but distinguish
-two kinds of return type, the Cwhere type from the Cof type, because
-the Cof type must be an official named type, while the Cwhere type
-is merely applied as a constraint to what may be returned by the routine.
+On a scoped subroutine, a return type can be specified before or after
+the name. We call all return types return types, but distinguish
+two kinds of return type, the Cinner type and the Cof type,
+because the Cof type is normally an official named type and
+declares the official interface to the routine, while the Cinner
+type is merely a constraint on what may be returned by the routine
+from the routine's point of view.
+our sub lay returns Egg {...} # inner type
our Egg sub lay {...} # of type
-our sub lay returns Egg {...} # where type
our sub lay of Egg {...} # of type
our sub lay (-- Egg) {...}# of type
+my sub hat returns Rabbit {...}# inner type
my Rabbit sub hat {...}# of type
-my sub hat returns Rabbit {...}# where type
my sub hat of Rabbit {...} # of type
my sub hat (-- Rabbit) {...} # of type
@@ -1559,14 +1567,14 @@
namespace (module, class, grammar, or package), as if it's scoped with
the Cour scope modifier. Any return type must go after the name:
-sub lay returns Egg {...} # where type
+sub lay returns Egg {...} # inner type
sub lay of Egg {...} # of type
sub lay (-- Egg) {...}# of type
On an anonymous subroutine, any return type can only go after the Csub
keyword:
-$lay = sub returns Egg {...}; # where type
+$lay = sub returns Egg {...}; # inner type
$lay = sub of Egg {...}; # of type
$lay = sub (-- Egg) {...};# of type
@@ -1581,12 +1589,12 @@
The return type may also be specified after a C -- token within
the signature. This doesn't mean exactly the same thing as Creturns.
The Cof type is the official return type, and may therefore be
-used to do type inferencing outside the sub. The Cwhere type only
+used to do type inferencing outside the sub. The Cinner type only
makes the return type available to the internals of the sub so that
the Creturn statement can know its context, but outside the sub we
don't know anything about the return value, as if no return type had
been declared. The prefix form specifies the Cof type rather than
-the Cwhere type, so the return type of
+the Cinner type, so the return type of
my Fish sub wanda ($x) { ... }
@@ -1598,7 +1606,7 @@
my
Re: [svn:perl6-synopsis] r9310 - doc/trunk/design/syn
l == larry [EMAIL PROTECTED] writes: l Log: shouldn't that be grandpa's log, earth date 200605252055? l Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in. lRef: http://www.wall.org/cgi-bin/photo/index.cgi?mode=viewalbum=/pix/Julian so when does he get his commit bits? :) congrats, grandpa! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: packages vs. classes
On 5/23/06, Sam Vilain [EMAIL PROTECTED] wrote: Right, but we should really ship with at least a set of Meta Object Protocol Roles, that covers the core requirements that we will need for expressing the core types in terms of themselves; - classes and roles - attributes and methods - subsets (ie constraints/subtypes) - generics (including, by induction, nested generics) I *think*, at this point, that's all that are necessary. I would maybe add a protocol for instance creation. We have recently added that to Moose, and found it very useful in terms of abstracting out the kind of instance storage used (ARRAY based storage currently Just Works given the right Instance sub(meta)class). I see the instance protocol as being an important component of cross language runtime thing. If all instances conform to, or can be made to conform to, an base instance protocol, making Perl 6 objects which inherit from Python objects should be fairly easy. People can instantiate the roles that cover all that to an actual metaclass in whatever way they like (eg, Moose::Meta::Class-isa(Class::MOP::Class)), but not having to detect the type and then figure out how to talk to it for at least the core of the object system would be good. I think the roles can serve as the core interface nessecary to function with the base object system. As long as my metaclass .does() the correct role, it should be able to function in the object system. Of course the old garbage-in garbage-out rule applies, we should give you enough meta-rope to shoot your meta-self in your meta-foot. People can diverge completely with completely incompatible metaclasses that don't .do those roles, the only side effect of which being that people who write code for the standard Perl 6 metamodel will be incompatible, and maybe some ways of setting up the class won't work without another layer of trickery. I *think* that's what you're getting at. Of course, it shouldn't be prohibited just because it smells. I am not sure I like this, incompatible metaclass issues are really really tricky and hard to debug (aka - smells *really* bad). And the system needed to support them really can bloat the metamodel internals in a nasty way. There are several papers out there on the subject, none of which IMO provide a satisfactory solution. The problem then becomes compounded by introducing the Python and Ruby metamodels into the fray. Having a single compatability level made out of roles is not that much of a restriction really, and keeps much of the system interals clean and orderly. It also makes it much easier for use to add new metamodels from other languages by just by writing a layer to map to the core metamodel roles. - Stevan
Re: packages vs. classes
--- Stevan Little [EMAIL PROTECTED] wrote: On 5/23/06, Sam Vilain [EMAIL PROTECTED] wrote: People can diverge completely with completely incompatible metaclasses that don't .do those roles, the only side effect of which being that people who write code for the standard Perl 6 metamodel will be incompatible, and maybe some ways of setting up the class won't work without another layer of trickery. I *think* that's what you're getting at. Of course, it shouldn't be prohibited just because it smells. I am not sure I like this, incompatible metaclass issues are really really tricky and hard to debug (aka - smells *really* bad). And the system needed to support them really can bloat the metamodel internals in a nasty way. There are several papers out there on the subject, none of which IMO provide a satisfactory solution. The problem then becomes compounded by introducing the Python and Ruby metamodels into the fray. Having a single compatability level made out of roles is not that much of a restriction really, and keeps much of the system interals clean and orderly. It also makes it much easier for use to add new metamodels from other languages by just by writing a layer to map to the core metamodel roles. my $.02 I'd say a more standard system is much better, so long as we leave a standard set of hooks by which someone can insert a nonstandard setup. A small API isn't a huge bloat, and is worth it, though I agree that a full system might actually be counterproductive. And by all that I've seen lately, the whole language is pretty malleable that way; those who really want the nonstandard model can take the small overhead hit of whatever internal shenanigans they need to implement, and just about anything like that can be stuffed into a module now, can't it? So the upshot is, a standardized metamodel seems like the way to go to me /my $.02 ot And Congrats again, gramps. May your new little one be as loved as the language you've also labored so much to guide to maturity. ;o] /ot Paul on est aisément dupé par ce qu'on aime -- Molière (one is easily fooled by that which one loves) Increase in wisdom can be measured accurately by the corresponding decrease in anger. -- Friedrich Nietzsche There are trivial truths and there are great Truths. The opposite of a trival truth is obviously false. The opposite of a great Truth is also true. -- Neils Bohr Real friends are those whom, when you must inconvenience them, are bothered less by it than you are. -- me. =o) Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))
Hi, I used AI::Prolog once briefly, and that's the extent of my logic programming knowledge. There do seem to be a few Perl 6 features that may be useful for logic programming, although I'm not really qualified to judge. How would one assert facts and rules in Perl6? How would one know that a variable is a logic variable and not a normal one? Assignment to a logic variable which is still subject to rebinding could break code. On the other hand, using normal variables for logic variables could let us use objects for them and I think this might get us contraint programming (long story). let variables and hypothetical assignments within rules may be a good starting point. Hypothetical variables are mentioned here: http://dev.perl.org/perl6/doc/design/syn/S04.html#Definition_of_Success While they usually occur within rules, hypothetical assignments can be to a target variable: http://dev.perl.org/perl6/doc/design/syn/S05.html#External_aliasing and let can now be used in any other closure. More details in A05: http://dev.perl.org/perl6/doc/design/apo/A05.html#Hypothetical_Variables,_er_Values There's also the question of non-logical behavior in logic programming. What happens if you try to use math in Perl6 logic programming? Generally speaking, math is non-logical in the sense that it's used in Prolog (see the aforementioned article). Opening and reading from a file is also non-logical (you can't backtrack over it). How are those issues to be handled? Closures may have an undo trait which should be written to revert the side-effects of the closure when it receives an UNDO control exception (the block fails, see Definition of Success above). http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits For file reading the undo would seek back to the correct point. This does require the programmer to code the undo operation, which may not be possible (with non-seekable handles for examples). Are there other languages that blend logic and imperative styles that can be stolen from? Perl6 grammars may be able to assist with this, but grammars (as far as I can tell) are still based around strings and not data structures. Admittedly, Prolog is essentially a fancy string rewriting system, but it's not clear how the grammars would be applied to this problem. There's some information about this in S05, with more info promised: http://dev.perl.org/perl6/doc/design/syn/S05.html#Matching_against_non-strings Brad -- Dohaku's wife suffered some severed fingers. Dohaku's wound was a severed neck bone, and since only his throat remained intact, his head hung down in front. Now boosting his head up with his own hands, Dohaku went off to the surgeon's.-- Hagakure http://bereft.net/hagakure/
