[perl6/specs] 5a7a5a: Add reminder to deprecate IO::Path.chdir in 6.d

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 5a7a5aab8569f903800767bee07beb1c2c07c1b5
  
https://github.com/perl6/specs/commit/5a7a5aab8569f903800767bee07beb1c2c07c1b5
  Author: Zoffix Znet <zoffixz...@users.noreply.github.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M v6d.pod

  Log Message:
  ---
  Add reminder to deprecate IO::Path.chdir in 6.d

[perl6/specs] 2c8786: Add 6.d for IEEE num division

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 2c8786a52edb1970df7bb600968771aa03ed37f4
  
https://github.com/perl6/specs/commit/2c8786a52edb1970df7bb600968771aa03ed37f4
  Author: Zoffix Znet <zoffixz...@users.noreply.github.com>
  Date:   2017-02-09 (Thu, 09 Feb 2017)

  Changed paths:
M v6d.pod

  Log Message:
  ---
  Add 6.d for IEEE num division

 Use IEEE 754-2008 semantics for num/Num infix:, infix:<%>, and infix:<%%>

[perl6/specs] d98ee5: Add reminder for 6.d

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: d98ee5412cbde7d220f0bc0a36155d5f9ba60e54
  
https://github.com/perl6/specs/commit/d98ee5412cbde7d220f0bc0a36155d5f9ba60e54
  Author: Zoffix Znet <zoffixz...@users.noreply.github.com>
  Date:   2017-01-27 (Fri, 27 Jan 2017)

  Changed paths:
M v6d.pod

  Log Message:
  ---
  Add reminder for 6.d

To properly reserve all C<< :sym<> >> colonpairs on subroutines
Impl[^1] (commented out) and tests[^2] (fudged) already exist.

[1] https://github.com/rakudo/rakudo/commit/48abeeef26
[2] https://github.com/perl6/roast/commit/53d6e8491d

doc.perl6.org cert expired on 6/25/2016

[Julian Brown]

Announce: [SixFix] A weekly dose of Perl 6 delivered to your inbox

[Nigel Hamilton]

SixFix is a weekly email with something new to learn about Perl 6. But there's
a catch! Each email includes a coding challenge and a question about Perl 6
you must answer to receive your next SixFix.

SixFix helps you learn Perl 6 with practical coding exercises (approx 1/2
an hour each week). You will write Perl 6 code that helps you code. The
first SixFix course is free and is delivered in 7 weekly doses.

Sign up for your first SixFix here:

http://sixfix.nigelhamilton.com

Re: A practical benchmark shows speed challenges for Perl 6

[yary]

On Wed, Mar 30, 2016 at 3:20 PM, Elizabeth Mattijsen  wrote:
> Thanks for your thoughts!
>
> I’ve implemented $*DEFAULT-READ-ELEMS in 
> https://github.com/rakudo/rakudo/commit/5bd1e .
>
> Of course, all of this is provisional, and open for debate and bikeshedding.


Thanks! And that was fast!

Allowing DEFAULT-READ-ELEMS to be set from the environment's a good
idea that I hadn't thought of- since it is a machine-dependent
performance tweak, letting it be set outside the code is a good idea.

I had originally envisioned this as an "option" to "sub open" for
fine-grained control as to which IO::Handles got what
DEFAULT-READ-ELEMS, but I'm not sure it belongs there. After all it is
a performance-related tweak and I'm liking the idea of it being
primarily set from the environment; setting it in the code means
you're writing something for a particular host, don't need to change
the spec to support that.

Is there anything similar on the "write" side- output buffering- that
could use this treatment?

-y

Re: A practical benchmark shows speed challenges for Perl 6

[Elizabeth Mattijsen]

> On 30 Mar 2016, at 16:06, yary  wrote:
> 
> Cross-posting to the compiler group-
> 
> On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen  wrote:
>> If you know the line endings of the file, using 
>> IO::Handle.split($line-ending) (note the actual character, rather than a 
>> regular expression) might help.  That will read in the file in chunks of 64K 
>> and then lazily serve lines from that chunk.
> 
> This reminds me of a pet peeve I had with p5: Inability to easily
> change the default buffer size for reading & writing.
> 
> I'm the lone Perl expert at $work and at one point was trying to keep
> a file processing step in perl. These files were about 100x the size
> of the server's RAM, consisted of variable-length newline-terminated
> text, the processing was very light, there would be a few running in
> parallel. The candidate language, C#, has a text-file-reading object
> that lets you set its read-ahead buffer on creation/opening the file-
> can't remember the details. That size had a large impact on the
> performance of this task. With perl... I could not use the
> not-so-well-documented IO::Handle->setvbuf because my OS didn't
> support it. I did hack together something with sysread, but C# won in
> the end due partly to that.
> 
> It seems this "hiding-of-buffer" sub-optimal situation is being
> repeated in Perl6: neither https://doc.perl6.org/routine/open nor
> http://doc.perl6.org/type/IO::Handle mention a buffer, yet IO::Handle
> reads ahead and buffers. Experience shows that being able to adjust
> this buffer can help in certain situations. Also consider that perl5
> has defaulted to 4k and 8k, whereas perl6 is apparently using 64k, as
> evidence that this buffer needs to change as system builds evolve.
> 
> Please make this easily readable & settable, anywhere it's implemented!

Thanks for your thoughts!

I’ve implemented $*DEFAULT-READ-ELEMS in 
https://github.com/rakudo/rakudo/commit/5bd1e .

Of course, all of this is provisional, and open for debate and bikeshedding.


Liz

Re: A practical benchmark shows speed challenges for Perl 6

[yary]

Cross-posting to the compiler group-

On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen  wrote:
> If you know the line endings of the file, using 
> IO::Handle.split($line-ending) (note the actual character, rather than a 
> regular expression) might help.  That will read in the file in chunks of 64K 
> and then lazily serve lines from that chunk.

This reminds me of a pet peeve I had with p5: Inability to easily
change the default buffer size for reading & writing.

I'm the lone Perl expert at $work and at one point was trying to keep
a file processing step in perl. These files were about 100x the size
of the server's RAM, consisted of variable-length newline-terminated
text, the processing was very light, there would be a few running in
parallel. The candidate language, C#, has a text-file-reading object
that lets you set its read-ahead buffer on creation/opening the file-
can't remember the details. That size had a large impact on the
performance of this task. With perl... I could not use the
not-so-well-documented IO::Handle->setvbuf because my OS didn't
support it. I did hack together something with sysread, but C# won in
the end due partly to that.

It seems this "hiding-of-buffer" sub-optimal situation is being
repeated in Perl6: neither https://doc.perl6.org/routine/open nor
http://doc.perl6.org/type/IO::Handle mention a buffer, yet IO::Handle
reads ahead and buffers. Experience shows that being able to adjust
this buffer can help in certain situations. Also consider that perl5
has defaulted to 4k and 8k, whereas perl6 is apparently using 64k, as
evidence that this buffer needs to change as system builds evolve.

Please make this easily readable & settable, anywhere it's implemented!


-y

Re: Perl 6 mentions on Wikipedia

[Dan Stephenson]

I want in. I'm working on a production project  for cloud computing that fuses 
5 and 6 together. It's proving very useful...

Sent from my iPhone

> On Feb 25, 2016, at 4:26 PM, Damian Conway <dam...@conway.org> wrote:
> 
> Dear fellow revellers in the dawning Golden Age of Perl 6,
> 
> I just had a colleague contact me, to express their surprise that Perl 6
> does not rate a mention in:
> 
> https://en.wikipedia.org/wiki/Functional_programming.
> 
> The Perl 6 community (and Larry in particular) has already done an
> incredible job raising Perl 6's profile on rosettacode.org, but the
> language still seems under-represented on Wikipedia, especially on 
> the various pages describing different language paradigms.
> 
> As Perl 6 is now the pre-eminent example of the imperative,
> declarative, functional, parallel, concurrent, pipelined, vector,
> object-oriented, aspect-oriented, reactive, introspective, and
> metaprogramming paradigms, surely it should be mentioned 
> on all those wiki pages?
> 
> Yeah, I know: "Thanks for volunteering!". I can't at present, but I
> didn't want this important observation, or the opportunity it
> represents, to be lost, just because it was initially directed at
> someone who's currently drowning in other commitments.
> 
> So I thought I'd mention it here, in the hope that someone else 
> who is looking for a slightly unusual way to contribute to Perl 6 
> might find the suggestion worth considering.
> 
> Damian
> 

Perl 6 mentions on Wikipedia

[Damian Conway]

Dear fellow revellers in the dawning Golden Age of Perl 6,

I just had a colleague contact me, to express their surprise that Perl 6
does not rate a mention in:

https://en.wikipedia.org/wiki/Functional_programming.

The Perl 6 community (and Larry in particular) has already done an
incredible job raising Perl 6's profile on rosettacode.org, but the
language still seems under-represented on Wikipedia, especially on
the various pages describing different language paradigms.

As Perl 6 is now the pre-eminent example of the imperative,
declarative, functional, parallel, concurrent, pipelined, vector,
object-oriented, aspect-oriented, reactive, introspective, and
metaprogramming paradigms, surely it should be mentioned
on all those wiki pages?

Yeah, I know: "Thanks for volunteering!". I can't at present, but I
didn't want this important observation, or the opportunity it
represents, to be lost, just because it was initially directed at
someone who's currently drowning in other commitments.

So I thought I'd mention it here, in the hope that someone else
who is looking for a slightly unusual way to contribute to Perl 6
might find the suggestion worth considering.

Damian

Re: It's time to use "use 6.c"

[Peter Pentchev]

On Sat, Feb 06, 2016 at 08:20:14PM -0500, yary wrote:
> Thanks all... I expect hiccups... just venting to help (future coders
> and current self)... while we're on this topic
> 
> a) lwp-download.pl doesn't have a "use 6". Since Windows ignores the
> shebang, it invokes perl5 which is registered to handle "pl" files,
> and gives a bunch of syntax errors. If it did have "use 6" at the top,
> then it would give a single more meaningful error... yet another
> reason for module authors to put "use 6" in their code.
> 
> b) subject line should be "use 6.c", the "v" is depreciated... edited

For the record, just to clear up some possible confusion, "use 6.c"
doesn't work in source files; you need "use v6.c".

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: It's time to use "use 6.c"

[Brandon Allbery]

On Tue, Feb 9, 2016 at 5:38 AM, Peter Pentchev <r...@ringlet.net> wrote:

> For the record, just to clear up some possible confusion, "use 6.c"
> doesn't work in source files; you need "use v6.c".
>

Clarifying: yary seems to have been confused by the fact that META6.json
(only) needs to use version numbers without the leading "v". Perl 6 code
needs to continue to use version-string syntax with the leading "v";
otherwise the ".c" confuses it since "c" is not a valid decimal digit. (I
assume this is because JSON marshaling of version strings creates /
consumes normal strings, those being the only strings defined in JSON, and
the leading "v" of a version string is treated as syntax in the same way
that Python's "r'" or Ruby's "%r{" are, with no way to represent those
"metadata" in JSON.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: It's time to use "use 6.c"

[yary]

Thanks all... I expect hiccups... just venting to help (future coders
and current self)... while we're on this topic

a) lwp-download.pl doesn't have a "use 6". Since Windows ignores the
shebang, it invokes perl5 which is registered to handle "pl" files,
and gives a bunch of syntax errors. If it did have "use 6" at the top,
then it would give a single more meaningful error... yet another
reason for module authors to put "use 6" in their code.

b) subject line should be "use 6.c", the "v" is depreciated... edited

[perl6/specs] db4354: update perl version example to use 6.c type vers

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: db43544188b774d1fe51d85a9293b1190503bb2b
  
https://github.com/perl6/specs/commit/db43544188b774d1fe51d85a9293b1190503bb2b
  Author: Steve Mynott <steve.myn...@gmail.com>
  Date:   2016-01-23 (Sat, 23 Jan 2016)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  update perl version example to use 6.c type vers

Does Perl 6 use $a and $b in sorting?

[Parrot Raiser]

Because of the the special significance of $a and $b in Perl 5's sort
comparison, I always avoid using the names in examples, lest it set a
booby-trap for later.

I've noticed "a" and "b' being used in some P6 examples. Are they no
longer significant, or are they just a poor choice of identifier?

Re: Does Perl 6 use $a and $b in sorting?

[Tobias Leich]

sort accepts something callable with an arity of 2.

Subroutines, blocks and pointies will do:

say sort { $^a cmp $^b }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)␤»

say sort { $^left cmp $^right }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)␤»

say sort -> $a, $b { $a cmp $b }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)␤»

sub foo($a, $b) { $a cmp $b }; say sort , 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)␤»

The { $^a cmp $^b } form also creates a anonymous sub that has two
parameters, $^a and $^b.
The funny thing about these params is that their position in the
implicit signature is obtained by the
alphabetical order of the parameter names.

So, there are no $a and $b special variables, it is just the common way
of naming them.

Am 26.09.2015 um 18:00 schrieb Parrot Raiser:
> Because of the the special significance of $a and $b in Perl 5's sort
> comparison, I always avoid using the names in examples, lest it set a
> booby-trap for later.
>
> I've noticed "a" and "b' being used in some P6 examples. Are they no
> longer significant, or are they just a poor choice of identifier?

Re: Types for Perl 6: request for comments

[yary]

Now that I've read ahead to 3.4, the multi method solution shown can be a
little simpler, just need to add multi to the original equal methods,
see attached.

-y

On Tue, Jun 30, 2015 at 4:16 PM, yary not@gmail.com wrote:

 Section 3.2's example does not fail for the given reason This tries to
 access the c instance variable of the argument $b thus yielding a
 run-time error - instead Perl6 more correctly complains that it was
 expecting a ColPoint, but got a Point instead. Indeed one cannot generally
 replace a subtype with its parent type, only the other way around. Can
 correct by re-writing along the lines of This fails to dispatch because
 ColPoint's equal method requires a ColPoint argument, but we are calling
 it with the supertype Point, which does not compose with the method's
 signature.

 (Furthermore if equal is defined as a multi method, then the
 dispatcher chooses Point's equal method, and the example returns
 True, which all looks good to me. But it doesn't illustrate the paper's
 point.)

 -y




Point.p6
Description: Binary data

Re: Types for Perl 6: request for comments

[yary]

Section 3.2's example does not fail for the given reason This tries to
access the c instance variable of the argument $b thus yielding a run-time
error - instead Perl6 more correctly complains that it was expecting a
ColPoint, but got a Point instead. Indeed one cannot generally replace a
subtype with its parent type, only the other way around. Can correct by
re-writing along the lines of This fails to dispatch because ColPoint's
equal method requires a ColPoint argument, but we are calling it with the
supertype Point, which does not compose with the method's signature.

(Furthermore if equal is defined as a multi method, then the dispatcher
chooses Point's equal method, and the example returns True, which all
looks good to me. But it doesn't illustrate the paper's point.)

-y

Re: Types for Perl 6: request for comments

[Brent Laabs]

On Fri, Jun 26, 2015 at 4:32 AM, Giuseppe Castagna 
g...@pps.univ-paris-diderot.fr wrote:



 my $sub = do {
 proto foo (|) { * }
 multi foo (Int $x) { $x + 1 }
 multi foo (Str $y) { $y ~ 'a' }

 foo;
 }


 Oh yes, nice ... I think I will add it in my paper (and if you send me
 your full name I will give credits to you)


The do block version to make anonymous sub was my work, Brent Laabs.
Using lexical subs to emulate anonymous multi subs was the first thing to
come to mind when I read that Perl 6 didn't have them.  Unfortunately, I
haven't had time to read the rest of your paper, maybe this weekend.

Re: Types for Perl 6: request for comments

[Giuseppe Castagna]

On 24/06/15 21:27, yary wrote:
I'm reading it a bit at a time on lunch break, thanks for sending it 
along, it's educational.


My comments here are all about the example on the top of page 5, 
starting with the minutest. First a typo, it says subC where it 
should say sumC


multi sub sumB is ambiguous, due to your use of ;; there. And sumI 
/should/ be ambiguous, because the caller sumC(Int $x ;; $y) 
{sumI($x,$y)} means sumI will always be called with $x - Int and 
varying $y. That example could use a little re-working.



Oh, right, Thank you, I apologize, I did some cutpaste errors in this 
code (I run all the code on rakudo but I must have missed this one). 
Here you are the correct version. I updated the paper online



multi sub sumI(Int $y ;; Int $x){ $x + $y }
multi sub sumI(Bool $y ;; Int $x) { sumC($y,$x)}

multi sub sumB(Bool $y ;; Bool $x) { $x  $y }
multi sub sumB(Int $y ;; Bool $x) { sumC($x,$y0) }

multi sub sumC(Int $x ;; Int|Bool $y) { sumI($y,$x) }
multi sub sumC(Bool $x ;; Int|Bool $y) { sumB($y,$x) }

I also added an explaination ... now it should be clearer.



Note to Rakudo-porters: Can the error message remember the ;; in 
the sig ? The message from Rakudo * has a , where the source has 
;; which is misleading:

Ambiguous call to 'sumB'; these signatures all match:
:(Bool $y, Bool $x)
:(Bool $y, Int $x)

The comment  example about considering anonymous multi definitions 
in the same block to define the same anonymous function does show the 
feature's desirability, but that proposed syntax might be problematic. 
(Deciding if  how to make that part of the syntax is not in the scope 
of the paper, but since you brought it up) What if one wants to 
define two different anonymous multi subs in the same scope? A 
contrived example:


sub pick_multi (Bool $p) {
  my multi sub hmmI(Int $y) { 2 * $y }
  my multi sub hmmI(Bool $y) { $y }

  my multi sub hmmB(Int $y) { 1 + $y  }
  my multi sub hmmB(Bool $y) { ! $y }

  $p ?? hmmI !! hmmB
}

Yes, one could enclose each anon-multi-set in a do block, but it 
feels to me that defining an anonymous multi-sub should require a 
single statement, to avoid unintentional co-mingling within a block.


  I see, but my purpose was completely different. I did not want define 
local multi-subroutines, I want to define a function whose *result* is a 
multi subroutine.


So the intended meaning of

multi sub sumC(Int $x){
   multi sub (Int $y) { $x + $y }
   multi sub (Bool $y) { sumC ($y)($x) }
}

is

multi sub sumC(Int $x){
  return {
multi sub (Int $y) { $x + $y }
multi sub (Bool $y) { sumC ($y)($x) }
}
}

in the same way as

multi sub sumC(Int $x){ sub (Int $y){$x + $y } }

stands for

multi sub sumC(Int $x){ return {sub (Int $y){$x + $y }} }

Again I added some more explaination in the text.

Now that I've thought about it for 90 seconds (not fully-formed idea), 
if one were to have an anonymous multi-sub, it ought to be constructed 
from a list of /signature/, /body /pairs.


And/or, any non-finalized sub could have a method to add another 
/signature, body/ to its dispatch list.


Yes, or just as I proposed the list is the argument of the return. I 
think that the notation I proposed in the paper should not pose any 
problem to the parser (or the programmer). But as you said, I am out of 
topic here at least as long as this paper is concerned.




my $sub = do {
proto foo (|) { * }
multi foo (Int $x) { $x + 1 }
multi foo (Str $y) { $y ~ 'a' }

foo;
}


Oh yes, nice ... I think I will add it in my paper (and if you send me 
your full name I will give credits to you)



Thanks a lot, this is the kind of feedback I really was looking for.

--Beppe---

Re: Types for Perl 6: request for comments

[yary]

The anon does something. For example this code prints bob

my $routine = proto bar (|) { * };
multi bar (Int $x) { $x - 2 }
multi bar (Str $y) { $y ~ 'b' }

say $routine('bo');

but change the first line to my $routine = anon proto bar (|) { * }; and
you get an error

Cannot call 'bar'; none of these signatures match:
  in block unit at type.p6:5

- and that makes sense to me, because anon means no name gets installed
in any scope, and thus the multi bar declarations have nothing to hold on
to. What confused me is that the $sub_anon example in my last email works,
I expected it to give the same kind of error! It looks like adding the
anon to the proto simply disconnects the proto from the multi, making it
like there was no proto at all.

-y

Re: Types for Perl 6: request for comments

[Brent Laabs]

Subs are lexical by default, so adding my to the function declarators does
nothing.

Not sure what anon is doing there.  My guess is that anon in sink context
does nothing, and Rakudo just builds another proto for foo when it sees the
first multi.  Protos are optional (but not in the compiler itself!), so
that first line is redundant but good practice.

On Sat, Jun 27, 2015 at 5:26 PM, yary not@gmail.com wrote:

 These two variations on Brent's work the same as the original- what subtle
 differences happen by adding anon or my to the declarations?

 my $sub_anon = do {
 anon proto foo (|) { * }
 multi foo (Int $x) { $x + 1 }
 multi foo (Str $y) { $y ~ 'a' }

 foo;
 }

 my $sub_my = do {
 my proto foo (|) { * }
 my multi foo (Int $x) { $x + 1 }
 my multi foo (Str $y) { $y ~ 'a' }

 foo;
 }

Re: Types for Perl 6: request for comments

[yary]

I'm reading it a bit at a time on lunch break, thanks for sending it along,
it's educational.

My comments here are all about the example on the top of page 5, starting
with the minutest. First a typo, it says subC where it should say sumC

multi sub sumB is ambiguous, due to your use of ;; there. And sumI
*should* be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)}
means sumI will always be called with $x - Int and varying $y. That
example could use a little re-working.

Note to Rakudo-porters: Can the error message remember the ;; in the
sig ? The message from Rakudo * has a ,  where the source has ;; which
is misleading:
Ambiguous call to 'sumB'; these signatures all match:
:(Bool $y, Bool $x)
:(Bool $y, Int $x)

The comment  example about considering anonymous multi definitions in the
same block to define the same anonymous function does show the feature's
desirability, but that proposed syntax might be problematic. (Deciding if 
how to make that part of the syntax is not in the scope of the paper, but
since you brought it up) What if one wants to define two different
anonymous multi subs in the same scope? A contrived example:

sub pick_multi (Bool $p) {
  my multi sub hmmI(Int $y) { 2 * $y }
  my multi sub hmmI(Bool $y) { $y }

  my multi sub hmmB(Int $y) { 1 + $y  }
  my multi sub hmmB(Bool $y) { ! $y }

  $p ?? hmmI !! hmmB
}

Yes, one could enclose each anon-multi-set in a do block, but it feels to
me that defining an anonymous multi-sub should require a single statement,
to avoid unintentional co-mingling within a block.

Types for Perl 6: request for comments

[Giuseppe Castagna]

I wrote an article trying explain/propose (static) typing for Perl 6. In 
particular I explain how to type subs, multi subs, classes, multi 
methods; how to use union, intersection and subset types; and I finally 
use these notions to explain the old problem of covariance vs. 
contravariance in object-oriented programming.


The target reader of (the first part of) the article is every Perl 6 
programmer, which is why all the above is explained by examples of Perl 
6 code (no formula, theory, theorem, or property whatsoever) and I tried 
to do my best to make the article completely self-contained. This is 
also why comments from this mailing list are *very* welcome.


The second part of the paper targets language implementers and 
designers: if the first part convinced you of the usefulness of such 
(possibly optional) types, then you will find in the second part the 
details of data structures and algorithms to efficiently implement this 
type system. I also give extensive  references in which you will find 
how to extend the system by some missing bits (notably, polymorphism).


The paper can be retrieved at the following url.

http://www.pps.univ-paris-diderot.fr/~gc/papers/perl6-typing.pdf

I insist, comments from Perl 6 programmers will be extremely welcome: 
just do not be (too) harsh, please :-)


Thank you in advance for your help

Giuseppe Castagna

[perl6/specs] bbb0e9: Clarify lack of special meaning of $a,$b in Perl 6

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: bbb0e90f3a67d61cd4be9f7a419d643bd504f72d
  
https://github.com/perl6/specs/commit/bbb0e90f3a67d61cd4be9f7a419d643bd504f72d
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2015-06-21 (Sun, 21 Jun 2015)

  Changed paths:
M S28-special-names.pod

  Log Message:
  ---
  Clarify lack of special meaning of $a,$b in Perl 6

Re: Perl 6 in CS (Was: [perl6/specs] 89cc32: Spec Bag.kxxv)

[Smylers]

Damian Conway writes:

 I have no confidence yet, however, that Perl 6 will be widely taken up
 as a CS teaching language. ... the decision on a teaching language
 usually reflects either the personal biases of the individual teacher,
 or those of the curriculum committee, or else mirrors the market
 demand of the local community. How else do we explain the awful
 languages that are so often taught in our universities. :-(

A university I'm familiar with taught introductory programming in the
90s using Pascal, chosen for its pedagogical merits, then taught OO
using C++. But students, and potential students, were put off by the
idea of learning Pascal, seen as an irrelevant language. So in the late
90s they switched to teaching C++ as a first language.

Shortly afterwards they found would-be applicants on open days were
querying why they were teaching C++ when rival universities offered
Java, seen as what they needed to learn for getting jobs. So a few years
later, they switched to Java.

In other words, the language chosen for teaching introductory
programming was determined by the views and misconceptions of
16-year-olds!

However, the staff teaching that module didn't feel that Java was a good
choice as an introductory language, so they asked the higher-ups to be
able to put some Python in there too, as an example of a different
programming language. This was agreed, so long as the course was still
marketed as teaching Java, and just happened to include some Python
along the way. (This was over 10 years ago, when Python wasn't as
widespread or recognized as it is now.)

I think that over time the amount of Python increased.

So maybe the situation isn't completely without hope.

Smylers
-- 
Why drug companies shouldn't be allowed to hide research results that they
don't like: http://gu.com/p/3zat8 — UK gov wasted millions on Tamiflu
Sign the AllTrials petition: http://www.alltrials.net/

Licensing: Perl 6 specification and test suite

[Kalinni Gorzkis]

Can I distribute and modify the Perl 6 specification documents and test
suite under which conditions? If not, I propose that they should be
distributed under the Artistic License 2.0.

Re: Licensing: Perl 6 specification and test suite

[Jan Ingvoldstad]

On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis
musicdenotat...@gmail.comwrote:

 Can I distribute and modify the Perl 6 specification documents and test
 suite under which conditions? If not, I propose that they should be
 distributed under the Artistic License 2.0.


That is an excellent question.

I've checked the git sources, and from what I can see, the examples
repository is under AL 2.0, as is STD.pm, but the synopses are not.

I'm unsure as to whether this is an artifact of how things got added to the
git repository or not, perhaps someone else can clarify.
-- 
Jan

Re: Licensing: Perl 6 specification and test suite

[Moritz Lenz]

Hi,

On 11/05/2013 03:16 PM, Jan Ingvoldstad wrote:

On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis
musicdenotat...@gmail.com mailto:musicdenotat...@gmail.com wrote:

Can I distribute and modify the Perl 6 specification documents and
test suite under which conditions? If not, I propose that they
should be distributed under the Artistic License 2.0.


That is an excellent question.

I've checked the git sources, and from what I can see, the examples
repository is under AL 2.0, as is STD.pm, but the synopses are not.

I'm unsure as to whether this is an artifact of how things got added to
the git repository or not, perhaps someone else can clarify.


historically the test suite comes from the 'Pugs' SVN repository, which 
I later migrated to git (when the SVN server failed, and nobody wanted 
to maintain it), and split it up into multiple repositorys. At that 
time, I didn't consider license questions, just getting the technical 
details worked out.


The remainder of the Pugs SVN, which hasn't been split out into 
different repositories, now lives on github as perl6/mu, and it doesn't 
seem to have a catch-all license.


Somehow I have always worked under the assumption that it is under the 
Artistic License 2, just as Rakudo and NQP, and community concensus seem 
to agree with me. Therefor I've added an AL2 LICENSE file to the 
perl6/roast repository, and I hope that any former or current 
contributor that disagrees with the choice of license speaks up soon.


I have no idea if the AL2 is well suited for sets of documents, as the 
specification is. I'll leave that decision to Larry.


Cheers,
Moritz

Re: Licensing: Perl 6 specification and test suite

[Jan Ingvoldstad]

On Tue, Nov 5, 2013 at 3:36 PM, Moritz Lenz mor...@faui2k3.org wrote:

 I have no idea if the AL2 is well suited for sets of documents, as the
 specification is. I'll leave that decision to Larry.


To anyone in doubt: please note that I'm not Larry, I'm not an authority,
I'm just opinionated. :)

Considering that the specification is sortof actually a language
specification, I think there should at least be some terms regarding how
this should apply.

Forking the documentation, or creating derivative works, shouldn't be a
problem, as long as it doesn't change the specification in itself, and
thereby create confusion regarding what the Perl 6 specification is.

Technically speaking, there shouldn't be a problem with pulling the Git
repository, making changes, and proposing that these changes should be
merged with the central Git repository for the specification – that is,
after all, an approximation of how the specification is changed and
developed by the community.
-- 
Jan

Re: Licensing: Perl 6 specification and test suite

[Patrick R. Michaud]

On Tue, Nov 05, 2013 at 03:36:47PM +0100, Moritz Lenz wrote:
 Somehow I have always worked under the assumption that it is under
 the Artistic License 2, just as Rakudo and NQP, and community
 concensus seem to agree with me. Therefor I've added an AL2 LICENSE
 file to the perl6/roast repository, and I hope that any former or
 current contributor that disagrees with the choice of license speaks
 up soon.

Just to add my +1:  I totally agree that perl6/roast is AL2, and
I believe that to be entirely consistent with the way things were
in the Pugs repository at the time of the split.

Pm

Re: Licensing: Perl 6 specification and test suite

[Patrick R. Michaud]

On Tue, Nov 05, 2013 at 04:21:12PM +0100, Jan Ingvoldstad wrote:
 Considering that the specification is sortof actually a language
 specification, I think there should at least be some terms regarding how
 this should apply.

Just to nit semantics a bit and push a little harder on something I've
generally not pushed too much in the past...

I believe that the Perl 6 language specification is actually the 
test suite.  Synopsis 1 even indicates this somewhat explicitly:  
Perl 6 is anything that passes the official test suite  and
... Perl 6 is defined primarily by its desired semantics, not by
accidents of history.

To me, the Synopses are primarily a detailed language description,
and I'm increasingly wishing we wouldn't consider them as the 
language specification...

 Forking the documentation, or creating derivative works, shouldn't be a
 problem, as long as it doesn't change the specification in itself, and
 thereby create confusion regarding what the Perl 6 specification is.

...and this is the exact reason for that wish.  The documentation isn't
the specification at all -- the test suite is.

Pm

Re: Licensing: Perl 6 specification and test suite

[Patrick R. Michaud]

On Tue, Nov 05, 2013 at 11:00:59AM -0600, Patrick R. Michaud wrote:
  Forking the documentation, or creating derivative works, shouldn't be a
  problem, as long as it doesn't change the specification in itself, and
  thereby create confusion regarding what the Perl 6 specification is.
 
 ...and this is the exact reason for that wish.  The documentation isn't
 the specification at all -- the test suite is.

I should probably clarify.  I think that referring to the Synopses
as specification *increases* confusion on the issue, because
it's the test suite that defines the language, not the Synopses.

In some sense, perhaps the Synopses should be considered just
another (human-readable prose) implementation of Perl 6.  Just
like any other Perl 6 implementation, a discrepancy between the
Synopses and the test suite means that one of them needs updating
(based on experience and evolution), but ultimately it's the test
suite that determines what is or is not correct in the Perl 6
specification.

Pm

Re: Licensing: Perl 6 specification and test suite

[Matthew Wilson]

frettled,
Right, it's just the AL2 requires you to thoroughly rename the project's
main name(s) if you redistribute a modified version..
-Matthew




On Tue, Nov 5, 2013 at 7:21 AM, Jan Ingvoldstad frett...@gmail.com wrote:

 On Tue, Nov 5, 2013 at 3:36 PM, Moritz Lenz mor...@faui2k3.org wrote:

 I have no idea if the AL2 is well suited for sets of documents, as the
 specification is. I'll leave that decision to Larry.


 To anyone in doubt: please note that I'm not Larry, I'm not an authority,
 I'm just opinionated. :)

 Considering that the specification is sortof actually a language
 specification, I think there should at least be some terms regarding how
 this should apply.

 Forking the documentation, or creating derivative works, shouldn't be a
 problem, as long as it doesn't change the specification in itself, and
 thereby create confusion regarding what the Perl 6 specification is.

 Technically speaking, there shouldn't be a problem with pulling the Git
 repository, making changes, and proposing that these changes should be
 merged with the central Git repository for the specification – that is,
 after all, an approximation of how the specification is changed and
 developed by the community.
 --
 Jan




-- 
Sent by the Internet

-
Login to LinkedIn to see my whole profile and Connect
http://linkedin.com/in/mattswilson

Re: Licensing: Perl 6 specification and test suite

[raiph mellor]

Perhaps these help?

http://pugs.blogs.com/pugs/2005/02/day_28_609.html

https://www.google.com/#q=site:http%3A%2F%2Fpugs.blogs.com%2F+licensing

--
raiph



On Tue, Nov 5, 2013 at 9:36 AM, Moritz Lenz mor...@faui2k3.org wrote:

 Hi,


 On 11/05/2013 03:16 PM, Jan Ingvoldstad wrote:

 On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis
 musicdenotat...@gmail.com mailto:musicdenotat...@gmail.com wrote:

 Can I distribute and modify the Perl 6 specification documents and
 test suite under which conditions? If not, I propose that they
 should be distributed under the Artistic License 2.0.


 That is an excellent question.

 I've checked the git sources, and from what I can see, the examples
 repository is under AL 2.0, as is STD.pm, but the synopses are not.

 I'm unsure as to whether this is an artifact of how things got added to
 the git repository or not, perhaps someone else can clarify.


 historically the test suite comes from the 'Pugs' SVN repository, which I
 later migrated to git (when the SVN server failed, and nobody wanted to
 maintain it), and split it up into multiple repositorys. At that time, I
 didn't consider license questions, just getting the technical details
 worked out.

 The remainder of the Pugs SVN, which hasn't been split out into different
 repositories, now lives on github as perl6/mu, and it doesn't seem to have
 a catch-all license.

 Somehow I have always worked under the assumption that it is under the
 Artistic License 2, just as Rakudo and NQP, and community concensus seem to
 agree with me. Therefor I've added an AL2 LICENSE file to the perl6/roast
 repository, and I hope that any former or current contributor that
 disagrees with the choice of license speaks up soon.

 I have no idea if the AL2 is well suited for sets of documents, as the
 specification is. I'll leave that decision to Larry.

 Cheers,
 Moritz




-- 
raiph

Re: Defining Perl 6 for the masses

[Parrot Raiser]

Minor corrections:

 may smply be my personal limitations).

s/smply/simply/

 dumb noob questions.

By my fairly harsh definition.

 with the sage of IBM's attempt to develop One Language To Rule Them All,

s/sage/saga/

Re: Defining Perl 6 for the masses

[Richard Hainsworth]

There are two issues here.

a) Using language in a consistent manner in Perl6 space
- the word 'specification' is used in Perl6 space both in the way it has 
become acceptable in computer language design circles, but also in a new 
and more nuanced way in Perl6.
- Perl6 is being developed using Larry Wall's 'whirlpool' model, as 
opposed to the 'waterfall' model, and this has an impact on the use of 
'specification'.
- The result of this double use is a sort of schizophrenia in Perl6's 
documentation when it comes to defining itself.

- Possibly the schizophrenia is useful - a manifestion of junctions :)

b) Educating the world about Perl6
- There are several attempts to address this issue.
- The problems addressed by Parrot Raiser exist and are understood by 
many of the developers.

- My guess is that it will be solved in multiple ways.
- We should remember that the way today's mature languages, such as 
Perl5, C, Fortran etc are taught today has been developed over many years.



On 09/30/2013 10:39 PM, Parrot Raiser wrote:

This is related to the conversation on the Synopses, but its
sufficiently different that it probably justifies its own thread.

I want to start by making it clear that I'm not criticising the design
of Perl 6, or any of the people working so hard to make it great. I'm
just trying to address what I see as an obstacle to its adoption, (but
may smply be my personal limitations). I've been following the project
from the beginning, and have Perl 6 and Parrot (2nd. ed),
http://shop.oreilly.com/product/9780596007379.do  which I understand
is no longer relevant.


snip

Defining Perl 6 for the masses

[Parrot Raiser]

This is related to the conversation on the Synopses, but its
sufficiently different that it probably justifies its own thread.

I want to start by making it clear that I'm not criticising the design
of Perl 6, or any of the people working so hard to make it great. I'm
just trying to address what I see as an obstacle to its adoption, (but
may smply be my personal limitations). I've been following the project
from the beginning, and have Perl 6 and Parrot (2nd. ed),
http://shop.oreilly.com/product/9780596007379.do  which I understand
is no longer relevant.

People on this list are undoubtedly familiar with the uncomfortable
feeling that they're the smartest person in the room. I get it
occasionally, but usually in the Perl community, I can relax. When
giving training classes, however, it wasn't uncommon. Generally,
groups would appear quite comfortable when shown the first four
arithmetic operators, (+,-,*,/), but when the modulus operator was
introduced they would become clearly uneasy. That meant I was in for
some work, but it's the level of enthusiasm I think we have to
consider.

People working on open-source projects naturally want to solve the
sort of problems that interest them. Languages developed by compiler
writers and language theorists will tend to address questions which
ordinary coders will not even understand, let alone want to solve.

The development team obviously need a vocabulary to discuss such
topics, so on top of natural obscurity, they've develped an IRC
culture nearly impenetrable to outsiders, (at least this one). I've
tried to follow it, but don't want to get in the way and slow down
people doing useful work by asking too many dumb noob questions.
However, some of the topics seem pretty esoteric.

It takes time and effort to understand features of a language, so
unless they are necessary to a problem, in a sense they become bugs.
Solutions should not generally be more difficult than the problems
they are supposed to solve.

The vertical view of the specification presented by the Synopses,
exploring each area in depth, makes perfect sense as a design
document, but presents an enormous challenge to a human memory trying
to load the whole language at once. This is compounded by them not
necessarily reflecting what the language should actually do at any
moment, either
because the feature hasn't been implemented yet, or because it has
been revised and the Synopsis hasn't.

I've made a couple of attempts to get up to speed by writing sample
programs, but I keep crashing into obstacles. Translating Mastering
Algorithms in Perl to Perl 6 stumbled almost instantly, because it
uses CPAN modules, so I turned to the Unix utilities for
specifications. wc seems like a simple task, but even that promptly
ran into the question
of $.'s replacement, which doesn't appear to work as advertised.

Reading Perl 6 examples on Rosettacode helps a little, but the site's
structure makes it a rather cumbersome process.

Having recently read Herbert Simon's The Sciences Of The Artificial,
(and listened to TIMTOWDI's State Of The Onion addresses),  I wonder
if a layered approach is the answer to Perl 6's sheer size? A series
of defined subsets of increasing abstraction, from the basics up to
the sophistication of grammar redefinition, would let beginners solve
simple problems with a simple language, but offer a path to more
advanced topics as far as they wish to go. (Just as Perl 5 goes from
Llama to Camel and onward to Jaguar.)

Even a guru has to take the path to enlightenment one step at a time.
Unfortunately, the starting point and boundaries of the path aren't
well-defined. This leaves the sage wandering a plain of obscurity, in
pursuit of ever more tenuous metaphors.

One particular historical analogue that occurs to me is PL/1. You may
be familiar with the sage of IBM's attempt to develop One Language To
Rule Them All, but in case you aren't, it goes something like this.
After tossing Cobol, Fortran, and Algol into the cauldron,
IBM kept stirring vigorously, to the point where scope creep was
putting the development behinder the longer it went on. The lab at
Hursley finally took on the project and delivered something, by
nailing down the subset of features they could promise to implement,
with the rest to follow later. (An early example of Agile practices,
I suppose.)

If a reasonably immutable basic language exists and can be published,
we can get on with learning it, preparing exercises and training
materials regardless of the obscure controversies over object
interface properties going on at the internal levels. Areas clearly
marked not done yet, do not try this can be bypassed. It might not
be release 1.0, but at least 0.nn (nn  0.5).

Is that realistic, or have I missed something vital?

[perl6/specs] 2d47c8: Match vars begin at $0 in Perl 6

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 2d47c89bbb86aa80e42bdc991b04aa3bbca1640f
  
https://github.com/perl6/specs/commit/2d47c89bbb86aa80e42bdc991b04aa3bbca1640f
  Author: Alex Moquin alexmoq...@gmail.com
  Date:   2013-08-08 (Thu, 08 Aug 2013)

  Changed paths:
M S28-special-names.pod

  Log Message:
  ---
  Match vars begin at $0 in Perl 6


  Commit: ac105c28ca590c622491ae2204cc370d9bff
  
https://github.com/perl6/specs/commit/ac105c28ca590c622491ae2204cc370d9bff
  Author: Brent Laabs bsla...@gmail.com
  Date:   2013-08-08 (Thu, 08 Aug 2013)

  Changed paths:
M S28-special-names.pod

  Log Message:
  ---
  Merge pull request #59 from Mouq/matchvars

Match vars begin at $0 in Perl 6
Looks good to me :)


Compare: https://github.com/perl6/specs/compare/a888b089ab07...ac105c28ca59

[perl6/specs] fce8a2: Framework for a Perl 6 glossary

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: fce8a2f8084258aed962521237a445dc53b2837f
  
https://github.com/perl6/specs/commit/fce8a2f8084258aed962521237a445dc53b2837f
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2013-06-26 (Wed, 26 Jun 2013)

  Changed paths:
A S99-glossary.pod

  Log Message:
  ---
  Framework for a Perl 6 glossary

Perl 6 in Perl 6?

[Darren Duncan]

Something (PyPy et al) got me wondering, is it a goal in the Perl community 
before too long to have a (compiling) implementation of Perl 6 written entirely 
in Perl 6?  Meaning, that at some point the entire non-optional codebase of the 
Perl 6 compiler (not just the parser) would be written in pure Perl 6?  This 
doesn't necessarily have to produce machine language; it could be another 
language that needs compiling itself externally, but the point is that the 
entire process of producing that target language out of Perl 6 would be written 
in Perl 6.  I know STD.pm does this for the parsing portion, but I'm wondering 
about the rest.  (Maybe the all-Perl-6 version would also eventually be able to 
produce the fastest running Perl 6 programs too, because it is easiest to write 
Perl 6 analysers/optimizers/etc in, corresponding to PyPy as I understand it.) 
-- Darren Duncan

Re: Perl 6 in Perl 6?

[Moritz Lenz]

On 10/18/2012 09:02 AM, Darren Duncan wrote:

Something (PyPy et al) got me wondering, is it a goal in the Perl
community before too long to have a (compiling) implementation of Perl 6
written entirely in Perl 6?


A fair amount of the two major Perl 6 compilers, Rakudo and Niecza, are 
already written in Perl 6.
Both also contain runtime code written in the native underlying 
language (C/C#), and plans to get rid of that are not realistic right now.


Currently the code generated for Perl 6 code simply can't compete 
speed-wise with hand-written C or C# code.


 (Maybe the all-Perl-6 version would also eventually be able to

produce the fastest running Perl 6 programs too, because it is easiest
to write Perl 6 analysers/optimizers/etc in, corresponding to PyPy as I
understand it.)


But since we are still far away from the point where Perl 6 runs faster 
than C/C#, we would sacrifice much performance by moving to an all-Perl 
6 implementation. So we don't.


Rakudo got rid of much PIR code in the last months, and mostly replaced 
it with NQP, which is a subset of Perl 6 (NQP = Not Quite Perl), which 
makes it far more hackable. For example the whole code generation is now 
written in NQP.


The priorities for most compiler hackers is to provide good compilers 
over complete bootstrapping, and I guess most users agree with that goal.


Cheers,
Moritz

Re: Perl 6 in Perl 6?

[Parrot Raiser]

On Thu, Oct 18, 2012 at 3:59 AM, Moritz Lenz mor...@faui2k3.org wrote:

 The priorities for most compiler hackers is to provide good compilers over
 complete bootstrapping, and I guess most users agree with that goal.

Agreed.

I'm most concerned about a reliable and consistent set of features
being defined, so I can learn them once, without having to backtrack
when they change.

No disrespect to the people working so hard to make it happen, but
Perl 6 is conceptually so big. It's hard to carve out a mind-size
chunk to learn and reinforce when things keep wobbling.

Re: Perl 6 in Perl 6?

[Patrick R. Michaud]

On Thu, Oct 18, 2012 at 09:59:21AM +0200, Moritz Lenz wrote:
 
 On 10/18/2012 09:02 AM, Darren Duncan wrote:
 Something (PyPy et al) got me wondering, is it a goal in the Perl
 community before too long to have a (compiling) implementation of Perl 6
 written entirely in Perl 6?
 
 A fair amount of the two major Perl 6 compilers, Rakudo and Niecza,
 are already written in Perl 6.
 Both also contain runtime code written in the native underlying
 language (C/C#), and plans to get rid of that are not realistic
 right now.

As a quick data point: Rakudo's codebase (compiler+CORE setting)
currently contains around 4,309 lines of C code (*.c, *.h, *.pmc) 
and 24,406 lines of Perl 6 code (*.pm, *.nqp).  

So, 85% of Rakudo is written in Perl 6 and 15% in C-ish languages.

Pm

[perl6/specs] cbb727: [S12] be explicit that Perl 6 uses C3 mro

[noreply]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs

  Commit: cbb72731f19f8bcdc51cdc6d4db28ae10cfdf60b
  
https://github.com/perl6/specs/commit/cbb72731f19f8bcdc51cdc6d4db28ae10cfdf60b
  Author: Moritz Lenz mor...@faui2k3.org
  Date:   2011-10-10 (Mon, 10 Oct 2011)

  Changed paths:
M S12-objects.pod

  Log Message:
  ---
  [S12] be explicit that Perl 6 uses C3 mro

Re: Close($file) required in Perl 6, unlike Perl 5

[Patrick R. Michaud]

On Mon, Jul 18, 2011 at 10:41:30AM -0400, Peter Lobsinger wrote:
 On Sun, Jul 17, 2011 at 11:00 AM, Patrick R. Michaud pmich...@pobox.com 
 wrote:
  On Sun, Jul 17, 2011 at 10:21:19AM +0200, Moritz Lenz wrote:
 
  Question to the Parrot developers: How could I implement DESTROY methods
  in Rakudo? Is there any vtable I can override, or so? Note that such a
  method might itself allocate new GCables. While not urgent, it's
  important for us in the long run.
 
  A possibly related (and more relevant) question for Parrot devs:
  is there any reason that FileHandle PMCs do not automatically
  flush + close on destruction?
 
 The destructor does exactly that, but is not triggered by global teardown.

To be a bit more direct, then:  Several of Parrot's target languages 
have the semantic that normal program exit will cause any open 
filehandles to be flushed and closed automatically.  How does a HLL
writer achieve this in Parrot?

Pm

Re: Close($file) required in Perl 6, unlike Perl 5

[Andrew Whitworth]

On Mon, Jul 18, 2011 at 10:41 AM, Peter Lobsinger plobs...@gmail.com wrote:
 The destructor does exactly that, but is not triggered by global teardown.

That seems wrong to me, we should be sweeping pools and destroying
PMCs on global teardown. If we aren't doing that, it's a bug.

--Andrew Whitworth

Re: Close($file) required in Perl 6, unlike Perl 5

[Peter Lobsinger]

On Sun, Jul 17, 2011 at 11:00 AM, Patrick R. Michaud pmich...@pobox.com wrote:
 On Sun, Jul 17, 2011 at 10:21:19AM +0200, Moritz Lenz wrote:

 Question to the Parrot developers: How could I implement DESTROY methods
 in Rakudo? Is there any vtable I can override, or so? Note that such a
 method might itself allocate new GCables. While not urgent, it's
 important for us in the long run.

 A possibly related (and more relevant) question for Parrot devs:
 is there any reason that FileHandle PMCs do not automatically
 flush + close on destruction?

The destructor does exactly that, but is not triggered by global teardown.

    pmichaud@kiwi:~/nom$ cat fh.pir
    .sub 'main' :main
        $P0 = new ['FileHandle']
        $P1 = $P0.'open'('test.txt', 'w')
        $P1.'print'(Hello\n)
    .end

    pmichaud@kiwi:~/nom$ install/bin/parrot fh.pir
    pmichaud@kiwi:~/nom$ cat test.txt
    pmichaud@kiwi:~/nom$ ls -l test.txt
    -rw-r--r-- 1 pmichaud pmichaud 0 2011-07-17 09:57 test.txt

.sub 'main' :main
 $P0 = new ['FileHandle']
 $P0.'open'('test.txt', 'w')
 $P0.'print'(Hello\n)
 $P0 = null
 sweep 1
.end

 Pm
 ___
 http://lists.parrot.org/mailman/listinfo/parrot-dev

Re: Close($file) required in Perl 6, unlike Perl 5

[Andrew Whitworth]

On Sun, Jul 17, 2011 at 4:21 AM, Moritz Lenz mor...@faui2k3.org wrote:
 Question to the Parrot developers: How could I implement DESTROY methods
 in Rakudo? Is there any vtable I can override, or so? Note that such a
 method might itself allocate new GCables. While not urgent, it's
 important for us in the long run.

We do have the ability to override VTABLE_destroy in a C-based PMC
type, but that is not exposed through Object PMC. I suspect this
capability could be exposed through 6model and the Rakudo PMC
infrastructure, and a Sub could be invoked from there. Because of the
sensitive nature of the timing, and because this has obviously not
gotten any good test coverage or developer attention, it probably
won't work so well.

This hasn't been a high-priority issue so far, either amonst users or
developers. If people are interested in seeing this happen, failing
use-cases or even tickets requesting fixes would be a great place to
start. My suggestion so far would be to add in a destroy override to
6model, try to use it, and see what blows up. Then open a ticket with
Parrot and we'll do our best to make it work the way you need.

--Andrew Whitworth

Re: Close($file) required in Perl 6, unlike Perl 5

[Patrick R. Michaud]

On Mon, Jul 18, 2011 at 11:26:49AM -0400, Andrew Whitworth wrote:
 On Mon, Jul 18, 2011 at 10:41 AM, Peter Lobsinger plobs...@gmail.com wrote:
  The destructor does exactly that, but is not triggered by global teardown.
 
 That seems wrong to me, we should be sweeping pools and destroying
 PMCs on global teardown. If we aren't doing that, it's a bug.

Now added as TT #2157, at least for the FileHandle not closing part.

Pm

Re: Close($file) required in Perl 6, unlike Perl 5

[Moritz Lenz]

On 07/13/2011 10:00 PM, Parrot Raiser wrote:
 The following program:
 
 my $skeleton = bones\n;
 my $new_file = grave;
 my $handle   = open($new_file, :w);
 $handle.print($skeleton);
 
 opens the grave file, but leaves it empty. A last line:
 
 close($handle);# close() generates an error message.
 
 is required to get any contents in the file, unlike the equivalent Perl 5 
 code:

That's because Rakudo isn't yet able to execute any code (like a DESTROY
method in Perl 5) when the garbage collector detects that an object is
not referenced anywhere anymore. So it's a limitation in Rakudo, not a
change in the language.

An intrinsic difference is that Perl 5 guarantees a timely execution of
such methods (because it is reference counted), whereas Perl 6 does not.

Question to the Parrot developers: How could I implement DESTROY methods
in Rakudo? Is there any vtable I can override, or so? Note that such a
method might itself allocate new GCables. While not urgent, it's
important for us in the long run.

Cheers,
Moritz

Re: Close($file) required in Perl 6, unlike Perl 5

[Patrick R. Michaud]

On Sun, Jul 17, 2011 at 10:21:19AM +0200, Moritz Lenz wrote:
 
 Question to the Parrot developers: How could I implement DESTROY methods
 in Rakudo? Is there any vtable I can override, or so? Note that such a
 method might itself allocate new GCables. While not urgent, it's
 important for us in the long run.

A possibly related (and more relevant) question for Parrot devs:
is there any reason that FileHandle PMCs do not automatically 
flush + close on destruction?

pmichaud@kiwi:~/nom$ cat fh.pir
.sub 'main' :main
$P0 = new ['FileHandle']
$P1 = $P0.'open'('test.txt', 'w')
$P1.'print'(Hello\n)
.end

pmichaud@kiwi:~/nom$ install/bin/parrot fh.pir
pmichaud@kiwi:~/nom$ cat test.txt
pmichaud@kiwi:~/nom$ ls -l test.txt
-rw-r--r-- 1 pmichaud pmichaud 0 2011-07-17 09:57 test.txt

Pm

Close($file) required in Perl 6, unlike Perl 5

[Parrot Raiser]

The following program:

my $skeleton = bones\n;
my $new_file = grave;
my $handle   = open($new_file, :w);
$handle.print($skeleton);

opens the grave file, but leaves it empty. A last line:

close($handle);# close() generates an error message.

is required to get any contents in the file, unlike the equivalent Perl 5 code:

my $skeleton = bones\n;
my $new_file = grave;
open(my $handle, , $new_file) or die $!;
print $handle $skeleton;

This might be a perfectly reasonable design decision, but I haven't
noticed it mentioned.

Re: dimensionality in Perl 6

[Moritz Lenz]

Am 19.11.2010 05:45, schrieb Jon Lang:

On Thu, Nov 18, 2010 at 8:25 PM, Carl Mäsakcma...@gmail.com  wrote:

Jon ():

Here's my proposal for how to handle dimensionality in Perl 6:

[...]

Thoughts?


The idea has come up before, everyone thinks that Perl 6 and unit
handling are a good fit for each other, and we're basically waiting
for someone to write such a module. Incidentally, your phrase a
complication that we needn't deal with up front is exactly why
there's no pressing need to put this in Perl 6 core (fsvo core).


I'm suggesting this because the recent thread about Duration indicates
to me that there _is_ a need to put at least a minimally-featured unit
handling system into the core,



That's not what I learned from that discussion.

My conclusions from the discussions about Durations where that
* the old attempt to forbid some operations as part of dimensionality 
analysis were a bad idea
* if there should be a dimensionality type system in Perl 6, it must be 
more powerful than simply forbidding some operations that do make sense


Nowhere have I seen the need for a unit handling system in core.
Just because we happen to know the units/dimensions of a single type 
(Duration) doesn't mean we have to ship a system that can enforce 
correct dimension handling. I've read that some people like that idea, 
but I've seen no *need*.


Iff somebody comes up with a nice, small unit handling system (*), and 
can demonstrate how well it can integrate with Durations and the rest of 
the type system, I (and the other sceptics) might reconsider my objection.


(*) runnable code please.

Cheers,
Moritz

dimensionality in Perl 6

[Jon Lang]

Here's my proposal for how to handle dimensionality in Perl 6:

Create a units trait that is designed to attach to any Numeric
object.  Dimensional information gets stored as a baggy object - that
is, something that  works just like a Bag, except that the count can
go negative.  (I don't know if the count should be a signed integer or
a Num; what happens in dimensional analysis when you try to take the
square root of two inches?)  Overload the Numeric operators to
properly track the units as well as performing their normal
activities.  Add one or two methods that allow you to easily extract
the raw number and/or the units.

For now, unit conversions are always handled manually, and the units
themselves are completely arbitrary   At some later date we might
consider adding a robust database of units and conversion rates; but
that's a complication that we needn't deal with up front.  Indeed, it
might work best as a module to be included by those who want the added
tools.  Regardless, such a module should not interfere in the ability
to use made-up units on the fly; instead, it should provide additional
details for units that have been properly registered (such as what
kind of value is being measured, which measurement system it's a part
of, what the conversion rates are, and what synonyms exist for it).
The goal should be to enhance, not restrict.

If this is implemented, Duration should be an alias for something to
the effect of Num but unitssecond.  Otherwise, Instant and
Duration remain unchanged.

Thoughts?

-- 
Jonathan Dataweaver Lang

Re: dimensionality in Perl 6

[Doug McNutt]

At 16:58 -0800 11/18/10, Jon Lang wrote:
If this is implemented, Duration should be an alias for something to
the effect of Num but unitssecond.  Otherwise, Instant and
Duration remain unchanged.

Thoughts?

http://www.physics.nist.gov/cuu/Units/index.html

with special attention to:  http://www.physics.nist.gov/cuu/Units/binary.html

When a user multiplies two dimensioned quantities the result should be assigned 
the product of the dimensions of the factors.

E = m*c**2 should acquire the dimension kg*m^2*s^-2, a joule. Comparison of 
that with another energy unit, like a BTU calculated from temperatures, should 
return an error unless some user selected add-in, which might well have a 
political flavor, is asked for.
-- 

-- A fair tax is one that you pay but I don't --

Re: dimensionality in Perl 6

[Carl Mäsak]

Jon ():
 Here's my proposal for how to handle dimensionality in Perl 6:

 [...]

 Thoughts?

The idea has come up before, everyone thinks that Perl 6 and unit
handling are a good fit for each other, and we're basically waiting
for someone to write such a module. Incidentally, your phrase a
complication that we needn't deal with up front is exactly why
there's no pressing need to put this in Perl 6 core (fsvo core).

See also the Physical::Unit example in a blog post of mine, for an
example of how postfix ops can be used to mark the units:

 
http://strangelyconsistent.org/blog/6-builtins-in-perl-6-that-you-never-knew-you-needed

// Carl

Re: dimensionality in Perl 6

[Jon Lang]

On Thu, Nov 18, 2010 at 8:25 PM, Carl Mäsak cma...@gmail.com wrote:
 Jon ():
 Here's my proposal for how to handle dimensionality in Perl 6:

 [...]

 Thoughts?

 The idea has come up before, everyone thinks that Perl 6 and unit
 handling are a good fit for each other, and we're basically waiting
 for someone to write such a module. Incidentally, your phrase a
 complication that we needn't deal with up front is exactly why
 there's no pressing need to put this in Perl 6 core (fsvo core).

I'm suggesting this because the recent thread about Duration indicates
to me that there _is_ a need to put at least a minimally-featured unit
handling system into the core, if for no other reason than to ensure
that Durations will be part of said system.  The trick is to come up
with something that's simple enough that including it in the core
won't unduly delay release of Perl 6, but robust enough that we can
build on it after release.

 See also the Physical::Unit example in a blog post of mine, for an
 example of how postfix ops can be used to mark the units:

  http://strangelyconsistent.org/blog/6-builtins-in-perl-6-that-you-never-knew-you-needed

Nice.  5 sec definitely beats 5 but unitssec for legibility, and
would be a very nice way of generating Durations on the fly.

-- 
Jonathan Dataweaver Lang

Re: dimensionality in Perl 6

[Buddha Buck]

Jon Lang asked me if I intended to send this message to him privately.
 The answer is No...


-- Forwarded message --
From: Buddha Buck blaisepas...@gmail.com
Date: Thu, Nov 18, 2010 at 10:39 PM
Subject: Re: dimensionality in Perl 6
To: Jon Lang datawea...@gmail.com


On Thu, Nov 18, 2010 at 7:58 PM, Jon Lang datawea...@gmail.com wrote:
 Here's my proposal for how to handle dimensionality in Perl 6:

 Create a units trait that is designed to attach to any Numeric
 object.  Dimensional information gets stored as a baggy object - that
 is, something that  works just like a Bag, except that the count can
 go negative.  (I don't know if the count should be a signed integer or
 a Num; what happens in dimensional analysis when you try to take the
 square root of two inches?)  Overload the Numeric operators to
 properly track the units as well as performing their normal
 activities.  Add one or two methods that allow you to easily extract
 the raw number and/or the units.

An added complication is dimensionality.  ergs, joules, btu and eV
are all units of energy, and it isn't unreasonable to want to add or
subtract energies of different units (my house used (100 therm +
8000kWh) of energy last month, for example).  However, it is incorrect
to add ergs and Newtons, since they are of different dimensionality.

The more robust units/dimensional analysis packages I've seen might
not allow one to add therms and kWh, but they do know that therms and
kWh are both [ML^2/T^2],  I believe at the time I was looking at
JScience's work on JSR-275.  In this setup, when units are registered,
they are given a dimensionality (essentially, a baggy of
dimensions), and values are given a baggy of units (and thus an
implicit baggy of dimensions, the union of the dimensions of the
units).

I don't think a Num is necessary, but I could see a Rat.

 If this is implemented, Duration should be an alias for something to
 the effect of Num but unitssecond.  Otherwise, Instant and
 Duration remain unchanged.

 Thoughts?

 --
 Jonathan Dataweaver Lang

Re: dimensionality in Perl 6

[Jon Lang]

Buddha Buck wrote:
 Jon Lang wrote:
 Here's my proposal for how to handle dimensionality in Perl 6:

 Create a units trait that is designed to attach to any Numeric
 object.  Dimensional information gets stored as a baggy object - that
 is, something that  works just like a Bag, except that the count can
 go negative.  (I don't know if the count should be a signed integer or
 a Num; what happens in dimensional analysis when you try to take the
 square root of two inches?)  Overload the Numeric operators to
 properly track the units as well as performing their normal
 activities.  Add one or two methods that allow you to easily extract
 the raw number and/or the units.

 An added complication is dimensionality.  ergs, joules, btu and eV
 are all units of energy, and it isn't unreasonable to want to add or
 subtract energies of different units (my house used (100 therm +
 8000kWh) of energy last month, for example).  However, it is incorrect
 to add ergs and Newtons, since they are of different dimensionality.

Right.  And in the basic package, it would be the programmer's
responsibility to convert therms to kWh, or vice versa, before the
addition takes place.  And just like Perl 6 implements Instant without
reference to a specific calendar system, leaving that to be
implemented by appropriate modules, dimensionality would leave the
implementation of specific systems of measurement to appropriate
modules.

With that in mind, your further suggestions would work well for the
purpose of defining such a module:

 The more robust units/dimensional analysis packages I've seen might
 not allow one to add therms and kWh, but they do know that therms and
 kWh are both [ML^2/T^2],  I believe at the time I was looking at
 JScience's work on JSR-275.  In this setup, when units are registered,
 they are given a dimensionality (essentially, a baggy of
 dimensions), and values are given a baggy of units (and thus an
 implicit baggy of dimensions, the union of the dimensions of the
 units).

I was using Baggy to describe an as-yet-hypothetical role that is to
Bags and Sets as Numeric is to Num, Rat, Int, Complex, and so on.  The
actual type for units would probably best be called an SBag, where
the S stands for Signed (meaning that its count can be negative as
well as positive).  That said, it might need to be a RatBag, or
possibly even a NumBag, if we want to leave open the possibility of
fractal dimensions.  Still, I'm thinking that an SBag would be good
enough to start with.

Your idea of having a registered unit be associated with an SBag of
dimensions (e.g., ML^2T^-2) would be good for allowing more
intelligent exceptions, and would cover what I was talking about in
terms of defining what kind of value a unit measures.

 I don't think a Num is necessary, but I could see a Rat.

As is, is Duration implemented by means of a Num, or a Rat?  Whichever
it is, that's the type that the difference of two Instances would
return (properly tagged with seconds, of course).

-- 
Jonathan Dataweaver Lang

Re: dimensionality in Perl 6

[Carl Mäsak]

Jon (), Carl (), Jon ():
 Here's my proposal for how to handle dimensionality in Perl 6:

 [...]

 Thoughts?

 The idea has come up before, everyone thinks that Perl 6 and unit
 handling are a good fit for each other, and we're basically waiting
 for someone to write such a module. Incidentally, your phrase a
 complication that we needn't deal with up front is exactly why
 there's no pressing need to put this in Perl 6 core (fsvo core).

 I'm suggesting this because the recent thread about Duration indicates
 to me that there _is_ a need to put at least a minimally-featured unit
 handling system into the core, if for no other reason than to ensure
 that Durations will be part of said system.  The trick is to come up
 with something that's simple enough that including it in the core
 won't unduly delay release of Perl 6, but robust enough that we can
 build on it after release.

Heh, I wasn't even thinking of it in terms of delaying release of
Perl 6. Maybe because I'm using Perl 6 on a daily basis, rather than
waiting for it to come out.

Anyway, since I don't see the need for all this unit handling with
Duration in the first place, I don't agree that there is a need to put
even a minimally-features unit handling system into the core.

 See also the Physical::Unit example in a blog post of mine, for an
 example of how postfix ops can be used to mark the units:

  http://strangelyconsistent.org/blog/6-builtins-in-perl-6-that-you-never-knew-you-needed

 Nice.  5 sec definitely beats 5 but unitssec for legibility, and
 would be a very nice way of generating Durations on the fly.

Note that due to the nature of postcircumfixes, you can't actually
write 5 sec with whitespace between the 5 and the sec. Either
5sec or 5\ sec is fine, though.

// Carl

Re: dimensionality in Perl 6

[Buddha Buck]

On Thu, Nov 18, 2010 at 11:53 PM, Jon Lang datawea...@gmail.com wrote:
 Buddha Buck wrote:
 I don't think a Num is necessary, but I could see a Rat.

 As is, is Duration implemented by means of a Num, or a Rat?  Whichever
 it is, that's the type that the difference of two Instances would
 return (properly tagged with seconds, of course).

Clarification:  I didn't mean to imply that a Rat would be sufficient
for Duration, but rather that it would probably suffice for
dimensioned values to have a RatBag of units, each with a RatBag of
dimensions, rather than NumBags.  SBags might be too restrictive.

(sent both publicly and privately on the first try, this time)

 --
 Jonathan Dataweaver Lang

Re: Pragma to change presentation of numbers in Perl 6.

[Dave Whipp]

Matthew wrote:


use base 16;
my $a = 10;
say $a;

puts the number 0x10 into $a, and outputs `10'. Here, say $a.fmt('%d') 
would output `16'.


As someone who has implemented, and used, mini-languages with such a 
feature, I'd say that the confusion that it would cause does 
significantly outweigh any potential benefit.


Question: what would be the behavior of:

use base 8;
use base 10;
$a = 10;

I think that $a now holds the value 0d8, because 0o10 is 0d8. That is, 
use base 10 would always be a no-op.


A pragma to control the default behavior of stringification would be 
less problematic -- indeed would be useful -- but even then it's 
probably more useful to have it as a property of the class/object that 
holds the value: { my $a = 10 but :stringification-base(16) }.


When you have a large number of constants that you want to hard-code 
into source code, it's probably better to scope it to an individual 
expression. Perhaps { my @a = :16 12 1a 1b  } would get you most of 
the way.


I have no problem if you want to make it possible to write such a pragma 
(just subclass the grammar to change the behavior of numeric literals) 
but it should be something that lives in in a user module with a nice 
long scary name.


I'd also note that use base has an existing, different, meaning in Perl 5.

Pragma to change presentation of numbers in Perl 6.

[Matthew]

Today I propose a pragma that changes how numbers are presented in Perl 
6. The idea arises from a discussion on the freenode channel #perl6, 
available here: http://irclog.perlgeek.de/perl6/2010-09-01#i_2773432


The most important thing to remember is that the presentation of numbers 
in Perl 6 is different from the number itself, the way we use numbers in 
our code is different from how Perl 6 handles them internally. We only 
chose for numbers in our code to be presented and treated as being in 
base 10 because that's how most of us count.


The pragma I propose is use base, which takes one positional argument 
that denotes what base you want Perl 6 to interpret and present numbers 
in your code. For example, use base 16 tells Perl 6 to handle all 
numbers as if they're in base 16, and to present them as base 16. Here, 
I present an example use:


my $a = 10;
say $a;

This code does what it always does. It puts the number 0d10 into $a, and 
then say outputs `10'. But this code:


use base 16;
my $a = 10;
say $a;

puts the number 0x10 into $a, and outputs `10'. Here, say $a.fmt('%d') 
would output `16'.


Now, this may cause some confusion in some cases, particularly with the 
radix conversion :10() and such. In the default base 10, :10($a) is 
interpreted to mean that $a is in base 10, and to convert it to how Perl 
6 currently presents numbers, base 10. Naturally, this is pretty 
useless. In base 16 mode, :10($a) is interpreted to mean that $a is in 
base 16 (because the 10 here is now 0x10), and to convert it to base 16, 
and is just as useless.  In base 16 mode, :A($a) would be used instead 
to convert base 10 to base 16.


If you see any significant problems or have suggestions, then feel free 
to reply. I feel this will help with making non-10 bases easier to deal 
with in applications where its necessary.


-lue

Re: Pragma to change presentation of numbers in Perl 6.

[Darren Duncan]

Matthew wrote:
Today I propose a pragma that changes how numbers are presented in Perl 
6. The idea arises from a discussion on the freenode channel #perl6, 
available here: http://irclog.perlgeek.de/perl6/2010-09-01#i_2773432

snip

I only see this pragma as being useful within limited circumstances, such as 
when applied lexically for when you want to use a large number of numeric 
literals in some other base, rather than always at a file level.


Generally speaking, I see it better to explicitly specify the base with each 
number when that base isn't ten, because it is much easier for people to 
correctly read the code.


Believe me when I say I empathize with wanting to let other numeric bases have 
equal treatment to base 10, but I believe the best way to do that in general is 
support a common syntax for specifying the base with each number, and Perl 6 
already provides this.


See also my Muldis D language which has explored these same kinds of ideas:


http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Dialect/PTMD_STD.pod#General_Purpose_Integer_Numeric_Literals

-- Darren Duncan

Re: Natural Language and Perl 6

[Stephen Weeks]

Not long ago, yary proclaimed...
 This is getting more and more off topic, but if you want some lojban
 pasers, start at
 http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers
I have a translation of the Lojban grammar in Perl 6 rules sitting
around somewhere, possibly on an old, dead laptop.  I've been thinking
about reviving that, but haven't been able to find it yet.  Maybe I'll
just start over.  It was quite nice for working with Lojban text.

See, not so off-topic after all. :)

Re: Natural Language and Perl 6

[Timothy S. Nelson]

On Tue, 3 Aug 2010, Carl Mäsak wrote:


Jason ():

No specific tool is best suited for natural language processing. There was
apparently a time in which everyone thought that a formal grammar could
clearly define any natural language, but I don't think anyone succeeded at
creating a complete formal grammar for any language other than something
like Esperanto.


Even Esperanto is about on the same level of complexity as your
regular Indo-European language. Sure, the word-formation is more
regular, but the freedom in creating sentences with non-obvious
antecedents and all manner of ambiguity, is just as large as in any
national language.

Now, had you said Lojban, I'd have believed you. :)


Or maybe Ithkuil: http://en.wikipedia.org/wiki/Ithkuil

:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-

Re: Perl 6 User Documentation

[Jonathan Leto]

Howdy,

 Attached are a 3 very initial (skeletal in nature) Perl 6 .pod
 documents, based loosely on the Perl 5 documentation. It is my
 understanding that currently there is no P6-Pod reader e.g. perl6doc
 so these are actually written in P5-POD, but the intent is to
 eventually of course translate them to P6-Pod.

There is actually a Perl 6 version of perldoc, called grok, which was
a Google Summer of Code project last year. It can be
installed from CPAN as App::Grok, which relies on Perl6::Doc . Perl6::Doc
is an bundled version of the Synopses and supporting material, but it has
not been updated from the Synopses in the Pugs repo, so it is a bit stale.

As for u4x, mentioned by moritz++, check out
http://search.cpan.org/~hinrik/grok-0.21/lib/App/Grok/Resource/u4x.pm
.

This information is not intended to hinder your excitement, just
wanted you to know about prior art
and possibly helpful and related work.

Good luck and thanks for your efforts!

Duke

-- 
Jonathan Duke Leto
jonat...@leto.net
http://leto.net

Re: Perl 6 User Documentation

[Moritz Lenz]

Hi,

Offer Kaye wrote:
 Following the release of Rakudo Star I've been playing around with
 learning Perl 6 and noticed a distinct lack of user-facing
 documentation. After some IRC chats with pmichaud++ I thought it would
 be a good idea if I got the ball rolling, assuming of course it
 doesn't reach a sharp incline, roll back and squash me.

I appreciate your effort, and will help wherever I can.

 Attached are a 3 very initial (skeletal in nature) Perl 6 .pod
 documents, based loosely on the Perl 5 documentation. It is my
 understanding that currently there is no P6-Pod reader e.g. perl6doc
 so these are actually written in P5-POD, but the intent is to
 eventually of course translate them to P6-Pod.

Agreed.

 My purpose is to get very initial feedback, see if this is the right
 direction to go at all, get some thoughts on basic terminology, stuff
 like that. For example:
 1. Use P5 POD or insist on P6 Pod?

p5pod is good for now.

 2. Is it Perl 6 or just Perl? Currently it's perl6 but will it
 be just perl eventually?

I'd use 'Perl 6' in the title, and then refer to it as 'Perl' in the
body of the document.

 3. Can I just rename S26.pod to perl6pod.pod and be done with it? :)

S26.pod is intended as a reference (but quite readable, if I remember
correctly). It's certainly a good start, maybe at some later point we
might want to have something more tutorial-style.


For what it's worth, there's an initial effort to get some documentation
going in http://svn.pugscode.org/pugs/docs/u4x/ (look in the README for
the vision, and documentation/ for some existing POD files). The
rendered documents are at http://doc.perl6.org/. Certainly needs a
better index file and some pre-text, but it's a start.

You're welcome to add your stuff there (ping me or other Perl 6 hackers
about a commit bit on #perl6), or start your own repo somwhere (though
I'd prefer it not to have too much fragmentation, so if you do, just
hand out commit bits liberally, and copy the u4x stuff over to the new
repo. masak, is that OK for you?).

Cheers,
Moritz

-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

Re: Natural Language and Perl 6

[Carl Mäsak]

Jason ():
 No specific tool is best suited for natural language processing. There was
 apparently a time in which everyone thought that a formal grammar could
 clearly define any natural language, but I don't think anyone succeeded at
 creating a complete formal grammar for any language other than something
 like Esperanto.

Even Esperanto is about on the same level of complexity as your
regular Indo-European language. Sure, the word-formation is more
regular, but the freedom in creating sentences with non-obvious
antecedents and all manner of ambiguity, is just as large as in any
national language.

Now, had you said Lojban, I'd have believed you. :)

// Carl

Re: Natural Language and Perl 6

[yary]

This is getting more and more off topic, but if you want some lojban
pasers, start at
http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers

-y




On Mon, Aug 2, 2010 at 3:58 PM, Carl Mäsak cma...@gmail.com wrote:
 Jason ():
 No specific tool is best suited for natural language processing. There was
 apparently a time in which everyone thought that a formal grammar could
 clearly define any natural language, but I don't think anyone succeeded at
 creating a complete formal grammar for any language other than something
 like Esperanto.

 Even Esperanto is about on the same level of complexity as your
 regular Indo-European language. Sure, the word-formation is more
 regular, but the freedom in creating sentences with non-obvious
 antecedents and all manner of ambiguity, is just as large as in any
 national language.

 Now, had you said Lojban, I'd have believed you. :)

 // Carl

Re: Natural Language and Perl 6

[Aaron Sherman]

On Sun, Aug 1, 2010 at 6:46 AM, Timothy S. Nelson wayl...@wayland.id.auwrote:

Hi.  I'm wondering if any thought has been given to natural language
 processing with Perl 6 grammars.


Yes.

;)

-- 
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs

Natural Language and Perl 6

[Timothy S. Nelson]

	Hi.  I'm wondering if any thought has been given to natural language 
processing with Perl 6 grammars.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-

Re: Natural Language and Perl 6

[Alberto Simões]

Hello

On 01/08/2010 11:46, Timothy S. Nelson wrote:
 Hi.  I'm wondering if any thought has been given to natural language
 processing with Perl 6 grammars.

I Think Perl 6 grammars can implement the most advanced parsing
algorithms like Generic LR, that that will not really solve the problem
of NLP. Unfortunately.

Natural language is too ambiguous and needs special treatment. At least,
this is my opinion on working on NLP for the Portuguese for about en
years ;)

Cheers

 
 :)
 
 
 -
 | Name: Tim Nelson | Because the Creator is,|
 | E-mail: wayl...@wayland.id.au| I am   |
 -
 
 BEGIN GEEK CODE BLOCK
 Version 3.12
 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++
 PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
 -END GEEK CODE BLOCK-
 

-- 
Alberto Simões

Perl 6 User Documentation

[Offer Kaye]

Hi,
Following the release of Rakudo Star I've been playing around with
learning Perl 6 and noticed a distinct lack of user-facing
documentation. After some IRC chats with pmichaud++ I thought it would
be a good idea if I got the ball rolling, assuming of course it
doesn't reach a sharp incline, roll back and squash me.

Attached are a 3 very initial (skeletal in nature) Perl 6 .pod
documents, based loosely on the Perl 5 documentation. It is my
understanding that currently there is no P6-Pod reader e.g. perl6doc
so these are actually written in P5-POD, but the intent is to
eventually of course translate them to P6-Pod.

My purpose is to get very initial feedback, see if this is the right
direction to go at all, get some thoughts on basic terminology, stuff
like that. For example:
1. Use P5 POD or insist on P6 Pod?
2. Is it Perl 6 or just Perl? Currently it's perl6 but will it
be just perl eventually?
3. Can I just rename S26.pod to perl6pod.pod and be done with it? :)

Best regards,
-- 
Offer Kaye


perl6.pod
Description: Binary data


perl6doc.pod
Description: Binary data


perl6intro.pod
Description: Binary data

Re: Natural Language and Perl 6

[Jason Switzer]

On Sun, Aug 1, 2010 at 5:46 AM, Timothy S. Nelson wayl...@wayland.id.auwrote:

Hi.  I'm wondering if any thought has been given to natural language
 processing with Perl 6 grammars.


No specific tool is best suited for natural language processing. There was
apparently a time in which everyone thought that a formal grammar could
clearly define any natural language, but I don't think anyone succeeded at
creating a complete formal grammar for any language other than something
like Esperanto. Modern NLP seems to be focused on (empirical based)
stochastic models or other statistical models. Most languages can be used to
build and represent such systems. That being said, there are sub-fields
where it might help, such as stemming, POS tagging, or text generation.

Perl 6 grammars seem best suited to reduce the workload to build and
manipulate parse trees or lattice models. Depending on what task is at hand,
this may be of no use. I am finishing a masters in NLP and after all this
work, p6 grammars wouldn't have helped much.

-Jason s1n Switzer

Rakudo Star - a useful, usable, early adopter distribution of Perl 6

[Patrick R. Michaud]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the July 2010 release of Rakudo Star, a useful and usable
distribution of Perl 6.  The tarball for the July 2010 release is
available from http://github.com/rakudo/star/downloads.

Rakudo Star is aimed at early adopters of Perl 6.  We know that
it still has some bugs, it is far slower than it ought to be, and
there are some advanced pieces of the Perl 6 language specification
that aren't implemented yet.  But Rakudo Perl 6 in its current form
is also proving to be viable (and fun) for developing applications
and exploring a great new language.  These Star releases are
intended to make Perl 6 more widely available to programmers, grow
the Perl 6 codebase, and gain additional end-user feedback about the
Perl 6 language and Rakudo's implementation of it.

In the Perl 6 world, we make a distinction between the language 
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  Rakudo Star is a distribution that includes
release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of
the Parrot Virtual Machine [2], and various modules, documentation,
and other resources collected from the Perl 6 community.  We
plan to make Rakudo Star releases on a monthly schedule, with
occasional special releases in response to important bugfixes or
changes.

Some of the many cool Perl 6 features that are available in this
release of Rakudo Star:
  * Perl 6 grammars and regexes
  * formal parameter lists and signatures
  * metaoperators
  * gradual typing
  * a powerful object model, including roles and classes
  * lazy list evaluation
  * multiple dispatch
  * smart matching
  * junctions and autothreading
  * operator overloading (limited forms for now)
  * introspection
  * currying
  * a rich library of builtin operators, functions, and types
  * an interactive read-evaluation-print loop
  * Unicode at the codepoint level
  * resumable exceptions

There are some key features of Perl 6 that Rakudo Star does not
yet handle appropriately, although they will appear in upcoming
releases.  Thus, we do not consider Rakudo Star to be a
Perl 6.0.0 or 1.0 release.  Some of the not-quite-there
features include:
  * nested package definitions
  * binary objects, native types, pack and unpack
  * typed arrays
  * macros
  * state variables
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * pre and post constraints, and some other phasers
  * interactive readline that understands Unicode
  * backslash escapes in regex [...] character classes
  * non-blocking I/O
  * most of Synopsis 9
  * perl6doc or pod manipulation tools

In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are
many that we've missed.  Bug reports about missing and broken
features are welcomed.

See http://perl6.org/ for links to much more information about 
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources.

Rakudo Star also bundles a number of modules; a partial list of
the modules provided by this release include:
  * Blizkost
  - enables some Perl 5 modules to be used from within Rakudo Perl 6
  * MiniDBI
  - a simple database interface for Rakudo Perl 6
  * Zavolaj
  - call C library functions from Rakudo Perl 6
  * SVG and SVG::Plot
  - create scalable vector graphics
  * HTTP::Daemon
  - a simple HTTP server
  * XML::Writer
  - generate XML
  * YAML
  - dump Perl 6 objects as YAML
  * Term::ANSIColor
  - color screen output using ANSI escape sequences
  * Test::Mock
  - create mock objects and check what methods were called
  * Math::Model
  - describe and run mathematical models
  * Config::INI
  - parse and write configuration files
  * File::Find
  - find files in a given directory
  * LWP::Simple
  - fetch resources from the web

These are not considered core Perl 6 modules, and as module
development for Perl 6 continues to mature, future releases
of Rakudo Star will likely come bundled with a different set
of modules. Deprecation policies for bundled modules will be
created over time, and other Perl 6 distributions may choose
different sets of modules or policies.  More information about
Perl 6 modules can be found at http://modules.perl6.org/.

Rakudo Star also contains a draft of a Perl 6 book -- see 
docs/UsingPerl6-draft.pdf in the release tarball.

The development team thanks all of the contributors and sponsors
for making Rakudo Star possible.  If you would like to contribute,
see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org
mailing list, or join us on IRC #perl6 on freenode.

Rakudo Star releases are created on a monthly cycle or as needed
in response to important bug fixes or improvements.  The next planned 
release of Rakudo Star will be on August 24, 2010.

[1] http://github.com/rakudo

Re: Rakudo Star - a useful, usable, early adopter distribution of Perl 6

[Xiao Yafeng]

Congratulations!

On Thu, Jul 29, 2010 at 8:23 PM, Patrick R. Michaud pmich...@pobox.com wrote:
 On behalf of the Rakudo and Perl 6 development teams, I'm happy to
 announce the July 2010 release of Rakudo Star, a useful and usable
 distribution of Perl 6.  The tarball for the July 2010 release is
 available from http://github.com/rakudo/star/downloads.

 Rakudo Star is aimed at early adopters of Perl 6.  We know that
 it still has some bugs, it is far slower than it ought to be, and
 there are some advanced pieces of the Perl 6 language specification
 that aren't implemented yet.  But Rakudo Perl 6 in its current form
 is also proving to be viable (and fun) for developing applications
 and exploring a great new language.  These Star releases are
 intended to make Perl 6 more widely available to programmers, grow
 the Perl 6 codebase, and gain additional end-user feedback about the
 Perl 6 language and Rakudo's implementation of it.

 In the Perl 6 world, we make a distinction between the language
 (Perl 6) and specific implementations of the language such as
 Rakudo Perl.  Rakudo Star is a distribution that includes
 release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of
 the Parrot Virtual Machine [2], and various modules, documentation,
 and other resources collected from the Perl 6 community.  We
 plan to make Rakudo Star releases on a monthly schedule, with
 occasional special releases in response to important bugfixes or
 changes.

 Some of the many cool Perl 6 features that are available in this
 release of Rakudo Star:
  * Perl 6 grammars and regexes
  * formal parameter lists and signatures
  * metaoperators
  * gradual typing
  * a powerful object model, including roles and classes
  * lazy list evaluation
  * multiple dispatch
  * smart matching
  * junctions and autothreading
  * operator overloading (limited forms for now)
  * introspection
  * currying
  * a rich library of builtin operators, functions, and types
  * an interactive read-evaluation-print loop
  * Unicode at the codepoint level
  * resumable exceptions

 There are some key features of Perl 6 that Rakudo Star does not
 yet handle appropriately, although they will appear in upcoming
 releases.  Thus, we do not consider Rakudo Star to be a
 Perl 6.0.0 or 1.0 release.  Some of the not-quite-there
 features include:
  * nested package definitions
  * binary objects, native types, pack and unpack
  * typed arrays
  * macros
  * state variables
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * pre and post constraints, and some other phasers
  * interactive readline that understands Unicode
  * backslash escapes in regex [...] character classes
  * non-blocking I/O
  * most of Synopsis 9
  * perl6doc or pod manipulation tools

 In many places we've tried to make Rakudo smart enough to inform the
 programmer that a given feature isn't implemented, but there are
 many that we've missed.  Bug reports about missing and broken
 features are welcomed.

 See http://perl6.org/ for links to much more information about
 Perl 6, including documentation, example code, tutorials, reference
 materials, specification documents, and other supporting resources.

 Rakudo Star also bundles a number of modules; a partial list of
 the modules provided by this release include:
  * Blizkost
      - enables some Perl 5 modules to be used from within Rakudo Perl 6
  * MiniDBI
      - a simple database interface for Rakudo Perl 6
  * Zavolaj
      - call C library functions from Rakudo Perl 6
  * SVG and SVG::Plot
      - create scalable vector graphics
  * HTTP::Daemon
      - a simple HTTP server
  * XML::Writer
      - generate XML
  * YAML
      - dump Perl 6 objects as YAML
  * Term::ANSIColor
      - color screen output using ANSI escape sequences
  * Test::Mock
      - create mock objects and check what methods were called
  * Math::Model
      - describe and run mathematical models
  * Config::INI
      - parse and write configuration files
  * File::Find
      - find files in a given directory
  * LWP::Simple
      - fetch resources from the web

 These are not considered core Perl 6 modules, and as module
 development for Perl 6 continues to mature, future releases
 of Rakudo Star will likely come bundled with a different set
 of modules. Deprecation policies for bundled modules will be
 created over time, and other Perl 6 distributions may choose
 different sets of modules or policies.  More information about
 Perl 6 modules can be found at http://modules.perl6.org/.

 Rakudo Star also contains a draft of a Perl 6 book -- see
 docs/UsingPerl6-draft.pdf in the release tarball.

 The development team thanks all of the contributors and sponsors
 for making Rakudo Star possible.  If you would like to contribute,
 see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org
 mailing list, or join us on IRC #perl6 on freenode.

 Rakudo Star releases are created on a monthly cycle or as needed

Re: Rakudo Star - a useful, usable, early adopter distribution of Perl 6

[Gabor Szabo]

Congratulations and thank you!



I have started to collect the links to the press coverage of the release:

http://www.perlfoundation.org/perl6/index.cgi?rakudo_star_press

Please help me collect all the important links!

Gabor

Re: Rakudo Star - a useful, usable, early adopter distribution of Perl 6

[Kiffin Gish]

Good stuff, let's celebrate!

On Thu, 2010-07-29 at 07:23 -0500, Patrick R. Michaud wrote:
 On behalf of the Rakudo and Perl 6 development teams, I'm happy to
 announce the July 2010 release of Rakudo Star, a useful and usable
 distribution of Perl 6.  The tarball for the July 2010 release is
 available from http://github.com/rakudo/star/downloads.
 
 Rakudo Star is aimed at early adopters of Perl 6.  We know that
 it still has some bugs, it is far slower than it ought to be, and
 there are some advanced pieces of the Perl 6 language specification
 that aren't implemented yet.  But Rakudo Perl 6 in its current form
 is also proving to be viable (and fun) for developing applications
 and exploring a great new language.  These Star releases are
 intended to make Perl 6 more widely available to programmers, grow
 the Perl 6 codebase, and gain additional end-user feedback about the
 Perl 6 language and Rakudo's implementation of it.
 
 In the Perl 6 world, we make a distinction between the language 
 (Perl 6) and specific implementations of the language such as
 Rakudo Perl.  Rakudo Star is a distribution that includes
 release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of
 the Parrot Virtual Machine [2], and various modules, documentation,
 and other resources collected from the Perl 6 community.  We
 plan to make Rakudo Star releases on a monthly schedule, with
 occasional special releases in response to important bugfixes or
 changes.
 
 Some of the many cool Perl 6 features that are available in this
 release of Rakudo Star:
   * Perl 6 grammars and regexes
   * formal parameter lists and signatures
   * metaoperators
   * gradual typing
   * a powerful object model, including roles and classes
   * lazy list evaluation
   * multiple dispatch
   * smart matching
   * junctions and autothreading
   * operator overloading (limited forms for now)
   * introspection
   * currying
   * a rich library of builtin operators, functions, and types
   * an interactive read-evaluation-print loop
   * Unicode at the codepoint level
   * resumable exceptions
 
 There are some key features of Perl 6 that Rakudo Star does not
 yet handle appropriately, although they will appear in upcoming
 releases.  Thus, we do not consider Rakudo Star to be a
 Perl 6.0.0 or 1.0 release.  Some of the not-quite-there
 features include:
   * nested package definitions
   * binary objects, native types, pack and unpack
   * typed arrays
   * macros
   * state variables
   * threads and concurrency
   * Unicode strings at levels other than codepoints
   * pre and post constraints, and some other phasers
   * interactive readline that understands Unicode
   * backslash escapes in regex [...] character classes
   * non-blocking I/O
   * most of Synopsis 9
   * perl6doc or pod manipulation tools
 
 In many places we've tried to make Rakudo smart enough to inform the
 programmer that a given feature isn't implemented, but there are
 many that we've missed.  Bug reports about missing and broken
 features are welcomed.
 
 See http://perl6.org/ for links to much more information about 
 Perl 6, including documentation, example code, tutorials, reference
 materials, specification documents, and other supporting resources.
 
 Rakudo Star also bundles a number of modules; a partial list of
 the modules provided by this release include:
   * Blizkost
   - enables some Perl 5 modules to be used from within Rakudo Perl 6
   * MiniDBI
   - a simple database interface for Rakudo Perl 6
   * Zavolaj
   - call C library functions from Rakudo Perl 6
   * SVG and SVG::Plot
   - create scalable vector graphics
   * HTTP::Daemon
   - a simple HTTP server
   * XML::Writer
   - generate XML
   * YAML
   - dump Perl 6 objects as YAML
   * Term::ANSIColor
   - color screen output using ANSI escape sequences
   * Test::Mock
   - create mock objects and check what methods were called
   * Math::Model
   - describe and run mathematical models
   * Config::INI
   - parse and write configuration files
   * File::Find
   - find files in a given directory
   * LWP::Simple
   - fetch resources from the web
 
 These are not considered core Perl 6 modules, and as module
 development for Perl 6 continues to mature, future releases
 of Rakudo Star will likely come bundled with a different set
 of modules. Deprecation policies for bundled modules will be
 created over time, and other Perl 6 distributions may choose
 different sets of modules or policies.  More information about
 Perl 6 modules can be found at http://modules.perl6.org/.
 
 Rakudo Star also contains a draft of a Perl 6 book -- see 
 docs/UsingPerl6-draft.pdf in the release tarball.
 
 The development team thanks all of the contributors and sponsors
 for making Rakudo Star possible.  If you would like to contribute,
 see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org
 mailing list, or join us on IRC #perl6 on freenode.
 
 Rakudo Star

Re: Rakudo Star - a useful, usable, early adopter distribution of Perl 6

[Jerome Quelin]

On 10/07/29 07:23 -0500, Patrick R. Michaud wrote:
 On behalf of the Rakudo and Perl 6 development teams, I'm happy to
 announce the July 2010 release of Rakudo Star, a useful and usable
 distribution of Perl 6.  The tarball for the July 2010 release is
 available from http://github.com/rakudo/star/downloads.

congratulations, but help me help you guys.

i'm currently shipping parrot and rakudo in mandriva. what should i do
regarding rakudo-star:
  - juste update rakudo to rakudo-star
  - create a new package rakudo-star, alongside rakudo

if the former, will future monthly rakudo releases feature everything
that rakudo* is shipping? (modules, etc.)
if the latter, can rakudo-star use rakudo as its perl6 interpreter, and
only installs addons?

thanks,
jérôme 
-- 
jque...@gmail.com

Announce: Rakudo Perl 6 compiler development release #31 (Atlanta)

[Will Coleda]

On behalf of the Rakudo development team, I'm happy to announce the
July 2010 development release of Rakudo Perl #31 Atlanta.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the July 2010 release
is available from http://github.com/rakudo/rakudo/downloads.

Please note: This is not the Rakudo Star release, which is scheduled
for July 29, 2010 [1]. The Star release will include the compiler, an
installer, modules, a book (PDF), and more.

The Rakudo Perl compiler follows a monthly release cycle, with each release
named after a Perl Mongers group. The July 2010 release is code named
Atlanta in recognition of Atlanta.pm and their Perl 5 Phalanx project [2],
which they selected for its benefits to Perl 6.

Some of the specific changes and improvements occurring with this
release include:

* Rakudo now properly constructs closures in most instances.

* Undefined objects can now autovivify into arrays or hashes when
  subscripted with .[ ] or .{ } .

* Arrays can now handle infinite ranges.

* Generic, multi-level Whatever-currying now works, e.g. (1, 1, *+* ... *).

* The REPL shell now remembers lexical declarations in susbsequent lines.

* The open() subroutine now returns a Failure instead of throwing
  a fatal exception.

* Rakudo now provides $*ARGFILES for reading from files specified
  on the command line.

* Added $*PERL, moved %*VM to $*VM.

* Simple binding operators := and ::= now work.

* Simple feed operators == and == now work.

For a more detailed list of changes see docs/ChangeLog.

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible, as well as those people who worked on parrot, the
Perl 6 test suite and the specification.

The following people contributed to this release:
Patrick R. Michaud, Jonathan Worthington, Moritz Lenz, Solomon Foster,
Carl Masak, Bruce Gray, Martin Berends, chromatic, Will Coke Coleda,
Matthew (lue), Timothy Totten, maard, Kodi Arfer, TimToady, Stephen Weeks,
Patrick Abi Salloum, snarkyboojum, Radu Stoica, Vyacheslav Matjukhin,
Andrew Whitworth, cognominal, Tyler Curtis, Alex Kapranoff, Ingy döt Net,
Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯, mathw, lue, Вячеслав Матюхин

If you would like to contribute, see http://rakudo.org/how-to-help, ask on
the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#32) is scheduled for August 19, 2010.
A list of the other planned release dates and code names for 2010 is
available in the docs/release_guide.pod file.  In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release.  Parrot releases the third Tuesday of each month.

Have fun!

[1] http://rakudo.org/node/73
[2] http://code.google.com/p/atlanta-pm-code/


-- 
Will Coke Coleda

Re: Perl 6 in non-English languages

[Gabor Szabo]

On Wed, Jun 23, 2010 at 1:34 AM, SundaraRaman R
sundaryourfri...@gmail.com wrote:
 Hi,

 This is an idea that originated in #perl6 during a discussion with slavik (
 http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow
 Perl 6 source code to be written in natural languages other than English.
 The motivation would be to make programming accessible to a lot of people
 who don't know English well (or at all), to make it easier to teach
 programming to kids in non-English speaking countries, and just plain fun.

 Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place
 a modification is required would be in the keywords. However, it is not a
 simple matter of substituting s/keyword/local_language_keyword/ since the
 resultant phrasing might be awkward or meaningless and unreadable (examples
 in the linked discussion). It requires reordering the syntax of each
 construct.

 Is it possible to do this at a module level? If so, how much English usage
 would that require before someone could start programming in their own
 language - say, two, for a shebang line and a use Lang::Language line?
 or zero, by using perl6 -MLang::Language in the command line?

 Are there any ongoing works in this vein?

It is a bit hard for me to imagine how that would look like in RTL
languages such as Hebrew or Arabic.
Would the sigils be still at the beginning of the word?
Would the assignments go from left to right?

;שלי $משתנה = 42

and I could not manage to type in a for loop via the Gmail interface
as it was turning around all the time.


What I'd like to see is a Scratch-like tool for a subset of Perl 6
that can actually generate Perl 6 code.
http://scratch.mit.edu/

I know, I talked about it already a year ago.

Gabor

Re: Perl 6 in non-English languages

[Moritz Lenz]

Am 23.06.2010 22:51, schrieb Aaron Sherman:

Moving on to more general theories on the matter, I believe that localized
dialects of programming languages are always a bad idea.


I totally agree.

However there are things that can be translated to other languages, and 
that is documentation, error messages and warnings.


The latter two require that we standardize exception types and messages, 
and provide some means to load different localizations.


If somebody could take on that project, that would be really great for 
non-English speakers (and would also help the standard, English 
implementation, because standardize exceptions make testing of 
meaningful errors much easier).


That would be a real benefit for the Perl 6 landscape at large, and 
probably not all too difficult (I'm sure that implementors of compilers 
and STD.pm will help with technical details where necessary, I for one 
would do my best to integrate such an effort into Rakudo).


Cheers,
Moritz

Re: Perl 6 in non-English languages

[Darren Duncan]

Moritz Lenz wrote:
However there are things that can be translated to other languages, and 
that is documentation, error messages and warnings.


And the next step is non-error messages intended to be seen by users.

The latter two require that we standardize exception types and messages, 
and provide some means to load different localizations.


If somebody could take on that project, that would be really great for 
non-English speakers (and would also help the standard, English 
implementation, because standardize exceptions make testing of 
meaningful errors much easier).


That would be a real benefit for the Perl 6 landscape at large, and 
probably not all too difficult (I'm sure that implementors of compilers 
and STD.pm will help with technical details where necessary, I for one 
would do my best to integrate such an effort into Rakudo).


I highly recommend a key-based approach, such that not even the English versions 
of these error messages and warnings etc are in the program code, but rather are 
in separate files, in the same format as versions of any other languages, and 
that the only thing actually in the code is a non-human-language lookup key, 
though that can be meaningful to programmers such as a variable name is.


See my simple Locale::KeyedText module for a working proof of concept of what I 
speak of.  Its the first module of mine that has matching Perl 5 and Perl 6 
versions, and I had produced the Perl 6 version in 2005 as part of the early 
Pugs development effort.  This said, I haven't updated it in years and I don't 
expect it to still run under Rakudo, but it did run under Pugs in the day.


The concept I describe and demonstrated is inspired by how Mac OS X works, where 
all user text is in separate language resource files.


I also recommend against the older gettext (name?) design that involved having 
one language's text inside the program code and using that as a key for others. 
 I prefer the more self-consistent design that I proposed.


-- Darren Duncan

Re: Perl 6 in non-English languages

[yary]

Reminds me of an article of yore from The Perl Journal Localizing
Your Perl Programs http://interglacial.com/tpj/13/ which discusses
the reasoning behind Locale::Maketext

the point of which is that the values you're looking up should be
able to be functions, to handle some edge cases where nothing else
will do. That module isn't exactly what Darren is looking for since
the keys are English strings with a little meta-language mixed in, but
the rest of it is worth referencing.

Re: Perl 6 in non-English languages

[Darren Duncan]

yary wrote:

Reminds me of an article of yore from The Perl Journal Localizing
Your Perl Programs http://interglacial.com/tpj/13/ which discusses
the reasoning behind Locale::Maketext

the point of which is that the values you're looking up should be
able to be functions, to handle some edge cases where nothing else
will do. That module isn't exactly what Darren is looking for since
the keys are English strings with a little meta-language mixed in, but
the rest of it is worth referencing.


Functions are fine.  My main point is that all languages are treated in exactly 
the same way as far as where their user text is stored and what format it has. 
The common format could in fact be a Perl module for each language containing 
the user text, and these all do a common role representing all the messages that 
could be used.


You should not be treating the user text for one language differently from 
others, by using the text of one language to look up the text of another, or by 
embedding one user language in the main program code.


Now, this isn't to say that the common key can't resemble English, but you 
should still have the separate copies of all the messages that are the actual 
user text, and the common English-like key can be a simplified version.


A main point here is that if any translator or human-interfaces person wants to 
tweak user text, say to capitalize a word or fix a misspelling, they shouldn't 
have to go into the main program code to do it, and the process is the same for 
every language, and you only have to update not more than one copy or location 
per language.


Something I want to avoid is the actual English user text being used to look up 
the others, because then if you want to tweak a misspelling or something in 
English, you'd then have to find an change all the other copies of the text in 
order for the mapping to be maintained.


Its a similar problem actually to a bad relational database design, where you 
use something descriptive and likely to mutate (such as the English name of a 
product for sale) as the column that a foreign key copies and points to, in 
contrast to say a less descriptive product code.  What I am proposing is to use 
the analogy of the product code in your main code rather than the English 
product name.  But the code can still be quite English like.


Such as a role's function name can be English like.

-- Darren Duncan

Perl 6 in non-English languages

[SundaraRaman R]

Hi,

This is an idea that originated in #perl6 during a discussion with slavik (
http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow
Perl 6 source code to be written in natural languages other than English.
The motivation would be to make programming accessible to a lot of people
who don't know English well (or at all), to make it easier to teach
programming to kids in non-English speaking countries, and just plain fun.

Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place
a modification is required would be in the keywords. However, it is not a
simple matter of substituting s/keyword/local_language_keyword/ since the
resultant phrasing might be awkward or meaningless and unreadable (examples
in the linked discussion). It requires reordering the syntax of each
construct.

Is it possible to do this at a module level? If so, how much English usage
would that require before someone could start programming in their own
language - say, two, for a shebang line and a use Lang::Language line?
or zero, by using perl6 -MLang::Language in the command line?

Are there any ongoing works in this vein?

Sincerely,
Sundar

-- 
! Knowing others is intelligence; knowing yourself is true wisdom. Mastering
others is strength; mastering yourself is true power.
http://www.google.com/profiles/sundaryourfriend

Re: Perl 6 in non-English languages

[yary]

If Perl 5 can support
Lingua::Romana::Perligatahttp://www.csse.monash.edu.au/%7Edamian/papers/HTML/Perligata.htmland
let you type 

benedictum factori sic mori cis classum.

instead of

bless sub{die}, $class;

then Perl 6 should be able to do it even better. I think it would be
implemented through a set of macros. Unfortunately at the moment, the Perl 6
implementation that is the most advanced at the moment, Rakudo, does not
support macros. (I'm not sure about Sprixel, Mildew, etc). So while the
language specification would make it possible to use a different natural
language as a base, it can't be implemented by the most natural method.

Re: Perl 6 in non-English languages

[Elizabeth Mattijsen]

On Jun 23, 2010, at 12:34 AM, SundaraRaman R wrote:
 This is an idea that originated in #perl6 during a discussion with slavik (
 http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow
 Perl 6 source code to be written in natural languages other than English.
 The motivation would be to make programming accessible to a lot of people
 who don't know English well (or at all), to make it easier to teach
 programming to kids in non-English speaking countries, and just plain fun.
 
 Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place
 a modification is required would be in the keywords. However, it is not a
 simple matter of substituting s/keyword/local_language_keyword/ since the
 resultant phrasing might be awkward or meaningless and unreadable (examples
 in the linked discussion). It requires reordering the syntax of each
 construct.
 
 Is it possible to do this at a module level? If so, how much English usage
 would that require before someone could start programming in their own
 language - say, two, for a shebang line and a use Lang::Language line?
 or zero, by using perl6 -MLang::Language in the command line?
 
 Are there any ongoing works in this vein?

Having been that road down at least once in my life already (using the TUTOR 
language), I would be very much against adding this as a standard feature.  
Unless you have people that can provide support (aka a user base) for that 
language, you are going to introduce a babylonian knot of misunderstanding in 
mailinglist, chats and what not.

If this would be added as a feature, then there should be an easy way to take 
any source file in a different natural language, and have it rendered into 
English (or any other of the languages supported that way).


My old 2cents worth...


Going back to lurking mode again.


Liz

Re: Perl 6 in non-English languages

[Aaron Sherman]

On Tue, Jun 22, 2010 at 6:34 PM, SundaraRaman R
sundaryourfri...@gmail.comwrote:


 Currently, since Perl 6 (afaik) supports Unicode identifiers, the only
 place
 a modification is required would be in the keywords.


Here's the relevant bits from S02:

The currently compiling Perl parser is switched by modifying one of the
braided languages in COMPILING::%?LANG. Lexically scoped parser changes
should temporize the modification. Changes from here to end-of-compilation
unit can just assign or bind it. In general, most parser changes involve
deriving a new grammar and then pointing one of the
COMPILING::%?LANGentries at that new grammar. Alternately, the
tables driving the current
parser can be modified without derivation, but at least one level of
anonymous derivation must intervene from the preceding Perl grammar, or you
might be messing up someone else's grammar. Basically, the current set of
grammars in %?LANG has to belong only to the current compiling scope. It may
not be shared, at least not without explicit consent of all parties. No
magical syntax at a distance. Consent of the governed, and all that.


So you could, for example, derive your grammar from the Perl compiler's
grammar and define your own rule for logical and, using the keyword
florgle instead of and. There's more complexity to it than that, when
I'll touch on, below, however.

However, it is not a
 simple matter of substituting s/keyword/local_language_keyword/ since the
 resultant phrasing might be awkward or meaningless and unreadable (examples
 in the linked discussion). It requires reordering the syntax of each
 construct.



I can't think of any case where that would be reasonable. Perl may have
taken some inspiration from English in terms of features like postfix
conditionals, but the structure of the language has nothing to do with what
the keywords mean in any given language. and could just as easily be
florgle (pardon my language), the construct would still be:

  if $a florgle $b florgle $c { die Mega florgle }

If your language doesn't do infix conjunctions, and instead lists the
relationships between items at the end of a sentence, re-iterating the items
whose relationships are being established, that's not a reason for Perl to
then be re-structured as:

  if $a, $b, $c florgle $a, $b, $c { die Mega florgle }

Worse, what would that mean for hyperoperators and other meta operations?

More importantly localized dialects of Perl 6 face some substantial
challenges even without re-structuring. Operators (remember, Perl 6 doesn't
have keywords in the traditional sense)  have a meta-meaning in Perl 6, and
if I write:

  multi sub infix:and(MyType $a, MyType $b) { $a.truth and $b.truth }

then I expect that to affect what happens when you try to perform a logical
union on two values of type MyType. There are two options when localizing:

1) You can change the grammar, but leave the operator's definition alone
(e.g. the action for that operator calls infix:and regardless of what the
name in the grammar is), or

2) You can change both the grammar and the operator.

If you do the former, then my and still works, but you can't define a
multi sub infix:florgle and have it do what you expect.

If you do the latter then your multi sub infix:florgle would work, but
mine won't (and if it's library code, then you have a problem where bugs are
now localization-specific. Ugh.

Moving on to more general theories on the matter, I believe that localized
dialects of programming languages are always a bad idea. Choosing a
spoken/written language to base a programming language on is always tricky
(I would have voted for Japanese for Perl 6, even being an English speaker),
but once that choice is made, the resulting programming language gives
speakers of any arbitrary language an opportunity to interact with the
developers from every culture in the world, simply by learning the
structured conventions of the programming language (and quite possibly NOT
the language from which it takes its cues).

If you choose, instead to program in Swahili Perl 6 then only people who
read Swahili will be able to tell what it was you were talking about,
whereas speakers of every language on Earth will know what you meant when
you write vanilla Perl 6.

Of course, education is often brought up in these discussions. I consider
this a red herring. The United States is particularly prone to using
localized versions of international symbols (e.g. meter), and this proves
confusing when interacting with the rest of the world. Take this to an
extreme, and we'd be taught to write 907 thousandsmallweights to the short
ton rather than 907 kilograms and that's just not going to help anyone
(yes, I'm aware that Brits try to spell that grammes, and I refer my right
honorable limeys to ISO 8-1:2009).

Sure, Perl 6 allows you to localize names. In theory, but I'd be very
concerned about anyone who actually wanted to promote the use of such a
thing.

-- 
Aaron Sherman
Email

Re: Perl 6 in non-English languages

[Aaron Sherman]

I should point out that I've had a great deal of coffee. The technical
details of what I've said are reasonable, but read the rest as off-the-cuff
opinion.

It's also true that seeing how Perl 6 would look/work when re-cast in the
grammatical conventions of another human language would be very cool, even
if I might take exception to its proposed use.

Re: Perl 6 in non-English languages

[Jon Lang]

Another thing to consider is that Perl 6 is symbol-heavy: that is, keywords
are often symbols (such as , =, or $_) rather than words.  AFAIK, those
symbols are not English, and I would not expect them to change under a
natural language transformation of the setting.  And to elaborate on Aaron's
point, I'd expect such things as function call syntax, operator syntax,
method call syntax, and the like to remain the same, as these things aren't
English either.

As for seeing a natural language variant of Perl, my own thought is that
the first such variant might be most useful if it mines a decidedly
artificial natural language for its keywords, such as Esperanto or
Interlingua.  Given that Perl is not English, and merely uses English loan
words whenever it needs alphanumeric keywords, I suspect that an
Interlingua-based variant might be close enough to, say, a Spanish- or
French-based variant that the latter two might possibly end up not being
worth the trouble of writing.

Not being a linguist, I could be wrong about any or all of the above.


As for Aaron's concerns about the use of alternate natural languages
complicating the use of modules: note that this really isn't any different
from any case where you change the underlying grammar.  Perl has a robust
module system that assumes that each module is written in the Perl dialect
that the module specifies rather than in the dialect that the script is
written in, and vice versa; so aside from the optional hassle of translating
English-based modules into the preferred natural language setting when you
import them (or vice versa, in the case of modules that are written in other
natural language variants), there is unlikely to be much of a problem from
Perl's perspective.

In terms of the Perl community, I suspect that we're best off assuming that
most Perl modules and scripts should be written using the default
English-based setting for the foreseeable future; the use of natural
language variants should be considered to be a niche market.  When and if
English gets supplanted by some other language as the technical language of
choice, this notion can be revisited.  Assuming that Perl is still in
reasonably wide use when that happens, it will have the flexibility to make
the transition.

-- 
Jonathan Dataweaver Lang

Re: Announce: Rakudo Perl 6 development release #30 (Kiev)

[Darren Duncan]

So, is Rakudo Star meant to be a parallel release series, sort of like Perl 
5.12.x vs 5.13.x are now, or are the monthly Rakudo releases we've been seeing 
going to be named Star at some point?  I thought I read recently that Star 
would be coming in June. -- Darren Duncan

Re: Announce: Rakudo Perl 6 development release #30 (Kiev)

[Stefan O'Rear]

On Thu, Jun 17, 2010 at 04:55:38PM -0700, Darren Duncan wrote:
 So, is Rakudo Star meant to be a parallel release series, sort of like 
 Perl 5.12.x vs 5.13.x are now, or are the monthly Rakudo releases we've 
 been seeing going to be named Star at some point?  I thought I read 
 recently that Star would be coming in June. -- Darren Duncan

Rakudo Star is a parrallel release series; however, it is not a series of
compiler releases, but a series of complete Perl 6 environments.  A
single release of Rakudo Star will contain:

- Some version of Rakudo (not necessarily a monthly)
- Some version of Parrot
- Some random libraries
- Documentation

all vetted to work OK together.

-sorear


signature.asc
Description: Digital signature

Re: Announce: Rakudo Perl 6 development release #30 (Kiev)

[Darren Duncan]

Stefan O'Rear wrote:

On Thu, Jun 17, 2010 at 04:55:38PM -0700, Darren Duncan wrote:
So, is Rakudo Star meant to be a parallel release series, sort of like 
Perl 5.12.x vs 5.13.x are now, or are the monthly Rakudo releases we've 
been seeing going to be named Star at some point?  I thought I read 
recently that Star would be coming in June. -- Darren Duncan


Rakudo Star is a parrallel release series; however, it is not a series of
compiler releases, but a series of complete Perl 6 environments.  A
single release of Rakudo Star will contain:

- Some version of Rakudo (not necessarily a monthly)
- Some version of Parrot
- Some random libraries
- Documentation

all vetted to work OK together.


Ah, that's even better than I expected.

So then the experience to a Perl 6 user could be like the same opaque experience 
of installing Perl 5 or some other language, where the whole language 
implementation is together and a single configure/make/etc will take care of 
everything, and users don't have to know about the distinct Parrot+Rakudo+etc 
components if they don't want to, as they get the perl binary.


Will this package work on Windows too like Strawberry for Perl 5 (I'm not a 
Windows user but that's a valuable project), or just Unixen for now?


-- Darren Duncan

Advocating Perl 6

[Aaron Sherman]

As the time nears, I figured some buzz was in order, and to help with
that, I'm Buzzing about Perl 6. If you would like to follow me /
reshare / comment, you can go here:

http://www.google.com/profiles/AaronJSherman#buzz

My current goal is to post a short snippet of Perl 6 code with an
equally brief explanation every day. We'll see how long I can keep it
up.

-- 
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs

Announce: Rakudo Perl 6 development release #29 (Erlangen)

[Solomon Foster]

On behalf of the Rakudo development team, I'm pleased to announce the
May 2010 development release of Rakudo Perl #29 Erlangen.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org).  The tarball for the May 2010 release
is available from http://github.com/rakudo/rakudo/downloads .

Rakudo Perl follows a monthly release cycle, with each release named
after a Perl Mongers group.  The May 2010 release is code named
Erlangen in recognition of Erlangen.pm and the Perl 6 talk that Moritz
Lenz, one of our core developers, gave this month.

Some of the specific changes and improvements occurring with this
release include:

* Lexical classes and roles were implemented. Additionally, anonymous classes
  -- which were never quite right in alpha -- are now implemented more
  correctly, and anonymous roles are also supported.

* Basic support for named enumerations of the form 'enum Weekday Monday
  Tuesday ...' has been restored.

* First cut of use Foo:fromperl5 and eval('foo', :langperl5); needs
  Blizkost[1] to be installed to work.

*  Numeric / Real roles much closer to the spec now.

*  As always, many additional small features and bug fixes make working with
   Rakudo more pleasant.

*  Rakudo now passes 32,347 spectests. We estimate that there are about
   39,500 tests in the test suite, so Rakudo passes about 82% of all tests.

For a more detailed list of changes see docs/ChangeLog.

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible, as well as those people who worked on parrot, the
Perl 6 test suite and the specification.

The following people contributed to this release:
Solomon Foster, Moritz Lenz, Jonathan Worthington, Martin Berends,
chromatic, Carl Masak, snarkyboojum, Stefan O'Rear, Reini Urban,
Jonathan Scott Duff, takadonet, Christoph Otto, isBEKaml,
ash_, bubaflub, Jimmy Zhuo, Peter Lobsinger and Patrick Abi Salloum

If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org
mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#30) is scheduled for June 17, 2010.
A list of the other planned release dates and code names for 2010 is
available in the docs/release_guide.pod file.  In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release.  Parrot releases the third Tuesday of each month.

Have fun!

[1] http://github.com/jnthn/blizkost

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

Rakudo Perl 6 development release #28 (Moscow)

[Moritz Lenz]

On behalf of the Rakudo development team, I'm pleased to announce the
March 2010 development release of Rakudo Perl #28 Moscow.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org).  The tarball for the April 2010 release
is available from http://github.com/rakudo/rakudo/downloads .

Rakudo Perl follows a monthly release cycle, with each release named
after a Perl Mongers group.  The April 2010 release is code named
Moscow in recognition of Москва.пм and their invitation of Jonathan
Worthington, one of our core develepors, to speak at the Russian Internet
Technologies 2010 [1] conference.

Some of the specific changes and improvements occuring with this
release include:

*  Expressions that begin with a variable and end with a circumfix now 
properly interpolate into double-quoted strings, like @array.sort() or 
%hashkey.


*  Item assignment now has tighter precdence than list assignment, so 
both 'my @a = 1, 2, 3' and '$a = 1, $b = 2' magically work.


*  Most of the DateTime built-in type has been backported from the 
alpha branch, and is now accompanied by a Date type for date-only 
calculations.


*  Many obsolete uses of Perl 5 constructs are now caught and give 
helpful  error messages.


*  As always, many additional small features and bug fixes make working 
with Rakudo more pleasant.


*  Rakudo now passes 30,931 spectests. We estimate that there are about 
39,000 tests in the test suite, so Rakudo passes about 79% of all tests.


For a more detailed list of changes see docs/ChangeLog.

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible.  If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org
mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#29) is scheduled for May 20, 2010.
A list of the other planned release dates and code names for 2010 is
available in the docs/release_guide.pod file.  In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release.  Parrot releases the third Tuesday of each month.

Have fun!

Re: Rakudo Perl 6 development release #28 (Moscow)

[Andrew Shitov]

Moscow.pm also reminds that today (22 Apr) is the birthday of Lenin :-)

 March 2010 development release of Rakudo Perl #28 Moscow.

-- 
Andrew Shitov
__
a...@shitov.ru | http://shitov.ru