Re: S26 - The Next Generation
Damian Conway writes: It's Sunday evening and, as promised, here's the new draft of S26. Wow, thanks for that -- it's most impressive and I'm already excited about what it will allow and how it permits improved documentation. * Hence it must always parsed using full Perl 6 grammar: perl6 -doc Having a multi-character option preceded by a single hyphen doesn't play well with bundling of single-character options (such as perl -wle in Perl 5): * The above looks like a bundled version of -d -o -c. That some of those don't exist doesn't affect that impression: it isn't reasonable to expect a user to know all options before she uses any of them, so if she's seen some single-letter options but doesn't know about -doc then she will misinterpret -doc. * In order for -doc to work, 'long' options have to trump 'bundled' options with the same spelling. If a version of Perl 6 introduces all of the -d, -o, and -c options then -cdo, -cod, -ocd, and so on will all be synonyms but -doc will be completely different. Putting arbitrary restrictions on bundling order that aren't related to the options themselves is an irritating cognitive load: if you're adding the -c option to a program that already has -do it matters where you put the c. * If long options with single hyphens are permitted in general then a future version of Perl 6 may add new ones. That means that _no_ single-character option bundling is safe to use from a forwards compatibility viewpoint, because any sequence may become a long option -- and hence radically change semantics -- in future. Using double-hyphens for all long options disambiguates them from bundled short options, and is familiar to many users from other software which follows that convention. Indeed others (including S19) already seem to believe that two hyphens are needed: jerry gay writes: this is why it's spelled 'perl6 --doc' Smylers
Re: S26 - The Next Generation
Jon Lang writes: FWIW, the current proposal for aliasing blocks of ambient text is functional; it just feels a bit kludgey, Why? To me it seems the opposite: what could be more natural for delimiting a block of code than braces? and I'm a bit bothered by the fact that you can't alias any ambient text other than a code block. Can't is a bit strong: it's more that if you want to quote an arbitrary portion of code then you need to add some braces around it. But those braces are unlikely to harm the program. The exception is if you want to quote an 'unbalanced' portion of code, for example the start of a loop but not the entire loop. Do you consider that to be likely? how about saying that an ambient code alias is normally terminated by the next blank line or Pod directive (as per =for) Braces are more robust than blank lines; if aliasing a brace-delimited block I may unthinkingly edit it to have a blank line in the middle of it, on the basis that the blank line isn't significant to perl. (Whereas if I edit the braces then I've changed the program as well as its docs.) An alternative would be to have blank-line termination for an alias which _doesn't_ start with a brace (that is, doesn't have an opening brace on the following non-blank line). However that would likely confuse somebody who happens to add a brace to the line following the alias directive (perhaps inside a quoted string, or changing the brackets on a hash look-up, or in a regex) and unwittingly changes the alias from several lines to just a few characters in the middle of that line. Terminating at a Pod directive sounds plausible, unless anybody can think of a good reason to be quoting Pod as part of code? Let's see what others think. OK. I like the braces. I suggest initially only providing for braces, but with the possibility of later adding options to indicate other termination points if in practice there turn out to be many situations where the braces don't work well. Smylers
Synopsis 02: Range objects
Hi Perl 6 people.
I've been looking closely at the definition of the Range class in S02
and the current Rakudo implementation, and I have some comments...
It seems that there are two intended uses for this class:
Range A pair of Ordered endpoints
Lets call the above the interval definition.
The |..| operator now constructs a |Range| object rather than merely
functioning as an operator. Both sides are in item context.
Semantically, the |Range| acts like a list of its values to the extent
possible, but does so lazily, unlike Perl 5's eager range operator.
And this one the list definition.
It seems fair enough to demand that a class supports both the concept of
being able to tell whether some value is between two endpoints (even
supporting open ranges) as well as being a lazy list in disguise, but
this concept only works on countable domains.
The most common example is 1 .. 100, which represents both an object
that can tell whether some other Integer is between 1 and 100
(inclusive) as well as the list of numbers from 1 to 100.
But there are problems if you try extending it to other data types that
model over-countable things, such as real numbers.
The Range 1.0001 .. 2.15 makes sense as an interval definition, but
there can hardly be a useful list definition without defining a step
size, at least, making it possible to use step sizes less than one.
This issue also surfaces when working with strings. As far as I can see,
Rakudo has some other comparison operation, which means that Ranges
using String endpoints are not dwimmy in the sense I'd expect:
say @(a .. ax).perl; # expands to a .. z, aa .. ax
say @(aa .. b).perl; # expands to the empty list
As far as I can see, the ordering is like so:
sub { $^a.chars cmp $^b.chars || $^a cmp $^b }
The code below shows that Rakudo does not currently use lexicographical
comparison, which may be surprising.
say 'aaa' cmp 'aa';
say 'aaa' cmp 'ba';
say 'aaa' ~~ 'aa' .. 'ba';
The output is:
1
-1
0
The last 0 should be 1 if using normal lexicographical ordering, just
like cmp does.
It is necessary to consider the data types that we want to use as
interval endpoints and carry out some sort of analysis of their domains.
The basic requirements are:
For the interval definition: there must be an obvious ordering relation,
so we can do $a cmp $b on any $a and $b of the given data type.
For the list definition: for any value $a of the given datatype, it must
be possible to come up with some $b, where no $c exists so $a $c $b.
Now for a short analysis of the different data types used as end points:
Integers - both interval and list definitions are ok.
Str - using lexicographical comparison permits only the interval
definition. Using the different comparison operator above permits both,
but results in counter-intuitive interval definition.
Num - using numerical comparison permits only the interval definition.
It should be easy to come up with a way to specify step sizes to support
list definition.
Complex - neither definitions are possible.
I am unsure about how this can be solved, apart from extracting the
interval definition to a super class to Range (we could call it an
Interval). The backside is that the class returned by the .. operator
depends on the operands:
Int .. Int - Range
Str .. Str - Interval
Complex .. Complex - undef, exception or some other bad thing.
DataTypeA .. DataTypeB - undef, exception or some other bad thing.
The most elegant solution would be if the data types themselves
indicated their capabilities. So if the given class has a cmp method
working on the same data type, the .. can construct an Interval. If the
given class has a next method (my name for a method returning the next
value), the .. can even construct a Range. If you want to construct an
Interval using non-countable things, you should then be able to provide
your own next replacement. Maybe like so:
my $range = 1.14 .. 1.82 :by {* + 0.01};
Another option is to provide a completely different operator for
constructing Intervals.
Darren Duncan brought this up before. See
http://osdir.com/ml/perl6-language/2009-02/msg00422.html
Regards,
Michael Zedeler.
Re: Synopsis 02: Range objects
Em Seg, 2009-08-24 às 23:50 +0200, Michael Zedeler escreveu:
The most elegant solution would be if the data types themselves
indicated their capabilities.
One thing I think you missed entirely is the fact that the infix:..
operator is a multi sub, so it falls to regular dispatch semantics, in a
way that any new class can export its own version of it with the desired
semantics...
my $range = 1.14 .. 1.82 :by {* + 0.01};
Including mandatory named arguments...
Another option is to provide a completely different operator for
constructing Intervals.
The other thing you're missing is that Range is a role, not a class,
which means that any type can behave like a range even if it provides a
completely different behavior, which might include
method list {
fail This type of Range cannot be used as a list...
}
daniel
Re: S26 - The Next Generation
Smylers wrote:
Jon Lang writes:
FWIW, the current proposal for aliasing blocks of ambient text is
functional; it just feels a bit kludgey,
Why? To me it seems the opposite: what could be more natural for
delimiting a block of code than braces?
Because sometimes you'll want to capture only part of a block of code,
or a little bit more than a block of code. In short, what you want
for documentation purposes won't always align with the conceptual
structure of the ambient code. I don't like the idea of being
required to break the code up into blocks whose only purpose is
documentation: if you're breaking the ambient code up into chunks for
documentation purposes, it should _look_ like the code is being broken
up into chunks for documentation purposes. Using Pod tricks for
denoting the start and end of aliased ambient text does that; using a
Perl block doesn't.
and I'm a bit bothered by the fact that you can't alias any ambient
text other than a code block.
Can't is a bit strong: it's more that if you want to quote an
arbitrary portion of code then you need to add some braces around it.
But those braces are unlikely to harm the program.
The exception is if you want to quote an 'unbalanced' portion of code,
for example the start of a loop but not the entire loop. Do you
consider that to be likely?
Actually, yes; I do.
how about saying that an ambient code alias is normally
terminated by the next blank line or Pod directive (as per =for)
Braces are more robust than blank lines; if aliasing a brace-delimited
block I may unthinkingly edit it to have a blank line in the middle of
it, on the basis that the blank line isn't significant to perl.
And =begin blocks are more robust than =for blocks in the same way.
Perl may not care about blank lines; but Pod does. And the author of
a file with both Perl and Pod in it is being remiss in his duties if
he doesn't consider both paradigms. Incidently, note that declarator
blocks already behave this way in Pod: the presence or absence of a
blank line determines the code to which it gets attached.
(Whereas if I edit the braces then I've changed the program as well as
its docs.)
Right. If the braces weren't part of the ambient code, and were there
merely to delineate the aliased text, I'd have less of a problem with
them. In fact, my main problem with them at that point would be how
much they look like a code block without being one, and the confusion
that's sure to arise.
Let's see what others think.
OK.
I like the braces. I suggest initially only providing for braces, but
with the possibility of later adding options to indicate other
termination points if in practice there turn out to be many situations
where the braces don't work well.
I like the idea of using the braces if they're there, and using
something else if they're not. Again, my concern is is being forced
to alias an entire code block, never anything more or less; I'm not
opposed to being _able_ to alias an entire code block, and I'm
especially not opposed to being able to do so in a simple and
intuitive manner.
But let me propose something for the absence of braces case:
introduce a new kind of delimiter into Perl - something that works
like an embedded comment, except that it doesn't actually comment
anything out. In the absence of a curly brace at the start of the
next line of code, a code alias will bind to the first document tag
that it finds, that isn't already claimed by another =alias directive.
For example:
=alias loop
#:[[
=alias loop-head
loop #:[($i = 1; $i $j; $i *= 2)]
=alias loop-body
{
DoSomething($i);
}
]]
In this example, I'm using #:[...] as a stand-in for the
documentation tag syntax. As such,
loop is aliased to:
loop ($i = 1; $i $j; $i *= 2)
{
DoSomething($i);
}
loop-head is aliased to:
($i = 1; $i $j; $i *= 2)
And loop-body is aliased to:
{
DoSomething($i);
}
I'm not fond of the document tag syntax used in the above example;
it looks a little bit too much like a comment. But whatever does get
used, it should be brief and distinct.
And since we're talking about connecting code and documentation, it's
possible that we might want to have this kind of alias be a special
case of the declaration block rather than a stand-alone directive,
using similar rules to determine what to alias (but focused on code
blocks and doc tags rather than declarators).
I've got to run right now; but I've more thoughts that just got
triggered by this. I'll get back to you as soon as I can.
--
Jonathan Dataweaver Lang
r28058 - docs/Perl6/Spec
Author: lwall
Date: 2009-08-25 02:21:44 +0200 (Tue, 25 Aug 2009)
New Revision: 28058
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] disallow alphanums as quote delims
[S02] document WhateverCode and HyperWhateverCode
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-24 22:52:58 UTC (rev 28057)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-25 00:21:44 UTC (rev 28058)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 11 Aug 2009
-Version: 173
+Last Modified: 24 Aug 2009
+Version: 174
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -840,7 +840,7 @@
closure binds them all to the same argument, so C* * * translates to
C{ $_ * $_ }.
-These closures are of type CCode:($), not CWhatever, so that constructs
can distinguish
+These closures are of type CWhateverCode, not CWhatever, so that
constructs can distinguish
via multiple dispatch:
1,2,3 ... *
@@ -864,7 +864,7 @@
does dwimmery, and in this case decides to supply a function { * + 1 }.
The final element of an array is subscripted as C@a[*-1],
-which means that when the subscripting operation discovers a CCode
+which means that when the subscripting operation discovers a CWhateverCode
object for a subscript, it calls it and supplies an argument indicating
the number of elements in (that dimension of) the array. See S09.
@@ -872,7 +872,7 @@
It is generally understood to be a multidimension form of C* when
that makes sense. When modified by an operator that would turn C*
into a function of one argument, C** instead turns into a function
-with a slurpy argument, of type CCode:(*@). That is:
+with a slurpy argument, of type CHyperWhateverCode. That is:
* - 1means- $x { $x - 1 }
** - 1 means - *...@x { map - $x { $x - 1 }, @x }
@@ -2893,6 +2893,7 @@
taken to mean another adverb regardless of what's in front of it.
Nor may a C# character be used as the delimiter since it is always
taken as whitespace (specifically, as a comment).
+You may not use whitespace or alphanumerics for delimiters.
=item *
r28059 - docs/Perl6/Spec
Author: lwall Date: 2009-08-25 02:24:05 +0200 (Tue, 25 Aug 2009) New Revision: 28059 Modified: docs/Perl6/Spec/S06-routines.pod Log: [S06] remove fossil spotted by jnthn++ Modified: docs/Perl6/Spec/S06-routines.pod === --- docs/Perl6/Spec/S06-routines.pod2009-08-25 00:21:44 UTC (rev 28058) +++ docs/Perl6/Spec/S06-routines.pod2009-08-25 00:24:05 UTC (rev 28059) @@ -15,8 +15,8 @@ Created: 21 Mar 2003 -Last Modified: 29 Jul 2009 -Version: 111 +Last Modified: 24 Jul 2009 +Version: 112 This document summarizes Apocalypse 6, which covers subroutines and the @@ -607,8 +607,7 @@ after the invocant argument. The colon is just a special form of the comma, and has the same precedence: -set_name $obj: Sam; # try $obj.set_name(Sam) first, then -# fall-back to set_name($obj, Sam) +set_name $obj: Sam; $obj.set_name(Sam); # same as the above An invocant is the topic of the corresponding method if that formal
r28060 - in docs/Perl6: Perl5 Spec
Author: carlin Date: 2009-08-25 02:26:56 +0200 (Tue, 25 Aug 2009) New Revision: 28060 Modified: docs/Perl6/Perl5/Differences.pod docs/Perl6/Spec/S03-operators.pod Log: [Differences.pod] Added a before/after comparison of the binary numeric AND. Added a note about the bitwise operator prefixes and added a before/after comparison of the shift left operator and the shift left assignment operator. [S03] Added an explicit example of an assignment operator. Modified: docs/Perl6/Perl5/Differences.pod === --- docs/Perl6/Perl5/Differences.pod2009-08-25 00:24:05 UTC (rev 28059) +++ docs/Perl6/Perl5/Differences.pod2009-08-25 00:26:56 UTC (rev 28060) @@ -154,6 +154,20 @@ is binary string AND, C+ is binary numeric AND, C~| is binary string OR etc. + Was: $foo 1; + Now: $foo + 1; + +The bitwise operators are now prefixed with a +, ~ or ? depending if the +data type is a number, string or boolean. + + Was: $foo 42; + Now: $foo + 42; + +The assignment operators have been changed in a similar vein: + + Was: $foo = 42; + Now: $foo += 42; + Parenthesis don't construct lists, they merely group. Lists are constructed with the comma operator. It has tighter precedence than the list assignment operator, which allows you to write lists on the right hand side Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-08-25 00:24:05 UTC (rev 28059) +++ docs/Perl6/Spec/S03-operators.pod 2009-08-25 00:26:56 UTC (rev 28060) @@ -2326,7 +2326,10 @@ (one's complement) becomes either C+^ or C~^ or C?^, since a bitwise NOT is like an exclusive-or against solid ones. Note that C?^ is functionally identical to C!, but conceptually coerces to -boolean first and then flips the bit. Please use C! instead. +boolean first and then flips the bit. Please use C! instead. As +explained in L/Assignment operators, a bitwise operator can be turned +into its corresponding assignment operator by following it with C=. +For example Perl 5's C = becomes C += . C?| is a logical OR but differs from C|| in that C?| always evaluates both sides and returns a standard boolean value. That is,
