r31885 -[S06] fix an obvious typo
Author: sorear Date: 2010-08-01 11:18:45 +0200 (Sun, 01 Aug 2010) New Revision: 31885 Modified: docs/Perl6/Spec/S06-routines.pod Log: [S06] fix an obvious typo Modified: docs/Perl6/Spec/S06-routines.pod === --- docs/Perl6/Spec/S06-routines.pod2010-08-01 07:09:36 UTC (rev 31884) +++ docs/Perl6/Spec/S06-routines.pod2010-08-01 09:18:45 UTC (rev 31885) @@ -64,7 +64,7 @@ name within its scope, unless they have an explicit modifier. (This is particularly useful when adding to rule sets or when attempting to compose conflicting methods from roles.) Abstractly, the Cproto -is a wrapper around the dispatch to the Cmulti.s +is a wrapper around the dispatch to the Cmultis. BOnly (keyword: Conly) routines do not share their short names with other routines. This is the default modifier for all routines,
Natural Language and Perl 6
Hi. I'm wondering if any thought has been given to natural language processing with Perl 6 grammars. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Natural Language and Perl 6
Hello On 01/08/2010 11:46, Timothy S. Nelson wrote: Hi. I'm wondering if any thought has been given to natural language processing with Perl 6 grammars. I Think Perl 6 grammars can implement the most advanced parsing algorithms like Generic LR, that that will not really solve the problem of NLP. Unfortunately. Natural language is too ambiguous and needs special treatment. At least, this is my opinion on working on NLP for the Portuguese for about en years ;) Cheers :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- -- Alberto Simões
Extending the sockets library
Hi folks, I was inspired by Ksplice's recent article on traceroute [1] to write my own traceroute in Perl 6 - but came upon problems in that the current socket library does not seem to be complete enough. I'd love to submit some patches for this, but after briefly discussing this with pmichaud in #perl6 [2] it sounds like I should ask here first for a little bit of guidance. My current plan is to extend Parrot with the necessary functions (I've done getprotobyname to get my feet wet so far, but there are others such as setsockopt that need to be added) and then write Perl 6 code for this. pmichaud suggests this is not done inside Raduko, but as a separate module. I'm a little unsure about this though, as IO::Socket::* is already core - and that seems to be the correct place to be adding most of these functions. I added my getprotobyname implementation as a core subroutine, as it is in Perl 5 - but that also may not be the correct approach (maybe IO::Socket should export that). Please advise, I'm eager to get hacking on this :) -- [1]: http://blog.ksplice.com/2010/07/learning-by-doing-writing-your-own-traceroute-in-8-easy-steps/ [2]: http://irclog.perlgeek.de/perl6/2010-08-01#i_2649053
Re: Smart match isn't on Bool
HaloO,
On Saturday, 31. July 2010 20:47:49 Patrick R. Michaud wrote:
On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
It's not unreasonable, especially if that's what you expect.
But it's even more reasonable to expect this to work:
given $something {
when True { say That's the truth! }
when 42 { say Good answer! }
when viaduct { say You guessed the secret word! }
}
I'm not so sure about this. There's an argument to be made that
the Cwhen 42 and Cwhen viaduct cases should never be reachable,
since both C42 and Cviaduct are considered true values...
Sorry, I don't understand this possible argument. Isn't the intent
of a given/when to select one alternative by means of the given?
This is what a switch statement does. Perl 6 allows non-constants
after when, so it's reasonable to have the constant in the given
and to see e.g. which function returns it. Of course the first actually
doing this determines the switch.
... unless you want Cwhen True to do a value-and-type check,
in which case it doesn't exactly follow the pattern for smartmatching
of the other builtin types (which only check value equivalence,
not type equivalence).
This is true only if you want to distinguish 1 and True which are the
same value. But 42 should be distinct from this. Same goes for viaduct.
So these three should be a valid disjoint set of choices that can be
made given $something.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
r31886 -[S03] remove Subst type, which appears nowhere else
Author: moritz Date: 2010-08-01 20:01:49 +0200 (Sun, 01 Aug 2010) New Revision: 31886 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] remove Subst type, which appears nowhere else Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2010-08-01 09:18:45 UTC (rev 31885) +++ docs/Perl6/Spec/S03-operators.pod 2010-08-01 18:01:49 UTC (rev 31886) @@ -3586,7 +3586,6 @@ named values created with Class, Enum, or Role, or generic type binding Type -Subst Regex Char CatStr Int UInt etc. Num Match Capture
Perl 6 User Documentation
Hi, Following the release of Rakudo Star I've been playing around with learning Perl 6 and noticed a distinct lack of user-facing documentation. After some IRC chats with pmichaud++ I thought it would be a good idea if I got the ball rolling, assuming of course it doesn't reach a sharp incline, roll back and squash me. Attached are a 3 very initial (skeletal in nature) Perl 6 .pod documents, based loosely on the Perl 5 documentation. It is my understanding that currently there is no P6-Pod reader e.g. perl6doc so these are actually written in P5-POD, but the intent is to eventually of course translate them to P6-Pod. My purpose is to get very initial feedback, see if this is the right direction to go at all, get some thoughts on basic terminology, stuff like that. For example: 1. Use P5 POD or insist on P6 Pod? 2. Is it Perl 6 or just Perl? Currently it's perl6 but will it be just perl eventually? 3. Can I just rename S26.pod to perl6pod.pod and be done with it? :) Best regards, -- Offer Kaye perl6.pod Description: Binary data perl6doc.pod Description: Binary data perl6intro.pod Description: Binary data
Re: Suggested magic for a .. b
On Wed, 28 Jul 2010, Darren Duncan wrote: I think that a general solution here is to accept that there may be more than one valid way to sort some types, strings especially, and so operators/routines that do sorting should be customizable in some way so users can pick the behaviour they want. The customization could be applied at various levels, such as using an extra argument or trait for the operator/function that cares about ordering, That much I agree wholeheartedly with, but ... or by using an extra attribute or trait for the types being sorted. ... puts us back where we started: how do we cope if the two endpoints aren't tagged with the same attribute or trait or locale? In any case I'd much rather prefer that the behaviour be lexically scoped, with either adverbs or pragmata, not with the action-at-a-distance that's caused by tagging something as fundamental as a String. Yes sometimes you want the behaviour of your range to mimic the locale of its operands, but then it should be explicit, with a trait that also explicitly selects either the left or right operand to extract the locale from. And probably throw an exception if they aren't in the same locale. If you don't specify that you want locale-dependent behaviour then the default action should be an unthrown exception unless both endpoints are inarguably comparable, so IMHO that pretty much rules out any code-points that are used in more than language, save perhaps raw ASCII. And even then you really should make an explicit choice between case-sensitive and case-insensitive comparison. When you want to be consistent, the behaviour of cmp affects all of the other order-sensitive operations, including any working with intervals. Indeed, the range constructor and the cmp operator should have the same adverbs and share lexical pragmata. So then, a cmp ส้ is always defined, but users can change the definition. I take the opposite approach; it's always undefined (read, unthrown exception) unless the user tells us how they want it treated. That can be a command-line switch if necessary. To paraphrase Dante, the road to hell is paved with Reasonable Defaults. Or in programming terms, your reasonable default is the cause of my ugly work-around. -Martin
Re: Smart match isn't on Bool
TSa (Thomas Sandlaß) wrote: ... unless you want Cwhen True to do a value-and-type check, in which case it doesn't exactly follow the pattern for smartmatching of the other builtin types (which only check value equivalence, not type equivalence). This is true only if you want to distinguish 1 and True which are the same value. But 42 should be distinct from this. Same goes for viaduct. So these three should be a valid disjoint set of choices that can be made given $something. Is that so? 1 and True *are* the same value now? Not Bool wraps Int rather than being a subset type and it and has wholly distinct values? Carl Mäsak wrote: I don't know whence you got the impression that Bool is a subtype. Bool is an enumeration type, which makes True and False distinct objects both of which aren't (but instead wrap) their corresponding Int values. Asking False eqv 0 should be false, though either False eqv ?0 or +False eqv 0 being true is okay. All those are as you want them. I would like for what Carl said to be true, but TSa seems to be contradicting it. 1 and True should *not* be the same value, and they should be distinguishable in any generic context like eqv or given-when. They should only compare alike when cast into the same type such as with a ? or +. -- Darren Duncan
Re: Smart match isn't on Bool
Darren Duncan wrote: TSa (Thomas Sandlaß) wrote: ... unless you want Cwhen True to do a value-and-type check, in which case it doesn't exactly follow the pattern for smartmatching of the other builtin types (which only check value equivalence, not type equivalence). This is true only if you want to distinguish 1 and True which are the same value. But 42 should be distinct from this. Same goes for viaduct. So these three should be a valid disjoint set of choices that can be made given $something. Is that so? 1 and True *are* the same value now? No, they aren't. Not Bool wraps Int rather than being a subset type and it and has wholly distinct values? We look at Bool as an enumeration type. The base type of that enumeration type may well represent False and True as 0 and 1, but that's an implementation detail. They're not eqv or ===. Carl Mäsak wrote: I don't know whence you got the impression that Bool is a subtype. Bool is an enumeration type, which makes True and False distinct objects both of which aren't (but instead wrap) their corresponding Int values. Asking False eqv 0 should be false, though either False eqv ?0 or +False eqv 0 being true is okay. All those are as you want them. I would like for what Carl said to be true, but TSa seems to be contradicting it. Carl is correct. 1 and True should *not* be the same value, and they should be distinguishable in any generic context like eqv Correct. or given-when. No, given-when is smart-matching. The RHS of a smart-match decides what happens. If you to True ~~ 1 then that's 1.ACCEPTS(True) which is going to do +True and thus match. They should only compare alike when cast into the same type such as with a ? or +. Right, which happens in given/when. Jonathan
Re: Suggested magic for a .. b
Martin D Kealey wrote: On Wed, 28 Jul 2010, Darren Duncan wrote: I think that a general solution here is to accept that there may be more than one valid way to sort some types, strings especially, and so operators/routines that do sorting should be customizable in some way so users can pick the behaviour they want. The customization could be applied at various levels, such as using an extra argument or trait for the operator/function that cares about ordering, That much I agree wholeheartedly with, but ... or by using an extra attribute or trait for the types being sorted. ... puts us back where we started: how do we cope if the two endpoints aren't tagged with the same attribute or trait or locale? In any case I'd much rather prefer that the behaviour be lexically scoped, with either adverbs or pragmata, not with the action-at-a-distance that's caused by tagging something as fundamental as a String. Lexical scoping *is* a good idea, and I would also imagine that users would frequently apply that at the file or setting level. But making this a pragma means that the pragma would have to be a little more verbose than a typical pragma. In the general format, one wouldn't just say, eg: collation FooNation; ... but rather it would at least be more like: collation Str FooNation; ... to say that you're only applying to operations involving Str types and not, say, Numeric types. So then, a cmp ส้ is always defined, but users can change the definition. I take the opposite approach; it's always undefined (read, unthrown exception) unless the user tells us how they want it treated. That can be a command-line switch if necessary. To paraphrase Dante, the road to hell is paved with Reasonable Defaults. Or in programming terms, your reasonable default is the cause of my ugly work-around. That might be fair. But if we're going to do that, then I'd like to go a step further and require some other operators have mandatory config arguments for users to explicitly state the semantics they want, but that once again a lexical pragma can declare this at a higher level. I'm restating this thought in another thread, rounding method adverbs, so that's the best place to follow it. -- Darren Duncan
rounding method adverbs
Martin D Kealey said (in the a..b thread): So then, a cmp ส้ is always defined, but users can change the definition. I take the opposite approach; it's always undefined (read, unthrown exception) unless the user tells us how they want it treated. That can be a command-line switch if necessary. To paraphrase Dante, the road to hell is paved with Reasonable Defaults. Or in programming terms, your reasonable default is the cause of my ugly work-around. That might be fair. But if we're going to do that, then I'd like to go a step further and require some other operators have mandatory config arguments for users to explicitly state the semantics they want, but that once again a lexical pragma can declare this at a higher level. Specifically, I think there should be a configuration for any numeric operations that might do rounding, where users specify the rounding method employed. For example, the Int-resulting division and modulo operators should require specifying how to round on an uneven division. I can think of at least 9 rounding methods to choose from off the top of my head: up (ceiling), down (floor), to-zero (truncate), to-infinity, half-up (common), half-down, half-to-zero, half-to-infinity, and half-to-even (statistics, banking, etc). There are probably more, so this should be extensible. The point here is that there are multiple distinct expectations on what is a reasonable default way to do numeric rounding, and it would be a lot more clear for everyone reading code if these semantics were spelled out. Just because such as default is stated in the Perl 6 manual doesn't mean it won't constantly trip people up all the same. In particular, common programming languages are often split between down/floor and to-zero/truncate as their semantics, and I believe even Perl 5 and Perl 6 differ on the issue. Having these options provided also supports some other common tasks. For example, the up/ceiling option would be common, if the task is to figure out how many containers we need to hold our widgets, or how many rows in which to display multi-column data. For example: $num_boxes_needed = $num_widgets div $box_capacity :round(Up) Similarly, explicitly stated rounding semantics are useful for non-integer operations such as currency or statistics or science. Also useful when we want to emulate other languages in Perl 6 elegantly and even-handedly. Now, of course, some rounding methods may be more efficient than others on particular hardware, but that's just something that should be documented, or alternately an explicit named rounding method of don't care could be provided, for users who don't care about exact portable semantics, and the implementation can decide what is fastest. I suggest using the whatever mnemonic for this: $a = $b div $c :round(*) ... though for those people, probably they'd do it at the file level. -- Darren Duncan
Smart-matching and m//
Consider 'abc' ~~ m/b/; By current spec this would 1) temporary set $_ = 'abc' 2) call m/b/, which matches against $_ 3) produce a Match object 4) calls .ACCEPTS($_) on the Match object 5) return False Likewise 'abc' ~~ .uc ends up comparing 'abc' to 'ABC and return False. I guess that's not what we want, so there might be a need for a rule preventing the .ACCEPTS call when $_ is used on the RHS. (The previous spec with syntactic forms kinda solved the problem, the $_ topicalization re-introduced it). Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Suggested magic for a .. b
On Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey mar...@kurahaupo.gen.nz wrote: In any case I'd much rather prefer that the behaviour be lexically scoped, with either adverbs or pragmata, not with the action-at-a-distance that's caused by tagging something as fundamental as a String. In many cases the collation isn't known at compile-time, so adverbs would be necessary anyway. Pragma's can make things easier in many cases. Leon
Re: Natural Language and Perl 6
On Sun, Aug 1, 2010 at 5:46 AM, Timothy S. Nelson wayl...@wayland.id.auwrote: Hi. I'm wondering if any thought has been given to natural language processing with Perl 6 grammars. No specific tool is best suited for natural language processing. There was apparently a time in which everyone thought that a formal grammar could clearly define any natural language, but I don't think anyone succeeded at creating a complete formal grammar for any language other than something like Esperanto. Modern NLP seems to be focused on (empirical based) stochastic models or other statistical models. Most languages can be used to build and represent such systems. That being said, there are sub-fields where it might help, such as stemming, POS tagging, or text generation. Perl 6 grammars seem best suited to reduce the workload to build and manipulate parse trees or lattice models. Depending on what task is at hand, this may be of no use. I am finishing a masters in NLP and after all this work, p6 grammars wouldn't have helped much. -Jason s1n Switzer
