Re: Perl 6 fundraising and related topics.
> Whilst debating issues like parrot vs pugs, or single-track vs parellel > track development, can be quite interesting, especially if it induces > Larry to compare straight lines to mountains and railroads, it is likely > to be more useful to have suggestions like chromatic's - 1month of > dedicated work for $5000. > > How about adding a page to one of the web sites where offers of help, > time and expense, can be made? Very good idea. Any takers? I would, but my internet connectivity is severely constrained atm. That will change from April 15th on, if noone made it until then, I'll do. But it would be shame to wait that long ;-) Cheers, Moritz
Re: Perl 6 fundraising and related topics.
> In article > [EMAIL PROTECTED]>, Conrad Schneiker > <[EMAIL PROTECTED]> wrote: > > >> So over the next few months, I'm planning to learn about >> fundraising, and see what I can accomplish on behalf of Perl >> 6 development. To that end, I'm soliciting: > > It's not really a money problem. It's finding someone to give the money > to. I've been trying to force money on some people to work on Perl 6, > but they don't wants it, for whatever reason. Part of that is that TPF > officers aren't supposed to get grant money. > > And, before you think about raising money, check how much money TPF > actually has. There is still half of the NLNet's $70k to be > distributed. for instance. It's not a fundraising problem. Find a > person who would take money before you spend too much time finding the > money. Targeted fundraising is more effective anyway :) That's why I raised the debate on whom to aid. I've seen that Daniel Ruoso applied for a grant for his smop project, basically a virtual machine and fast backend for kp6, and perhaps other implementations. TPF decided not to invest into yet another implementation. So I learn that they do have money, and don't seem to finde worthy targets to spend it. On the other hand there are applications that I do consider worthwhile. That's what made me come to the conclusion that it's really "The Parrot Foundation". But from chromatic's response I learned that there is good way to support parrot - but financing him for month. So where is the problem? Why doesn't the money flow one way or another? Does TPF want to sponsor more Perl 5 related development? Or was that offer, $5k for 1 month full time hacking, not known before? Moritz
Re: question about twigil ?
> currently just used for compile time constants like $?LINE allright so > far so good. > but why not use that for all constants like > > my $?constant = 5; Because then you'd have to change existing code if you find out that constant was not so constant at all, and you'd like to have a variable instead ;-) Moritz
Re: Which brackets should @a.perl use?
> m...@edward:~/perl/6$ ./ap2
> @c: 3 elements: ["blue", "light", "hazard"]
> @c[0]: blue
> $c: 3 elements: ["blue", "light", "hazard"]
> $c[0]: blue
> m...@edward:~/perl/6$
>
>
> Is Rakudo's behaviour correct here?
S02 says:
"To get a Perlish representation of any object, use the .perl method. Like
the Data::Dumper module in Perl 5, the .perl method will put quotes around
strings, square brackets around list values,"
So according to this, Rakudo has it right.
But I think that a .perl()ification as ("blue", "light", "hayard",) would
make much more sense, because simple thing like
@a.push eval(@b.perl)
would then DWIM.
Chhers,
Moritz
Re: Which brackets should @a.perl use?
>>>>>> "m" == moritz writes:
>
> m> S02 says:
>
> m> "To get a Perlish representation of any object, use the .perl method.
> Like
> m> the Data::Dumper module in Perl 5, the .perl method will put quotes
> around
> m> strings, square brackets around list values,"
>
> m> So according to this, Rakudo has it right.
> m> But I think that a .perl()ification as ("blue", "light", "hayard",)
> would
> m> make much more sense, because simple thing like
>
> m> @a.push eval(@b.perl)
>
> m> would then DWIM.
>
> for your def of DWIM. i can see wanting an anon array to be pushed onto
> @a building up a structure.
DWIM in the sense that "eval($stuff.perl)" should behave the same as
$stuff itself.
since @a.push(@b) flattens @b into @a, why should I expect something
different from @a.push(eval(@b.perl))?
> your example is too simple to really cover
> this as you could just push @b or a ref to @b (damn, i need to learn
> more basic p6 syntax! :).
If people want @a.push(\...@b) or @a.push([...@b]), they can just write that -
and if the want to use eval + perl, they can include the brackets or
backslash just as well.
> a more useful example would be serializing data trees. if you dump @b
> with .perl do you want the current dumper output of a anon array or your
> list of values? when serializing a tree, you must get the ref version so
> that is the common and default usage. your version isn't DWIMmy there at
> all.
Maybe we can construct something magic with slice context and captures
instead?
Cheers,
Moritz
Re: Does =$*ARGS work?
Hi,
brian d foy wrote:
> Under the section "The for Statement" in S04, it says that the diamond
> operator
>
>while( <> ) { ... }
>
> becomes in Perl 6
>
>for =$*ARGS { ... }
Some time ago I read that too, and wondered why that's not [EMAIL PROTECTED]
That
seems more reasonable, because the command line arguments are stored in
@*ARGS.
I can't answer your question, sorry ;-).
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Does =$*ARGS work?
Hi,
brian d foy wrote:
> In article <[EMAIL PROTECTED]>, Moritz Lenz
> <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> brian d foy wrote:
>>> Under the section "The for Statement" in S04, it says that the diamond
>>> operator
>>>
>>>while( <> ) { ... }
>>>
>>> becomes in Perl 6
>>>
>>>for =$*ARGS { ... }
>> Some time ago I read that too, and wondered why that's not [EMAIL PROTECTED]
>> That
>> seems more reasonable, because the command line arguments are stored in
>> @*ARGS.
>
> well, $*ARGS is a magical filehandle, not a list of files. If you could
> use an array there, I think you'd have to allow any array, and that
> would be weird.
Why would that be weird? When things like
my $file = "/etc/passwd";
for =$file -> $line { ... }
work, why shouldn't we allow things like
my @files =
for [EMAIL PROTECTED] -> $line { ... }
and let '=' followed by an empty list default to $*IN (like in =<>)?
I think that would be consequent magic, and very convenient.
(If you already had that discussion earlier, just say it and I'll shut
up ;-)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: What should file test operators return?
Hi, brian d foy wrote: > At the moment the file test operators that I expect to return true or > false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. If you want a boolean, use ? $fn ~~ :x or something. HTH, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Is Perl 6 too late?
Thomas Wittek wrote: > chromatic schrieb: >> On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: >>> What is nedded is a very simple step: >> Contributors. > > And to attract contributors, you have to have a convincing vision. > I'm not sure, if the (current) Perl6 specs are convincing enough to > attract the developers out there. I think they are ;-) > But I also think that there is a great opportunity to make _big_ changes > to Perl to be even more competitive. I don't think that there is space for the changes you are implying in the following paragraphs. Small changes are acceptable, of course. > But maybe Perl6 is probably too far defined to encounter big changes in > some critical aspects. Right ;-) > As Ruby and Python are getting more and more attraction [1][2] I think > they do something right, that Perl doesn't. > What I think where both (especially Python) do better is in readable code. > > What makes Perl hard to read is the excessive use of special characters > (/\W/). I disagree: The make it look ugly, but not hard to read. > Global variables with cryptic names, that no beginner can make any sense > of by reading it. And after not working with "$<" for some months I > can't remember it either, although I've got quite some Perl experience. Well, most of them are gone or renamed to more readable ones in p6. > Additionally I'm not a friend of sigils: Then you shouldn't program in perl. Really. > I would also like semicolons to be optional. Most people don't ;-). > I really like the Python way of doing it: Set the variables type on the > assignment and remember it. The (fewer) operators now work according to > the type of the operands. No implicit (and error prone) type casting. > That way seems to be the best compromise of easiness and type safety. Well, if you like the python way, feel free to code in python. Perhaps some day it will be possible to mix them: use python; # Write python code here Don't get me wrong, there's nothing bad in writing some critics, but yours is impossible to realize in Perl 6, and therefore are it's hard to call it constructive. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Is Perl 6 too late?
Thomas Wittek wrote: > BTW: Why do so much people say "go away if you don't like it" instead of > being open for ideas and discussing them from a neutral point of view? because the design process of perl 6 started long time ago, and if we incooperate major changes to it, no implementation will ever finish. I don't think most of are not open to new point of views, but regard p6 they just don't help atm. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Is Perl 6 too late?
Thomas Wittek wrote: > Moritz Lenz schrieb: >>> What makes Perl hard to read is the excessive use of special characters >>> (/\W/). >> >> I disagree: The make it look ugly, but not hard to read. > > Even if it's "only" ugly: To what advantage? I don't think ugliness is a > good characteristic of a programming language. In fact it makes the code easier to read. At least to me. The other day I had a lot of work to do with matlab code, and it just sucked. No variables where declared, and therefore I had no type information. I didn't knew if arguments passed to functions were arrays/matrices or scalars, and sigils would have helped very much. And don't say "but a good IDE.." - I didn't have one. No language should depend on its IDE's syntax hilighting. >>> I would also like semicolons to be optional. >> >> Most people don't ;-). > > Oh, really? Source? :) I paraphrased Larry Wall. Iirc it was "everybody wants the semicolon" or something - correct me if I'm wrong. > I think they were invented to allow easier parsing and not easier coding. I think the p6 grammar is so complex that you couldn't do it without a statement terminator, be it a semicolon or a newline. And we know that you prefer the newline, I (and it seems, many other) do prefer semicolons. > E.g. in JavaScript, Python, Ruby and Groovy they are optional or even > don't exist. most languages don't allow you to call a function without parentheses. if you have foo bar without a statement termination, you can't know if thats foo(bar()), or foo() bar() whereas if you force the parentheses, it is unambigous anyway. Which explains why languages with simpler syntax can well live without the semicolon. >>> I really like the Python way of doing it: Set the variables type on the >>> assignment and remember it. The (fewer) operators now work according to >>> the type of the operands. No implicit (and error prone) type casting. >>> That way seems to be the best compromise of easiness and type safety. >> >> Well, if you like the python way, feel free to code in python. > > Oh, if I didn't like Perl, why should I care about posting my ideas here? > Perl has stolen the largest part of the language from other languages. > Why not do so again by adopting good ideas. because, as was pointed out earlier, huge changes a) delay implementation significantly and b) change the character of the language too heavily. We want Perl 6 to be Perl still. >> Don't get me wrong, there's nothing bad in writing some critics, but >> yours is impossible to realize in Perl 6 > > Admittedly I'm much too late and I didn't expect applause for my critics > -- but at least I hoped to get a discussion based on arguments. Most of these issues have been discussed in one way or another, either on p6l or on use.perl.org. If you really want the arguments, you'll find most of them. >> and therefore are it's hard to call it constructive. > > Unfortunately I already thought this. Even if everyone agreed that > sigils (or forced semicolons, or tons of operators, ...) are more bad > than good (and this seems like persuading the pope to allow homosexual > muslims to marry with priests) the design process is probably too far to > introduce such dramatic changes. Right. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Is Perl 6 too late?
Moritz Lenz wrote: > Thomas Wittek wrote: >> Moritz Lenz schrieb: >>>> I would also like semicolons to be optional. >>> Most people don't ;-). >> Oh, really? Source? :) > > I paraphrased Larry Wall. Iirc it was "everybody wants the semicolon" or > something - correct me if I'm wrong. sorry, masak++ pointed out that it was wrong indeed. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
POD <-> Code entanglement (was: Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
Mark Overmeer wrote:
> We had a private discussion about this already three years ago: I
> fully disagree! If the code and the documentation are not entangled,
> why do you want to put them in the same file? Why do you put them in
> the same distribution even?
>
> No, the documentation is all about the code. The docs present everything
> what the user should know about the code. The docs are the user's view
> of the implementation, and the code is the computer's view on the same.
I agree.
And while writing a class in Perl 6 the other day I noticed that copied
& pasted the signature of method to the pod:
=begin pod
=head3 C
initialize the Sudoku from a string C<$s>, with a 0 denoting an empty cell
and a number between 1 and 9 a clue.
Note that there is currently no way to use this function for sizes bigger
than 9x9 overall length.
=end pod
method from_string(Str $s){
# implementation of that method here
}
Since method signatures are very expressive in Perl 6, there should be a
way of accessing them in the POD without copy & paste. If you don't
think that's necessary: try it out for yourself. Write a class and
document it properly. I'm sure you'll end up doing the same as I did.
ATM I don't know that should be implemented, but perhaps somebody else
can think of a good way.
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: POD <-> Code entanglement
Thomas Wittek wrote:
> Moritz Lenz:
>> =begin pod
>>
>> =head3 C
>> [..]
>> =end pod
>>
>> method from_string(Str $s){
>> # implementation of that method here
>> }
>>
>> Since method signatures are very expressive in Perl 6, there should be a
>> way of accessing them in the POD without copy & paste.
>
> As I read "=head 3 method..." I also had the idea that semantically more
> meaningful directives might be a good idea.
That may be my fault, I didn't care to look if there was a more semantic
way to describe it.
> I mean POD uses constructs like headlines, lists, blocks, italic etc.
> which all describe _how it looks like_ and not _what it is_.
Headlines, lists and blocks are IMHO semantic markup.
If I'd say "Huge font in bold" that'd be descriptive rather than
semantic markup.
> A head3 might be the headline of a method documentation as well as one
> introducing the contact information for the author of a module.
> The directive doesn't have much semantics.
That doesn't make a headline worthless. It just shouldn't be abused the
way I did it ;)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Jonathan Lang wrote: > Jonathan Lang wrote: >> Which is not to say that there isn't a time and place when ease of >> implementation should trump ease of programming; taking an extreme >> example, being able to write a program that consists of the single >> line: >> >> attend my every wish >> >> is the ultimate in terms of ease of programming; it's also impossible >> to implement, barring the invention of mind-reading hardware and >> sapient artificial intelligence software. If a small increase in the >> programmer's learning curve is the price that must be paid to achieve >> a massive reduction in the implementor's workload, it may very well be >> worthwhile to foist some of the complexity onto the programmer. >> >> The question is whether or not this is one of those cases. > > Addendum: let me note that Perl has a reputation for bending over > backward to accommodate the programmer; as such, the difference in > implementation workloads for the two models that Damian referenced is > going to have to be _very_ severe for "ease of implementation" to win > out over "ease of programming" - IMHO. Unfortunately for me, MHO > doesn't count as much as DHO. "Help, help! I'm being oppressed!" I agree, and I want to make a point for the "ease of programming" point of view. If we have any kind of references to code, the POD parser must be able to parse method/sub signatures. But since default values are allowed for optional (and iirc named) arguments, it has to parse arbitrary complex expressions anyway. Which means that a complete POD parse will likely have to fall back to STD.pm, and in that case it's ridiculous to argue about a line based parser for POD anymore - when you can parse perl 6, you can just pick the POD from the syntax tree. Moreover part of the Perl philosophy has always been to provide the best for the programmer, even if it makes implementation of the interpreter/compiler rather hard - why should we stop with this philosophy when talking about POD and POD-Parser? I'd find it very annoying to have lines starting with '=' in a heredoc beeing counted as POD. Humans don't think in terms of lines, but in terms of visual blocks (at least I do), so if everything in heredoc goes verbatim into a string, I'd expect _everything_ in that block to go into that string. Everything else looks like an artificial exception to me. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Perl 6 & Parrot Essentials as project documentation
Allison Randal wrote: > I just signed an agreement with O'Reilly that assigns the full copyright > in the book "Perl 6 and Parrot Essentials" to The Perl Foundation. The > text is out-of-date, but can be updated much more rapidly than it can be > rewritten from scratch. Sounds great. Does TPF have a license for it already? > Where do you want the text for the Perl 6 parts of the book? Maybe: > > <http://svn.perl.org/perl6/doc/trunk/books/p6tut> If you want many potential committers, use the pugs tree. I think the number of committers of svn.perl.org/perl6/doc is very low. I'd suggest something beneath <http://svn.pugscode.org/pugs/docs/>, perhaps essentials/ Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Perl 6 & Parrot Essentials as project documentation
Allison Randal wrote: > I just signed an agreement with O'Reilly that assigns the full copyright > in the book "Perl 6 and Parrot Essentials" to The Perl Foundation. The > text is out-of-date, but can be updated much more rapidly than it can be > rewritten from scratch. Sounds great. Does TPF have a license for it already? > Where do you want the text for the Perl 6 parts of the book? Maybe: > > <http://svn.perl.org/perl6/doc/trunk/books/p6tut> If you want many potential committers, use the pugs tree. I think the number of committers of svn.perl.org/perl6/doc is very low. I'd suggest something beneath <http://svn.pugscode.org/pugs/docs/>, perhaps essentials/ Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Perl6 new features
cdumont wrote: > I know that perl doesn't only focus on web apps and my question might > seem irrelevant > but I've been searching the web in order to find the new features of > perl6 regarding > new functions, core module lists (not perl grammar itself) but couldn't > find any thing... Perl 6 is not yet finished, so the the list of core modules is not yet specified. > I would like to develop web apps with perl too but having to download > modules from CPAN > every time makes me feel these apps will never be able to evoluate in > different environments. > (environments you don't have control of) That's a general problem with libraries, not only Perl ones. And you can't solve this by putting everything into core - it just blows up the distribution. > I am a bit amazing to see that perl doesn't include a bunch a set theory > functions too. Perl 6 does. See for example ext/Set/ in the pugs repository. And so does Perl 5: http://search.cpan.org/~samv/Set-Object-1.21/lib/Set/Object.pm > I am not blaming perl but only hopes that perl6 will allow to make > things easy for the programmer. That's one of the most important design goals ;-) > as for the web, maintaining state thru server side cookies and DBI are > the very minimum I would recommend. > more hash and array functions a minimum too. > if there are such things in perl6, I'll be very happy to work with this > language ! You could help by contributing some suggestions to what the new "Web" module should be able to do, and how so. Web is hopefully "CGI done right", and still in its early planning stage. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Perl6 new features
A: because it disrupts the natural way of thinking. Q: Why is top posting frowned upon? cdumont wrote: > Perl 6 is not yet finished, so the the list of core modules is not yet > specified. > > > I know that it is somehow not the subject, > but I think the actual 5.8 doc should be changed to some extents. You should discuss that on p5p, not here. Only Perl 6 is on topic here. > Is there a place where we can add suggestions ? apart from the first one in... > 2003 ? 4 years ago ? You can write them here on p6l. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Web Module (Was: Perl6 new features)
Smylers wrote: > Moritz Lenz writes: > >> You could help by contributing some suggestions to what the new "Web" >> module should be able to do, and how so. Web is hopefully "CGI done >> right", and still in its early planning stage. > > Web module? This is the first I've heard of it. Where is it being > planned, if not on this list? > > Also, why are we hoping that it will be "done right"? Because we hope we learned from the past. There are several other modules that fullfill most of CGI's tasks, some of them do most of it better. Reimplementing one of them would already make Web a "better CGI" ;-) > Given the history > of things like this it strikes me as unlikely that now is the particular > moment where we suddenly manage to create a perfect library, and as such > this would be hoping against the light of available evidence! You're right, but we should ship things as best as we can, so we try ;-) > It seems entirely possible that during Perl 6's life somebody, possibly > somebody who at the moment hasn't even heard of Perl 6, will create a > better web module. It would be good if at that point it becomes > straightforward for it to get acceptance and people to adopt it. Right, but that's no reason not to try hard on your own. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Damian Conway wrote:
> Mark Overmeer wrote:
> Would the following syntax suffice?
>
> method isValidPostalCode(str $postalcode) returns bool {...}
> =PURPOSE Check weather the postal code confirms to the standards
> =ARG $postalcode
> a string with blanks trimmed.
> =RETURN
> the string is not cleaned-up.
>
> Because you can already do precisely that in the current design of Pod 6.
I really like that example.
And it makes me think that some of this discussion results from
insufficient Pod 6 knowledge, simply because we haven't read enough real
Perl 6 that is annotated with Pod 6.
So everybody reading this is now condemned to write an OO Perl 6 module,
and document it with Pod 6 ;-)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Some questions about using NaN and Inf
brian d foy wrote:
> * If I can match $x to NaN (or its stand-in), what happens when $x is
> undef?
undef is a property of the container variable (that it holds no value),
whereas NaN is a property of the content (like 1/0). so undef ~~ NaN
should be false IMHO.
> There's a note about this in S02 ("Conjecture: num might ...").
> "Native type" say that an int type defaults to 0, which complicates
> things for beginners, but if everything starts off as a num, it doesn't
> matter until we talk about types.
And "native" means "no container, no magic", so it can't be undef.
> * If I declare a sub to return a number of some sort (either by using
> C or C, what happens when the value is NaN or Inf? I suppose
> that should be fine as a return value, but it also seems that if
> someone wants to impose some sort of constaint on the return value that
> they wouldn't want exceptional values.
return a native type?
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Concurrency
I'll try to reply as good as possible, but I'm sure others will do better. David Brunton wrote: > This last SOTO re-reminded me of what an inveterate fan I am of Perl 6. Wow. > > My question today is about concurrency. I can imagine how things like IPC > Mailboxes > (e.g. RFC 86) happen in modules. I can also imagine why Threads (e.g. RFC 1) > should > be in modules- given the obvious dependence on underlying OS. > I do see both C and C in S29, but not in STD.pm, which brings me > to the questions: There's no need for any "keyword" to be in STD.pm. STD.pm just defines the grammar. Syntactically fork will be like just another sub, so it can safely be handled in the compiler's runtime. > * Where will C, C, and possible friends (e.g. Perl 5's > C-with-|) live? What do you mean by "where"? The namespace? Or the implementation? > * Is there any expectation of message-passing concurrency functions living > inside STD.pm? Again it won't be in STD.pm, because it doesn't care about it. But I think there will be both event based and thread based concurrency in Perl 6. Larry Wall usually points to this paper: http://www.seas.upenn.edu/~lipeng/homepage/unify.html Something like that, with a perlish interface, will be part of Perl 6's concurrency model. > * How about shared/software-transactional memory? Yes. Maybe http://svn.pugscode.org/pugs/docs/Perl6/Spec/Concurrency.pod (still a draft) contains a bit more helpful information. > Hopefully I'm not inadvertently starting any kind of flame-fest > about anyone's favorite concurrency model here :-D Why flame, when we can have all of them at once? ;-) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Sequential bias in S04 (and Perl6 in general)
Dave Whipp wrote:
> I was reading Synopsis 4 with regards to multi core programming. It
> seems to be infused with a bias towards non-parallel models of
> computation. Concurrently appears to be an add-on feature -- whereas we
> should have a mindset that explicit sequential constraints are the
> add-on feature.
That sounds really like a bad idea for simple "just do it" scripts. Just
imagine explaining concurrency issue to a beginner who is not even
confident with variables and blocks...
> Two statements that are missing from S04 (feel free to change the names)
> are C; and a form of C that tests/executes multiple
> C clauses in arbitrary order (without needing the sequential
> C statement).
>
>
>forall @a -> $x { ... }
>
> runs the code block on each element of @a (no defined order).
You can achieve that with the "hyper" list-op (see S02).
Also note that an optimizer is free to automatically add the "hyper"
list op if it can prove that the executed block has no side effects.
...
> Similarly, C, C, C, C, ... should all
> accept this ":sequential" adverb to force them to iterate their lists
> sequentially -- and should otherwise iterate in arbitrary/concurrent order.
Some of this can be written with hyper ops, just as the dot for method
calls has a "hyper dot" Object>>.method
> I'm not too concerned about the exact details: my point is that we
> should be fully aware of the fact that perl6 will be released into a
> multicore (some people use the term many-core for devices with hundreds
> of cores) world, and that exploitation of these parallel resources
> should be the default (easy) behavior. We shouldn't have a "concurrency"
> synopsis (we don't -- but we do have Spec/concurrency.pod). Instead, we
> should have "sequential.pod" that defines how to impose additional
> sequential constraints (e.g. ":atomic", ":sequential") on top of the
> those inferred from data dependencies.
I think that the concurrency synopsis is still useful for explicit
threading, STM and the like.
Also note that Perl 6 tries to preserver Perl's soul, and is not an
Erlang based language ;-)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r14485 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote:
> The C<:ii> variant may be used on a substitution to change the
> substituted string to the same case pattern as the matched string.
> -Case info is carried across on a character by character basis. If
> -the right string is longer than the left one, the case of the final
> -character is replicated.
> +Case info is carried across on a character by character basis. If the
> +right string is longer than the left one, the case of the final
> +character is replicated. Titlecase is carried across if possible
> +regardless of whether the resulting letter is at the beginning of
> +a word or not; if there is no titlecase character available, the
> +corresponding uppercase character is used. (This policy can be
> +modified within a lexical scope by a language-dependent Unicode
> +declaration to substitute titlecase according to the orthographic
> +rules of the specified language.)
what happens if some of the characters aren't cased at all, like white
spaces?
my $str = "AB DE";
$str ~~ s:ii/.*/abcde/;
is the result ABcDE ? or is the space ignored and the substition is
performed as if $str was "ABDE" in the first place?
IMHO the current behaviour is not very DWIMmy.
Instead I'd suggest to check if the matched string is
* all lowercase
* all uppercase
* firsts letter upper, rest lower
* the other way round
* Capitalized (first char of each word is upper)
and if any of these hold true (checked in this order), then the same
casing rule is applied to the substitution string.
> @@ -212,7 +218,8 @@
> substituted string to the same accent pattern as the matched string.
> Accent info is carried across on a character by character basis. If
> the right string is longer than the left one, the remaining characters
my $str = "määh";
$str =~ s:bb/.*/mo i/;
is $str now 'mö i' ? Or does the space get a \N{COMBINING DIAERESIS}? Or
is it tranlated to \N{DIAERESIS}? What about other non-letter characters?
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
POD in the test suite
I noticed that many test files contain "old" POD like this: =pod some description here =cut Should that all be replaced by the new POD? =begin description text here =end description -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: pluralization idea that keeps bugging me
Larry Wall wrote:
> Last night I got a message entitled: "yum: 1 Updates Available".
> Of course, that's probably just a Python programmer giving up on doing
> the right thing, but we see this sort of bletcherousness all the time.
>
> After a recent exchange on PerlMonks about join, I've been thinking
> about the problem of pluralization in interpolated strings, where we
> get things like:
>
> say "Received $m message{ 1==$m ?? '' !! 's' }."
>
> My first thought is that this is such a common idiom that we ought
> to have some syntactic sugar for it:
>
> say "Received $m message\s."
>
> which reads nicely enough since the usual case is plural.
> Basically, \s would be smart enough to magically know somehow whether
> the last interpolation was 1 or not. It would be particular nice when
> the interpolation is a closure:
>
> say "Received {calculate_number_of_messages()} message\s."
I think the most general solution is a nice quoting construct.
So if you say
say qq:l10n(en)"Received $m message\s";
the quote handler in l10n:en (or whatever) receives a list of pairs of
strings and variables to interpolate, ['$m' => $m, '\s' => undef].
It can then decide what to do with it.
Wait, that smells like macros, which are already specced - so never mind ;-)
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Regex syntax
I have two questions/suggestions regarding regex syntax:
1)
The :ii modifier is influenced by :sigspace modifier.
IMHO this is ugly, because the matching part and the replacement part of a
regex should be as orthogonal as possible.
Therefore I'd like a different syntax for :ii :sigspace, maybe :smartcase
(I'm always bad at inventing names, so please come up with different
suggestions), or :ii :smartcase or some such.
Any comments?
2)
I noticed that in larger grammars (like STD.pm and many PGE grammars in
the parrot repo) string literals are always quoted for clarity
regex foo {
'literal'
}
Since I think this is a good idea, we could just as well enforce that, and
drop the <...> around method/regex calls:
regex foo {
'literal' subregex
}
This way we'll approximate "normal" Perl 6 syntax, and maybe even improve
huffman coding.
I guess such a syntax wouldn't be acceptible in short regexes, which are
typically written as m/.../, rx/.../ or s[...][..], so we could preseve
the old syntax for these regexes.
Do you think it would be worth the effort of maintaining (and teaching)
two different regex syntaxes?
(If this has been proposed and rejected before, please just tell me, I'm
only following Perl 6 development for about a year).
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Getting Started - What to try?
Hi, John M. Dlugosz wrote: > I've installed the Win32 build of Pugs, but is appears to be incomplete. How > do I get the "real thing"? I've also heard that Pugs is in stasis, so is > this still a good way to write stuff and learn today? There is no "real thing" yet, which is why we're working on it ;-) > Likewise, how do I get synched up with the Parrot implementation? svn co https://svn.perl.org/parrot/trunk parrot cd parrot perl Makefile.PL && make cd src/languages/ make then you can fire up ../../parrot perl6.pbc and start playing. > I understand the most official grammar is being developed there. Not quite. The "official" grammar is in the pugs repo in src/perl6/, but it can't really run on anything yet. > Is there a grammar-checker tool that will help me to validate proposed Perl 6 > code fragments, even if I can't execute it yet? Not yet, but we hope to build one soon. > > In general, what are the various repositories and version-control systems > used? What ought I install and get working to join up with the Perl 6 > community? Both parrot and pugs use subversion aka svn. The parrot repo contains parrot, rakudo (perl6 on parrot) and various other languages, the pugs repo contains pugs, STD.pm (the grammar), some of synopsis (in docs/Perl6/Spec/), kp6 (in v6/v6-KindaPerl6), smop (in v6/smop/) and various other stuff. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: What I'm Working On
John M. Dlugosz wrote: > I'm taking a stab at turning the S\d\d documents into a formal standard. That's certainly a nice idea, and much work. ++ for taking it. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: cross operator and empty list
[EMAIL PROTECTED] wrote: > Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Clarify "Design by Contract"
John M. Dlugosz wrote:
> PRE/POST on methods:
>
> "
> When applied to a method, the semantics provide support for the "Design by
> Contract" style of OO programming: a precondition of a particular method is
> met if all the PRE blocks associated with that method return true. Otherwise,
> the precondition is met if all of the parent classes' preconditions are met
> (which may include the preconditions of their parent classes if they fail,
> and so on recursively.)
>
> In contrast, a method's postcondition is met if all the method's POST blocks
> return true and all its parents' postconditions are also met recursively.
> "
>
> If the PRE blocks on the method don't all return true, it appeals to the
> preconditions on the base class of the class defining the method? I don't
> get it. Why would a class-level precondition override a method-level
> precondition? Why bother defining them on the method, if they are ignored if
> they are false anyway?
Finally one that I'm able to answer ;-)
class MyMath {
method sqrt($x:) {
PRE { $x >= 0 }
# your calculation here.
}
}
Now whenever you have an object of Type MyMath, you can be sure that
it's valid to pass any non-negative number to sqrt.
If a inherited class could harden that precondition, that assumption
would be false. That's why it's only allowed to weaken preconditions:
class MyComplexMath is MyMath {
method sqrt($x:){
PRE { True }
# your calculation here
}
}
This is described in depth in "Object oriented software construction" by
Bertrand Meyer.
If you want to harden a precondition, you can revert to addtional methods:
class MyMath {
method can_take_sqrt($x:){
$x >= 0;
}
method sqrt($x:){
PRE { $x.can_take_sqrt }
...
}
}
class MyComplexMath is MyMath {
method can_take_sqrt($x:){
True
}
...
}
That way a user of class MyMath can always call can_take_sqrt() to check
if she can satisfy the precondition.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Idea: infir types of constants
John M. Dlugosz wrote: > Just surfing, I noticed something about the "D" programming language: > > " > The types of constants need not be specified explicitly as the compiler > infers their types <http://en.wikipedia.org/wiki/Type_inference> from > the right-hand sides of assignments. > > const fact_7 = Factorial!(7); > " Doesn't perl do this when you don't specify a type? constant $pi = sub_that_calcs_pi(); Since static types are optional, I don't see the point in explicitly speccing type inference. That's only stating that type information is determined at compile time, which seems like an optimization to me that doesn't need to be in perl 6.0.0. Of course any implementer is welcome to do perform that optimization where possible ;-) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Clarify "Design by Contract"
John M. Dlugosz wrote: > Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: >> >> This is described in depth in "Object oriented software construction" by >> Bertrand Meyer. >> >> > OK, reading about it in Wiki, I see what it's supposed to do. > > PRE - derived classes may weaken but not strengthen. > > So if it fails, but the preconditions of the same method on the base > class pass, that means you wrote the precondition wrong. No. Only if it *always* fails. PRE conditions between a class and its ancestors are OR'ed - there's nothing wrong if one part of an OR branch evaluates to false. > Rather than > ignoring that, shouldn't it be an error? Only if the compiler can prove that the condition is always false. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: New specdoc available
John M. Dlugosz wrote:
> Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:
>> John M. Dlugosz wrote:
>>
>>> I posted my current work at
>>> http://www.dlugosz.com/files/specdoc.pdf
>>> and .odt.
>>>
>>
>> 3.1.1 Normalization uses a constant without a sigil - is that really
>> allowed?
>>
> Yes, it's in the Synopses.
>
>
>> 3.1.2 BOM - can you detect UTF-32 U+FEFF painlessly? If so, you could
>> allow that
>> 3.1.3 The =encoding is used only for POD in perl 5. And if you force it
>> to be on the first line, you forbid #!/usr/bin/perl lines. What about
>> 'use encoding('ISO-8859-1');' instead? Any other thoughts?
>>
> No problem if it can read that 'use' line in the first place.
>
> Does a BOM also interfere with #!/usr/bin/perl ?
Sadly, yes.
I used vim with
:set nobinary fileencoding=utf-8 bomb
:w
./foo.pl
bash: ./foo.pl: cannot execute binary file
moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: given vs for
> Paul Fenwick perltraining.com.au> writes:
>
>>for ($foo) {
>> when ($_ < 500) { ++$_ }
>> when ($_ > 1000) { --$_ }
>> default { say "Just right $_" }
>>}
>
> Ahh... that's exactly what I was looking for. Thanks.
>
> Makes you wonder why the 'given' keyword was added, when for/when is so
> close...
I'd assume 'given' provides scalar context onto its argument, 'for'
obviously provides list context.
But I guess the main difference is that 'for' is associated with
iteration, and IMHO it feels unnatural to iterate over one item.
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: grammar for 'constant' ?
John M. Dlugosz wrote:
> The synopses are contradictary over the way 'constant' works. First it says
> that it is a declarator like 'my'.
That's what STD.pm says:
token scope_declarator:my { {*} }
token scope_declarator:our { {*} }
token scope_declarator:state{ {*} }
token scope_declarator:constant { {*} }
token scope_declarator:has { {*} }
> Then in S12 it shows
>
> my constant ...
> and
> our constant ...
>
> that is, independant from the my or our declarator.
I grep'ped STD.pm tentatively for other occurrences of 'constant', and
couldn't find where that should be implemented.
> Assuming the second way is newer/better, what is the grammar for this? Is it
> a declarator if used on its own, or a different category?
>
> Oh, and should it still say that if you leave off the optional 'my' or 'our'
> that it defaults to 'my', or should it be 'our' like everything else?
>
> --John
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Private methods in classes and roles
S12 says (in the context of classes): my method think (Brain $self: $thought) (Such methods are completely invisible to ordinary method calls, and are in fact called with a different syntax that uses ! in place of the . character. See below.) And later on, in the context of roles: my method !foo ... my method foo ... # same, but &foo is aliased to &!foo Am I right in assuming that the second example is valid only for roles? I find this different syntax for classes and roles quite confusing. Is it intended that way? I'd welcome a uniform syntax. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Private methods in classes and roles
and a few more thoughts:
I wrote:
> S12 says (in the context of classes):
>
>
> my method think (Brain $self: $thought)
>
> (Such methods are completely invisible to ordinary method calls, and are
> in fact called with a different syntax that uses ! in place of the .
> character. See below.)
for private subs S12 also says
Generally you'd just use a lexically scoped sub, though.
my sub foo ...
[Conjectural: To put a private sub into the class, say
our sub !foo ...
]
Which lead me to the thought that 'my method foo' is a bad idea because
the lexical scoping of the 'my' is orthogonal to the scope of the class.
class A {
my method foo { }
}
class A is also {
method bar {
# no way to access self!foo here
}
}
So is
our method !foo {}
allowed in classes? and is it the recommended way to declare private
methods?
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
make POST blocks more usable
I skimmed through S06 and I found no convenient way to use the return
value of sub/method in it's POST blocks.
Since they can (and should) be used (among other things) to check the
sub's/method's return value, I'd like to propose that the return value
of a sub is given as the argument to POST block, so that you can write
sub my_sqrt ($x) {
# calculation with many possible return pathes
POST -> $result {
$result * $result == $x
}
}
I don't really know what do when the sub is left through an exception,
maybe it should search for a POST multi with empty arguments? (or do
exceptions ignore POST blocks anyway?)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: building pugs under Fedora 9 doesn't work
Ryan Richter wrote: > On Tue, Jun 03, 2008 at 12:03:00PM +0200, Moritz Lenz wrote: >> My last successful build was r18093 with GHC 6.6.1. >> Maybe we should just die in Makefile.PL until somebody finds a fix. > > Maybe we should just revert the pugs source to that rev. Haven't the > modifications since then basically just broken the build for most > people? They were an attempt to get it working under ghc 6.8.1. As long as pugs isn't actively developed, the question is mostly irrelevant. Yet feel free to revert the changes to pugs, unless somebody vetoes. (But please don't blindly revert any commit in the meantime, there were other non-pugs changes to the repo that many hackers would hate you for reverting ;-) Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
clarification on samecase() and samebase()
Hi all, Auzon has written a few tests for the samecase() and samebase() (S29), which raised a question: For both the :samecase and there :samebase regex modifier (S05) there is a "dumb" and a "smart" version. S29 is silent about which it refers to. Should both have a second, optional argument which specifies the operation mode? Or are they both "dump", and the regex engine does the mapping from smart to dump itself? Anyway, S29 needs clarification. BTW the naming seems inconsistent to me: same*case* preserves *case*, but same*base* preserves *accents* -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Google index and subsets (two topics for the price of one!)
Ovid wrote:
> Anyone have any idea why Google is not indexing the official Perl 6
> documentation at perlcabal.org/syn? I checked the robots.txt and it
> looks fine:
>
> http://www.perlcabal.org/robots.txt
>
> But the search box on http://www.perlcabal.org/syn/ returns nothing.
The whole domain seems to be missing from the index, not only the synopsis.
If nobody else has any idea, I could get a webmaster account and try to
find out what's wrong.
> Specifically, I was looking for the documentation on how subsets work
> as it looks like we can get declarative style constraint programming
> for free:
>
> subset Crosshair of Point where { $_.inside_of($target_zone) };
>
> Is that valid syntax?
Yes. See http://perlcabal.org/syn/S02.html#Polymorphic_types for similar
examples.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
fallback semantics of list methods
In the test suite and on IRC there was quite some confusion about how
list builtins are specced, and how they should behave in corner cases.
One is join():
our Str multi method join ( @values: Str $separator = ' ' )
our Str multi join ( Str $separator = ' ', [EMAIL PROTECTED] )
It is quite clear that the perl 5-style
join 'sep', $value, $value2;
invocation remains valid, and
@list.join($sep)
is the new method form.
The confusion arises what to do with
'str'.join('other_str')
should be.
Fallback semantics in S12 suggest that since no matching multi method is
found, subs are tried - that is, the expression is interpreted as
join('str', 'other_str')
yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
result to be 'str'.
Daniel Ruoso argued in favour of the tested behaviour, suggesting that
perhaps the specs should be updated accordingly, mostly because
('str').join('other_str')
would be confusing otherwise.
Patrick Michaud argued in favour of the specced behaviour, and I agree.
Mostly because nobody sane will write things like
'str'.join('other_str') with a literal string as the invocant in first
place. And if it's not a literal, and you want it to behave as list, the
invocant is either something that returns a list, or a variable with the
'@' sigil. We just need to be careful that everything that should return
really does that, even if it contains a single list.
Currently both pugs and rakudo make return a list (pugs actually
an array, but that's a different problem), but is a Str.
If we'd just be more consistent and always return a list, I don't see a
problem with the spec. If not, it would be rather weird to have .join('c') return 'abc', but .join('c') return 'c'.
Consider
my $x = A.new();
$x.y = ;
say $x.y.join('b')
The output is different for the two possible declarations of class A:
class A { has $y is rw } # -> b
class A { has @y is rw } # -> a
not pretty IMHO.
So I see the following options:
1) be more consistent with what returns a list
2) Add a method with invocant Any for each list builtin
3) drop method fallback, thus disallowing Str.join(Str) outright
4) be lisp, make everything a list *g* (not serious)
I haven't thought a lot about the third option, and what it would mean
to the language as a whole, so I have no idea if it's a viable alternative.
Any thoughts on the topic are welcome. I hope I didn't confuse too much
here ;-)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: .join on Array
Patrick R. Michaud wrote:
> Following up to a thread on p6c regarding method fallbacks and .join:
>
> * What should [1,3,5].join('-') produce?
I'm pretty sure it should be '1-3-5', because [1,3,5] is an Array ref
> * How about ([1,3,5], 20).join('-') ?
Probably the same as (~[1,3,5], 20).join('-')
> Thanks!
>
> Pm
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #56230] [PATCH] Multimethods for Complex.
Another question: Vasily Chekalkin (via RT) wrote: > +.sub 'sqrt' :multi(Complex) > +.param pmc a > +a = sqrt a > +.return (a) > +.end Do we actually want a sqrt(Complex)? Somebody who is sufficiently mathematically educated to work with complex numbers should now that sqrt() is ambigous, because there are two possible results, and will revert to roots() for that. Any thoughts? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Type of literals
In the test suite there are some tests like this: is(1.WHAT, 'Int', '1 as a literal is an Int); This seems to imply that we guarantee the direct type of literals. But do we? Actually I see no need for that. All my programs work fine if the literal 1 is of type Foo, and Foo isa Int. What's our policy on that? Will a 1.WHAT always return Int? do we guarantee (1..4).WHAT always to be 'Range'? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
(cross-posting to p6l) Ryan Richter wrote: > On Thu, Jun 26, 2008 at 11:36:05AM +0200, Moritz Lenz wrote: >> 2) How do we know which numeric type is a class and which is a role? Is >> there an explicit spec about the types of number literals? That could >> have some impact on type checking in the tests. (Maybe I should prod p6l >> with that). > > You can't instantiate a role so they're pretty much all classes I think. > The only role that I saw specced was Order, and Num does Order so all > Num types inherit that. Complex is its own type separate from Num, and > everything else descends from Num. See docs/p6types in pugs, it's meant > to answer these questions :) Thanks for the effort, but it also raises new questions. For example: > Int is Num Rakudo doesn't do it that way, because the 'A is B' relation in OO means "Every instance of A is also an Instance of B", which certainly isn't the case with Ints. Int is more like a subset of Num. Which made me think, shouldn't Num be a role? and then 3.14 would be a Rat or a Float or whatever, 42 would be an Int, and Int does Num Rat does Num That way a compiler that only implements classes and roles (and no subset types) can get the hierarchy of numeric types right. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
Mark J. Reed wrote: > On Thu, Jun 26, 2008 at 10:23 AM, Moritz Lenz > <[EMAIL PROTECTED]> wrote: >> Thanks for the effort, but it also raises new questions. For example: >>> Int is Num >> Rakudo doesn't do it that way, because the 'A is B' relation in OO means >> "Every instance of A is also an Instance of B", which certainly isn't >> the case with Ints. Int is more like a subset of Num. > > Huh? If Int is a subset of Num, then every instance of Int *is* also > an instance of Num. That's what subset means... Uhm, yes. I was confused, sorry. > Maybe you mean they are disjoint types in the type system, but the set > of numerical values of all possible Ints is a subset of the set of > numerical values of all possible Nums? But then how is type > compatibility obtained? > >> Which made me think, shouldn't Num be a role? and then 3.14 would be a >> Rat or a Float or whatever, 42 would be an Int, and >> Int does Num >> Rat does Num > > But Int should do Rat, too... > >> That way a compiler that only implements classes and roles (and no >> subset types) can get the hierarchy of numeric types right. > > ...assuming it's a hierarchy in the first place. What's the alternative? I don't think it's a good idea to special-case numeric types, and I don't think it's a good idea to define multis for each numeric type either. I assume that 'Num' is meant to be a non-complex. Then it seems to make sense to assume: Int is Rat Rat is Num Num is Complex or am I off again? Anyway, for our work in the test suite it would be nice to have it specced somewhere. Or should I rely on Ryan's docs/p6types? If so, it would be nice to convert it to format that can smartlinked to. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
Trey Harris wrote: > In a message dated Thu, 26 Jun 2008, Moritz Lenz writes: >> I assume that 'Num' is meant to be a non-complex. >> Then it seems to make sense to assume: >> Int is Rat >> Rat is Num >> Num is Complex >> or am I off again? > > S29 seems to have been assuming this, if I'm reading the multis correctly. If it assumed that, why would exp() be defined in class Num, instead of the more general class Complex? It would also imply that the method polar, which is defined in Complex, is available for all other numbers. Don't know if that's intended. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Rakudo test miscellanea
Larry Wall wrote:
> On Thu, Jun 26, 2008 at 04:50:21PM +0200, Moritz Lenz wrote:
> : I assume that 'Num' is meant to be a non-complex.
> : Then it seems to make sense to assume:
> : Int is Rat
> : Rat is Num
> : Num is Complex
> : or am I off again?
>
> Well, there's this little thing called Liskov substitutability...
>
> Neither "is" nor "does" is quite right here, because the mathematicians
> have seen fit to confuse representation semantics with value semantics. :)
>
> I think what we want is something more like
>
> Int as Rat
> Rat as Num
> Num as Complex
>
> where "as" means, A is not a B because it limits the methods that
> can be applied, and A doesn't do B because it doesn't have the right
> native representation internally, but A can be used as a B by explicit
> conversion to a value that either is or does B.
Or in other words, our type system can't really express the relation.
I know that Eiffel found an interesting workaround through their "Design
by Contract" system. It works like this, ported to Perl 6:
class Complex {
method can_do_sqrt {
True;
}
method sqrt {
PRE { self.can_do_sqrt() }
# calculation here
}
}
class Num {
method can_do_sqrt {
self >= 0;
}
}
Through the polymorphic preconditions one can escape the Lady Liscov.
Can we use something similar, perhaps? (I have no idea how and if that
can be transferred to types, I'm just think aloud here)
> This declaration implies the existence of Rat(Int), Num(Rat), and
> Complex(Num) functions and/or methods, as well as the authorization
> for any such inferior A type to advertise itself as doing B, where
> the VM somehow sneaks in the appropriate conversion for us if we
> actually try to pass an Int to a Rat.
That's fine by me, as long as user defined mathematical types have the
same ability to provide these automatic conversions, and the type
checker and MMD dispatcher honours these conversion.
> An interesting question arises as to whether "as" should be considered
> transitive, or do we have to say
>
> Int as Rat as Num as Complex
> Rat as Num as Complex
> Num as Complex
>
> to avoid long chains of accidental conversions. One can argue both
> sides of that: on the one hand, you don't want for type A to have
> to worry about things regarding type C that are type B's bailiwick.
> On the other hand, transparency of code suffers under transitive
> coercion, and the syntax above is no great hardship. Plus we could
> always add something spectacularly explicit like
>
> Int as (Rat.as)
>
> if people decide they give one. ;)
Usually when there are two equally valid sides, we try to give the
programmer the opportunity to pick one. Atm I don't see how we can do
that here, but perhaps somebody has a good idea how we can get around
making that decision?
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Should C and C work in C ?
Ovid wrote: > --- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > >> Do C and C act like the >> C method, in that >> they work for C object and not just objects of >> type C? >> >> In other words,, should C< $x.grep(...) > work even >> if $x isn't normally a list type? > > If I understand you correctly, I think you're asking if grep and map can be > applied to junctions? I think Patrick meant something else. The other day we had the discussion what $x.join($sep) should be, specifically if it should work for non-List $x. $Larry said yes, it should work, and the way to achieve that is to use Any.join. Now Patrick wants to know which of the various list methods need to be in Any. BTW Junctions aren't a subtype of Any, but of Object. > If I've misunderstood, feel free to print this out and burn it :) $rant_about_wasting_resources_and_climate_change ;-) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [svn:parrot] r28689 - trunk/languages/perl6/t ("-" versus "_")
Conrad Schneiker wrote: >> Moritz Lenz wrote (on perl6-compiler) >> Patrick R. Michaud wrote: >> >> +S02-builtin_data_types/num.t >> >> S02-builtin_data_types/type.t >> >> S02-literals/autoref.t >> >> S02-literals/hex_chars.t# pure >> >> S02-literals/radix.t >> >> S02-polymorphic_types/subset-code.t # pure >> >> S02-polymorphic_types/subset-range.t >> >> +S03-operators/assign-is-not-binding.t >> >> S03-operators/autoincrement.t # pure >> >> S03-operators/comparison.t >> >> S03-operators/context.t >> > >> > In the test suite, could we perhaps aim for some >> > consistency on the use of hyphens versus underscores, >> > or at least articulate when one is used versus the other? >> > For example, "assign-is-not-binding.t" versus "hex_chars.t" >> > in the above. >> > >> > Personally I vastly prefer hyphens to underscores, >> >> Same here. Since the directly names already match m/^S\d\d-/ I'll >> assume >> that will be our standard. >> >> > but I >> > suspect people have good reasons for preferring underscores. > > One reason (probably not a good one) is to use the same > convention as programming language variable names (which is > typically more of a "CamelCase" versus "not_Camel_case" issue). With the small distinction that there are case insensitive, case preserving and case sensitive file systems, whereas identifiers are always case sensitive. My experience is that it's hard to get case right on the former two types of systems because you don't have real testing. That's why I'm in favor of all lower case file names. > So would a user-supplied Perl 6 syntax-morphing module to allow > use of embedded-hyphens in variable names (and other names, such > as labels and subs) to Perl 6 (with minimally-sane adjustments > needed to make hyphen-related operator parsing unambiguous) be > reasonably feasible? Or does this open a messy Pandora's box of > cascading language-redesign kludges? I think it could cause confusion, but it should be so easy to do that you'll just be able to try it out. Just allow '-' in the mid of an identifier, and longest token matching takes care of the rest. Since whitespaces terminate LTM, they automatically disambiguate operators. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Complex planes
Today bacek++ implement complex logarithms in rakudo, and one of the tests failed because it assumed the result to be on a different complex plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). Should we standardize on one complex plane (for example -pi <= $c.angle < pi like Complex.angle does)? Or simply fix the test to be agnostic to complex planes? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Complex planes
Jon Lang wrote: > Larry Wall wrote: >> On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: >> : Today bacek++ implement complex logarithms in rakudo, and one of the >> : tests failed because it assumed the result to be on a different complex >> : plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). >> : >> : Should we standardize on one complex plane (for example -pi <= $c.angle >> : < pi like Complex.angle does)? Or simply fix the test to be agnostic to >> : complex planes? >> >> Standardizing on one complex plane is the normal solution, though >> this being Perl 6, there's probably a better solution using infinite >> Junctions if we can assume them to be both sufficiently lazy and >> sufficiently intelligent... :) > > By the principle of least surprise, I'd recommend against this. Most > programmers, when they see 'sqrt(1)', will expect a return value of 1, And that's what they get unless they write it as sqrt(1 + 0i). > and won't want to jump through the hurdles involved in picking '1' out > of 'any(1, -1)'. 1 and -1 aren't just separated by a complex plain, they are really distinct numbers > That said, I'm not necessarily opposed to these > functions including something like an ':any' or ':all' adverb that > causes them to return a junction of all possible answers; but this > should be something that you have to explicitly ask for. > > And even then, I'm concerned that it might very quickly get out of > hand. Consider: > > pow(1, 1/pi() ) :any - 1 > > (I think I got that right...) Not quite. Afaict the only functions that might return a junction are Complex.angle and Complex.log. But having $compl.angle > pi always yield True would be quite weird ;-) > Since pi is an irrational number, there are infinitely many distinct > results to raising 1 to the power of 1/pi. No. exp($x) is a single, well-defined value. > (All but one of them are > complex numbers, and all of them have a magnitude of 1, differing only > in their angles.) Thus, pow(1, 1/pi() ) :any would have to return a > junction of an indefinitely long lazy list. Now subtract 1 from that > junction. Do you have to flatten the list in order to do so, > subtracting one from each item in the list? Obviously we'd have to avoid that if there's any infinite list/junction involved somewhere ;-) But you do have a point that we can't really use infinite junctions unless we can ensure that we can do all sorts of arithmetics with it without loosing lazyness. And I don't think we can prove that (but I might give it it shot if I have some spare time) > Or is there a reasonable > way to modify the list generator to incorporate the subtraction? > > Or how about: > > sqrt(1):any + sqrt(1):any > > -- > > In any case, there's the matter of what to do when you only want one > answer, and not a junction of them. IMHO, we should standardize the > angles on '-pi ^.. pi'. My reasoning is as follows: if the imaginary > component is positive, the angle should be positive; if the imaginary > component is negative, the angle should be negative. If the imaginary > component is zero and the real component is not negative, the angle > should be zero. And the square root of -1 should be i, not -i; so if > the imaginary component is zero and the real component is negative, > the angle should be positive, not negative. > -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Complex planes
Jon Lang wrote:
> Moritz Lenz wrote:
>> Jon Lang wrote:
>>> By the principle of least surprise, I'd recommend against this. Most
>>> programmers, when they see 'sqrt(1)', will expect a return value of 1,
>>
>> And that's what they get unless they write it as sqrt(1 + 0i).
>
> I suppose that you _could_ use the programmer's choice of whether or
> not to use complex numbers in the argument list as the indicator of
> whether to return one answer or a junction of them. Of course, this
> could lead to subtle bugs where the programmer assigns a complex value
> to $x and later takes the sqrt($x), but forgets that he assigned a
> complex number earlier. This may or may not be sufficient grounds for
> requiring an explicit declaration that you want junctions.
If the programmer errs on what he thinks is in a variable, it'll always
be a bug.
>>> and won't want to jump through the hurdles involved in picking '1' out
>>> of 'any(1, -1)'.
>>
>> 1 and -1 aren't just separated by a complex plane, they are really
>> distinct numbers
>
> True enough. I fail to see how that invalidates my point, though: if
> you're going to mess with multiple complex planes, why wouldn't you
> also address the issue of distinct numbers as well?
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) < 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who tries
to debug that code, and doesn't know about junctions. It just won't DTRT.
> The latter issue
> is intimately connected to the former, as I demonstrate below.
>
>>> And even then, I'm concerned that it might very quickly get out of
>>> hand. Consider:
>>>
>>> pow(1, 1/pi() ) :any - 1
>>>
>>> (I think I got that right...)
>>
>> Not quite. Afaict the only functions that might return a junction are
>> Complex.angle and Complex.log.
>
> Why is that?
As I pointed out above it's insane to return a junction of logically
distinct values. It might even be insane to do it for Complex.log:
my $a = (Num::e * 1i).log.angle;
What do you expect $a to be?
Let's see, 1i can be written as exp(1i*(1/2 + 2 *$k) * pi), for Int $k.
So log(Nom::e * 1i) would
1 + any(..., -1.5 * pi, 0.5 * pi, 2.5 * pi, 4.5*pi)*1i
if you imagine this, all these values have re = 1, and lie on a straight
line. So their angle are discrete (but not dense) values between -pi and
+pi. There' no way you can represent that in finite space without a fair
bit of algebra, something we don't want to burden on our implementors.
And somehow I also don't think that meets the "principle of least
surprise" criterion.
I think that I don't have to comment on the rest of the mail to make
clear that Larry's proposal, although being quite interesting, is a very
bad idea to actually implement (and very hard to implement as well)
(unless somebody comes to its rescue with a really clever idea on how to
resolve all these weirdnesses).
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Perl6::Str on CPAN
Hi, today I released Perl6::Str to CPAN. It's a module for grapheme level string handling, and the methods are modeled closely after those of Perl 6. I cheated a bit in that I didn't implement codepoint and byte level semantics, since perl 5 supports them natively already. It lacks some features, some features aren't properly tested yet (like normalization), and some aren't planned at all (pack/unpack for example). It's also meant as an inspiration: grapheme level string handling doesn't have to be hard (it just becomes hard if you optimize the code ...) All comments are welcome. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Project idea: Perl 6 syntax hilighting with STD.pm
John M. Dlugosz wrote: > Does that mean there is a tool I can use to apply STD.pm to syntax-check > my examples or ask questions of it? Can you point to that? in the pugs repository: $ cd src/perl6 $ make $ ./tryfile $filename That assumes a perl 5.10 in /usr/local/bin/perl HTH, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Design of the "code" classes
John M. Dlugosz wrote:
> I wrote up a summary and some notes and posted at
> <http://www.dlugosz.com/Perl6/web/code.html>.
I think what the discussion is missing that there Regexes are also
Callable (I think so, at least).
Also I'm not sure that Routine actually isa Block, because a Block can
be left with leave(), but I'm not sure if a Routine can be (that's what
return() is for).
So I'd say
role Callable { ... }
class Regex does Callable { ... }
class Code does Callable
class Block is Code
class Routine is Code
> Can we come to a definitive statement of the Callable/Code/Block/Routine
> types, relative to the hints that are in the synopses thus far?
>
> What I would like to do is get a consensus to write this up formally in
> my specdoc, and I'll also mark up the synopses files with the
> inconsistencies and proposed new wording, for Larry (the document owner)
> to have.
>
> --John
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
P5ism in S02
I discovered a small p5ism in S02. Patch below. (My copy of S02 might be
a bit out of date, though. Sorry, I've been offline for a while).
--- Syntax.pod.old 2008-08-13 19:48:21.0 +0200
+++ Syntax.pod 2008-08-13 19:48:25.0 +0200
@@ -2447,7 +2447,7 @@
qw /a b c/; # P5-esque qw// meaning q:w
Qc '...{$x}...';# Q:c//, interpolate only closures
-qqx/$cmd @args/ # equivalent to P5's qx//
+qqx/$cmd @args[]/ # equivalent to P5's qx//
(Note that C doesn't interpolate.)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: arrayref/hashref in spectest suite
Patrick R. Michaud wrote:
> There are quite a few tests in the spectest suite that
> make mention of "arrayref" and "hashref", and that expect
> things to work like references do in Perl 5. I'd like to
> get some confirmation/clarification on them.
>
> Here's one example:
>
> my $foo = [ 42 ];
> my $bar = { a => 23 };
> $foo[1] = $bar;
> $bar = 24;
>
> say $foo[1]; # "24" or undef ???
>
> The test suite expects "24" to be output here, treating
> treating C< $foo[1] > as a reference to the hash in
> C<$bar>, such that any changes to C<$bar> are also reflected
> in C<$foo[1]>. Is this correct Perl 6?
IMHO yes. Remember that $foo is really just an Array object, just like
any other object. Why should Array objects be cloned on assignment? If
you do a
@a = @b
you get cloning behaviour because the @ sigil implies a container type,
whereas a with a $ sigil you just hand references to objects.
> I would somewhat expect
> a reference to be instead handled using a statement like
>
> $foo[1] := $bar;
>
> Comments and clarifications appreciated.
>
> Pm
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: new method question
Xiao Yafeng wrote:
> There are no barewords in Perl 6, but it seems new method is an exception:
>
> class Dog {
>
> has $name;
Attributes need to have a twigil, so it would be
has $.name
> method bark () {
> say $name;
> }
> }
> my $p = Dog.new($name => 'boo');
You haven't defined a variable $name in this scope, so you can't use on.
> $p.bark;#error!
> my $p = Dog.new( name => 'boo');
> $p.bark#say boo
the => automatically quotes the left hand side, just like in perl 5. I
see no barewords here.
This works fine with current rakudo:
class Dog {
has $.name;
method bark() {
say $.name;
}
}
my $x = Dog.new(name => 'boo');
$x.bark;
> more confused:
>
> class Dog {
>
> has @names;
> method bark () {
> say @names;
> }
> }
> my $p = Dog.new(names => 'boo');
> $p.bark;#nothing but passed.
>
> So, how set array attribute of a class by new method?
I'd expect this to work:
class Dog {
has @.names;
method bark() {
say @.names.join(', ');
}
}
my $x = Dog.new(:names);
# or: Dog.new(name => ('foo', 'bar'))
$x.bark;
but currently it doesn't in rakudo (in does in pugs though)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: whats wrong with this code?
Hi Andy,
you seem to have discovered a whole bunch of bugs at once :/
Andy Colson wrote:
> Hi List --
>
> I'v started playing around with perl 6, and I am having problems with
> this example:
>
> use v6;
>
> sub xsum (@list)
> {
> my $i = 0;
> print "summing: ";
> for @list
> {
> $i += $_;
> print $_,",";
> }
> say " = $i";
> return $i;
> }
> say "sum = ", xsum( (1,2,3,4,5) );
>
> It returns this:
>
> summing: 1 2 3 4 5, = -1.2289e+09
> sum = -1.2289e+09
>
>
> Looks like the "for @list" has one element in it, "1 2 3 4 5".
Not quite. When you add these lines:
say @list.elems;
say @list.WHAT
at the start of the sub, you'll get 5 as the answer for the count, which
seems correct, and 'List' as the type, which seems weird, but I'm not
sure if it's actually wrong (normally something that starts with an @
should be an Array, but since it's a subroutine argument it's read only.
So List might be fine).
The 'for' in conjunction with this weird List is broken. This works:
my @list = (1, 2, 3, 4, 5); my @x = @list; for @x { .say }
(prints all numbers on separate lines)
but this is broken:
sub a(@b) { for @b { .say } }; my @x = (1, 2, 3); a(@x)
prints all at once.
The second problem is the result of the += operation, which does
something really weird.
When you write it as $i = $i + 1, it gives you 5, which is the number of
items in the Array $i (which is correct, if we accept the previous bug
for the moment)
I'll write bug reports for both problems to [EMAIL PROTECTED]
The recommended way to write such a sub is
sub xsum([EMAIL PROTECTED]) { ... }
xsum(1, 2, 3);
With the * before the @list it is "slurpy", which means that it doesn't
expect one list as the argument, but rather an arbitrary number of items.
If you happen to have an Array already, you can interpolate it:
my @x = 1, 2, 3;
xsum(|@x);
HTH,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: whats wrong with this code?
Patrick R. Michaud wrote:
> On Fri, Aug 22, 2008 at 04:34:04PM -0500, Andy Colson wrote:
>> sub xsum (@list)
>> {
>> my $i = 0;
>> print "summing: ";
>> for @list
>> {
>> $i += $_;
>> print $_,",";
>> }
>> say " = $i";
>> return $i;
>> }
>> say "sum = ", xsum( (1,2,3,4,5) );
>>
>> It returns this:
>>
>> summing: 1 2 3 4 5, = -1.2289e+09
>> sum = -1.2289e+09
>
> I suspect that Rakudo is having trouble binding array parameters
> at the moment -- so it's likely a bug in the parameter handling code
> (which I'm expecting will need some refactoring soon anyway). I'm
> guessing that Rakudo is binding @list as if it is a Scalar Array,
> and thus the for loop sees only one element.
>
> This probably deserves a tracking ticket at <[EMAIL PROTECTED]>.
Already wrote one:
[perl #58276] AutoReply: [BUG] Can't iterate over list that was passed
as a subroutine argument
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Does tha capture object $/ retain a live tie to the string it matched?
Carl Mäsak wrote: > Yesterday I got bitten by the fact that currently in Rakudo, $/ > doesn't copy content from the matched string, but instead trusts that > it stays in the matched string and doesn't change. > > Is this the intended behaviour, or should $/ keep a copy the string > contents? As the following examples show, Im hoping for the latter. > > # should $/ really keep ties to $s like this? > rakudo: my $s = "hello"; $s ~~ /hello/; $s = "goodbye"; say $/ > rakudo 29834: OUTPUT[goodb] I'm pretty sure it's a bug in rakudo. The "live tie" you mentioned in the subject should only be present if the :rw modifier is given (but even then I think it should only work the other way round). > # I mean, it's not only unintuitive, it's dangerous, too > rakudo: my $s = "abcdefg"; $s ~~ /efg/; $s = "abc"; say $/ > rakudo 29834: OUTPUT[Cannot take substr outside > stringcurrent instr.: 'parrot;PGE::Match;text' pc 328 > (compilers/pge/PGE/Match.pir:220)] > > # this is how I discovered this behaviour. action at a distance! > rakudo: my $t = 'ABC'; $t ~~ /(A)B(C)/; $t = $0; my $u = $1; > rakudo 29834: OUTPUT[Cannot take substr outside > stringcurrent instr.: 'parrot;PGE::Match;text' pc 328 > (compilers/pge/PGE/Match.pir:220)] > > # the fact that there's such a method as .orig gives me some hope that > # the above is not the intended behaviour. however, as you see, $/.orig > # is not implemented in rakudo. > rakudo: my $s = "hello"; $s ~~ /ello/; say $/.orig > rakudo 29834: OUTPUT[Method 'orig' not found for invocant of > class 'PGE::Match'current instr.: '_block11' pc 60 (EVAL_14:24)] > > S05:2377: > > The currently defined methods are > > $/.from # the initial match position > $/.to # the final match position > $/.chars # $/.to - $/.from > $/.orig # the original match string > $/.text # substr($/.orig, $/.from, $/.chars) $/.text seems to be a bit superfluous, because it's already available as ~$/ and $/.Str But that only as a side note. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)
Moritz Lenz wrote: > Tests 34 to 36 were a bit overcritical: > > (0|undef && say "not ok 34") || say "not ok 34"; > (0&undef && say "not ok 35") || say "not ok 35"; > (0^undef && say "not ok 36") || say "not ok 36"; > > but are easily corrected. The rest seem fine to me. Easier said than done. Question to p6l: do && and || autothread? Or do they collapse the junction prior to evaluation? (I hope the latter, since I think it's more dwimmy). Also do prefix: and prefix: collapse the junction? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)
Larry Wall wrote: > On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote: > : Moritz Lenz wrote: > : > Tests 34 to 36 were a bit overcritical: > : > > : > (0|undef && say "not ok 34") || say "not ok 34"; > : > (0&undef && say "not ok 35") || say "not ok 35"; > : > (0^undef && say "not ok 36") || say "not ok 36"; > : > > : > but are easily corrected. The rest seem fine to me. > : > : Easier said than done. > : Question to p6l: do && and || autothread? Or do they collapse the > : junction prior to evaluation? (I hope the latter, since I think it's > : more dwimmy). > : > : Also do prefix: and prefix: collapse the junction? > > I think it would be best if all boolean contexts collapse consistently, > and I would consider all of those to be boolean contexts. More > precisely, && and || are boolean on the left, but not on the right. Very good. As a follow-up for the testers: should ok() expect an Object as its first argument? If so we could say ok 1|2, 'Junction 1|2 is true in boolean context'; (Which has the nice side effect of not confusing fudge because more tests are executed than expected). Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)
Patrick R. Michaud wrote: > On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote: >> Larry Wall wrote: >> > I think it would be best if all boolean contexts collapse consistently, >> > and I would consider all of those to be boolean contexts. More >> > precisely, && and || are boolean on the left, but not on the right. >> >> Very good. >> As a follow-up for the testers: should ok() expect an Object as its >> first argument? If so we could say >> >> ok 1|2, 'Junction 1|2 is true in boolean context'; > > Keeping with my general philosophy that I'd like to keep > the requirements needed to run Test.pm (and the test suite) > as simple as possible, I'd prefer to not require type checking > within Test.pm in order for it to work right. > > Beyond that, if we're testing a Junction in boolean > context, I think I would prefer to make that an explicit > part of the test itself: > > ok ?(1|2), 'Junction 1|2 is true in boolean context'; I re-wrote the tests to use that kind of syntax, and add it to the official tests: http://svn.pugscode.org/pugs/t/spec/S03-junctions/boolean-context.t My next step will be to fudge it for rakudo. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Regex repetition controlled by characters
Stephen Simmons wrote:
> In S05, I found this regarding the generalized repetition specifier:
>
> ** '|'# repetition controlled by presence of character
>
> I tried it out with
>
> rule thislist { ** '|' };
>
> and got (with Rakudo):
>
> perl6regex parse error: Error in closure quantifier at offset 28, found '''
>
> Is this feature unsupported at the moment or am I misunderstanding it?
It seems to be not yet supported, yes.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58424] Named regex, token and rule don't work outside of a grammar
Patrick R. Michaud wrote:
> On Thu, Aug 28, 2008 at 08:32:41AM -0700, Carl Mäsak wrote:
>> r30590:
>> $ ./perl6 -e 'regex a { b }; "b" ~~ a'
>> too few arguments passed (0) - 2 params expected
>> [...]
>>
>> I've also added tests for this in t/spec/S05-metasyntax/regex.t.
>>
>> (S05 is not entirely clear as to whether this should actually work.
>> IMHO, there's noreason for it not to. Storing anonymous regexes in
>> scalar variables already works.)
>>
>> $ ./perl6 -e 'my $a = regex { b }; say "b" ~~ $a'
>> b
>
> For now I'm going to claim that Rakudo has this one correct. The
> difference between the first and second examples above is that in
> the scalar variable example, the $a variable passed to infix:<~~>
> contains the regex sub itself, whereas in the first example the
> a regex is being invoked as a 0-argument listop prior to calling
> the smart match.
I'm not quite sure. To quote S03:
"The first section contains privileged syntax; if a match can be done
via one of those entries, it will be. These special syntaxes are
dispatched by their form rather than their type."
[...]
$_X Type of Match Implied Match if (given $_)
=== = ===
Any Code:($) item sub truth X($_)
So what does the "Code" mean? A code object? or the name of a sub?
Since it says that the first dispatch is based on the form, I could
imagine that ~~ has some kind of macro semantics, actually.
CC'ing p6l in the hope of some clarification.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Speccing Test.pm?
Howdy, The test suite is considered "official" as in "everything that passes the (completed) test suite may name itself Perl 6", and nearly all of these files 'use Test'; However we don't ship an "official" Test.pm, nor do we define which test functions it should contain and export by default, nor their semantics. Now this may sound a bit theoretical and far-fetched, but we've actually encountered test files that contain tests which are only in Rakudo's Test.pm (probably my fault), and otoh there are a few functions in pugs' Test.pm that are not used (for example unlike(), which is only used in t/02-test-pm/1-basic.t to test unlike()). So how should we proceed? Should I assemble a list of commonly used test functions and remove all others both in the Test.pm's and the test files? And then? Spec it? Or ship a prototype Test.pm as "official"? Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/
Re: capitalization of classes
Hi, Stephen Simmons wrote: > While S02 reserves some all caps names, I assume that all lower case class > names are okay (I don't see anything against them). Rakudo doesn't support > them. This is a "not yet implemented" feature. Basically Rakudo doesn't keep a symbol table yet while parsing, so it uses the case of the first letter to distinguish type names from sub names. This is an evil hack that will at some point be cleaned up. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Should !~~ /regex/ set $/?
The subject says it all: should !~~ with a regex on the RHS set $/? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
List.uniq
There are some tests for List.uniq in the test suite, and pugs
implements it, but it's not in S29.
Damian seems to have though we should have it:
http://groups.google.com/group/perl.perl6.language/msg/4c8c9bd73c862bed
So should we have it? If not, I'll replace the tests with
eval_dies_ok('(1, 2).uniq', 'List.uniq not specced');
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: How do you do a lazy map?
John M. Dlugosz wrote:
> Consider something like a 'map' call, only I want it to be lazy.
map *is* lazy, as are all list builtins that can be lazy (which doesn't
include stuff like sort, which has to look at all items anyway).
> I know that a
> list can contain internally iterators that generate elements as needed or
> perhaps in the background. But how do you create such a thing? Something
> like:
>
> @lazy_list := parallel-map { get_info($_) } @filenames;
@lazy_list = @filenames.map: { get_info($_) };
I suppose ;-)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: List.uniq
Damian Conway wrote: > Moritz Lenz wrote: > >> There are some tests for List.uniq in the test suite, and pugs >> implements it, but it's not in S29. >> Damian seems to have though we should have it. >> So should we have it? > > I still think we should. If only because I've seen it re-(mis)-implemented so > many times. > > I'd also suggest that it have the same interface as .sort. Namely that you > can > pass a block to specify either a unary key-extractor or a binary comparator > function. I like the idea with an unary function, but I have my doubts with the two arg comparison function, because it implies O(n²) runtime. But then again if the user needs that, he'd have to implement it in O(n²) anyway... Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[PATCH] How to match against a grammar
Hi,
we had the discussion a few times on how to match against a grammar, for
example here: http://irclog.perlgeek.de/parrot/2008-05-31#i_322490
Attached patch adds the $string ~~ Grammar.new form to S05, on which
@Larry.pick($some) seems to have agreed upon.
In the end I don't really care how it's done, I just want it to be
specced ;-)
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
--- Rule.pod.old 2008-09-08 17:27:42.0 +0200
+++ Rule.pod 2008-09-08 17:32:15.0 +0200
@@ -3586,8 +3586,6 @@
$parsetree = m:keepall//;
}
-=back
-
=item *
To switch to a different grammar in the middle of a regex, you may use the C<:lang> adverb.
@@ -3595,6 +3593,14 @@
token funnylang { '{' [ :lang($funnylang.unbalanced('}')) ] '}' }
+=item *
+
+To match against the C rule of a grammar, you instantiate the grammar:
+
+$string ~~ Identity.new;
+
+=back
+
=head1 Syntactic categories
For writing your own backslash and assertion subrules or macros, you may
What should 'my $str $x; $x ~= "a"' return?
Well, the subject line already contains my question. I wrote some tests about scalar autovivification. The short sequence: my Str $x; $x ~= 'a'; produces 'Stra' in pugs, because $x contains a Str proto object, that stringifies to the type name. >From my understanding of the synopsis that's correct, but rather unintuitive. So, what should $x be after these two statements? -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: How to define a new value type?
TSa wrote: > HaloO, > > Darren Duncan wrote: >> If you are wanting to actually mutate a Dog in a user-visible way rather >> than deriving another Dog, then I don't think that calling Dog a value >> type is appropriate. > > I think that mutating methods of immutable value types just have > to modify the identity. The problem is how that relates to references. > Take e.g. the Str type > > my $s = 'abc'; # $s points to 'abc' > $s.reverse; [...] > Well, or the language is explicit about the capture of the new > value. Is this meant with > > $s.=reverse; # means $s = $s.reverse > > or is this an error that 'abc' is readonly? $s.reverse returns a reversed copy of $s, and $s.=reverse does the "in place" reverse, ie it directly modifies $s (but not the string stored in $s. At least conceptually. But you can't observe the differences, afaict) When you read carefully through S29 you'll notice that most methods in immutable classes (like Str, List, Int) only return modified copies, even if they mutate the string in Perl 5. (There are some exceptions like Str.substr, which explicitly 'is rw', and which implies that the object somehow has to gain access to its container). Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Should $.foo attributes without "is rw" be writable from within the class
Just to bring some of the IRC discussion to the list...
Carl Mäsak wrote:
> Rakudo and I have a disagreement over this: I expect to be able to
> assign to a $.foo attribute in methods within the class, whereas
> Rakudo demands the "is rw" attribute in order to do that.
>
> We discussed it a bit on #perl6 today.
>
> <http://irclog.perlgeek.de/perl6/2008-09-17#i_572836>
>
> I only have pragmatic arguments to offer for my point of view:
> somehow, it feels like each and every attribute gets an "is rw" as
> things stand now. The modifier somewhat loses its meaning... if it
> meant "_publicly_ readable/writable", it would only be used for some
> variables.
There's also the point that you can initialize attributes with the . twigil:
class Stuff { has $.more_stuff = 3 }
So at least visually it appears as though you *can* assign to it. Not
allowing that in other places feels weird.
Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just
fake assignment to '$.foo' to actually affect '$!foo'?
> Finally, some useless statistics: I count 12 attributes in different
> classes in November right now. Out of those, 12 (100%) have the "is
> rw" attribute.
This is mostly probably due to non-working constructors. Simple cases
seem to work, though:
12:29 < moritz_> rakudo: class A { has $.b }; my A $x .= new(b => 3);
say $x.b
12:29 < p6eval> rakudo 31204: OUTPUT[3]
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: How to define a new value type?
TSa wrote: > The 'is rw' is on the method but I guess it is foreseen that the > result is stored in $string without preserving the identity of the > string? No. It means that the Str object has to get hold of the container in which it is stored, and store a modified copy in it. If that fails (for example in "abc".substr(0, 1) = "foo", where "abc" isn't in a container at all) the write operation will fail. > my $a = "His name is barney"; > my $b = $a; > > $a ~~ /(barney)/; > substr($a, $0.from, $0.to) = "fred"; > > say $b; # prints fred? No, the match object needs to be bound to the value (which is immutable) unless the :rw modifier is present. > If substr should get access to the container passed as argument then > the signature should read > > our Str multi method substr (Str $string is rw: StrPos $start, > Int $length) is rw is export > > and the docu should say that the result is written into the container > passed in the invocant slot. But the 'is rw' on the invocant has the > drawback that calling with a string literal is precluded. Makes sense to me. (The Int should really be StrLen, but that's only a minor glitch). That said, much of S29 needs some loving care... Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
What should ''.split('') return?
Hi,
what should ''.split('') return? The empty list, or a list with one null
string?
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: What should ''.split('') return?
Larry Wall wrote:
> On Fri, Sep 19, 2008 at 05:58:59PM +0200, Moritz Lenz wrote:
> : Hi,
> :
> : what should ''.split('') return? The empty list, or a list with one null
> : string?
>
> Empty list would make more sense as a degenerate case. In
>
> 'a'.split('')
>
> we don't return the null strings before or after 'a', just ('a').
And with the same argumentation the same holds true for regexes as well?
'a'.split(rx/a/) # also empty list
''.split(rx/ '' /) # dito
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Split with negative limits, and other weirdnesses
Today a patch to rakudo brought up the question what split() should do
if the $limit argument is either zero or negative.
In Perl 5 a negative limit means "unlimited", which we don't have to do
because we have the Whatever star. A limit of 0 is basically ignored.
Here are a few solution I could think of
1) A limit of 0 returns the empty list (you want zero items, you get them)
2) A limit of 0 fail()s
3) non-positive $limit arguments are rejected by the signature (Int
where { $_ > 0 })
Any thoughts?
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Another split() question - when is there a capture?
split seems to be a suprisingly tricky beast ;-) To quote S29: : As with Perl 5's split, if there is a capture in the pattern it : is returned in alternation with the split values. Unlike with : Perl 5, multiple such captures are returned in a single Match object. Unlike in Perl 5, it is not determined at (pattern) compile time if a regex has captures. In Perl 5 the regex m/(foo)?/ always has one capture ($1), in Perl 6 it has either zero or one ($0 doesn't exist if 'foo' never matched). So does split return the match objects * if the regex has the potential to create at least one capture or * at least one match actually produces a capture or * (weird) only those matches that produce a capture put a match object into the result list. I'd go for the first option. In that case it might be useful to have some sort of introspection, ie a method like $regex.has_capture (which might return either True (unconditional captures) or False (no captures at all) or True|False (for my example above) ;-) Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Does colonpair notation produce a Bool or Int?
Patrick R. Michaud wrote: > Lines 46-52 of t/spec/S02-literals/pairs.t claims that > the colonpair notation should produce a Bool instead of > an Int: > > #?rakudo todo 'Adverbial pairs without should produce a Bool (not Int)' > is f2(:a), "Bool", "':a' is a named"; > #?rakudo todo '.() sub calls' > is(f2.(:a), "Bool", "in 'f2.(:a)', ':a' is a named"); > #?rakudo todo 'Adverbial pairs without should produce a Bool (not Int)' > is $f2(:a), "Bool", "in '\$f2(:a)', ':a' is a named"; > > However, S02 says that C<:a> corresponds to C<< a => 1 >> in > fatarrow notation, which seems to argue that C<:a> should in > fact have an Int value. > > Are the tests correct here, or am I reading too much into > the synopsis description? Most likely the tests are wrong. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #59396] [PATCH] Implementation of Hash.reverse.
Patrick R. Michaud via RT wrote:
> It feels a little weird to have 'reverse' as an exported symbol
> here. Based on S29, the exports on 'reverse' mean that we get:
>
> my $str = 'abc';
> say reverse $str; # cba
> say reverse $str, 5; # 2abc
5abc
> my %hash = { a=>1, b=>2, c=>3 };
> say reverse %hash; # 1 a\n2 b\n3 c\n
> say reverse %hash, 5; # 5\na 1\nb 2\nc 3\n
># note keys and values are not reversed
>
> It just seems a bit odd to me that adding an extra argument causes
> the meaning of 'reverse' to change for hashes and strings.
It is weird indeed, but from my grasp of the synopsis it's correct
nonetheless.
But IMHO it feels a bit less weird than the Perl 5 behaviour where the
context decides.
Perl 5:
say reverse "abc";# abc\n
say scalar reverse "abc"; # cba\n
Maybe the solution is to avoid name conflicts in this case, maybe name
the methods like this:
Str.mirror
List.reverse
Hash.inverse (or Hash.flip)
(I've never been good with names, so there might be much better ones).
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: globs and trees in Perl6
Timothy S. Nelson wrote: > Hi all. I've enjoyed(?) reading over the February/March thread > entitled "Musings on operator overloading". I've brought a few thoughts > along; if they're old news, please tell me where to do more reading on it :). > > Over the last year or two, I've discovered XPath. I've always thought > XML a little annoying, but I'm very impressed with XPath (which I regard as > "the glob() of XML"), and I've been wondering how to get the power of XPath > in > relation to *all* data, not just XML. Sometimes I wish for something similar. Perl 5's Data::Diver goes a bit in that direction, but it's not nearly as flexible as XPath. > My eventual thought was that what would be useful is a role called > Plex (for those who aren't familiar with a Plex, just think "Tree" and you'll > have the right idea). The basic idea is that the Plex role could have a > variety of implementors depending on the data desired (much like the DBI/DBD > split, but for trees instead of tables). The backends could of course > include > filesystems, but also XML, LDAP, OO databases, and DNS domains. > > Tabular data could also be mapped into trees if desired. This could > be anything from SQL to text files. > > As an additional idea, backend conversion could be performed. This > would be especially useful in the case of files. For example: > > $root/etc/fstab / "/boot" > > ...which would select the row from fstab that contains the "/boot" > partition; admittedly I've fudged the conversion here. It sounds like a perfect idea for a very general library or rather library framework. Perl 6 has all the hooks to install stuff like this. > Btw, it was quite a long time before I was able to find the operator > overloading documentation; "Subroutines" was not an intuitive place to look When you know that operators are mostly[1] just weirdly named subs, it is ;-) > :). Is there any chance we could add something to S03 that says something > like "see S06 and S13 for operator overloading"? That would be mainly Larry's decision. Other ways to search in the Synopsis are * check out a copy of the svn repo, and grep/ack in them * ask in #perl6 where some particular item is documented Sadly we have next to no user-level documentation at them moment. The closest might be the open sourced version of "Perl 6 and Parrot Essentials", but it's rather incomplete and some parts are quite out of date. [1] some operators like ~~ actually have more macroish semantics -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [svn:perl6-synopsis] r14586 - doc/trunk/design/syn
TSa wrote: > HaloO, > > Larry Wall wrote: >> The operator iterates each function until the function fails to >> produce any list elements > > What is the list type these days? It used to be List for writeable > lists and Seq for readonly ones. Array = mutable List = immutable, lazy Seq = immutable, eager Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [svn:perl6-synopsis] r14593 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote:
> +-> {:$name, :$addr, *%guest_data}, $room_num { # WRONG
> +
> +However, as described in the next section, you can always use a
> +sub-signature instead:
> +
> +-> (:$name, :$addr, *%guest_data), $room_num { # WRONG
> +
> +In fact, the [...] and {...} forms are really just extra documentation
> +about what you expect.
I guess it's not intentional to use the same example twice?
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Store captures and non-captures in source-string order
When we write regexes, we generally capture stuff in a way that makes the following semantic analysis easier. For example we could have a regex m/ + ? */ if we're only interested in the match trees of what and matches, not their respective order. But if you want to re-used the match tree for something different (say, instead of doing a semantic analysis we want to do syntax hilighting) it's rather hard to reconstruct the original text, and what part of it was matched by which subrule. Currently you have to fiddle with $/.from and $/.to, and sort all subrules by their respective $/.from and $/.to, and then work out which part hasn't been matched by subrules. This is rather weird and error-prone difference, and I wonder if we should provide some easier way to access all chunks of text in the order that they were matched. I guess this description isn't very clear, so I'll try with an example: "abc 234 def 789 for 456" ~~ mm/ [ \d+ ]**0..2 'for' (\d+) /; $/.chunks would be this list: $[0], ' ', '234', ' ', $[1], ' ', '789', ' ', 'for', ' ', '456' I don't know if the syntax and exact semantics are very good, but IMHO we should have some way of reconstructing a match that is closer to the original string than to the structure of the matching regex. (I also don't know if that's feasible in terms of efficiency) Any ideas? Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Store captures and non-captures in source-string order
Patrick R. Michaud wrote: > On Sun, Oct 12, 2008 at 11:44:05AM +0200, Moritz Lenz wrote: >> When we write regexes, we generally capture stuff in a way that makes >> the following semantic analysis easier. For example we could have a >> regex m/ + ? */ if we're only interested in the match >> trees of what and matches, not their respective order. >> [...] >> But if you want to re-used the match tree for something different (say, >> instead of doing a semantic analysis we want to do syntax hilighting) >> it's rather hard to reconstruct the original text, and what part of it >> was matched by which subrule. > > Perhaps aliases...? > > m/ + ? * / > > This is probably not exactly what you're looking for, but > that would be what I would look at for this specific example. I'm looking more for a general solution for which you don't have to manipulate the rule itself, and which should ideally work with as little knowledge of the rule as possible. Just see through which loops STD5_dump_match (in the same dir as STD.pm) has to jump to get a grab of the parse tree in the right order. Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Running Perl 6 Tests
Ovid wrote: > I've been doing some work integrating Perl 6 into vim and now I'm trying to > figure out how to run individual Perl 6 tests. It appears that the > incantation is along the lines of: > > perl t/harness --verbosity 1 t/01-sanity/02-counter.t > > However, in digging further, I found this: > > perl t/harness --verbosity 1 t/02-test-pm/1-basic.t > > That starts off with "Statement not terminated properly at line 87, near > "(\"Hello Wo"" and goes downhill from there. The t/02-test-pm/* tests never worked with rakudo, and should either be made to work or be ripped out. Since "making it work" hasn't been done for quite some time now, I'm all in favor of ripping them out. > In fact, in reading through the Makefile, I don't see that this gets run > unless you do 'make testtest' (added by particle back in Dec 2007). This > doesn't appear to be documented. Is it supposed to be run? Should those > Perl 6 tests be valid? No. > Also, the way that t/00-parrot/06-op-inplace.t is written forces the test > numbers to be out of sequence. This causes "make test" to fail, even though > it's merely a parse error. The Test.pm module appears to work (I've only > checked it superficially), so why not use that to make some of these tests a > bit easier to write? Are we trying to avoid loading modules while testing > core features? The 01-sanity/ tests predate module loading. The "real" testing is to run 'make spectest', which loads a bunch of tests from the pugs repository, prepares and run them. If you want to run those individually, you can simply say $ make t/spec/S02-literals/radix.t Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Running Perl 6 Tests
Ovid wrote: > --- On Mon, 20/10/08, Moritz Lenz <[EMAIL PROTECTED]> wrote: > > > >> > Also, the way that t/00-parrot/06-op-inplace.t is >> written forces the test numbers to be out of sequence. This >> causes "make test" to fail, even though it's >> merely a parse error. The Test.pm module appears to work >> (I've only checked it superficially), so why not use >> that to make some of these tests a bit easier to write? Are >> we trying to avoid loading modules while testing core >> features? >> >> The 01-sanity/ tests predate module loading. >> The "real" testing is to run 'make >> spectest', which loads a bunch of >> tests from the pugs repository, prepares and run them. >> >> If you want to run those individually, you can simply say >> $ make t/spec/S02-literals/radix.t > > Fair enough. From playing around with this, it appears that all Perl 6 tests > can be run with: > > perl t/harness --verbosity 1 --fudge --keep-exit-code $testname > > Is it an accident that this works for regular test files? No. But be aware that the --fudge option (which is needed for some files below t/spec/) calls the t/spec/fudge script, which doesn't exist on a clean checkout, but is fetched from the pugs repo on the first 'make spectest'. > If not, I can integrate this into vim easily and since module loading works, > t/00-parrot/06-op-inplace.t can be updated with "use Test;" to at least > ensure that "make perl6" passes and people don't get confused when trying to > build. I'd be happy to update that test and send a patch. That's Patrick's decision I think; I don't mind either way, but then I don't use t/00-parrot/ at all. Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: operator vs function
Xiao Yafeng wrote:
> Off the top of one's head, since there is no particular difference between
> an operator and a function, can I see a function as a operator:
>
> (1, 2, 3, 4) >>elems<<(2, 3, 4, 5) #(2, 2, 2, 2)
> (1, 2, 3, 4) >>shift<<(2, 3, 4, 5) #(2, 3, 4, 5)
But remember that operators come with an associativity:
$a / $b / $c == ($a / $b) / $c # left associative
$a ** $b ** $c == $a ** ($b ** $c) # right associative
When you make a function into an operator, you need a good syntax for
defining the associativity of the new pseudo-operator.
Also note that shift(1, 2) doesn't work, because it gets a list, not an
array, and lists are immutable.
> Moreover, can I see a subroutine as a operator:
>
> (1, 2, 3, 4) >>{$a>$b??$a!!$b}<<(2, 3, 4, 5)#(2, 3, 4, 5)
Every operator is accessible as a function (or a macro) already, for
example the operator in 2 + 3 is known as &infix:<+>.
The ternary is a rather ugly case, I guess it's called &infix:($condition, $true, $false), and it's short-circuiting, so it must be
a macro rather than normal function.
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
dpuu wrote:
> Question: is it appropriate to P6 look&feel to have methods on
> functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
> The definition of C includes the statement that it's not
> available on most system unless you're superuser; and this can be
> checked using a POSIX incantation. I was wondering if it would be
> reasonable to provide this as a method on the chown function, so that
> a user could say:
>
> if &chown.is_restricted {
> ...
> }
> else {
> chown $user, $group <== @files
> }
I'd rather go with the "try it and fail() if you can't" approach, partly
because of race conditions, partly because it's much more reliable in
the presence of extended security models (think of SeLinux for example).
If 'use fatal' is in effect, that dies, if not, you can check the return
value.
For chmod() I could imagine an interface like this:
$file.chmod(:8<540>);
$file.chmod( :set, :user => :r & :x, :group => :r)
# both same as 'chmod 540 $file'
$file.chmod( :modifiy, :other => :!x)
# same as 'chmod o-x $file'
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
Larry Wall wrote: > On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote: > : For chmod() I could imagine an interface like this: > : > : $file.chmod(:8<540>); > : $file.chmod( :set, :user => :r & :x, :group => :r) > :# both same as 'chmod 540 $file' > : > : $file.chmod( :modifiy, :other => :!x) > :# same as 'chmod o-x $file' > > A pair on the left side of => could be construed as a design smell. oops, I menat 'user => :r' instead of ':user => :r'. I should take the warning serious that 'sudo' prints out the first time you use it ;-) > And I wonder if the set/modify distinction can be better mapped onto > assignops somehow... maybe as hash slices? $file.perms = 1, 0, 1; Still that would become clumsy if you want to change the rights for user, group and other at the same time... Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: multi return values
Andy Colson wrote:
> (Sorry if this dbl-posts, sent it from the wrong account the first time)
>
> Hi all, what's wrong with this code:
>
> use v6;
>
> sub multireturn($x, $y)
> {
> my $a = $x * 2;
> my $b = $y * 2;
> return($a, $b);
> }
>
> my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: multi return values
Andy Colson wrote:
> Moritz Lenz wrote:
>> Andy Colson wrote:
>>> (Sorry if this dbl-posts, sent it from the wrong account the first time)
>>>
>>> Hi all, what's wrong with this code:
>>>
>>> use v6;
>>>
>>> sub multireturn($x, $y)
>>> {
>>> my $a = $x * 2;
>>> my $b = $y * 2;
>>> return($a, $b);
>>> }
>>>
>>> my($a, $b) = multireturn(2, 3);
>>
>> There's (nearly) nothing wrong with your code, only with the compiler ;-)
>>
>> Rakudo doesn't support list assignment yet (that's where the error
>> message comes from), and doesn't support returning values either.
>>
>> A workaround for now is to use arrays instead.
>
> You mean like:
>
> my @list = multireturn(2, 3);
That, and make multireturn return an array, not a list.
> That still doesn't work. But its not a big deal... I was just playing
> around trying to learn the language.
>
>>
>> (The thing that's still wrong with your code is that you need a
>> whitespace after the 'my', otherwise my(...) should be parsed as a
>> function call).
>
> OH! Good call, I'd forgotten about that. That's going to take some
> getting used to. I assume it'll error out and say "method my not found?"
s/method/sub/, but apart from that: yes.
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [perl #60732] Hash indexes shouldn't work on array refs
jerry gay wrote: > On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz > <[EMAIL PROTECTED]> wrote: >> # New Ticket Created by Moritz Lenz >> # Please include the string: [perl #60732] >> # in the subject line of all future correspondence about this issue. >> # http://rt.perl.org/rt3/Ticket/Display.html?id=60732 > >> >> >> From #perl6 today: >> >> 19:33 < moritz_> rakudo: my $x = [ 42 ]; say $x<0> >> 19:33 < p6eval> rakudo 32984: OUTPUT[42] >> >> I don't think that should be allowed. >> > the real test is: > > (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x<0_but_true>; > (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] > (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $x; > (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] > (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $x; > (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] > (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x; > (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] > (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x<1.4>; > (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] > (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x<0.4>; > (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] > > so, the index is coerced to an integer. is that really wrong? > ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. But that's just my two cents, CC'ing p6l for clarification. Moritz
