Paradise Regained
Hello, The Pure and Declarative Syntax Defintion: Paradise Lost and Regained paper presented at Onward! 2010 talks about extensible grammars that are very similar to the grammars provided by/built into Perl 6: it appears Perl 6 already had the Paradise that the authors recently regained! The work described is part of the Spoofax Language Workbench, a platform for developing textual domain-specific languages with full-featured Eclipse editor plugins: With the Spoofax/IMP language workbench, you can write the grammar of your language using the high-level SDF grammar formalism. Based on this grammar, basic editor services such as syntax highlighting and code folding are automatically provided. Using high-level descriptor languages, these services can be customized. More sophisticated services such as error marking and content completion can be specified using rewrite rules in the Stratego language. This sounds very much like what has been envisioned for Perl 6. I wonder if the Perl6 team can leverage (in the future) the work done for Spoofax? Regards, Henry -- Henry Baragar Instantiated Software
Re: Rukudo-Star = Rakudo-lite?
Ruby anyone? See http://en.wikipedia.org/wiki/Rake_(software). Henry On August 9, 2009 11:44:24 am Austin Hastings wrote: How about Rake? =Austin Richard Hainsworth wrote: Referring to Patrick's blog about an official 'useable' version of Rakudo, a suggestion: Since Rakudo* (not sure how it is to be written) is intended to be a cut-down version of perl6.0.0 that is useable, how about Rakudo-lite? Its just that */star/whatever doesnt convey [to me] the fact that its a sub-set of of Perl6. -lite seems [to me] to be used to define a functional, but stripped down version of a larger spec. Richard (finanalyst) -- Henry Baragar Instantiated Software
Re: Amazing Perl 6
On May 27, 2009 01:52:58 pm Mark J. Reed wrote:
On Wed, May 27, 2009 at 1:42 PM, Daniel Carrera
daniel.carr...@theingots.org wrote:
sub postfix:! { [*] 1..$^n }
say 5!;
WOW!! That *IS* cool. Can you explain to me how it works? I figured out
postfix: myself, but the rest is obscure to me.
Key concepts:
1. placeholder variables. The ^ in $^n means it's a placeholder: no
predeclaration required, and placeholders in an expression are
assigned the passed-in arguments in serial order. (The sub could also
have been written more traditionally as sub postfix:!($n) { [*]
1..$n } .)
2. the range operator .. : $x..$y for integers $x and $y generates,
in list context, a list of the integers from $x to $y, inclusive.
3. the reduction meta-operator [...] : [OP](@list) collects the
result of applying OP to the elements of the list in order. That is,
assuming foo() is a binary sub, [foo](1,2,3,4) =
foo(foo(foo(1,2),3),4). So [+](@list) generates a sum of the listed
values, [*] generates their product, etc.
So, given the argument to !:
It might have been implied, but you kind of missed the discussion about the
ability to add new operators (and how they relate to other operators).
To recap (slightly differently) there are several impressive features that are
easier to explain and can be part of the build up to the factorial example:
Placeholder variables: non-declared and descriptive
Ranger operators: not so impressive and inherited from perl5 (etc.)
The reduction meta-operator [...]: nice syntax and no need to provide a
identity/seed element
A side discussion of other interesting meta-operators
User defined operators: overloading and novel mechanism of declaring
precedence (looser, tighter, etc.)
Finally, a simple slide where the factorial definition takes up the whole slide
and let the audience have a few moments of silence to let them figure it out
and to start to really appreciate the expressiveness/impressiveness of perl6
Henry
1. create a list of integers from 1 to that value (1..$^n)
2. multiply them all together ([*])
and of course a sub without an explicit return statement returns the
value of the last expression.
I do think captures are inherently impressive, but not easy to
explain...
Got a link?
Daniel.
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
On May 23, 2009 11:31:35 pm John M. Dlugosz wrote:
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
From rakudo:
sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()
Henry
Uh, @y is an Array of one item, that one item being Nil.
I think the intent was to be an empty list. Nil is not supposed to go
into lists, but to become nothing when used in such a way. Wrapping Nil
into a list when it wasn't a list at all to begin with is totally
missing the point. And where did the wrapping Array come from?
Good question, since Nil does Positional, as evidenced by rakudo:
say Nil ~~ Positional
1
Should report this as a bug?
Henry
At its
simplest, Nil is an object whose Positional personality shows an empty
list, and that's what the @ variable uses.
--John
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
, no matter how many Scalars I nested in this manner. So how does VAR work? It can't just wrap another level around the original object to cancel out the automatic indirection. It can't tell the compiler to generate different code, since the code knows nothing about this interesting property of scalars. Instead it must return a proxy that knows how to trigger the actual methods on the scalar, avoiding the forwarding behavior of normal method calls. === Is that right? Relying on rakudo again: my $x; say $x.WHAT Failure() my $x = Scalar.new; say $x.WHAT Could not find non-existent sub Scalar Regards, Henry Thanks for your help everyone. I hope to give back just as much, once I've caught back up. In any case, what I learn I will document for all who come later. --John -- Henry Baragar Instantiated Software 416-907-8454 x42
Re: Array variables as formal parameters ???
On May 22, 2009 06:55:49 pm John M. Dlugosz wrote:
Please take a look at
http://www.dlugosz.com/Perl6/web/passing_examples.html.
I think that in your Example 1, that you may be making too making too much
of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array.
Hence, @y and $x work the same beneath the surface and there is no extra
level of indirection.
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
See, no problems with f2().
Regards,
Henry
I started working through how the detailed behavior of the Capture and
passing rules need to work, and I ran into something that startled me.
There's no examples in S06 of formal parameters, other than the special
*...@slurp form, that is declared with a sigil other than a $. For example,
sub f1 ($x, @y, @z) { ... }
Before I get any farther with this line of thought, I want to know if
I'm missing something important.
Thanks,
--John
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
On May 23, 2009 04:10:49 pm John M. Dlugosz wrote:
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
I think that in your Example 1, that you may be making too making too
much of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type
Array. Hence, @y and $x work the same beneath the surface and there is
no extra level of indirection.
But... $x has an Item container, and @y doesn't !
From whence did it get its Item container?
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your
example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
From rakudo:
sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()
Henry
And if the argument types are viewed as constraints only, denoting
whether the call is acceptable but not changing anything about it, and
f2 is written as way above, the two functions would produce the same
output. Clearly they're not.
See, no problems with f2().
Good. Thanks.
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
On May 23, 2009 04:19:53 pm John M. Dlugosz wrote:
@y just means the argument must do the Positional role, so it's a
looser constraint than is Array. Equivalent is more like:
sub f2(Positional $x) { }
Thanks,
Jonathan
I'm finding a difference in how a Positional is bound to a plain item
variable.
If the paramter-argument bond is shown as:
my $x := @A;
how can the Item variable really bond directly to the Positional
object? It doesn't have STORE and FETCH methods. The item variable
forwards methods to the contained item, and a directly-bonded Array does
not.
If you think of parameters as being slots and the type information as being
conditions on the objects being put into the slot, then an object is allowed
to be put into a slot only if it meets those conditions. Once the subroutine
starts to run, then it uses the passed in object directly (e.g. the @A), but
with its own name (e.g. $x): no additional containers.
I think I'm assuming more is (can be) happening at compile time.
The delegation would have to be handled at run-time, rather than as
something the compiler knows about?
Defining the constraints happens at compile time, but everything else happens
at run time (including checking the constraints). For example (from rakudo):
sub f1(@y) {say @y.WHAT}; my $x = 1, 2, 3; f1($x); $x = 5; f1($x)
Array()
Parameter type check failed; expected something matching Positional()
but got
something of type Int() for @y in call to f1
in sub f1 (unknown:1)
called from Main (unknown:1)
Regards,
Henry
Regards,
Henry
Thanks,
--John
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: [Fwd: Re: junctions and conditionals]
On Wednesday, April 01 2009 07:38 am, Richard Hainsworth wrote: Right now, yes. I'm arguing that the way that they're designed to work doesn't DWIM. Try a slightly different example: 0 = $x = 1 # 0 is less than $x is less than 1. $x ~~ 0..1 # $x is in the range of 0 to 1. I submit that most people would expect these two statements to be conceptually equivalent to each other: they may go about tackling the issue from different angles, but they should always end up reaching the same conclusion. But as things stand now, if $x = -2 | 2, these result in two very different conclusions: the first evaluates as true, the second as false. This most certainly doesn't do what I mean until I have been indoctrinated into the intricacies of Perl and learned to think like it does - which runs directly counter to the principle of DWIM. When you say DWIM, I take it you mean that there is an assumption that $x is a point in a field (http://en.wikipedia.org/wiki/Field_theory_(mathematics)). As you have illustrated, junctions do no form a field. You would run into the similar problems if $x was a point in a ring (http://en.wikipedia.org/wiki/Ring_(mathematics)). Consider the ring of integers modulo 8: my Ring8 $x = 5 + 3;# evaulates to 0 say OMG, its 0! unless $x;# prints the message which does not DWIM if I am expecting $x to be part of a field. Maybe the problem is that junctions are too easy to create, which is causing people to confuse the mathematical structure of the space created by using a junction with that of the structure of the space of the underlying (non-junctioned) object. Regards, Henry
Re: On Junctions
Patrick R. Michaud wrote:
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the value of the hand is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ 21}.max;
Since the result of [+] is a scalar we don't need to 'map' it.
Assuming that .eigenstates exists it would then be
my $p = ([+] @p).eigenstates.grep({ $_ 21 }).max
Argh... the multiple personalities of the junction caused me to forget
that there is only one scalar! HB
Pm
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote:
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa = 21 $pb = 21) {
if ($pa $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
The blackjack program is an excellent example for junctions (and not so
good for sets, IMHO). The problem in the example above is that the
calculation of the value of a hand was not completed. The complete
calculation is as follows:
my $pa = ([+] @a).eigenstates.grep{$_ 21}.max
If the result is undef, then the @a hand is a bust, and comparing $pa to
a similarly calculated $pb is sane.
Henry
daniel
Re: On Junctions
of the schizophrenic junctions when
calculating the value.
Henry
ps. I am not sure that I am using valid perl6 syntax. In pseudo-perl5
I would do it as:
my $p = max grep {$_ 21} map {$_.eigenstates} [+] @p;
HB
Richard (finanalyst)
--
Henry Baragar
Principal
Instantiated Software Inc.
416-907-8454 ext 42
Re: r25541 - docs/Perl6/Spec
I am starting to get overwhelmed by the number of special names and I am
wondering why we need to have a flat naming space?
For example, wouldn't it be easier to remember (and to introspect) the
following?
$*SYSTEM.uid
$*SYSTEM.euid
$*SYSTEM.pid
$*SYSTEM.perl
$*SYSTEM.env
$*SYSTEM.program_name
$*SYSTEM.error_handle
$?COMPILER.vm
$?COMPILER.svm
$?COMPILER.perl
$?COMPILER.parser
$?COMPILER.setting
$?COMPILER.os_distro
$?PROGRAM.scope
$?PROGRAM.routine
$?PROGRAM.role
$?PROGRAM.class
This way we only have a few special names (objects?) that organize
everything in this synopsis.
Regards,
Henry
pugs-comm...@feather.perl6.nl wrote:
Author: wayland
Date: 2009-02-25 07:08:52 +0100 (Wed, 25 Feb 2009)
New Revision: 25541
Modified:
docs/Perl6/Spec/S28-special-names.pod
Log:
S28: Incorporated some more stuff from the old documentation lower down, and a few
variables from S02.
Modified: docs/Perl6/Spec/S28-special-names.pod
===
--- docs/Perl6/Spec/S28-special-names.pod 2009-02-25 05:31:24 UTC (rev
25540)
+++ docs/Perl6/Spec/S28-special-names.pod 2009-02-25 06:08:52 UTC (rev
25541)
@@ -50,6 +50,7 @@
$?CLASS # current class (as variable)
%?CONFIG # configuration hash
$=DATA# data block handle (=begin DATA ... =end)
+ $?DISTROS02 # Which OS distribution am I compiling under
$*EGID# effective group id
%*ENV # system environment
$*ERR S16 # Standard error handle; is an IO object
@@ -71,16 +72,20 @@
$?OSVER # operating system version compiled for
$*OSVER # operating system version running under
$*OUT S16 # Standard output handle; is an IO object
+ $?PARSERS02 # Which Perl grammar was used to parse this
statement?
$?PACKAGE # current package (as object)
$?PACKAGENAME S10 # name of current package
- $?PERLVER # perl version compiled for
- $*PERLVER # perl version running under
+ $?PERL S02 # Which Perl am I compiled for?
+ $*PERL# perl version running under
$*PROGRAM_NAME# name of the program being executed
$*PID # system process id
::?ROLE # current role (as package name)
$?ROLE# current role (as variable)
?ROUTINE S06 # current sub or method (itself)
+ $?SCOPE S02 # Current my scope
$*UID # system user id
+ $?VMS02 # Which virtual machine am I compiling under
+ $?XVM S02 # Which virtual machine am I cross-compiling for
Note that contextual variables such as C$*OUT may have more than
one current definition in the outer dynamic context, in which case
@@ -166,10 +171,11 @@
$^H - These were only ever internal anyway
%^H -
- $! Current exception (see LS04-control)
- $! $ERRNO $OS_ERROR - Can get some info from new $!
- $? $CHILD_ERROR-
- $@ $EVAL_ERROR - Just throws an exception now (see
LS04-control)
- $^E -
+ $! $ERRNO $OS_ERROR - Use shiny new $!
+ $? $CHILD_ERROR- Use shiny new $!
+ $@ $EVAL_ERROR - Use shiny new $!
+ $^E - Use shiny new $!
+ $^S -
$. $NR $*IN.input_record_number()
$/ $RS $*IN.input_record_separator()
$| $*OUT.autoflush()
@@ -203,14 +209,22 @@
ARGVOUT $*ARGVOUT Another IO object
@F @*INPLACE_AUTOSPLIT_FIELDS ..or some such
%ENV%*ENV
+ ${^OPEN}- This was internal; forget it
=head2 Old stuff for p5/p6 comparison
This section will eventually die, but for now, it contains some old information on which
-Perl5 special variables will turn into Perl6 special variables.
+Perl5 special variables will turn into Perl6 special variables. The reason they are
+retained is either:
-=over 4
+=over
+=item * Their status is undecided
+
+=item * They have some commentary on stuff that needs consideration
+
+=back
+
Because a blank entry in either column could be taken to mean either
not in Perl 6 or unknown, the information as presented
below presumes an entry in both columns for every entry.
@@ -229,29 +243,25 @@
Other organizational
schemes may become appropriate when the table is more complete.
-=back
-
*** XXX the columns seem to have switched! *
? ${^ENCODING}
+ ? ${^UNICODE} Pending S15 Unicode
-
- $^V $PERL_VERSION
- $] version + patchlevel / 1000 of Perl
