Re: Unwanted failure and FAILGOAL

[Moritz Lenz]

Hi,

On 05/11/2016 07:45 AM, Richard Hainsworth wrote:

I have the following in a grammar

 rule TOP{ ^ + $ };

 rule statement  {  '=' 
  | { { self.panic($/, "Declaration syntax
incorrect") } }
 };

 rule endvalue   {  '(' ~ ')' 
  | { self.panic($/, "Invalid declaration.") }
 }

The grammar parses a correct input file up until the end of the file. At
that point even if there is no un-consumed input, there is an attempt to
match , which fails. The failure causes the panic with 'Declaration
syntax'.

Am I missing something simple here?

I would have thought  (though this is only a very newbie assumption)
that if the end of the input being sent to the grammar has been reached
after the last  has been matched, then there should be no
reason for the parse method to try to match  again, and if it
fails to test for the end of input.


This is not how regexes or grammars work.

The + quantifier tries as many times as possible to match the regex. It 
doesn't look ahead to see if more characters are available, and it 
doesn't know about the end-of-string anchor that comes next in the grammar.


In fact, it doesn't know if the rule it quantifies might have a way to 
match zero characters. In this case, it would be wrong behavior to not 
do a zero-width at the end of the string.


As for improving the error reporting from within a grammar, there are 
lots of way to get creative, and I'd urge you to read Perl 6's own 
grammar, which is a good inspiration for that.

See https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp

One thing you could do is structure the statement rule differently:

rule statement {

   [  '=' 
   || { self.panic($/, "Invalid declaration.")
   ]
}

And maybe also TOP:

rule TOP{ ^ [  || . { self.panic($/, "Expected a 
statement") } ] $ };


That extra dot before the panic ensures it's not called at the end of 
the string. If you don't want that, you could also do


[  || $ || { self.panic(...) } ]

Cheers,
Moritz

Re: Rationale for $!

[Moritz Lenz]

Hi,

On 01/28/2016 04:06 PM, Todd C. Olson wrote:
> Is there a way to make the exception be thrown eagerly, at the devision 
> statement rather than waiting until use, at the say statement?

Yes, 'use fatal;'

Cheers,
Moritz

Re: Rationale for $!

[Moritz Lenz]

On 01/27/2016 04:32 PM, Felipe Gasper wrote:

On 27 Jan 2016 10:15 AM, Moritz Lenz wrote:


On 01/27/2016 03:15 PM, Felipe Gasper wrote:

So, what *is* the scoping of $!?


Scoped to a routine, iirc (sub, method, regex)


Interesting. JavaScript programmers that I’ve known bemoan that their
language uses function scoping rather than block scoping.

That also seems incongruent with the built-in block scoping for try/CATCH.

Has Perl 6 embraced function scoping as a major paradigm, then?


I wouldn't say "major paradigma", but it's not the only construct that 
uses routine scoping. return() and fail() come to mind, which are also 
routine-scoped.



But, what is the point of $! at all?


Convenience. It makes it easy to write commonly-used constructs much faster.

My mostly unscientific approach to gather usage of try vs. CATCH in the 
ecosystem:
moritz@hack:~/p6/perl6-all-modules$ git grep --word CATCH | wc -l 


461
moritz@hack:~/p6/perl6-all-modules$ git grep --word try | wc -l
864

CATCH is also rather clunky by comparison (requires an explicit block, 
whereas 'try' can be used as a statement prefix; requires a "when" or 
"default" blocks).



$! is also not mentioned here: http://perl6intro.com/#_exception_handling


Feel free to fix that by submitting a pull request :-)

Cheers,
Moritz

Re: Rationale for $!

[Moritz Lenz]

Hi,

On 01/27/2016 07:17 AM, Felipe Gasper wrote:

Hello,

 What is the purpose of having $! in Perl 6?

 The global variables in Perl 5 are a constant headache, prompting
us to need to local()ize variables like $@, $!, and $? to avoid
unforeseen consequences like RT #127386 and those documented in
Try::Tiny’s POD.

 Perl 6 seems to give us both the “right” and the “wrong” solution
to accessing exception variables: we get $_ within a CATCH block
(right), but we also get that global $!--which, to me, seems
pathologically wrong.


But it's not global! None of $_, $/, $! are global.

Cheers,
Moritz

Re: Rationale for $!

[Moritz Lenz]

On 01/27/2016 03:15 PM, Felipe Gasper wrote:

So, what *is* the scoping of $!?


Scoped to a routine, iirc (sub, method, regex)

Announce: Rakudo Star Release 2015.11

[Moritz Lenz]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the November 2015 release of "Rakudo Star", a useful and usable
distribution of Perl 6. The tarball for the November 2015 release is
available from .

This Rakudo Star release comes with support for the MoarVM
backend (all module tests pass on supported platforms).

In the Perl 6 world, we make a distinction between the language
("Perl 6") and specific implementations of the language such as
"Rakudo Perl". This Star release includes [release 2015.11] of the
[Rakudo Perl 6 compiler], version 2015.11 of [MoarVM], plus various
modules, documentation, and other resources collected from the
Perl 6 community.

[release 2015.11]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.11.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[MoarVM]: http://moarvm.org/

Some of the new compiler features since the ast Rakudo Star release include:

+ There is now an `infix:<.>` operator that does method calls with slightly
  looser precedence than the postfix unary method call.
+ New operator `infix o` for function composition
+ `fc` for Unicode-correct case folding implemented
+ grep now accepts :k, :v, :kv, :p attributes
+ `Supply.throttle` for rate-limiting
+ Array.push is now used for pushing one element (mostly); Array.append
  exists for pushing multiple values. Same for `unshift`/`prepend`
+ Basic arithmetic operations (`+`, `*`, `-`, `/`) on Range objects
  that shift or scale the end points while maintaining exclusions
+ The v notation now allows alphabetic components: v1.2.beta.  (Incompatible
  because method calls on a version must be protected by \ or () now.)
+ `use v6b+;` notation is now recognized and enforced
+ Many built-in methods that return iterables are now much faster
+ Better error messages when comparing version strings with numbers
+ Several error messages that were lacking line numbers now include them
+ Initial shaped array support
+ `\r\n` (Carriage Return/LineFeed) is now a single (synthetic) grapheme
+ Unicode support adheres to Unicode Annex #29
+ Unicode quotes are now also allowed in regular expressions
+ Improved newline support with "use newline" and updates to IO::Handle
+ Added List.head, List.tail, List.repeated methods
+ Str.encode now allows :replacement parameter for unencodable sequences
+ Str.split now accepts multiple strings to split on
+ New Range.int-bounds returns first/last value for integer ranges
+ Auto-generated meta-ops vivified by referring to them, instead of
executing
+ Illegal assignment of different Numeric values now caught at compile time
+ `` implemented, which returns the routine that `nextsame`
would invoke
+ Many speedups

The Rakudo Perl 6 compiler is now officially in beta for the upcoming
production release around Christmas 2015.

Please note that this release of Rakudo Star is not fully functional
with the
JVM backend from the Rakudo compiler. Please use the MoarVM backend only.

Notable changes in modules shipped with Rakudo Star:

* Bailador: Add MIT License
* DBIish: Improved Windows support
* doc: More documentation; generated HTML is better searchable
* Template::Mustache: Switched from LGPL to Artistic License 2.0
* panda: Default action is no longer `install`; better help messages
* Digest::MD5: Now accepts non-ASCII input (internally encodes as Latin-1)
* LWP::Simple: Support for successful return codes besides 200
* Shell::Command: `which` routine for locating executables
* Updated docs/2015-spw-perl6-course.pdf from Nov 21

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * non-blocking I/O (in progress)
  * much of Synopsis 9 and 11

There is an online resource at 
that lists the known implemented and missing features of Rakudo's
backends and other Perl 6 implementations.

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 at .

See  for links to much more information about
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources. A
Perl 6 tutorial is available as docs/2015-spw-perl6-course.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
, ask on the 
mailing list, or join us on IRC \#perl6 on freenode.

Re: confused about 'try'

[Moritz Lenz]

Hi,

On 11/24/2015 06:39 AM, brad clawsie wrote:
> Been playing with perl6 and it is truly amazing.
> 
> I'm somewhat confused as to when I should should wrap subroutine
> invocations with `try`. My `CATCH` clauses seem to be able to catch
> thrown Exception instances if I use `try` or not.

That's correct. "try" is merely a convience for catching all exceptions,
and not needed when you have an explicit CATCH block.

> I see in the
> "Exceptional Perl 6" slide deck
> ( http://moritz.faui2k3.org/files/talks/2013-yapc-p6-exceptions/ ),
> there seems to be an indication that `try` should be used when I want to
> access a Backtrace...is there something here I am missing?

The exception object always gives you access to the backtrace. If you
use CATCH, then the exception is in $_ inside the CATCh block. If you
use try, the exception is in $! outside the try block.

Here are two examples that do the same thing:

try { die "oh noez" };
say $!.message; # oh noez
say $!.^name;   # X::AdHoc

do {
die "oh noez";
CATCH {
default {
say .message;   # oh noez
say .^name; # X::AdHoc
}
}
}

Why bother with the more verbose form at all? There are basically two
reasons:
1) you can chose to only catch some exceptions, like
EVAL $some-code;
CATCH {
   when X::Comp {  say "Your code didn't even compile" };
   # let run-time exceptions fall through
}

2) When you want to access some variables from the inner scope that
produced the exception. Since CATCH runs before the stack is unwound,
you can even inspect dynamic variables.

Cheers,
Moritz

Re: Backwards compatibility and release 1.0

[Moritz Lenz]

On 10/15/2015 10:47 AM, Smylers wrote:

Moritz Lenz writes:


On 10/13/2015 10:52 AM, Richard Hainsworth wrote:


Following on the :D not :D thread, something odd stuck out.

On 10/13/2015 03:17 PM, Moritz Lenz wrote:


We have 390+ modules, and hand-waving away all trouble of
maintaining them seems a bit lofty.


Surely, the idea of keeping the release number below 1.0 is to warn
early adopter developers that code is subject to change and thus in
need of maintenance?


... a large percentage of the module updates are done by group of
maybe five to a dozen volunteers. ... 5 people updating 70% of 390
modules. Modules they are usually not all that familiar with, and
usually don't have direct access. So they need to go through the pull
request dance, waiting for reaction from the maintainer. In short, it
sucks.


Thanks for the explanation, Moritz. That does make sense.

I'm still a _little_ uneasy because that sounds a bit like the
explanation of why Makefiles have to use tab characters:

   I just did something simple with the pattern newline-tab. It worked,
   it stayed. And then a few weeks later I had a user population of about
   a dozen, most of them friends, and I didn't want to screw up my
   embedded base. The rest, sadly, is history.

 — Stuart Feldman http://stackoverflow.com/a/1765566/1366011


The problem is, that with this kind of argument one can defer the 
declaration of a "stable" version indefinitely.


May I remind everybody that we want a stable release this Christmas?

Cheers,
Moritz

Re: Backwards compatibility and release 1.0

[Moritz Lenz]

On 10/13/2015 10:52 AM, Richard Hainsworth wrote:

Following on the :D not :D thread, something odd stuck out.

On 10/13/2015 03:17 PM, Moritz Lenz wrote:



But hopefully none of them breaking backwards compatibility on such a
large scale. The last few backwards incompatible changes still cause
pain in the ecosystem. We have 390+ modules, and hand-waving away all
trouble of maintaining them seems a bit lofty.



Surely, the idea of keeping the release number below 1.0 is to warn
early adopter developers that code is subject to change and thus in need
of maintenance?


It is. But we still should try to limit the module author's burden.

In Practice, there's a small number of people who try to update modules 
to match when the compiler changed. Most module authors don't hang out 
in #perl6, eager to update their modules to the lastest rakudo change.


So a large percentage of the module updates are done by group of maybe 
five to a dozen volunteers. So, do the math: 5 people updating 70% of 
390 modules. Modules they are usually not all that familiar with, and 
usually don't have direct access. So they need to go through the pull 
request dance, waiting for reaction from the maintainer. In short, it sucks.


The ecosystem hasn't yet fully recovered from the s/done/done-testing/ 
change, nor from the GLR, nor from the need to prefix 'unit' to some 
declarations.


And this is why I'm getting increasingly frustrated and angry when 
people propose major breaking changes, brushing off the implications for 
the ecosystem and its maintainers with "but it's not 6.0", "shouldn't be 
a problem", "we aren't stable yet".


We want to release Perl 6 by Christmas, and it'll reflect *very* badly 
on us and the language if many modules in the ecosystem are broken. And 
any change that requires us to touch all .pm files will result in that.


Richard, I'm sorry that I'm writing the response in an email of yours; 
Mark or any number of p6l participants in the last few years triggered 
the same mental response from me. I only just now articulated it.




Cheers,
Moritz

Re: To :D or not to :D

[Moritz Lenz]

On 10/12/2015 09:51 PM, Mark Overmeer wrote:

* Moritz Lenz (mor...@faui2k3.org) [151012 15:32]:

   . are they using :D correctly?


Yes, though not everybody uses :D as much as they do. Do you check that
all the parameters that your Perl 5 methods/subs receive are defined? If
not, you wouldn't use :D in Perl 6 either.


In Perl5, you get slower code when you test for definedness... in Perl6
you get faster (better optimized) code.  That's a big difference.


Do you? Did you actually measure that?


FWIW you can now (as of a few days ago) control the default with
use invocant :D;


How can de invocant not be defined?


Well, if you call a constructor, you call it on the type object. Hence 
the type object is the class, and not defined.



use parameters :D;


The new "use warnings"/"use strict"...


which means all those :D annotations can go away, and you have to use :_
explicitly if you want to allow all.


Oh, use :U for that.  Ehhh already in use.


:U means "undefined", :_ means "defined or undefined, I don't care"


And I don't know if we can change it now without creating a huge havoc
in the existing ecosystem.


There shouldn't be a problem making :D a superfluous option.  Of swiftly
add  "use parameters $_;"  to all modules.


Why shouldn't this be a problem?


 And there still quite a
number of other crucial changes going in anyway...


But hopefully none of them breaking backwards compatibility on such a 
large scale. The last few backwards incompatible changes still cause 
pain in the ecosystem. We have 390+ modules, and hand-waving away all 
trouble of maintaining them seems a bit lofty.



   . :D looks really ugly, don't you think?  Try to explain to students
 to add this smiley everywhere.


It's not uglier than a 'die "Must be defined" unless defined $x'


Much too expensive in Perl5.


Then don't do in Perl 6 either. If you can argue away the need for 
safety based on the need for performance, you can also argue away the 
need for safety based on the need for cleaner code.


Cheers,
Moritz

Re: To :D or not to :D

[Moritz Lenz]

Hi,

On 10/12/2015 03:41 PM, Mark Overmeer wrote:
> 
> Hi all,
> 
> Liz and Tux demonstrate powerful Perl6 code at each monthly meeting of
> our Mongers in Amsterdam.  Looking at their examples, I collected a few
> questions of which I want to discuss the first one in this thread.
> 
> 
> When I look at Merijns (Tux') code, I see a huge number of :D attributes.
> https://github.com/Tux/CSV/blob/master/lib/Text/CSV.pm
> 
> Close to all scalar positional parameter (51x) carry the :D flag.  I count
> only 3 where the parameter does accept undef and the method is able to
> handle it.  I count another 3 where the :D is missing, but the method is
> not able the handle it.
> 
> The same for examples Liz shows us in our core code: most scalar
> positional parameters have :D.
> 
> Writing a sub which is able to handle undef is usually more work than
> implementing "I expect sane values for all of the parameters".
> 
> 
> Questions:
>   . are they using :D correctly?

Yes, though not everybody uses :D as much as they do. Do you check that
all the parameters that your Perl 5 methods/subs receive are defined? If
not, you wouldn't use :D in Perl 6 either.

>   . the simpelest code does not handle the undef case... but now needs
> the more complex prototype to be correct.
>   . it feels like the wrong default: usually you have to do something
> extra for the unusual cases, not the 90%+ usual cases.

FWIW you can now (as of a few days ago) control the default with

use invocant :D;

and

use parameters :D;

which means all those :D annotations can go away, and you have to use :_
explicitly if you want to allow all.

That said, I agree that it's the wrong default. And the design documents
even mandate a default to :D, though at the time it was written, it
wasn't clear how to switch off that default, nor how to avoid having to
write

method new(MyClassHere:U: *@args) { ... }

in the constructor, which would be quite hostile to newbies. It's still
not clear to me how to avoid that.

And I don't know if we can change it now without creating a huge havoc
in the existing ecosystem.

Another concern is that if "everything" defaults to :D, then classes
(and other type objects) aren't really first class objects anymore,
which is a really neat thing to have.

>   . :D looks really ugly, don't you think?  Try to explain to students
> to add this smiley everywhere.

It's not uglier than a 'die "Must be defined" unless defined $x'

Cheers,
Moritz

Announce: Rakudo Star Release 2015.09

[Moritz Lenz]

On behalf of the Rakudo and Perl 6 development teams, I'm excited to
announce the September 2015 release of "Rakudo Star", a useful and
usable distribution of Perl 6. The tarball for the September 2015
release is available from .

This Rakudo Star release comes with support for the MoarVM backend (all
module tests pass on supported platforms).
Please note that this release of Rakudo Star is not fully functional
with the JVM backend from the Rakudo compiler. Support should be
restored shortly.

In the Perl 6 world, we make a distinction between the language ("Perl
6") and specific implementations of the language such as "Rakudo Perl".
This Star release includes [release 2015.09] of the [Rakudo Perl 6
compiler], version 2015.09 of [MoarVM], plus various modules,
documentation, and other resources collected from the Perl 6 community.

[release 2015.09]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.09.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[MoarVM]: http://moarvm.org/

Some of the new compiler features added to this release include:

* Great List Refactor (GLR) - See http://design.perl6.org/S07.html
* All Deprecations removed in preparation for Christmas release
* Added support for calling into C++ libraries and calling methods on
C++ classes
* New slurpy parameter, +args or +@args, to allow for one-argument style
binding
* New with/orwith/without conditionals allow you to check for .defined
but topicalize to the actual value returned
* New `supply`, `whenever` and `react` blocks for easy reactive programming
* All Unicode digits can now be part of literal numbers
* `val()` and allomorphic types implemented
* Most European quoting styles are now supported
* New $[...] and ${...} constructs allow prefix itemization
* The .gist and .perl methods can now deal with self-referential structures


Notable changes in modules shipped with Rakudo Star:

* All modules fixed to work with GLR where needed
* Panda now includes JSON::Fast and no longer precompiles to byte code
* Terminal::ANSIColor replaces the deprecated Term::ANSIColor
* New Perl 6 tutorial replaces original perl6 book draft

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * non-blocking I/O (in progress)
  * much of Synopsis 9 and 11

There is an online resource at 
that lists the known implemented and missing features of Rakudo's
backends and other Perl 6 implementations.

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 at .

See  for links to much more information about
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources. A
Perl 6 tutorial is available as docs/2015-spw-perl6-course.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
, ask on the 
mailing list, or join us on IRC \#perl6 on freenode.

Announce: Rakudo Star Release 2015.03

[Moritz Lenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

## A useful, usable, early adopter distribution of Perl 6

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

This Rakudo Star release comes with support for the MoarVM
backend (all module tests pass on supported platforms) along with
experimental support for the JVM backend (the modules `Bailador`,
`Digest::MD5` and `Grammar::Profiler::Simple` are known to fail tests).

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl. This Star release includes [release 2015.03] of the
[Rakudo Perl 6 compiler], version 2015.03 of [MoarVM], plus various
modules, documentation, and other resources collected from the
Perl 6 community.

[release 2015.03]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.03.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[MoarVM]: http://moarvm.org/

Some of the new compiler features added to this release include:

+ several renames of semi-internal methods. Please refer to [the Rakudo
  2015.02 release
notes](https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.03.md)
for the full list
+ Allow `Buf.AT-POS` to return an l-value.
+ Implement `method ^foo($) { ... }` syntax.
+ Implemented [PairMap](http://doc.perl6.org/type/PairMap) (the simple
case only, for now).
+ Implemented `.antipairs` (pairs with value = key).
+ Implemented [pairup](http://doc.perl6.org/type/Any#method_pairup)
for creating pairs from lists.
+ Implemented `LEXICAL`, `OUTERS` and `CALLERS` pseudo-packages
+ Add `array[T]`, usable for native `int`/`num` (MoarVM only for now)
+ Other native improvements, e.g. `my int $a; $a++`
+ Implement `IO::Path.resolve` on r-m/POSIX

In future, the `nqp::` namespace willl only be available after a
declaration
like `use nqp;`.

Changes to modules included in Rakudo Star:

- - [DBIish](https://github.com/perl6/DBIish) supports local Sockets on
mysql,
  and now correctly handles returned NULL values in the Pg backend
- - [doc](https://github.com/perl6/doc) ships with much more documentation

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency (in progress)
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O (in progress)
  * much of Synopsis 9 and 11

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo's
backends and other Perl 6 implementations.

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 at rakudo...@perl.org.

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. A
draft of a Perl 6 book is available as 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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlUN3iYACgkQT81LMIj/VkTYSACfeumxLQzxeRPfNHIYge6ZHEwU
L9sAn0rfiVwi5CB0RSFJ125UKvv5P7OG
=+CBE
-END PGP SIGNATURE-

Re: S02 mistake re Blob?

[Moritz Lenz]

Hi Darren,

On 21.02.2015 08:51, Darren Duncan wrote:
 I notice from looking at http://design.perl6.org/S02.html that Blob is listed 
 both as being a role and as a type.  See 
 http://design.perl6.org/S02.html#Roles 
 for an example of the former, and 
 http://design.perl6.org/S02.html#Immutable_types for an example of the 
 latter. 
 -- Darren Duncan

so, you think roles aren't types?

(Also, roles auto-pun into classes upon usage).

Cheers,
Moritz

Announce: Rakudo Star Release 2015.02

[Moritz Lenz]

## A useful, usable, early adopter distribution of Perl 6

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

This Rakudo Star release comes with support for the MoarVM
backend (all module tests pass on supported platforms) along with
experimental support for the JVM backend (some module tests fail).
One shipped module is known to fail on Parrot (jsonrpc).

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl. This Star release includes [release 2015.02] of the
[Rakudo Perl 6 compiler], version 6.10.0 of the [Parrot Virtual
Machine], version 2015.02 of [MoarVM], plus various modules,
documentation, and other resources collected from the Perl 6
community.

[release 2015.02]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.02.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[Parrot Virtual Machine]: http://parrot.org
[MoarVM]: http://moarvm.org/

Some of the new compiler features added to this release include:

+ On MoarVM, symlinks are now followed.  This means that e.g. a given
  path can have both .l and .d be true, if the symlink points to a
  directory. This behaviour now matches the behaviour on the Parrot
  and JVM backend, therefore one could consider this a bug fix,
  rather than an incompatible change.
+ Overriding `invoke`/`postcircumfix:( )` for type coercions (ex.
  `MyType(...)`) now passes the function arguments as-is, rather than
  just passing a Capture containing them. To get the old behavior,
  simply declare a Capture parameter (|c).
+ `6;` at unit start is no longer a way to say `no strict;`.  It was
  deemed to be a bad meme and huffmannized inappropriately.
+ Coercion syntax now works in signatures: `sub foo(Str(Any) $a) { ... }`
  will take Any value as its first positional parameter, and coerce
  it to `Str` before making it available in `$a`.  Note that `Str(Any)`
  can be shortened to `Str()`.
+ `sub MAIN;` (as in, rest of file is the MAIN unit) has been
  implemented.
+ Metaop `=` now respects the precedence of the op it is meta-ing.
+ Many optimizations, improved error messages and bugs fixed (over
  200 commits to Rakudo since the 2015.01 release).

In future, the `nqp::` namespace willl only be available after a
declaration like `use nqp;`.

Changes to modules included in Rakudo Star:

- [JSON::Tiny](https://github.com/moritz/json) gives better error
messages on invalid input
- [panda](https://github.com/tadzik/panda) gives better error messages
when
  projects.json is not a valid JSON file (for example due to ISP-level
HTTP filtering)
- [doc](https://github.com/perl6/doc) ships with much more documentation
- [LWP::Simple](https://github.com/cosimo/perl6-lwp-simple) supports
PUT and HEAD requests,
  as well as TLS if
[IO::Socket::SSL](https://github.com/sergot/io-socket-ssl/) is installed.

The `Math::Model` and `Math::RungeKutta` modules no longer ship with
Rakudo
Star. They can still be installed with `panda`.

This is the last Rakudo Star release with support for the Parrot
backend, until volunteers are found that bring the Parrot backend in
shape and on par with the other backends, and implement necessary
features for upcoming changes. See
[this blog post](http://pmthium.com/2015/02/suspending-rakudo-parrot/)
for more information.

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency (in progress for the JVM and MoarVM backend)
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O (in progress for the JVM and MoarVM backend)
  * much of Synopsis 9 and 11

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo's
backends and other Perl 6 implementations.

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 at rakudo...@perl.org.

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. A
draft of a Perl 6 book is available as 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.

Re: [perl #121454] Can't inline complex constraints in multisub signatures

[Moritz Lenz]

On 03/28/2014 02:28 PM, Parrot Raiser wrote:
 On 3/27/14, Moritz Lenz mor...@faui2k3.org wrote:
 
 Agreed. We just need to come up with a consistent, intuitive way to
 handle the rest of the cases. And implement it.

 
 Whenever somebody offers a solution to a problem formulated as We
 just need to  (or why don't you just?), it's usually a sign
 that they've overlooked some fundamental aspect of the problem. Or, as
 I suspect in this case, poured irony all over it. :-)*

Sorry, it's not meant ironic at all. I just meant to indicate that
speccing without implementation is a useless exercise, and right now I'm
not seeing myself as the one who thinks through and decides on all the
corner cases, and implements it.

Cheers,
Moritz

Re: [perl #121454] Can't inline complex constraints in multisub signatures

[Moritz Lenz]

On 03/19/2014 11:06 AM, Damian Conway wrote:
 To me, the issue is: how does Perl 6 actually carry out the
 type inference we're doing here?
 
 And I believe it's an important question to get right, as we
 may eventually see Perl 6 doing more type inference...either
 in core, or else through some nefarious module that some
 evil genius eventually writes. ;-)
 
 If Perl 6 does type inference on some $value simply by calling
 $value.WHAT, then:
 
 multi foo(0|1) {...}
 
 should indeed be equivalent to:
 
 multi foo(Junction $ where 0|1) {...}
 
 
 However, that's not the only possibility (nor, in my opinion,
 the most predictable or useful).
 
 If, for example, Perl 6 did type inference by calling an internal:
 
 multi infer-type (Any $value) { $value.WHAT }
 
 then:
 
 multi foo(0|1) {...}
 
 would be equivalent to:
 
 multi foo(Int|Int $ where 0|1) {...}
 
 which is, of course, just:
 
 multi foo(Int $ where 0|1) {...}

No.

The type of Int|Int is still Junction, not Int.

However you turn the problem, you'll need some form of special-casing to
fold Int|Int into Int, and please formulate it so that the Mu case
continues to work.

To spin the tale further, we need to think about what happens if
somebody writes

multi foo(1|2e0) { ... }

so now we have Int|Num. We could explore the most-derived common
ancestor (Cool), or look into role space (Real, Numeric come to mind),
or simply error out.

 which, in my view, would be a much more useful outcome in the vast
 majority of cases.

Agreed. We just need to come up with a consistent, intuitive way to
handle the rest of the cases. And implement it.

Cheers,
Moritz

 I accept that it's important to be able to explicitly declare a
 parameter as a Junction, so it's immune to junctive autothreading,
 but I don't think that should be the norm...and certainly shouldn't
 happen implicitly. That's why variables, parameters, and return values
 that are not explicitly typed default to Any, rather than to Junction.
 
 And, I think this is another implicit case where a non-junctive outcome
 would be more useful...and more widely expected.
 
 In other words, for the one time in a thousand (or fewer) where I
 actually want:
 
 sub foo(Junction $ where 0|1) {...}
 
 then I should have to be explicit about that argument being junctive
 (because I should *always* have to be explicit about an argument being
 junctive).
 
 And for the 999 times I want:
 
 sub foo(Any $ where 0|1) {...}
 
 I should be able to just write:
 
 sub foo(0|1) {...}
 
 
 Damian
 

Re: [perl #121454] Can't inline complex constraints in multisub signatures

[Moritz Lenz]

f'up to p6l, because the ticket doesn't need the rest of the discussion.

On 03/19/2014 10:21 PM, Darren Duncan wrote:
 On 2014-03-19, 1:20 AM, Moritz Lenz wrote:
 On 03/19/2014 12:45 AM, Darren Duncan wrote:
 Damian, Moritz, etc,

 It seems to me that the basic problem here is that the vertical bar |
 has 2 different meanings (outside rules) depending on context.

 When used with type names it produces a union type, while with normal
 values such as integer literals it produces a junction value.

 No. It's always a Junction. Perl 6 has no union types.
 
 Really?  All this time I thought in Perl 6 you could write say:
 
my Int|Str $foo;

You were wrong.

The only way to achieve something comparble is

subset IntStr of Any where Int|Str

but for example for multi dispatch, it matters that not a nominal type
matched, but rather a constraint, so that's a not a great replacement.

 Or otherwise say Int|Str anywhere a type name could go, and then this is 
 saying 
 you accept anything that is a Int or a Str but nothing else there.
 
 Was that never true or was it replaced by something while I wasn't looking?

There was something like that in the specs, but no concept whatsoever of
how that might work. You can't just slap on union types onto an existing
type system, and have it magically work out. In languages like Haskell
where they work fine, they are right at the core of the language.

So the feature was removed years ago, because it's not really implementable.

Cheers,
Moritz

Re: Unexpected expansion of string with xx

[Moritz Lenz]

On 12/20/2013 04:52 AM, Richard Hainsworth wrote:

OK x not xx.

The doubling of operators is confusing.


OTOH having a single operator which two different meanings is also 
confusing (and very un-perlish).


Cheers,
Moritz

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: Class attribute introspection

[Moritz Lenz]

Hi Richard,

On 10/28/2013 08:07 AM, Richard Hainsworth wrote:

Perhaps I am using class incorrectly, but I set up a class, then change
some of the parameters in an instance of the class. Next I would like to
discover what the current state of the instance is.


There is a way to introspect through the MOP:

class A { has $!x = 42; };
my $obj = A.new;
say A.^attributes[0].get_value($obj);

It's not straight forwards, and that's actually a feature :-)

The usual way to go is through the accessors, and indirect method calls 
with $obj.$name();


Cheers,
Moritz

Re: Introduction to Synopses

[Moritz Lenz]

Hi Richard,

On 09/29/2013 07:28 AM, Richard Hainsworth wrote:
 Some suggestions about documentation.
 
 Originally the Synopses were implementation oriented sumaries of the 
 previous description base Apocalypses. That meant that the Synopses were 
 derivative and secondary to the Apocalypses
 
 However, the Synopses are now primary specification and the Apocalypses 
 have only historical significance. Also there are more Synopses than 
 Apocalypses.
 
 I suggest the introductory paragraphs to the Synopses are changed to 
 reflect this.

A good idea. Please do it!

The page you're probably think of is in the perl6/mu repo on github in
the file docs/feather/syn_index.html. If you have a github user name,
please tell me, and I can give you commit access.

Cheers,
Moritz

Announce: Rakudo Star Release 2013.09

[Moritz Lenz]

## A useful, usable, early adopter distribution of Perl 6

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the September 2013 release of Rakudo Star, a useful and usable
distribution of Perl 6. The tarball for the September 2013 release is
available from http://rakudo.org/downloads/star/. A Windows .MSI
version of Rakudo star will usually appear in the downloads area
shortly after the tarball release.

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes [release 2013.09] of the
[Rakudo Perl 6 compiler], version 5.5.0 of the [Parrot Virtual
Machine], plus various modules, documentation, and other resources
collected from the Perl 6 community.

[release 2013.09]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.09.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[Parrot Virtual Machine]: http://parrot.org

Some of the new features added to this release include:

+ candidate argument to bless removed (per spec change)
+ @a.VAR.name and %h.VAR.name implemented
+ The $var.++ and $var.() syntaxes work
+ basics of tr/// implemented
+ Sets/Bags/KeySet/KeyBag now up to spec, except for the empty set 
symbol '∅'


This release also contains a range of bug fixes, improvements to error
reporting and better failure modes.

Please note that this release of Rakudo Star does not support the JVM
backend from the Rakudo compiler. While the JVM backend mostly implements
the same features as the Parrot backend, many bits are still missing,
most prominently the native call interface.
We hope to provide a JVM-based Rakudo Star release soon.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are planned
to be removed or changed as follows:

  * `postcircumfix:[ ]` and `postcircumfix:{ }` will become
multi-subs rather than multi-methods *IN THE NEXT RELEASE* of Rakudo
Star. Both at_pos and at_key will remain methods.

  * All unary hyper ops currently descend into nested arrays and
hashes. In the future, those operators and methods that are
defined nodal will behave like a one-level map.

  * The Str.ucfirst builtin is deprecated; it will be replaced by
Str.tc.  In the next Rakudo Star release, use of Str.ucfirst will 
actually

generate a warning upon first usage.

  * Leading whitespace in rules and under :sigspace will no longer be
converted to `.ws`.  For existing regexes that expect this
conversion, add a `?` in front of leading whitespace to make it
meta again.

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9 and 11

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo and
other Perl 6 implementations.

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 at rakudo...@perl.org.

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.  A
draft of a Perl 6 book is available as 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 2013.08 released

[Moritz Lenz]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the August 2013 release of Rakudo Star, a useful and usable
distribution of Perl 6. The tarball for the August 2013 release is
available from http://rakudo.org/downloads/star/. A Windows .MSI
version of Rakudo star will usually appear in the downloads area
shortly after the tarball release.

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes [release 2013.08] of the
[Rakudo Perl 6 compiler], version 5.5.0 of the [Parrot Virtual
Machine], plus various modules, documentation, and other resources
collected from the Perl 6 community.

[release 2013.08]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.08.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[Parrot Virtual Machine]: http://parrot.org

Some of the new features added to this release include:

* `is default` traits on variables are now implemented
* assigning Nil restores the default value
* `Buf` is now a role, and Buf objects are immutable.
* `printf` now correctly handles big integers
* fixed handling of indented heredocs
* `dir()` is now lazy

This release also contains a range of bug fixes, improvements to error
reporting and better failure modes.

Please note that this release of Rakudo Star does not support the JVM
backend from the Rakudo compiler. While the JVM backend mostly implements
the same features as the Parrot backend, many small IO bits are still
missing, rendering some crucial parts like the module installer unsable.
We hope to provide a JVM-based Rakudo Star release soon.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are planned
to be removed or changed as follows:

  * `postcircumfix:[ ]` and `postcircumfix:{ }` will become
multi-subs rather than multi-methods. Both at_pos and at_key will
remain methods.

  * All unary hyper ops currently descend into nested arrays and
hashes. In the future, those operators and methods that are
defined nodal will behave like a one-level map.

  * The Str.ucfirst builtin is deprecated; it will be replaced by
Str.tc.

  * Leading whitespace in rules and under :sigspace will no longer be
converted to `.ws`.  For existing regexes that expect this
conversion, add a `?` in front of leading whitespace to make it
meta again.

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo and
other Perl 6 implementations.

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 at rakudo...@perl.org.

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.  A
draft of a Perl 6 book is available as 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.

Re: Commensurability as Key

[Moritz Lenz]

Hello,

some clarifications below

On 08/21/2013 05:19 AM, Doug McNutt wrote:
 * a function is a subroutine returning a scalar  ( see below)

fwiw we don't make that distinction in the specification; we just talk
about subroutines. We can return nothing, a scalar or a non-scalar.

, a procedure is a subroutine with no
return value, side-effects only. A subroutine returning many values- a
parcel of containers, perhaps, or an iterator, etc- is a
many-to-many relation. I understand relational algebra from
decades of SQL work, and have seen ORM's replicate relations in object
systems with some success. What's missing for creating a relational
wonderland in perl6?
 
 
 I confess.  I'm here because I hoped perl 6 would do vector operations after 
 reading an early small book.

And it does, if you teach it to.
Perl 6 has some facilities to spread out operations over lists of
elements, though not all operations common in linear algebra (vector
cross product, multiplying a vector with a matrix etc.) are built-in.
Just like they aren't built into Fortran, for that matter.

 I would really like to see perl support a function called a cross product 
 that would return a vector, the product of amplitudes and the sine of the 
 angle between them, as a vector using the   notation.  That's not a scalar! 
  But i surely would be commensurate with the input arguments.

Please don't fall prey to some mismatch in terminology. In Perl 6, a
scalar is just some form of container, which happens to be used in
variables beginning with a dollar ($). Nothing stops you from putting a
vector, however you define or declare one, into a scalar (variable). Nor
is there any restriction that makes it impossible to return more than
one value from a subroutine -- it just happens to be the case that
yary's definition of function restricts functions to one value. But
that's really a matter of terminology, not technology.

Cheers,
Moritz

Re: Are set operations needed?

[Moritz Lenz]

On 07/18/2013 01:07 PM, Richard Hainsworth wrote:

Are set operations needed in Perl6? No implementation of the perl6 set
specification yet exists (AFAIK).


You are wrong. Both rakudo and niecza implement significant subsets of 
the set specification.


Cheers,
Moritz

Announce: Rakudo Star 2013.02 released

[Moritz Lenz]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the February 2013 release of Rakudo Star, a useful and
usable distribution of Perl 6.  The tarball for the  February 2013
release is available from http://rakudo.org/downloads/star/.
A Windows .MSI version of Rakudo star will usually appear in
the downloads area shortly after the tarball release.

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes release 2013.02.1 [0] of the
Rakudo Perl 6 compiler [1], version 4.10.0 of the Parrot Virtual
Machine [2], and various modules, documentation, and other
resources collected from the Perl 6 community.

Some of the new features added to this release include:

* Did you mean ... suggestions for symbol-not-found errors

* Compile-time optimization of some cases of junctions in boolean context

* IO::Socket.get now works again with non-ASCII characters

* constant folding for routines marked as 'is pure'

* natively typed variables and better error reporting in the REPL

* speed up eqv-comparison of Bufs

* warnings for useless use of (some) literals, variables and constant
  expressions in sink context


This release also contains a range of bug fixes, improvements to error 
reporting

and better failure modes.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are being removed
or changed as follows:

* .gist on a type object will return '(Typename)' instead of 'Typename()'.
  If you want to get the class name alone, continue to use $obj.^name

* postcircumfix:[ ] and postcircumfix:{ } will become multi-subs rather
  than multi-methods. Both at_pos and at_key will remain methods.

* Unary hyper ops currently descend into nested arrays and hashes.
  This will change to make them equivalent to a one-level map.

* The Str.ucfirst builtin is deprecated; it will be replaced by Str.tc.

* Leading whitespace in rules and under :sigspace will no longer be
  converted to .ws .  For existing regexes that expect this conversion,
  add a ? in front of leading whitespace to make it meta again.

* The ?-quantifier on captures in regexes currently binds the capture
  slot to a List containing either zero or one Match objects; i.e., it
  is equivalent to ** 0..1.  In the future, the ?-quantifier will
  bind the slot directly to a captured Match or to Nil.  Existing code
  can manage the transition by changing existing ?-quantifiers to
  use ** 0..1, which will continue to return a List of matches.

There are some key features of Perl 6 that Rakudo Star does not
yet handle appropriately, although they will appear in upcoming
releases.  Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo
and other Perl 6 implementations.

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 at rakudo...@perl.org.

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.
A draft of a Perl 6 book is available as 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.

[0] https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.01
[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

Rakudo Star 2013.01 released

[Moritz Lenz]

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

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the January 2013 release of Rakudo Star, a useful and
usable distribution of Perl 6.  The tarball for the  January 2013
release is available from http://rakudo.org/downloads/star/.
A Windows .MSI version of Rakudo star will usually appear in
the downloads area shortly after the tarball release.

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes release 2013.01 [0] of the
Rakudo Perl 6 compiler [1], version 4.10.0 of the Parrot Virtual
Machine [2], and various modules, documentation, and other
resources collected from the Perl 6 community.

Some of the new features added to this release include:

* Sink context (what some other languages call void context) is now
enforced correctly. This means that for-loops are now lazy by default.
It fixes the  bug where a map in sink context would not execute, and
also means that a Failure returned to sink context will be properly thrown.

* 'require' now works with indirect module names

* Restored socket read semantics to returning the requested number of bytes

* $obj.Some::Role::meth() now passes the correct $obj

* try/CATCH now returns Nil when the CATCH is triggered, rather than the
  exception; this brings it in line with try without a CATCH

* whatever-star cases of splice now implemented

* can now import multis with the same name from different modules,
  provided all dispatchers are onlystar

This release also contains a range of bug fixes, improvements to error
reporting and better failure modes.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are being removed
or changed as follows:

* postcircumfix:[ ] and postcircumfix:{ } will become multi-subs rather
  than multi-methods. Both at_pos and at_key will remain methods.

* Unary hyper ops currently descend into nested arrays and hashes.
  This will change to make them equivalent to a one-level map.

* The Str.ucfirst builtin is deprecated; it will be replaced by Str.tc.

* Leading whitespace in rules and under :sigspace will no longer be
converted to .ws .  For existing regexes that expect this conversion,
add a ? in front of leading whitespace to make it meta again.

* The ?-quantifier on captures in regexes currently binds the capture
  slot to a List containing either zero or one Match objects; i.e., it
  is equivalent to ** 0..1.  In the future, the ?-quantifier will
  bind the slot directly to a captured Match or to Nil.  Existing code
  can manage the transition by changing existing ?-quantifiers to
  use ** 0..1, which will continue to return a List of matches.

There are some key features of Perl 6 that Rakudo Star does not
yet handle appropriately, although they will appear in upcoming
releases.  Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo
and other Perl 6 implementations.

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 at rakudo...@perl.org.

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.
A draft of a Perl 6 book is available as 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.

[0] https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.01
[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

Announce: Rakudo Star 2012.12 release

[Moritz Lenz]

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

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the December 2012 release of Rakudo Star, a useful and
usable distribution of Perl 6.  The tarball for the  December 2012
release is available from http://rakudo.org/downloads/star/.
A Windows .MSI version of Rakudo star will usually appear in
the downloads area shortly after the tarball release.

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes release 2012.11 [0] of the
Rakudo Perl 6 compiler [1], version 4.10.0 of the Parrot Virtual
Machine [2], and various modules, documentation, and other
resources collected from the Perl 6 community.

Some of the new features added to this release include:

* Parse errors are much improved, and follow STD, the standard parser,
  much more closely; they are more accurate and more information is given

* Rakudo now keeps parsing after some less serious errors

* Better errors for various parse failures

* The junction autothreader is now an order of magnitude faster

* Texas (ASCII) versions of the Set and Bag operators implemented

* Nested Pairs now give correct .perl output

* { a = $_ } now correctly considered a block, not a hash as before

This release also contains a range of performance improvements, bug fixes,
improvements to error reporting and better failure modes.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are being removed
or changed as follows:

* 'for'-loops will become lazy, and are only evaluated eagerly in
  eager or sink (void) context. This means that if a for-loop is
  the last statement in a routine, it will usually run after the
  routine has returned, so it cannot call return() anymore.

* Unary hyper ops currently descend into nested arrays and hashes.
  This will change to make them equivalent to a one-level map.

* The Str.ucfirst builtin is deprecated; it will be replaced by Str.tc.

* Leading whitespace in rules and under :sigspace will no longer be
  converted to .ws .  For existing regexes that expect this conversion,
  add a ? in front of leading whitespace to make it meta again.

* The ?-quantifier on captures in regexes currently binds the capture
  slot to a List containing either zero or one Match objects; i.e., it
  is equivalent to ** 0..1.  In the future, the ?-quantifier will
  bind the slot directly to a captured Match or to Nil.  Existing code
  can manage the transition by changing existing ?-quantifiers to
  use ** 0..1, which will continue to return a List of matches.

There are some key features of Perl 6 that Rakudo Star does not
yet handle appropriately, although they will appear in upcoming
releases.  Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo
and other Perl 6 implementations.

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 at rakudo...@perl.org.

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.
A draft of a Perl 6 book is available as 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.

[0] https://github.com/rakudo/rakudo/blob/nom/docs/announce/2012.12
[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

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: When do named subs bind to their variables? [perl #113930]

[Moritz Lenz]

On 07/08/2012 11:12 AM, Damian Conway wrote:
 Father Chrysostomos pointed out:
 
 I said when, not whether. :-)
 
 Isn't that just typical of me: confusing ontology with chronology. ;-)
 
 I'm afraid don't know the implementation details for Rakudo. It may be
 bound as the surrounding block is entered, or perhaps just-in-time when
 the Code object is first accessed in some way.

When the surrounding block is entered.

http://perlcabal.org/syn/S04.html#When_is_a_closure_not_a_closure

All remaining blocks are conceptually cloned into closures as soon as
the lexical scope containing them is entered.

Cheers,
Moritz

Re: When do named subs bind to their variables? [perl #113930]

[Moritz Lenz]

On 07/08/2012 11:12 AM, Damian Conway wrote:
 Father Chrysostomos pointed out:

 I said when, not whether. :-)

 Isn't that just typical of me: confusing ontology with chronology. ;-)

 I'm afraid don't know the implementation details for Rakudo. It may be
 bound as the surrounding block is entered, or perhaps just-in-time when
 the Code object is first accessed in some way.

When the surrounding block is entered.

http://perlcabal.org/syn/S04.html#When_is_a_closure_not_a_closure

All remaining blocks are conceptually cloned into closures as soon as
the lexical scope containing them is entered.

Cheers,
Moritz

Re: [perl #113930] Lexical subs

[Moritz Lenz]

On 07/08/2012 09:57 PM, Father Chrysostomos via RT wrote:
 my $x;
 my sub f { say $x }
 for 1..10 - $x { f(); }

It prints

Any()
Any()
Any()
Any()
Any()
Any()
Any()
Any()
Any()
Any()

(because Any is the default value in uninitialized variables).

As an aside, you can run short Perl 6 scripts on IRC (on irc.perl.org
and irc.freenode.org) with something like

/msg p6eval p6: my $x; sub sub f { say $x }; for 1..10 - $x { f() }

This runs it through both rakudo and niecza.

If you want, I can also send the bot into #p5p.

Cheers,
Moritz

Re: [perl6/specs] 34fddf: [S32::Str] substr is not rw anymore, but substr-rw...

[Moritz Lenz]

On 06/09/2012 12:32 PM, Richard Hainsworth wrote:
 I noticed that subst-rw does not have is export in the definition.
 
 Does this mean that subst-rw is not available outside the module?

No.

All routines from the setting are available to user space code, because
they are simply in an outer scope of the user code.

What the 'is export' traits in that document do is creating a subroutine
version of a method.

Currently it means that there is only a subroutine version of substr-rw
specced, not a method form.

Cheers,
Moritz

Re: The trouble with awesome

[Moritz Lenz]

Am 26.05.2012 21:12, schrieb Parrot Raiser:

There are a lot of programmers who know several programming languages already,
and who don't  want to read a whole page on how to print 'Hello World', 5 pages 
on
if-statements and while-loops  and another 10 pages explaining lists and 
iteration.


However experienced a programmer may be, there are certain minimum
levels of knowledge one needs to get into a new language.

What class of language is it? Machine code, assembler, compiler,
interpreter, executed from source, like Java? (Obviously, we know
that, but for the few sentences it takes to explain it, it might as
well be stated anyway for newcomers.) A couple of paragraphs can
explain where it might be expected to run, and what's required to
start using it.


Indeed, rereading the preface, it seems we don't mention what kind of 
language it is. I'll try to fix that later.



  That's the purpose of Hello, world programs; not to babble inane
greetings, but to show simply to run something in the language.  Even
there, Perl 6 is unusually rich in options; interactive mode, command
line, argument, and stand-alone executable. Each step requires
slightly more input, so that's the order I would introduce them.


I'd still start with simple script files, because that's what most 
programmers are most familiar with.



When introducing a programming language, as opposed to teaching
programming from scratch, it should not be necessary to explain what a
variable is, or why decision statements are required. The reader's
questions are more in the nature of what's a valid variable name or
how are blocks bounded?

Without the basics of of statement syntax, variable name rules, block
structure, how decisions are  delimited, and how to iterate, how does
one interpret more complex concepts? Certainly, they can be explained
by reference to some previous standard; The rules for  are
exactly the same as in Perl 5, except when . These rules are
.. That allows the Perl maven to skip forward enlightened, and
the beginner to keep learning.

Learning's a process of building on previous foundations, and so is
programming. Somebody creating simple tabulations may never need the
techniques of the compiler writer, but the compiler creator had to
learn the rules for variable names.


Agreed. We need to get better on this front. Maybe insert a small cheat 
cheat before the 'Basics' chapter.



But much more is needed. Please help us with it.


Specifying the problem was meant to be the first step. I wanted to get
the discussion going, (but not the bikeshedding about the language
name).

For the author of Perl 6 documentation, the problem is knowing the
language well enough to see the logical stages to extend basic
concepts and introduce new ones. Where are the rings of the onion?
For example, double  and single ' quotes are pretty much essential
from the start; when do the alternative forms begin to be necessary?

I see at least 3 levels of complexity, demanding increasing levels of
sophistication; basic computation on streams of structured I/O,
manipulation of unstructured data, like text, and higher order work,
like program-creating programs, compilers,c. Does this seem like a
reasonable taxonomy, or are other groupings a better fit?


Where would you put nested data structures and custom classes? At the 
beginning of the higher order work?


Apart from that, it sounds quite well.

Cheers,
Moritz

Re: The trouble with awesome

[Moritz Lenz]

 My point is that while it
 started out as a way to improve/formalize Perl 5, it's developed
 sufficiently to the point where it is its own language and not the
 next version of 'perl'.

But it is still a version of Perl. It might not be the next version of
Perl, but it certainly the sixth version of Perl.

If you think that the difference between Perl 5 and Perl 6 is too big to
still call Perl 6 Perl, then compare some early FORTRAN code to
idiomatic Fortran 2008 code.


On 05/25/2012 03:44 PM, B. Estrade wrote:
 Rebranding this as a new language is one step in the right direction.
 Having the language called the same thing as whatever the defacto
 reference implementation is would be a nice way to go. But it's more
 than just a name to me, it's a signal saying that it's okay to stop
 thinking of Perl 6 in terms of Perl 5 - and therefore it won't be
 necessary to unlearn what I already know and love; rather, it'll allow
 me to tap into the part of my brain that is willing and ready to learn
 new languages.
 
 Perhaps simply renaming the specification (OpenPerl?) and allowing the
 reference implementation (Rakudo) to take center stage.

All those people who propose a rebranding assume that a good name will
just be found with a bit of thought. So far I haven't heard a single
good one.

(OpenPerl? I don't think Perl 6 is more open than Perl 5 on any
measurable level; and if it is, it's not the main difference)

And no, Rakudo is not the and not even a reference implementation.
It is an implementation, period. There's nothing that makes it more
official or reference than Niecza, for example. Just like GCC is not
more official or reference to C than is Clang, ICC, TCC or whatever.

Re: The trouble with awesome

[Moritz Lenz]

Hallo Parrot,

we are well aware that the documentation for Perl 6 is quite lacking. 
Any contributions in that area are greatly appreciated.


Am 23.05.2012 01:35, schrieb Parrot Raiser:


The problem we have is to provide a path for learning 6, that presents a
comprehensible but useful subset of the language to the average user
as soon as possible, while leading the programmer with more complex needs,
(and greater abilities), to the features they need or will appreciate.

The Synopses are comprehensive. They define the language in great depth,
feature by feature, (some features bordering on the pathological, do not
try this at home). Since they specify what the language is to become, not
what is implemented at present, they can be frustrating to follow. Maybe
it's just an effect of advancing age, but it's easy to forget the contents
of a previous synopsis by the time one has read the next. The Perl 6
Tablets have a similar organisation, and hence the same problem.


The synospis were not originally meant as learning material, and they 
still are not. It's easy to forget, because they are the most 
comprehensive documents out there. But you don't learn Java by reading 
the specification either.



I haven't recently revisited the book in Rakudo*, but it struck me, last
time I looked, as a powerful deterrent to learning the language. It starts
with the tricky stuff.


It's by design that it starts with tricky stuff, because it's not 
directed at somebody who is new to programming. There are a lot of 
programmers who know several programming languages already, and who 
don't want to read a whole page on how to print 'Hello World', 5 pages 
on if-statements and while-loops and another 10 pages explaining lists 
and iteration.


At this point, Rakudo mostly appeals to language enthusiasts and early 
adopters, so that's quite a good fit.


In the long run, we need a book for beginners too.

An attempt to write materials for beginners is at.
https://github.com/perlpilot/perl6-docs/

But much more is needed. Please help us with it.

Cheers,
Moritz

Re: allow .re and .im to be l-values

[Moritz Lenz]

On 05/19/2012 06:05 AM, Siddhant Saraf wrote:
 sisar r: my $x = 4 + 2i; $x.re = 5;
 p6eval rakudo 45679a: OUTPUT«Cannot assign to a non-container␤  in
 block anon at /tmp/PeeJaa8bWJ:1␤␤»
 
 I think $x.re (Real part of $x) and $x.im (Imaginary part of $x)
 should be allowed to be l-values.
 What do you say?

No.

Complex objects are value types and immutable.

It's bad enough that we conflate the container/value distinction for
substr-rw already, but we do it because it's quite useful.

But for complex numbers, it's not so useful, because you can just create
a new one quite easily:

$x = 5 + $x.im*i;

Cheers,
Moritz

Re: The = operator and context

[Moritz Lenz]

Am 03.04.2012 17:10, schrieb Daniel Carrera:

(1..10).WHAT   # =  Range()

@foo = 1..10;

@foo.WHAT # =  Array()


When you assign a range to @foo, the result is an array. Something
similar happens, for example, if you assign a scalar to @foo... The
context of the assignment causes Perl 6 to convert the value into an
array.

I was wondering if this sort of magic is limited to pre-defined types
(arrays, hashes, etc) or if it can be extended to any class that I
might create.


It's something inbetween. The distinction between the list assignment 
and scalar assignment is syntactic. In the case of list assignment, 
@foo.STORE(1..10) is called under the hood.



For example, imagine hat I create a 'Vector' class to do
basic linear algebra. Imagine that it works this way:

my @vec = Vector.new(  1,2,3,4 )

@vec * 3   # =  ( 3,6,9,12 )

In other words, the '*' operator is overloaded to behave like scalar x
vector multiplication in linear algebra. I was thinking that it would
be neat if instead you could do this:


my Vector @vec;

@vec = 1,2,3,4;

@vec.WHAT   #  =  Vector()



You can, very nearly. You just need to write

my @vec is Vector;

because you really want to change the type of the container, not just of 
the contents (my Vector @vec would be an array containing Vector objects).


This syntax doesn't quite work yet in Rakudo (though it wouldn't be too 
hard to get running), but this works:


use v6;

class Vector is Array {}
multi sub infix:*(Vector $a, Real $b) {
Vector.new( $a.list X* $b );
}

my @vec := Vector.new(1, 2, 3, 4);
say @vec.WHAT;
say @vec * 3;

Output:

Vector()
3 6 9 12

Using binding := instead of assignment replaces the array container with 
a Vector object.


You can even write

my @vec := Vector.new;
@vec = 1, 2, 3, 4;

and get the same output.

(you can also override the .STORE method of a scalar, but that's a bit 
creepy if you ask me).


Cheers,
Moritz

Re: The = operator and context

[Moritz Lenz]

On 04/03/2012 08:24 PM, Daniel Carrera wrote:
 On 3 April 2012 17:24, Moritz Lenz mor...@faui2k3.org wrote:
 You can, very nearly. You just need to write

 my @vec is Vector;

 because you really want to change the type of the container, not just of the
 contents (my Vector @vec would be an array containing Vector objects).
 
 
 Another option might be to just use scalar variables to hold vectors:
 
 my Vector $vector;
 my Vector @array_of_vectors;
 
 $vector = 1,2,3,4,5;

but then you don't get list assignment semantics for that last line, so
it'll parse as ($vector = 1), 2, 3, 4, 5;

 Doesn't work for me :-(  For me the last statement gives 12.

which version of Rakudo are you using? (I've tried on the last
development version from git)

 
 (you can also override the .STORE method of a scalar, but that's a bit
 creepy if you ask me).
 
 Hmm...  So you'd have to mess with the STORE method of *all* scalars
 (i.e. not just the Vector() class) ?

No. Just those that you want to behave specially. And I never
recommended it.

Cheers,
Moritz

Re: Floating-point equality (was Re: How to make a new operator.)

[Moritz Lenz]

On 03/25/2012 06:55 AM, Moritz Lenz wrote:
 I don't know if the majority of the perl6-language posters have realized
 it yet, but both Perl 6 and the its implementations are quite mature
 these days. Mature enough that such proposals should be prototyped as
 modules, and thoroughly tested on lots of existing code before taken
 into consideration for

... inclusion into the spec.

Sometimes I do finish my sentences with several hours delay, sorry for that.

Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

On 03/23/2012 09:14 AM, Damian Conway wrote:
 it means we cannot do the same fuzziness for the endpoint,
 
 Except that we will be encouraging people to use: * = $END
 as their standard endpoint pattern, which will provide
 most of the necessary fuzz.

and which will still surprise those people who are surprised
by floating point inaccuracies.

 This discussion makes me think that maybe
 deducing geometric sequences is too much magic as well.
 
 Geometric sequence inference is fine on Ints and Rats.
 
 But, if we can't perform inferences involving Nums in a sound numerical
 way (and it may well be that we can't, without taking a noticeable
 performance hit), then I think that we would be better off limiting the
 deduction of *both* arithmetic and geometric sequences to starting lists
 that contain only Ints and Rats.

Floating point numbers *can* represent a huge number of commonly used
values without errors, and you can do error-free arithmetic operations
on many of them. Excluding Nums from automatic deduction feels like an
unnecessary pessimization or stigmatization, especially if you consider
that writing a number like 0.001 in your program gives a Rat by default
not a Num.

Most of the time you only get a Num in Perl 6 if you consciously decide
to write one, in which case you should also be well aware of the
limitations of FP math.

At least in #perl6 I've never seen anybody try to write an auto-deduced
sequence, and fail because of floating-point errors.

Cheers,
Moritz

Re: Floating-point equality (was Re: How to make a new operator.)

[Moritz Lenz]

On 03/25/2012 05:59 AM, David Green wrote:
 On 2012-March-23, at 12:01 am, Damian Conway wrote:
 [...] we ought to allow for the inevitable loss of significant digits within 
 the two preliminary division ops, and therefore compare the results with an 
 suitably larger epsilon.
 That would not only be computational more justifiable, I suspect it might 
 also produce more least surprise. ;-)
 
 I think that comparisons for floating-point values should take some kind of 
 'significance' adverb and complain if it's missing.  Having to be explicit 
 makes for the least surprise of all.
 
π == 22/7   # error
π == 22/7 :within(0.002)# true
π == 22/7 :within(0.2)  # false

Note that neither 22/7 nor 0.002 are floating-point values.

I don't know if the majority of the perl6-language posters have realized
it yet, but both Perl 6 and the its implementations are quite mature
these days. Mature enough that such proposals should be prototyped as
modules, and thoroughly tested on lots of existing code before taken
into consideration for

Niecza supports operator adverbs, and supports them on user-defined
operators, so there's nothing to stop you from trying it.

Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

On 03/23/2012 07:01 AM, Damian Conway wrote:
 Patrick correctly observed:
 
 On Rakudo on my system, sqrt(2) indeed produces a Num,
 but since floating point arithmetic doesn't result in
 sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced
 and the sequence fails with unable to deduce sequence.
 
 Although, arguably, that might be considered a bug.
 
 Not that sqrt(2) / 1 should == 2 / sqrt(2) of course, but that, when
 deducing a sequence we know we're comparing quotients, so we ought to
 allow for the inevitable loss of significant digits within the two
 preliminary division ops, and therefore compare the results with an
 suitably larger epsilon.
 
 That would not only be computational more justifiable,
 I suspect it might also produce more least surprise. ;-)

But unless we twist smartmatching semantics for that purpose, it means
we cannot do the same fuzziness for the endpoint, condemning people to
write infinite loops instead of failing fast.

So I'm firmly against such magic. All the previous iterations of the
sequence operator had some additional degrees of magic, and we've come
to regret all of them. This discussion makes me think that maybe
deducing geometric sequences is too much magic as well.

Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

On 03/23/2012 05:30 AM, Patrick R. Michaud wrote:
 On Fri, Mar 23, 2012 at 03:03:09PM +1300, Martin D Kealey wrote:
 Question: do we support
 
  1, 2i, -4 ... 256
 
 I think this ought to work, but for some reason Rakudo on my system
 hangs whenever I try it.

The problem was that infix:!= hung with Complex numbers, because it
was defined for each numeric type, but the Complex candidate was
missing. Thus the most general candidate called .Numeric on its
arguments, re-dispatched, and looped infinitely.

Fixed in 2012.03-3-g4a247b1, and tested in S32-num/complex.t.
This also fixes the sequence 1, 2i, -4 ... 256.

Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

On 03/22/2012 11:51 AM, Daniel Carrera wrote:
 On 22 March 2012 11:02, Carl Mäsak cma...@gmail.com wrote:
1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64

 That last one doesn't work on Rakudo :-(

 And it never will. Note that 100 is not a power of 2, and that the
 goal needs to match exactly. This is because smartmatching is used,
 ...
 If you're wondering why things are factored in this way, it's because
 previous versions of the spec that tried to special-case 100 to work
 in cases like the above, ended up not working out. It turned out that
 the unification of infix:... and smartmatching was what did work. It
 has the slight drawback that we have to educate users to write * =
 100 instead of 100 in the case of not-exactly-matching goal states.
 But it's still a net win, because this unified semantics works better
 than anything we had before.
 
 But that's a bit of a problem if I *don't* want a value higher than 100.

Then exclude it: 2, 4, 8 ...^ *  100

Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

Am 22.03.2012 17:07, schrieb Bruce Gray:

I have run into the same need for something like :index, while
playing with RosettaCode tasks like Continued_fraction.


If you want the index, don't use series. It's easy enough to access the 
array elements yourself. You can do something like


my @a := (1..*).map: - $i {
$i ** 2 + @a[$i - 1] // 0;
};

to access previous elements.  You can even use 'last' inside the map 
block to get out of the loop.




Well, it works in Niecza. It does not (yet) work in Rakudo:
15:25 Util perl6: my @squares := 0, (- *@a { @a.elems ** 2 }) ... *;
say ~@squares[^11];
15:25 p6eval ..niecza v15-4-g1f35f89: OUTPUT0 1 4 9 16 25 36 49 64
81 100NL
15:25 p6eval ..rakudo 1a468d: OUTPUT0 0 0 0 0 0 0 0 0 0 0NL


higher-arity sequences are a known regression in rakudo, 
S03-sequence/limit-arity-2-or-more.t currently isn't run.




After writing all the above, it occurred to me that the use of @_ should
implicitly define a closure as slurpy/n-ary.


It shouldn't only, it does already (in all rakudo pugs niecza).
The future is already here, it's just unevenly distributed.


Cheers,
Moritz

Re: How to make a new operator.

[Moritz Lenz]

On 03/21/2012 09:07 PM, Daniel Carrera wrote:
 Hello,
 
 Is it possible to create a new range operator ':' such that:
 
 a:b is the same as a..b  (this is the easy part)
 
 a:b:c is a range from 'a' to 'b' by steps of 'c'. For example, 2:15:3
 == 2,5,8,11,14

That can be done by giving the new infix:: operator list associativity
(niecza already supports this)

 :b is the same as 0..b

create a new prefix operator... except that that prefix : is already
taken for constructing pairs

 a: is the same as a..Inf

create a postfix:: operator... except that postfix : is already taken
as invocant marker

 ::c is the same as 0:Inf:c

create a prefix::: operator. Except that this collides with existing
syntax...

 : is the same as 0..Inf

create a term::.


There are hooks for all of that, but it requires you to come up with a
new syntax that doesn't collide heads-on with lots of existing grammar
rules.

Cheers,
Moritz

Re: DBC-ish PRE and POST phasers, spec clarifications

[Moritz Lenz]

On 03/11/2012 03:21 AM, Damian Conway wrote:
 Carl asked:
 
class A {
method foo($x) {
PRE { $x  10 }
# ...
}
}

class B is A {
method foo($a, $b, $c) {
PRE { [] $a, $b, $c }
# ...
}
}

 When CB.foo is called, are both CPRE blocks meant to be run?
 
 No. Contractual constraints are only inherited by methods of the
 same signature.

And here the problem already starts. Signatures with where-blocks can't
by compared by a Turing machine. At least we know which signatures we
can compare and which we can't. So we need to think about that case too.

 BTW, that example isn't Liskov substitutable, so it really doesn't
 matter what it does under DbC. ;-)
 
 Also, it would be much better if such cases issued a warning in Perl 6,
 rather than just silently hiding the inherited method and thereby
 breaking the shared polymorphic interface of the hierarchy.

+1

Though of course then we need a mechanism to silence that warning.


 For a start, PRE- and POST- inheritance should only occur when a derived
 method does indeed have the same signature as some base method, and then
 only from that identically signatured method. Secondly, PREs have to be
 inherited disjunctively (i.e. be allowed to weaken), rather than being
 conjunctively accumulated (i.e. being forced to to strengthened).
 
 
 In fact, method-level CPRE and CPOST cease to be a concept, CPRE
 and CPOST submethods can be handled delicately in a corner of the
 MOP somewhere, the abomination that is CCALL-VIA-DBC goes away, and
 all that we're really left with are block-level CPRE and CPOST
 phasers, which already seem like they could work.

 So, what do y'all think?
 
 
 I think this is probably the only reasonable way forward at the moment.
 What we've proposed as a DbC mechanism in the spec can't be implemented
 for all the reasons Carl enumerated so well.
 
 However, I'd also want the spec to remove all reference to DbC when talking
 about PRE and POST. Or, better still, to state explicitly that PRE and
 POST do *not* have DbC semantics when applied to methods (perhaps even
 using some of the examples above to illustrate why not).
 
 And if we are ever to properly supply DbC, then I think we'd also want
 to explicitly reserve--but not spec--the phaser names REQUIRE and ENSURE
 for possible later use (either in-core or via a future 'use contracts'
 pragma or module that some heroic soul may attempt write. ;-)

I think we reserve all-caps names anyway, though I can't find the
reference to it right now.

 
 On the other hand, because DbC requires and ensures are really
 much more like (inheritable) traits of a method's signature,
 rather than phasers tied to the method's block, it seems likely that
 any eventual DbC mechanism should not use phasers at all. So perhaps
 we ought to reserve the traits 'will require' and 'will ensure' so that the
 eventual DbC mechanism could be specified like so:
 
 class A {
 method foo(Num $x -- Num $result)
   will require { $x  10 }
   will ensure  { $result  $x }
 {
 return 2 * $x;
 }
 }
 
 class B is A {
 method foo(Num $x -- Num)
   will require { $x  100 }
 {
 return $x+1;
 }
}

Just a small syntax nit: I think your example of 'will require BLOCK' is
a violation of the rule that we shouldn't have two terms in a row.
Probably better to go with 'requires' and 'ensures' traits right away:

method foo(Num $x -- Num $result)
  requires { $x  10 }
  ensures  { $result  $x }
  {
 return 2 * $x;
  }


 And, yes, this does indeed imply a syntax for optionally naming the
 return value in a signature (which syntax seems to fall out quite
 naturally in any case).

Or we simply reuse the convention from POST and CATCH that the
interesting value (either exception or return value) is passed in as $_.

Re: Setting private attributes during object build

[Moritz Lenz]

On 02/01/2012 11:41 PM, Carl Mäsak wrote:
 Getting back to the topic of the original post: I think blessall is
 a bad name for what's proposed, and I don't see a fantastically large
 need for that functionality. What's wrong with just defining a BUILD
 submethod in the class?

The current approach is violating the DRY principle. When you write a
.new method that wants to initialize private attributes, you have to
repeat all their names again in the signature of your BUILD submethod:

class A {
has ($!x, $!y, $!z);
method new($x, $y, $z) { self.bless(*, :$x, :$y, :$z) }
submethod BUILD(:$!x, :$!y, :$!z) { } # is this repetition really
needed?
}

It also means that private attributes are less convenient to work with
than those with accessors, which IMHO is a not signal in the right
direction.

Cheers,
Moritz

Re: Setting private attributes during object build

[Moritz Lenz]

On 02/02/2012 07:40 AM, Damian Conway wrote:
 My point was that I don't want the named arguments that BUILD can take
 to be restricted to only the names of public attributes...which was, I
 thought, yary's complaint when writing:

No, the complaint was that when you write self.bless(*, |%named) in your
method 'new', then you have to list each private attribute as

submethod BUILD(:$!a, :$!b, ...) { }

in order for them to be bound to their values.

This is necessary since the change that private attributes cannot be
initialized from the default 'new' constructor, because it's 'bless' (or
the 'BUILDALL' that bless calls) that distinguishes private and public
attributes, not 'new'

Re: Encapsulating the contents of container types

[Moritz Lenz]

Am 09.09.2011 12:44, schrieb Carl Mäsak:

Non-rw attributes, non-rw parameters, and non-rw return values all
share the same mechanism. Fine. Makes sense.

[...]

Non-rw-ness in this case should be all the way, not one level down.


(I hope I didn't change the meaning by stripping parts of your quote).

Woah there. Every routine that returns something mutable would have to 
indicate that in its signature, and there are a lot of routines that 
return mutable objects, or lists thereof (map, sort, grep, first, 
constructors of ref types, ...)


That would basically move Perl 6 to a level where you have to declare 
mutability in an almost Haskell-ish way.


I think we should consider the implications of 
immutability-all-the-way-down before we jump to any conclusions. In 
particular list cases where typical Perl 5 code fails when ported to Perl 6.


Basically any code that deals with file handles, database handles, 
statement handles etc. (all mutable objects) would need to take care 
while passing them around, because a single non-rw return would render 
them immutable, and thus useless.


I used to be in favor of the immutability approach, but the more I think 
about its effect on actual code I've written in the past, the more I get 
scared by the thought.


Cheers,
Moritz

Re: More bugs or PEBKAC

[Moritz Lenz]

On 09/05/2011 09:03 PM, Carl Mäsak wrote:
 1parrota ():
 1. Should there be a way to make die behave like the Perl 5 version,
 reporting the place of death unless the message is terminated by \n ?
 The \n no longer suppresses the location indormation. I can't find a
 definition either way in the Synopses.
 
 Yes, there should.
 
 The problem is one of the perfect being the enemy of the good. People
 pretty much agree that the mechanism shouldn't be governed by \n at
 the end of the error string, but no-one has suggested anything
 significantly more attractive either. So here we are, currently
 without a way to get die (and warn) without location information.

FWIW the current factoring allows the catcher of the exception to
control whether a backtrace is printed. A solution is thus to catch
exceptions on the outermost level of your program, and print the
exception (but not the backtrace) there.

A cheap (but probably wrong) approach would simply be a named argument
to die, like

die 'OH NOEZ', :suppress-backtrace

But as Larry usually points out, such a modified behavior is often a
sign of design smell.

And I guess that's what happens here: we conflate two concepts here:
Error messages that usually stem from errors that the programmer made,
and error messages for things that the user did wrong (and which I guess
is the reason one wants to surpress backtraces -- are there others?)

So I guess the exception object could contain a hint whether the error
is a user error or a programming error. All those errors that are thrown
by the Perl 6 compiler count as programming error, but we can still
provide a X::UserError class, which disables printing of backtraces by
default.

The question is if we provide a separate sub for such cases (error() or
report-error() or so), or if we rely on something like

UserError.new(message = 'You did something wrong here').throw

or something similar.

Cheers,
Moritz

Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)

[Moritz Lenz]

Am 24.08.2011 11:33, schrieb Carl Mäsak:

Damian (), Moritz (), Smylers ():

... why hidden_from_backtrace instead of hidden-from-backtrace?


... low-level things are spelled with underscores, while we reserve
the minus character for user-space code.


So the idea is that if Perl 6 has an identifier zapeth_clunk itself that
leaves zapeth-clunk free to be used by developers to mean something
else?


Not much of a problem in Perl 6 in the first place; built-ins from the
setting are considered to be lexical declarations from a block outside
of the mainline program code, and any declarations made by the
developer will just shadow these.

No, my understanding is that the naming convention is there to
separate stuff API stuff from internals stuff:

   dashes
 this is part of the Perl 6 API -- feel free to call it
   underscores
 this is an internal function -- unless you're doing something
internal yourself, you shouldn't call it

To me, it has a nice visual mnemonic, since underscores themselves are
more low-level.


That's how I understood it too, but wasn't able to phrase it so nicely.


Of course, it remains to be seen whether this convention is (a)
useful, (b) correctly guessing the boundaries between API and
low-level, or even (c) consistently applied within the spec.


(c) is false, I'm quite sure. I'm all for cleaning it up, once we agree 
on a naming scheme



Damian (), Patrick (), Smylers ():

I'd like there to be a more consistent approach than that


+1 to consistency.


Could we have underscores and hyphens mean the same thing? That is, Perl
6 always interprets illo-figut and illo_figut as being the same
identifier (both for its own identifiers and those minted in programs),
with programmers able to use either separator on a whim?

That would seem to be the most human-friendly approach.


It's not machine friendly. It means you can't easily dispatch methods by 
looking them up in hash, you first have to name-mangle. And consider how 
often you call methods in Perl 6 (like, all the time), that wouldn't be 
nice at all.



Maybe, but in my humble opinion that wouldn't promote consistency in
user code. Also, the name mangling needed to do this would waterbed up
*somewhere* and likely cause new, interesting kinds of pain.


Like interoperation with other languages. What if you call methods from 
a language that doesn't have this name mangling rule (like, all of 
them)? Suddenly you must be careful where you didn't have to be careful 
before. So a best practice would evolve that you always be careful in 
the first place, and the whole idea is being frowned upon.


Let's take a shortcut, frown upon the idea right now, and don't spec it :-)

Cheers,
Moritz

Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul

[Moritz Lenz]

Am 23.08.2011 10:46, schrieb Damian Conway:

It's a trivial point, but why hidden_from_backtrace instead of
hidden-from-backtrace? Especially given that the associated
method is is-hidden, not is_hidden?


The current stance seems to be that low-level things are spelled with 
underscores, while we reserve the minus character for user-space code. 
Try grepping the specs for identifiers of built-ins that have a minus in 
it -- I didn't find any in a quick search.




And why is this entire message written in questions?


Is it? I'm afraid I don't understand what you mean.

See 
https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 
maybe it's a charset problem on your machine, or something.


Cheers,
Moritz

Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul

[Moritz Lenz]

Am 23.08.2011 10:56, schrieb Moritz Lenz:

And why is this entire message written in questions?


Is it? I'm afraid I don't understand what you mean.


Never mind?

Re: Encapsulating the contents of container types

[Moritz Lenz]

On 08/21/2011 06:00 AM, Darren Duncan wrote:
 Patrick R. Michaud wrote:
 On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote:
 I believe the general solution to this problem is to make all
 objects immutable, with the only exception being explicit
 references, and so mutating an object isn't an option; rather you
 have to derive a new object.

 Values of all types should be immutable, even if that type is
 Array or whatever, and only Variables should be mutable.
 ...
 
 To make sure I understand correctly, you're essentially
 saying that @a.push(3) should not modify @a directly -- someone
 would have to write something like
 
  @a = @a.push(3)  # or @a .= push(3)
 
 And to do a shift, one would have to do something like
($value, @a) = @a;
 since @a.shift would be unable to mutate the array.  (I'm not 
 exactly sure what pop would look like.)
 
 Is that correct?
 
 Yes, that's what I'm saying.
 
 And we've already been making moves in that direction.

Moving into the direction of immutability doesn't help with the problem
at hand -- it only helps here if we force everything(*) to be immutable,
or at least encapsulating every mutable object into special types, like
Monads in Haskell.

(*) ok, not everything, but everything that can be stored in an object

And I'd be very disappointed if Perl 6 turned into Haskell so late in
its development stage (remember that we have working compilers, a
growing number of modules and active users), especially since it's not
tailored to be a language that is tailored towards immutability.

Cheers,
Moritz

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: Bug?

[Moritz Lenz]

On 07/14/2011 11:47 PM, Parrot Raiser wrote:
 When a subroutine is invoked with an empty parameter list, as follows:
 
 run_stuff();
 
 sub run_stuff {
 my ($parm) = @_;
 say Parameter is $parm;
 }
 
 @_[0] contains Any().

Not Any(), but Any (which say() prints as Any() to ease debugging)

 Should it?

Yes.

Re: Base conversion: not enough rope

[Moritz Lenz]

On 05/06/2011 10:25 PM, Carl Mäsak wrote:
 S02:3185-3280 does a nice job of explaining what can and cannot be
 done with the radix syntax (i.e. :21010 etc). I'm left with two
 questions, however:
 
 * If :21010 is the way to way to interpret a string as a number in
 base two, giving the number 10 -- what's the way to go in the other
 direction?

Sounds like a job for sprintf of fmt.

 * What's the way to interpret a number of some *parameterized* base $r
 ? The syntax :$r123 is legal, but doesn't have anything to do with
 base conversion.

FWIW in NQP you can cheat and reuse the internal function of the compiler:


09:24  moritz nqp: use NQPHLL; say(HLL::Actions::string_to_int('14', 8))
09:24 +p6eval nqp: OUTPUT«12␤»

I think in the end it should come down to exposing more number parsing
primitives as functions or methods.

On a related note, we had this discussion about a generic string parser
that would parse any Perl 6 literals, but I don't know if it ever got
specced.

If such a function exists, you could call literal(:{$base}123), and
have no fear of code injection like you'd have to have with eval.

Cheers,
Moritz

Re: eval should throw an exception on compile error

[Moritz Lenz]

On 05/07/2011 07:45 AM, Michael G Schwern wrote:
 I was just playing around with eval, trying to figure out if you can define an
 operator overload at runtime (seems you can't, good) and noticed this in the
 spec... [1]
 
 Returns whatever $code returns, or fails.
 
 How does one get the compile error from an eval? 

It's in $!, like all other errors.

 I don't see anything in the eval tests [2] that's checking for the error,
 just that it returned false.
 
 In addition, I'm surprised that eval doesn't throw an error when it fails.

I agree that eval shouldn't be catching errors, that's what try { } /
CATCH are for (and i know that other #perl6 regulars things similarly).

I dimly recall that Larry had an objection, but I can't remember what it
was :(

Cheers,
Moritz

Re: lol context and X

[Moritz Lenz]

On 03/31/2011 11:16 PM, Aaron Sherman wrote:
 # parens on the arglist causes flattening?
 $ ../rakudo/perl6 -e 'for 1 .. 2 X 4 .. 5 - ($a, $b) { say $a.perl, $b.perl 
 }'
 Not enough positional parameters passed; got 0 but expected 2 in sub-signature

The error message already tells you that you wrote a sub-signature.
I'm not sure what positional parameters in a sub signature should mean
though - do you?

 # Lack of parens gives lol context?

Rakudo doesn't properly implement lol context, so probably not.

 $ ../rakudo/perl6 -e 'for 1 .. 2 X 4 .. 5 - $a, $b { say $a.perl, $b.perl }'
 14
 15
 24
 25

looks more like flattened to me.

 # Default context is flat?
 $ ../rakudo/perl6 -e 'for 1 .. 2 X 4 .. 5 { say .perl }'
 1
 4
 1
 5
 2
 4
 2
 5

yes.

Cheers,
Moritz

Re: spell check in code

[Moritz Lenz]

On 03/17/2011 09:55 PM, Darren Duncan wrote:
 It occurs to me, both from my own experience in writing code as well as seeing
 some production code by others, that spell-checking may be useful in 
 programming
 languages.
 
 To be specific, often user-defined entities such as variable or routine names 
 or
 attribute names or type names may be declared with dictionary words, but
 sometimes they may be misspelled, and programmers may not always spot this.
 
 I think it would be useful for programming language implementations to 
 provide 
 the option to flag entity names that appear to be mis-spelled dictionary
 words for programmers.

Depends on what you mean by programming language implementations. If
you are talking about tools like lint, I fully agree. If are talking
about the compiler, I'm afraid I have to disagree -- it's not their job.

The good news is that we already have STD.pm6, which gives you parse
tree and makes it rather easy to extract identifiers. You can write such
a tool today.

And even better, since niecza uses STD.pm6 for bootstrapping (*), you
can even write such a tool in Perl 6 today. Have fun!

(*) actually a slightly simplified version, but still quite the same in
structure

Cheers,
Moritz

[perl #81548] [BUG] Can't do 'handles' on a type in Rakudo

[Moritz Lenz via RT]

FWIW 'has $!a handles TypeObject' is now implemented, and works fine for
roles.

It doesn't work for classes, because they have a .new method. So the
standard .new is overridden, trying to call the .new on an attribute,
but since there's no instance yet, the access to the attribute fails.

That's a conceptual problem and needs a spec resolution.

One possible approach would be to only install methods not yet present
in $?CLASS or its superclassess any better ideas?

Moritz

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

Re: exponentiation of Duration's

[Moritz Lenz]

Am 17.11.2010 10:31, schrieb Kris Shannon:

A recent rakudo commit [1] is a quick fix for #78896 [2] to allow
exponentiation of Duration's.


And it did so with a real world use case in mind.


I'm uneasy with allowing this and I think the spec probably meant not
to but is badly worded [3]:

  Durations allow additive operations with other durations, and allow
  any numeric operation with a number as the other argument:

  $duration * $duration# WRONG, durations aren't geometric
  $duration * 2# ok, a duration twice as long
  2 * $duration# same

What are your thoughts?


I've summarized my thoughts here, before I read your email: 
http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html


Another example: current Duration % Duration is forbidden. But I have a 
very good use case:


suppose I want to organize a 60 minutes session, and it's filled with 
presentations, each 8 minutes long. How long do I have for the 
introduction, if I fit in as many presentations as possible?


The operation $session_duration % $presentation_duration answers me 
that. Why am I not allowed to carry out that operation? Because some 
designer thought I'd be better off not doing that operation. Wow, 
awesome reason/sarcasm.



[1] 
https://github.com/rakudo/rakudo/commit/d9e22463479927fa8f1f594753979022de35970d
[2] http://rt.perl.org/rt3/Ticket/Display.html?id=78896
[3] 
https://github.com/perl6/specs/commit/32abb95b9776e1cb7672c8a6a77612c86b37aea2#L0R1333

Re: exponentiation of Duration's

[Moritz Lenz]

Am 17.11.2010 12:55, schrieb Richard Hainsworth:

On 11/17/10 14:03, Moritz Lenz wrote:

Am 17.11.2010 10:31, schrieb Kris Shannon:

$duration * $duration # WRONG, durations aren't geometric
$duration * 2 # ok, a duration twice as long
2 * $duration # same

What are your thoughts?


I've summarized my thoughts here, before I read your email:
http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html


Ignoring the sarcasm, Moritz's blog and reply seem reasonable about what
should be defined by perl.


Please note that my sarcasm applied only to one particular sentence, not 
to the whole mail :-)



Once a number has been generated, viz., by obtaining a duration, that
number can be manipulated however necessary. The interpretation of the
number is a matter for the programmer, not the language designer.

To illustrate, lets take a different problem. Suppose we have lengths in
$x and $y, then the dimension of $a = $x * $y is of area, not of length.
Is it really consistent to forbid $x = $x * $y in case the $x may be
mistakenly interpretted as a length and not an area?

In the same vein, $duration * $duration has the physical dimension of
duration squared. True that is not the dimension of duration, and so
assigning it to a duration variable might cause a problem of physical
interpretation.


Indeed.

Just as a data point, in physics duration squared does exist.

Just think of the definition of acceleration, which is the second time 
derivative of position. Approximation of derivative as a finite fraction 
makes it a = x / t^2.

(And I might add that it also appears in force, energy and power that way).


Neverthless, it doesn't seem to me that trapping dimension errors is
something a programming language should be doing.


Thank you for phrasing it much better than I managed to.

Cheers,
Moritz

Re: exponentiation of Duration's

[Moritz Lenz]

Am 17.11.2010 14:02, schrieb Oha:

On 11/17/2010 01:46 PM, Moritz Lenz wrote:

Just as a data point, in physics duration squared does exist.

On the other hand, i can see why an Instant can't be used as a linear
value: it does not have a clear origin (or zero value).


That's correct, and the reason that nobody argued for changing Instant 
so far.



Therefore the multiplication of two Instant may results in different
results based on where you place the zero, unless you first convert
the Instant in a Duration (e.g. seconds since 1 jan 1970)


Right. And therefore having to do the conversion explicitly is a good 
thing -- you immediately see which epoch was used.


Cheers,
Moritz

Re: exponentiation of Duration's

[Moritz Lenz]

Am 17.11.2010 15:20, schrieb Oha:

On 11/17/2010 02:56 PM, Carl Mäsak wrote:

Or, by Ockham, since Duration is now deprived of its only task --
making life harder for the programmer -- remove it altogether from the
language and just put a number type in its place, representing number
of seconds.

I could be wrong but this reminds me that a Duration could not be only
based in seconds, but also in other units (which may automagically be
converted to seconds)


That's indeed a possible use case, but no such thing is specced at the 
moment.



and also those seconds may be leap or not.


They are not. As S02 says.


Maybe the point is that really the power of a Duration should not be
performed, unless you coerce the Duration in a specific unit value?


S02 is pretty explicit that usage of Duration as a numerical value 
assumes seconds as a unit.



Extending a bit more, does an Instant be specified in a TimeZone?


Read S02.


Could
an Instant be incremented by Day units?


Only if you define a day as 24 * 60 * 60 seconds.


What happen if this increment
change from daylight saving to normal time?


Instants and Durations don't have such a concept. Please read S02.

Cheers,
Moritz

Re: exponentiation of Duration's

[Moritz Lenz]

Am 17.11.2010 17:50, schrieb Jon Lang:

If I'm following this correctly, shouldn't we just say that Duration
does Num?


Num is a class (think floating point number).
The role you're looking for is probably either Numeric or Real.

If we say that Duration inherits from Rat or FatRat, it automatically 
does both roles.



 That way, a Duration can be used exactly like a Num is
(with units measured in seconds); but it could also have special
capabilities above and beyond what a Num can do, if such capabilities
are needed.


Right. That's what role composition, inheritance and possibly other 
forms of subtyping are about.



More generally, I wonder if maybe we _should_ provide a tool to help


I think this question can only be answered in a meaningful way if 
somebody actually implements such a thing as a module (which should be 
entirely possible in Rakudo right now). Then we'll see if people take it 
up and use it.



That said, it's possible that this would open up a can of worms.
Would it?


Another reason to prototype it as a module.

Cheers,
Moritz

Re: base-4 literals

[Moritz Lenz]

On 11/16/2010 08:46 PM, Darren Duncan wrote:
 So, any thoughts on this?

A wonderful application for a module.

And don't we already have

:41230

for base 4 literals? With a simple scheme that can be used up to base 36?

Cheers,
Moritz
How thinks that Perl 6 should really become smaller over time, not larger

Re: Packed arrays and assignment vs binding

[Moritz Lenz]

On 11/14/2010 03:46 AM, Mason Kramer wrote:
 I understand everything you've written except the following:
 
 On Nov 13, 2010, at  12:09 PM, Jonathan Worthington wrote:
 
 Hi,
 ...
 
 my Int @x;
 
 Where we get an array of scalar containers, each of which is only allowed to 
 contain an Int (strictly, something that Int.ACCEPTS(...) hands back true 
 on).
 @x[0] = 1;
 @x[0] := 1;
 
 In the first, we look up the container in slot 0 or the array and assign a 1 
 into it. In the second, we bind a 1 directly into the slot. There's no 
 container any more (so any future assignment attempts will fail, for 
 example).
 
 ...
 
 Jonathan
 
 
 What's a 1?  If it's not an Int, I don't know what it is.  If it is an Int, I 
 don't understand how you could bind it into a packed array.

On IRC, Jonathan said that 1 is basically an Int, which is something
like a boxed int. So whatever operation works removes the box, and puts
the result in the variable.

However I wonder how well that's going to work, since Int can store
arbitrarily large integers, while int can't.
What happens on overflow?

Cheers,
Moritz

Re: Packed arrays and assignment vs binding

[Moritz Lenz]

On 11/13/2010 06:09 PM, Jonathan Worthington wrote:
 With packed arrays, however, I'm less clear what they mean. Since the 
 point of a packed array is compact storage, there's no chance to 
 actually have containers. Thus does assignment to a slot in a compact 
 array ever make sense? There's not a container to look up and store 
 things in.
 
 While I can happily convince myself that:
 
 @x[0] := 1; # works, just sticks 1 into the appropriate location
 @x[0] = 1; # dies, can't assign when there's no container
 
 Actually makes sense, I can also somewhat see users not liking it.

Indeed. As a user I think of the = operator as put the thing on the RHS
into the var (or array slot) on the LHS. I don't care about the
underlying container model. I just care that

1) the RHS now contains a 1
2) I don't get any spooky action at a distance.

I'd like those two points to remain the same for packed arrays.

 So my questions are:

 1) What semantics would users expect? Is it OK to say no, you can't 
 assign in this case?

see above

 2) If proposing that both should work, what, roughly, would that look 
 like at an implementation level?
 
 When answering (2), consider that:
 
 @x[0] = 42;
 
 Currently really means:
 
 infix:=(@x[0], 42);
 
 That is, we really do look up the container and then perform an 
 operation in it. So if you de-sugar it all, it's kinda like:
 
 VAR(@x[0]).STORE(42)
 
 So just saying oh, just given assignment semantics like binding ones 
 is not so simple, since it'd seem that we do not get anything we could 
 call .STORE on back from @x[0] from a natively typed array.
 
 Any thoughts? (Same questions/answers apply for natively typed 
 attributes in objects, or at least I'd be very surprised if they are 
 different.)

I don't have a good idea right now; just consider that whatever ends up
storing a 1 into the array also might need to do a coercion; after all
an Int is not an int. Maybe the two things (handling of assignment and
coercion) are somehow related?

Do we always know at compile time that a certain container is natively
typed? if yes, maybe we can automagically rewrite assignment to binding
at compile time...

If nobody comes up with a practical idea on how to solve it, I'd
grumpily accept only binding for storing things in a natively typed
container. We'd need a *VERY* good error message in that case.

Cheers,
Moritz

Re: IO Multiplexing

[Moritz Lenz]

Hi,

Am 12.11.2010 02:47, schrieb Ben Goldberg:

I would like to know, is perl6 going to have something like select
(with arguments created by fileno/vec), or something like IO::Select
(with which the user doesn't need to know about the implementation,
which happens to be done with fileno/vec/select), or only an event
loop.


The IO specification for Perl 6 is very suboptimal as is. On the one 
hand it's over-engineered, in that there's a plenthora of confusing 
roles that makes it hard to do anytyhing. On the other hand it's 
under-engineered in the sense that it doesn't even talk about 
non-blocking IO yet.


If that's a topic you know and care about, I'd welcome any contributions 
you can make to the spec. Don't be scared, it's just a collection of 
text documents :-)
So if you send me your github ID (get one if you don't have one), I'll 
give you commit access.



I would recommend that there NOT be any sort of fileno exposed to the
user, unless he goes out of the way to get it -- any function (in
particular, posix functions) should simply take a perl filehandle, and
that function in turn would pull out the fileno (or fail
appropriately, if the filehandle doesn't have a fileno).  If users
want to know if filehandles correspond to the same underlying file,
then there could be a method -- perhaps $fh.uses_same_desciptor($fh2),
or somesuch.


Agreed. A higher level interface than POSIX would be a good default, IMHO.


If there's a select() builtin (and I'd much rather that there not be
-- it should be hidden away in a class, like perl5's IO::Select), I'd
very much hope that it would take and return Sets of filehandles, not
vec packed strings.  I'd prefer there not be one[**]


As I tried to imply above, you can shape Perl 6 if you want. If you 
supply a superior alternative to select/IO::Select, people will happily 
implement and use it.



Lastly, if perl6 has an efficient enough built-in event loop, and
sufficiently lightweight coroutines (or maybe I should say fibers?),
then we might not need to have any kind of explicit multiplexing.


I'm not sure if the question about having an event loop is fully 
answered; there was some discussion about it in relation to concurrency 
and feed operators, but I didn't follow them too closely.


We certainly have coroutines in the form of gather/take.

I'm sorry for not commenting more on your actual proposals, which is 
mostly due to my lack of real-world experience with non-blocking IO.


Cheers,
Moritz

Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful

[Moritz Lenz]

On 11/09/2010 09:26 PM, TSa (Thomas Sandlaß) wrote:
 But doesn't
 
my $x = (1,2,3);
my $y = map {$^x * $^x}, $x;
 
 result in $y containing the list (1,4,9)? 

Not at all. The $ sigil implies a scalar, so what you get is roughly

my $y = (1, 2, 3).item * (1, 2, 3).item;

so $y ends up with a single list item of 9.

Cheers,
Moritz

Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful

[Moritz Lenz]

On 11/08/2010 01:51 AM, Darren Duncan wrote:
 Mason Kramer wrote:
 snip
 I want to propose one major change to the Bag spec: When a Bag is used as an 
 Iterable, you get an Iterator that has each key in proportion to the number 
 of times it appears in the Bag.
 snip
 
 You present some interesting thoughts here.  But I don't have enough time to 
 think about any implications to the point of agreeing or disagreeing with 
 that 
 change, other than to say that the proposal seems reasonable at first glance.
 
 However, if the above proposal is done, I would still want an easy way to get 
 the value-count pairs from a bag if I wanted them.

There'd be still .kv and .pairs.

Cheers,
Moritz

Re: Tweaking junctions

[Moritz Lenz]

On 10/22/2010 06:16 AM, Damian Conway wrote:
 That is, a C$value is an eigenstate of a C$junction if-and-only-if:
 
 $value !~~ Junction$value ~~ $junction

In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects. Or anything more complicated than the built-in value types.

 But the C!eigenstates method (as currently defined) does not return
 a list of such eigenstates. Instead it merely returns a partially-flattened
 list of the raw internal values of the junction...which is not (usually) the
 same thing at all.

Right; but afaict it's the only thing that can actually be implemented.
And because it doesn't make all too much sense, it's specced to be private.

Re: Tweaking junctions

[Moritz Lenz]

On 11/01/2010 12:41 PM, Damian Conway wrote:
 Moritz wrote:
 
 $value !~~ Junction$value ~~ $junction

 In general this definition makes it impossible to return a list of
 eigenstates from the junction. Just think of junctions containing Code
 objects.
 
 Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't
 check for identity between the two objects. Likewise the Regex ~~ Regex
 doesn't check for identity. Likewise Range ~~ Range testing for identical
 endpoints. Etc. ;-)

Sorry, I disagree. It's exactly what smartmatching was designed to be.
If you don't want that kind of behaviour, use infix:eqv or infix:===
instead.

 The definition of eigenvalues() is supposed to be abstractly
 descriptive, not specifically constructive. The idea is simply: any
 leaf state inside the junction to which the junction could collapse.

Junctions only collapse to Bool::True or Bool::False.

So an attempt to fix your definition could be

'any leaf state inside the junction, which makes the junction collapse
to True if compared to the junction as a whole'

but begs for a more concrete comparison rule. For which, IMHO
smartmatching would be nice, since I mostly use junctions for
smartmatching. Which brings us into the dilemma I mentioned before.


 Right; but afaict it's the only thing that can actually be implemented.
 And because it doesn't make all too much sense, it's specced to be private.
 
 Fine. But please change the name anyway.
 
 If we all agree it's not returning eigenstates, and some of us believe it
 *can't* every return eigenstates, then it certainly shouldn't be called
 C.eigenstates.

Agreed.

Cheers,
Moritz

Re: Tweaking junctions

[Moritz Lenz]

Food for thought, a few non-junction solutions:

On 10/22/2010 06:16 AM, Damian Conway wrote:
 # Find the list of common elements in two lists...
 sub intersection (@list1, @list2) {
 (any(@list1)  any(@list2).eigenstates;
 }

sub intersection(@list1, @list2) {
uniq gather for @list1 X @list2 - $a, $b {
 take $a if $a eqv $b
}
}

or

sub interseection(@list1, @list2) {
   (@list1 X= @list2).grep({ .key eqv .value}).key.uniq
}

Admittedly it's not as declarative, but it's explicit about the
comparison used (which is a plus, in my eyes).

If you want to use eq or ===, hash based solutions come to mind too.

 # Find the factors of a number...
 sub factors (Num $n) {
 ( $n/any(1..$n) ).eigenstates.grep({ $^q.Int == $q });
 }


sub factors($n) {
($n X/ 1..$n).grep: { .Int == $_ }
}

or

sub factors($n) {
   (1..$n).grep: { %n %% $_ }
}

 # Check for an unacceptable password, and list all when warning...
 constant UNACCEPTABLE = any  Godel Escher Bart etc... ;
 
 if $passwd ~~ UNACCEPTABLE {
 say Unacceptable password. Don't use any of these:;
 say UNACCEPTABLE.eigenstates¬».fmt(\t%s\n);
 }

constant UNACCETABLE = Godel Escher Bach;

if $passwd ~~ any UNCACCEPTABLE {
say Unacceptable password. Don't use any of these:;
say UNACCEPTABLE».fmt(\t%s\n);
}

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

[Moritz Lenz]

Am 30.09.2010 10:32, schrieb Carl Mäsak:

Moritz in the spec (), Damian ():

After lengthy IRC discussion, we concluded that it's a good idea to provide
some form of introspection that doesn't bother about perceived privacy
borders, provided that the implementation makes it feasible.


Wow, that's the first time I've ever been sorry not to be on IRC!

Talk about snatching (directly accessible) defeat from the jaws of
(encapsulated) victory. :-(


For what it's worth, we had exactly this discussion a couple of days
ago on IRC. I represented your views above, Damian.

  http://irclog.perlgeek.de/perl6/2010-09-22#i_2852991

To summarize, I consider myself having lost that debate. I even
demonstrate the complete unviability of my views (that privacy has any
kind of footing in Perl 6) with the below one-liner.

masak  rakudo: class X { has $!foo; has $!bar; has $!baz }; say
eval(X.new( foo =  1, bar =  2, baz =  3).perl.subst(X.new(, \{
).subst(/\)$/,  })).perl
p6eval  rakudo 8156be: OUTPUT«{foo =  1, bar =  2, baz =  3}␤»

As long as C.perl  works the way it does, there can be no real
privacy. And thus C.get_value  and C.set_value  are just convenient
access points for the same behaviour.


To re-iterate, Perl 6 has no real privacy by default -- both the 
default .new and .perl methods give you access to private attributes, 
unless you explicitly override them.



Could we at least specify that .get_value() and .set_value() can only
be called if the calling scope declares a Cuse MONKEY_TYPING;
so that violations of good OO practice are explicitly marked in a
consistent and easily searched-for manner?


I'm still undecided on whether or not I think Cuse MONKEY_TYPING;  is
the right way to enable this kind of privacy breakage. Maybe nothing
is needed, since the C^  in C$obj.^attributes  (or the CHOW)
already says warning! meta!.


The same goes for SomeClass.^add_method and the likes; we should make a 
general decision whether to allow metaclass access without 
MONKEY_TYPING, or maybe just restrict some form of metaclass accesses to 
MONKEY_TYPED scopes.


I would be fine with changing get_value and set_value method names to 
all uppercase, as an additional warning sign, if that would comfort you 
in some way.


Cheers,
Moritz

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

[Moritz Lenz]

Darren Duncan wrote:
 Carl Mäsak wrote:
 To summarize, I consider myself having lost that debate. I even
 demonstrate the complete unviability of my views (that privacy has any
 kind of footing in Perl 6) with the below one-liner.
 
 masak rakudo: class X { has $!foo; has $!bar; has $!baz }; say
 eval(X.new( foo = 1, bar = 2, baz = 3).perl.subst(X.new(, \{
 ).subst(/\)$/,  })).perl
 p6eval rakudo 8156be: OUTPUT«{foo = 1, bar = 2, baz = 3}␤»
 
 As long as C.perl works the way it does, there can be no real
 privacy. And thus C.get_value and C.set_value are just convenient
 access points for the same behaviour.
 
 I think then that .perl needs to be updated so it is more expressly limited 
 and 
 only works on some objects rather than on all of them.
 
 The way I see it, .perl is mainly about representing *value* objects in a 
 serialized form, and what it should produce is a value expression whose 
 execution results in an object which would eqv the original.

Are you using value object in the same sense as in the Perl 6
specification?

 Objects that you can't do that with don't make sense to be serialized and so 
 .perl can reasonably refuse to work on them.

method perl {
die Can't serialize objects of type $?CLASS, because ...;
}

 I don't think anyone can argue that every object of every class can 
 reasonably 
 be serialized with .perl and so it should only try where it makes sense.  Now 
 if 
 .perl is also savvy enough to take a reference to a subroutine and can 
 produce 
 the source code for said subroutine, I'd have a bit less of a case.

I don't understand the connection; How would you serialize an open socket?

 Bottom line, if .perl isn't supposed to work on 100% of objects then we 
 should 
 fix .perl so it doesn't break encapsulation.

+1. The question is: how?

My proposal: the default .perl method should only spit out value for
public attributes, ie those that have accessors. Maybe .new should also
default to his behavior.

 Or maybe so that we can have our cake and eat it too, there should be two 
 .perl 
 where the first is more restricted like I say and the second just dumps the 
 private attributes, and the second can only be used with MONKEY PATCHING.

1) please don't abuse MONKEY_TYPING for anything that might look like
dangerous
2) I find .perl very, very valuable in real world debugging; I don't
want to make it its usage any harder.

 Then Damian's position (which I support) is supported and so are monkeys.

Ook ook!
Moritz
(who actually writes Perl 6 code on a nearly daily basis).

Re: [perl6/specs] 761178: remove some some duplicate words words

[Moritz Lenz]

Patrick R. Michaud wrote:
 On Wed, Sep 08, 2010 at 04:02:10PM +0400, Richard Hainsworth wrote:
 I do want the diffs back: its the only way I have to keep at least
 some idea of what is changing any why.
 
 We know that a lot of people would like to see the diffs available
 through the commit messages, but afaik none of us actively maintaining
 the github archive quite know how to make that happen.  Something
 beyond please bring diffs back would be very helpful to us here.

Currently the Email service hook in github is enabled for the specs repo.

They are open source, see http://github.com/github/github-services for
details. Somebody could implement the include-the-diff feature, and make
the github folks apply the changes.

Or somebody could follow the feed and send emails to p6l, in which case
I'd disable the service hook.

Cheers,
Moritz

Re: [perl6/specs] 761178: remove some some duplicate words words

[Moritz Lenz]

Brandon S Allbery KF8NH wrote:
 On 9/7/10 08:17 , nore...@github.com wrote:
 Commit: 7611788411e5aff5f3ae150e2da9929ee546d6d8
 
 http://github.com/perl6/specs/commit/7611788411e5aff5f3ae150e2da9929ee546d6d8
 
 It was nicer when these contained the actual diffs like they used to,
 instead of forcing me to go poke at the tree.

Indeed. Any contributions to restoring that behavior are very welcome.

Cheers,
Moritz

Announce: Pugs repository move

[Moritz Lenz]

After years of neglected maintenance, we had to shut down the
pugs svn repository. It caused undue strain on the server that
hosted it, and made it nearly unusable.

Therefore we needed an alternative; since many active Perl 6
developers prefer git to svn anyway, we[1] decided to go with github.

Since the repository doesn't contain the Pugs compiler anymore,
it was renamed to 'mu', a pun on the type 'Mu', which in Perl 6
is the root of the type hierarchy.

Significant parts of the old pugs repo have been split up

/http://github.com/perl6/mu
/docs/Perl6/Spec http://github.com/perl6/specs
/t/spec  http://github.com/perl6/spectests

Other parts will slowly be split off, and moved to separate
repositories in the 'perl6' organization account. To keep maintenance
easier, all these repositories will have the same access control list.

If you want to have commit access to any of the perl6 repositories,
please send an email to me mor...@faui2k3.org with [perl6] in the
subject, or ask on the #perl6 IRC channel [2]. We are still working
on a better mechanism for adding contributors.

Since this move came rather unprepared, there are still a lot of
loose ends and broken links. I apologize for the inconvenience, and the
same time ask for help.

More news will surely follow in the next few days, so stay tuned for
updates.

Finally I'd like to thank Juerd for his long (and often thankless)
efforts to maintain the pugs repo, and the 'feather' server on which
it was hosted. It is certainly a less exciting task than writing a
compiler, but just as valuable for the Perl 6 community.

Cheers,
Moritz

[1] Actually, I decided, and nobody spoke up against it. If you're
not happy with that decision, feel free to decide otherwise, and
implement that decision
[2] http://perl6.org/community/irc

Re: regex and

[Moritz Lenz]

philippe.beauch...@bell.ca wrote:
 On the  operator... are you saying that it would operate basically as 
 expected... 
 allowing sets of rules and'ed rather than or's with the | ?

Yes, with the limitation that both parts separated by  have to match
the same length of string, so that for example

^ [ a+  . ** 3 ]

could only match exactly 3 a's. If you don't want to them tied to the
same length, you look-ahead assertions instead.

Cheers,
Moritz

Re: pattern alternation (was Re: How are ...)

[Moritz Lenz]

Darren Duncan wrote:
 David Green wrote:
 On 2010-08-05, at 8:27 am, Aaron Sherman wrote:
 On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak cma...@gmail.com wrote:
 I see this particular thinko a lot, though. Maybe some Perl 6 lint tool
 or another will detect when you have a regex containing ^ at its start, $
 at the end, | somewhere in the middle, and no [] to disambiguate.
 
 I think conceptually the beginning and the end of a string feels like a
 bracketing construct (only without symmetrical symbols).  At least that seems
 to be my instinct.  Well, it doesn't in / ^foo | ^bar | ^qux /, but in
 something like /^ foo|bar $/, the context immediately implies a higher
 precedence for ^ and $.  Maybe something like // foo|bar // could work as a
 bracketing version?
 
 Personally, I had always considered the ^ and $ to be the lowest precedence 
 things in a pattern. 

Meta characters don't have a precedence on their on - concatenation has.

Cheers,
Moritz

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Moritz Lenz]

Carl Mäsak wrote:
 * It is my feeling that such encapsulation-breakage shouldn't be
 allowed. Do you agree, p6l?

Time may proof me wrong, but I think it's not such a big issue.

Note that encapsulation can be broken in many ways already, wither with
MONKEY_TYPING or by using introspection techniques (which aren't fully
specced yet, but they *will* exist. In case of doubt you can just parse
.perl output).

 * If it isn't allowed, which of the two steps is disallowed?
 *Detaching* a method containing references to private accessor slots
 (thereby extending the syntactic restriction of no private accessors
 outside of the class block), or *attaching* an anonymous method to an
 object belonging to a different class than the one from which it was
 detached (thereby by necessity having to complicate anonymous methods
 somewhat)?

There's a third possiblity - $!foo being bound to the $!foo attribute of
the lexically enclosing class at compile-time. So that re-attaching
methods make them still refer to the old attribute. Not sure if it's a
good idea, just food for thought.

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

Re: S26 broken link

[Moritz Lenz]

Hi,

Offer Kaye wrote:
 The link to the S26 Synopsys on http://perlcabal.org/syn/ points to
 http://perlcabal.org/syn/S26.html which is a broken link - would it be
 possible to fix this?

I't not that easy, because we currently don't have tool to turn p6doc
into HTML. I can remove the link for now, if it's a concern to you.

 My apologies if this is the wrong place to ask this question.

For infrastructural discussions, the perl6-compiler might be better
suited, but we're not picky in here (I hope :-)

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

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/

Smart-matching and m//

[Moritz Lenz]

Consider

'abc' ~~ m/b/;

By current spec this would

1) temporary set $_ = 'abc'
2) call m/b/, which matches against $_
3) produce a Match object
4) calls .ACCEPTS($_) on the Match object
5) return False

Likewise

'abc' ~~ .uc

ends up comparing 'abc' to 'ABC and return False.

I guess that's not what we want, so there might be a need for a rule
preventing the .ACCEPTS call when $_ is used on the RHS.

(The previous spec with syntactic forms kinda solved the problem, the $_
topicalization re-introduced it).

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

Re: Smart match isn't on Bool

[Moritz Lenz]

Aaron Sherman wrote:
 In this code:
 
 given False {
   when True { say True }
   when False { Say False }
   default { say Dairy }
 }
 
 I don't think it's unreasonable to expect the output to be False.

In this code:

sub test() { True };

given 0 {
when test() { say OH NOEZ }
}

I don't think it's unreasonable to expect the output to be OH NOEZ.

 However, it actually outputs True. Why? Well, because it's in the
 spec that way. So... why is it in the spec that way?

Because you can't have a ponie, and eat it. Or so.

You can't please everyone, so we try to please at least some of the
people, and in the future you can expect a warning from a bare True or
False in a 'when', or on the RHS of a smart-match.

STD.pm already implements that warning, Rakudo doesn't. (But I'd
appreciate it if some brave soul could port the warning over to Rakudo,
shouldn't be too hard)

Cheers,
Moritz

Re: Suggested magic for a .. b

[Moritz Lenz]

Dave Whipp wrote:
 To squint at this slightly, in the context that we already have 0...1e10 
 as a sequence generator, perhaps the semantics of iterating a range 
 should be unordered -- that is,
 
for 0..10 - $x { ... }
 
 is treated as
 
for (0...10).pick(*) - $x { ... }

Sorry, I have to ask. Are you serious? Really?

Cheers,
Moritz

Re: Suggested magic for a .. b

[Moritz Lenz]

yary wrote:
 though would a parallel batch of an anonymous block be more naturally written 
 as
 all(0...10) - $x { ... } # Spawn 11 threads

No,

hyper  for 0..10 - $x { ... } # spawn as many threads
# as the compiler thinks are reasonable

I think one (already specced) syntax for the same thing is enough,
especially considering that hyper operators also do the same job.

Cheers,
Moritz

Re: Suggested magic for a .. b

[Moritz Lenz]

Dave Whipp wrote:
 Moritz Lenz wrote:
 Dave Whipp wrote:
for 0..10 - $x { ... }
 is treated as
for (0...10).pick(*) - $x { ... }
 
 Sorry, I have to ask. Are you serious? Really?
 
 Ah, to reply, or not to reply, to rhetorical sarcasm ... In this case, I 
 think I will:

No sarcasm involved, just curiosity.

 Was my specific proposal entirely serious: only in that it was an 
 attempt to broaden the box for the discussion of semantics of coercion 
 ranges.

I fear what Perl 6 needs is not to broaden the range of discussion even
further, but to narrow it down to the essential points. Personal opinion
only.

 Why do we assume that ranges iterate in .succ order -- or even that they 
 iterate as integers (and are finite). Why not iterate as a top-down 
 breadth-first generation of a Cantor set?

That's easy: Principle of least surprise.

Cheers.
Moritz

Re: series operator issues

[Moritz Lenz]

Am 23.07.2010 00:29, schrieb Damian Conway:

However, those *are* clunky and nigh unreadable, so I certainly wouldn't
object to having the index of the next generated element readily
available as an explicit variable in a series' generator block.

That would make all manner of evil both easier and cleaner.;-)


I'm still not convinced.

Yes, it would be convient, but I've yet to see a non-contrived example 
where it's actually necessary, and which can't be implemented trivially 
with other Perl 6 tools.


The series code is already rather complex (and thus slow), and having to 
add introspection to find out whether the production code object accepts 
a named parameter 'i' is not going to help in any way.


IMHO we are in the what can we add? phase, while we should be in the 
what can we take away? design phase.


Cheers,
Moritz

Re: series operator issues

[Moritz Lenz]

Hi,

Am 22.07.2010 17:18, schrieb Jon Lang:

When I last reviewed the writeup for the series operators, I noticed two issues:

First, why is the RHS argument a list?  You only ever use the first
element of it; so why don't you just reference a single value?


The idea is that you can continue series:

  1, 2, 3 ... 10,
  20, 30, ... 100,

etc.


Second, I'm trying to think of a simple and intuitive way to write up
a series expression for:

triangle numbers: 0, 1, 3, 6, 10, 15, 21, etc.


Use the right tool for the right job:

17:32 @moritz_ rakudo: say ~[\+] 0..6
17:32 +p6eval rakudo 925a9b: OUTPUT«0 1 3 6 10 15 21␤»


square numbers: 0, 1, 4, 9, 16, 25, 36, etc.


17:34 @moritz_ rakudo: say ~(1..10).map(* ** 2)
17:35 +p6eval rakudo 925a9b: OUTPUT«1 4 9 16 25 36 49 64 81 100␤»

Or with a bit of a math trick:

17:36 @moritz_ rakudo: say ~(1, { $_ + 2 * .sqrt + 1} ... 100)
17:36 +p6eval rakudo 925a9b: OUTPUT«1 4 9 16 25 36 49 64 81 100␤»



factorials: 1, 1, 2, 6, 24, 120, 720, 5040, etc.


17:33 @pmichaud rakudo:  say ~[\*] 1..6
17:33 +p6eval rakudo 925a9b: OUTPUT«1 2 6 24 120 720␤»


The difficulty that I'm running into is that there's no reasonably
straightforward way of computing a given term solely from the previous
one or two items in the list.


The difficulty you're running into is that you're trying to use the 
wrong tool for the job. Just don't use the series operator when it's not 
easy to use. Perl 6 has other mechanism too, which are better suited for 
these particular problems.


The series operator is intented to be a relatively powerful (and yet 
simple to use) tool to generate some common series. For other cases, the 
full power of Turing-complete Perl 6 stands at your disposal (to which 
you probably need to revert when you want both index *and* previously 
computed values, *and* can't rely on other operator magic).


Cheers,
Moritz

Re: r31755 -[S05] specifiy that .parse can invoke other subrules than TOP by name

[Moritz Lenz]

Hi,

Am 19.07.2010 04:20, schrieb Stéphane Payrard:

Note that I sent a patch to that effect to p6c Jun 2  in a mail titled
support of parsing from a non TOP rule


Either somebody applied it, or it was superfluous - :rulerulename 
works in Rakudo (though I don't know if it works in nqp-rx).

Anyway, thanks for your patch.


use Test;  grammar A { token hi { hi } };  ok   A.parse( 'hi',
:rulehi) eq 'hi',  Grammar.parse: :rulesomerule


Test passes.

BTW it's preferrable to use is($got, $expected, $message) instead of 
is($got eq $expected, $message), because the former gives better 
diagnostics if the test fails.


Cheers,
Moritz

Re: Suggested magic for a .. b

[Moritz Lenz]

Ruud H.G. van Tol wrote:
 Aaron Sherman wrote:
 
 Having established this range for each correspondingly indexed letter, the
 range for multi-character strings is defined by a left-significant counting
 sequence. For example:
 
 Ab .. Be
 
 defines the ranges:
 
 A B and b c d e
 
 This results in a counting sequence (with the most significant character on
 the left) as follows:
 
 Ab Ac Ad Ae Bb Bc Bd Be
 
 glob can do that:
 
 perl5.8.5 -wle 'print for {A,B}{c,d,e}'

Or Perl 6, for that matter :-)

 .say for A B X~ ('a' .. 'e')
Aa
Ab
Ac
Ad
Ae
Ba
Bb
Bc
Bd
Be

In general, stuffing more complex behaviour into something that feels
unintuitive is rarely (if ever) a good solution.

The current behaviour of the range operator is (if I recall correctly):

1) if both sides are single characters, make a range by incrementing
codepoints
2) otherwise, call .succ on the LHS. Stop before the generated values
exceed the RHS.

I'm not convinced it should be any more complicated than that. Remember
that with the series operator you can easily define your own
incrementation rules, and meta operators (like the cross meta operator
demonstrated above) it's also easy to combine different series and lists.

Cheers,
Moritz

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: r31050 -[S03] refine hyper dwimminess to be more like APL, with modular semantics

[Moritz Lenz]

Solomon Foster wrote:
 On Wed, Jun 2, 2010 at 3:52 PM, Aaron Sherman a...@ajs.com wrote:
 Is there some automatic translation of these examples into tests? If not,
 here's what they'd be:

 ok(( (1,2,3,4) «+» (1,2) ) ~~ (2,4,4,6) )
 ok(( (1,2,3)   «+» (1,2) ) ~~ (2,4,4)   )
 ok(( (1,2,3,4) «+« (1,2) ) ~~ (2,4) )
 ok(( (1,2,3,4) »+» (1,2) ) ~~ (2,4,4,6) )
 ok(( (1,2,3)   »+» (1,2) ) ~~ (2,4,4,6) )
 ok(( (1,2,3)   »+»  1) ~~ (2,4,4,6) )

 I tested these all with Rakudo, and they all currently fail, though I guess
 that's not shocking.
 
 ~~ (2, 4, 4) (for example) isn't actually supposed to work, is it?
 Certainly doesn't work in Rakudo and I've never seen a spectest
 written like that...

Even if it did, we try to keep the spectests as simple as possible, and
not relying on the finer points of smart matching (which traditionally
have changed rather often).

I tend to write such tests as

is ( (1,2,3,4) «+» (1,2) ).join('|'), '2|4|4|6', '«+» dwims by repeating
RHS';

etc.

the .join method is more basic than smart matching, and makes it very
obvious with what semantics the comparison happens.

Also you get good diagnostics from is() in case of failure (expected vs.
got in the output).

Cheers,
Moritz