Re: comprehensive list of perl6 rule tokens
On Thu, Jun 02, 2005 at 12:52:36AM -0400, Jeff 'japhy' Pinyan wrote:
> Further woes, arguments, questions:
>
> In regards to <@array>, A5 says "A leading @ matches like a bare array..."
> but this is an over-generalization. A leading '@' merely indicates the
> rule is found in an array. <@array[3]> would be the same as
> <$fourth_element_of_array>, assuming those two values are identical.
I'll leave this to the A05 authors to decide. :-) S05 doesn't
present any examples of subscripted rules or hashes, so perhaps
that particular syntax was reconsidered (i.e., I think one could
do <{ @array[3] }>).
> Next, about and . What is the justification for
> that syntax? There is no other example of a <-sequence with whitespace,
> at least that I can see. It would appear "RULE" is an argument of sorts
> to the 'before' and 'after' rules, but how do they access that argument?
> How do I write a rule that takes an argument?
According to A05, rules take arguments much the same way that
subs do. (In fact, it's *very* useful to think of rules as subs or
methods.) So, one can do:
rule myrule ($x) { \w+ $x }
and $x is scoped something like a subroutine parameter would be.
A05 also mentions several mechanisms for passing parameters to
a rule:
# same as calling myrule(/pattern/)
# same as calling myrule(q)
# same as calling myrule(expr)
Of course, there are other "implicit" parameters that are given
to a rule -- the target string to be matched and an initial
starting position. But I think some of those details are still
being worked out.
Pm
Re: comprehensive list of perl6 rule tokens
Further woes, arguments, questions: In regards to <@array>, A5 says "A leading @ matches like a bare array..." but this is an over-generalization. A leading '@' merely indicates the rule is found in an array. <@array[3]> would be the same as <$fourth_element_of_array>, assuming those two values are identical. Next, about and . What is the justification for that syntax? There is no other example of a <-sequence with whitespace, at least that I can see. It would appear "RULE" is an argument of sorts to the 'before' and 'after' rules, but how do they access that argument? How do I write a rule that takes an argument? -- Jeff "japhy" Pinyan % How can we ever be the sold short or RPI Acacia Brother #734 % the cheated, we who for every service http://japhy.perlmonk.org/ % have long ago been overpaid? http://www.perlmonks.org/ %-- Meister Eckhart
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005 19.37, Damian Conway wrote: > Deborah Pickett wrote: > > Someone please convince me otherwise. > So what you want is not an identity value as default (which isn't even > possible for many operators, as Luke pointed out), but a predictable > failure value as default, so you can intercept that failure and choose your > own outcome in the edge case. You haven't convinced me, but rather than flog a dead horse, I'll just suggest that we both reserve the right to say "I told you so" when there are several years' worth of Perl 6 code out there, and we see how common our respective examples are. Meanwhile, it's safer to take the "fail" course of action, because it can be relaxed later on; the converse couldn't be true. What you and Luke *have* convinced me of is that the one-element list rule isn't right either; for operators like <, it still makes sense to fail in some soft way on one-element lists: $ordered = ([<] @array) // 1; # Zero- and one-element arrays get the 1. I'm starting to agree that there have to be different rules for associative* and non-associative reduction. * Left and right association might need to be different too in terms of the order they eat list elements. -- Debbie Pickett [EMAIL PROTECTED]
Re: date and time formatting
On Wed, Jun 01, 2005 at 03:42:57PM +1200, Sam Vilain wrote: > I've made a start on this. See ext/Date in pugs. I don't think that > your views are necessarily contrary. That's what I'm looking for. Thank you! > The biggest reason I didn't use DateTime was that I found it awkward > for the common case; most of the time I just want to stuff in an > ISO8601 date. I also don't like implicit normalisation to seconds > underneath the hood when I'm doing basic date calculations, and > the way that the "DateTime" base class is inherantly based on the > Gregorian calendar. > > The "Date" and "Duration" roles are extremely minimal; see > >http://svn.openfoundry.org/pugs/ext/Date/lib/Date.pm >http://svn.openfoundry.org/pugs/ext/Date/lib/Duration.pm > > The major API is described at: > >http://svn.openfoundry.org/pugs/ext/Date/lib/Date/Gregorian.pod > > This module is supposed to be somewhere between DateTime and > Class::Date, with built-in ISO-8601 support (as it's the standard ;)). So, if we continue following this API, Perl6 core will contain time(), but no localtime() nor gmtime(). The Date module will provide human readable date and time strings, and basic date math. > With a bit of luck, all Date implementation can share this `Date' > Role, and Gregorian calendar modules share the `Date::Gregorian' Role, > so that the multitude of implementations that crop up will be mutually > exchangable, and the simple case fast, efficient and useful. So further date manipulation could be provided by other date modules, hopefully within the same framework. Sounds good to me. -kolibrie
Re: reduce metaoperator on an empty list
> > $ordered = [<] @array; This is asking "Is @array ordered?" In the case of a 0-element or 1-element array, the answer is "It is not disordered", which means $ordered is true. $ordered = ! [!<] @array; Rob
Re: Transparent / Opaque references
Juerd wrote:
Thomas Sandlass skribis 2005-05-28 17:34 (+0200):
I propose %hash = { key => :\$variable, foo => 'bar' };
:\$variable looks like many things to me, but not an alias.
Let's forget that idea, because I have a bunch of better ones!
$hash = { key => \ $variable but rw , foo => 'bar' };
$hash = { key => \ :rw $variable , foo => 'bar' };
$hash = { key => ref:rw $variable , foo => 'bar' };
They are all assuming that &prefix:<\> has named params
that determine its behaviour by means of adverbial modifiers.
Well or that a rw role can be composed into a reference to
force binding behaviour. BTW, but is lower in precedence than \,
isn't it?
--
TSa (Thomas Sandlaß)
My presentation on last weekend
Hi, I just would like to share it with you. We had a weekend at the lake Balaton on the last weekend, where I had a talk about Perl 6. The guys liked it (the girls had sunbath during the event :), and one of them (Poetro) said the summary: then we can say, that Perl 6 is an "operator oriented language"? We agreed. Bye, Andras
Re: (1,(2,3),4)[2]
Larry Wall wrote: : my $b <== foo(); : : declares $b to be an iterator rather than an array ref. Though that would seem to imply that *$x slurpy parameters should work that way too, and that's not how they work right now... This is very in line with my current conclusion that List is a subtype of Code. Like the talking frog that the geek takes as it is instead of flattening it into a princess :) The princess here beeing the list of everything the frog had to say before his disappearance. Hmm, and ** beeing the kissing operation ;) -- TSa (Thomas Sandlaß)
Re: "returns" and context
Gaal Yahas wrote:
How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}
If it were two subs, one would "is returns" Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.
Well, if my type lattice proposal were accepted as the way the type system
of Perl 6 works, the return type of your function could indeed be written
or possibly inferred by the compiler to be :(Int|List[Sheep]) but it would
mean a LUB (least upper bound) of the two types mentioned. This implies
that if you were to give foo's return value to a multi which has two
different possible receivers for :(Int) and :(List of Sheep) respectively,
the context might be undef or a LUB as well.
The base point with type systems is that if one is not specific about the
types than nothing specific can happen! So either the caller must state
what shall be the return type or the implementation must specify what it
returns. I would call the former reverse dispatch or somesuch. Since every
function that has a very unspecificly declared return type might
nonetheless produce something beeing the most specific. So, all
dispatchable targets have to be called and after all return types are
available the most specific is picked. That smells like the autothreading
of junctions that I don't understand either.
The case where the caller just hands over the args to the dispatcher OTOH,
calls the most specific target and then has to go with whatever the output
is. It might just produce a type error or lead to the next dispatch.
An alternative return type of your sub might be :(Int ^ List of Sheep)
which firstly excludes the GLB (greatest lower bound) of :(Int) and
:(List of Sheep) which is written :(Int & List of Sheep) and secondly
doesn't prevent the double call or undefined context, either.
My conclusion from all this is that the notion of context is Perl's
version of static typing ala C++ and Java.
Sorry if this wasn't what you wanted to hear.
--
TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
Luke Palmer wrote: For something like: $ordered = [<] @array; If @array is empty, is $ordered supposed to be true or false? It certainly shouldn't be anything but those two, because < is a boolean operator. I have no problem with 3-state logic systems (true, false, undef) if this is what is required to let me choose the corner-case behavior. Damian previously wrote: > 2+ args: interpolate specified operator > 1 arg: return that arg > 0 args: fail (thrown or unthrown exception depending on use fatal) The 1-arg case doesn't seem to work right with the [<] operator: ? [<] 1 ? [<] 0 If the [<] is taken to mean "ordered", then it doesn't seem right that these two tests would give different results. In this case, I need to special case both the 0-arg and 1-arg scenarios. We either need to hard code these special-cases into perl (belch), or we need to make it easy to code both special-cases inline in the code, or we need a better general-case rule. One approach might be to reverse the direction of the definitions. That is, instead of defining the binary form and then autogeneralizing in terms of "join", we might define operators in terms of thier reduction behavior, and then autospecialize to the binary case. Of course, that still doesn't help for Damian's "product Vs factorial" example for the 0-arg case. Or we take the well trodden road of ignoring mathematical correctness and simply state "this is what perl does: take it or leave it".
Re: date and time formatting
Sam Vilain wrote: I also don't like implicit normalisation to seconds underneath the hood when I'm doing basic date calculations, and the way that the "DateTime" base class is inherantly based on the Gregorian calendar. I concur in this view. From a typing point of view there should be some common base type that can handle cross-calender arithmetic but as long as one stays in a homogenous subtype like Gregorian in a particular time zone no generalization code should fire up. -- TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005, Luke Palmer wrote: I read that (mathematically) as "for all i, for all j such that j-i=1, a_i Yep, it sure is. Now tell Perl to read it that way for any operator. Should _I_?!? ;-) I wonder what a logic-oriented programming language a' la prolog would say in this case. Now, Perl6 is supposed to support similar features too - maybe the right(TM) answer could be along that way... Michele -- primordinarily concerned with providing ... Neat "word"! - Donald Arseneau in comp.text.tex
Re: mod/div
Mark Reed wrote:
At least, not in cases where the intended result is consistent across 0.
Lots of date arithmetic falls into this category, and works beautifully with
the definitions above.
Does it? If you have a year 0, what is the number corresponding
to the middle of that year? Is it 0.5? Is than 1.5 the middle of
year one? Where is the middle of year -1? -1.5? Or -0.5? With the
middles as -0.5 and 0.5 you get at least a time difference of one
year. But what is the first quarter of year 0? 0.25? And the last
quarter of year -1? -0.25? That works numerically, but March of a
year is then not always the same difference to the start of the year,
actually this is where you have to make the case destinction on
the sign of the year to add or substract 1 in the fractional part
of a sub-year units. Two's complement integers and positive remainders
give that automatically.
BTW, the above arithmetic very nicely fits the string positions
depending on Unicode level. Position 0 is before the first character
of the string, the position n is after a string of length n. Positions
of lower levels are positive fractions into the higher level character.
An empty string has start == end.
It lets me do things without bounds checking and
correct the ranges later, because, e.g., plugging in January -20, 0 AD
yields the correct result for December 11, 2 BC. Such calculations break
dramatically across 0 if you use the definition found in some C
implementations, where (-3 mod 5) == -3.
Ahh yes, the C definition doesn't fulfill the Division Rule. Neither
does the Perl 5 pair of int() and %. But I hope the latter is corrected
for Perl 6? Does someone know which code depends on that unfortunate
behaviour? Note that all definitions give the same results for positive
dividend and divisor.
In which case, for or your example of 8 == $q * (-3) + $r, $q == -2 and $r
== +2? Seems odd to me that just swapping the signs (from -8,3 to 8,-3)
yields completely different numbers like that.
Sorry, you are changing the numbers you divide and wonder that the results
are different? Don't be fooled by the usual number denotations which
are asymetric around the Origin: +2.3 is (+2 + 0.3) while -2.3 is
(-2 + -0.3). This is expressed in words as "2.3 is 0.3 after 2" and
"-2.3 is 0.3 before -2". While a two's complement interpretation would
keep the remainder always positive because it is in ascending direction
into the intervall spanned by the integer part and its successor.
Unfortunately only few people know about the interpretation -2.3 as
(-2 + 0.3) which reads "-2.3 is 0.3 after -2". This can be generalised
to "$x is {$x mod 1} after {$x div 1}".
Here are ASCII charts of these two functions, with * indicating the jumps.
A divisor d determines the distance abs(d) between the jumps of (x div d)
and zeros of (x mod d). For d < 0 the intervall 0 <= x < abs(d) remains 0
and all others flip sides of the x axes as expected. Note that ifinite
precision can be interpreted as arithmetik modulo 0, not Infinity. Thus
the remainder is always 0, and the div function is the 45 degree line
through the origin, which is equivalent to the definition of the
multiplicative inverse x * y == 1 and of course y = 1/x for x != 0.
And as many people know these are hyperbolas through (1,1) and (-1,-1)
respectively and I stop ranting ...
|
3+ *===
|
2+ *===
|
1+ *===
|
---|---|---|---*===|---|---|>
-3 -2 -1 0 1 2 3
*===+-1
|
*===+-2
|
*===+-3
|
|
+abs(d)
/ / /| / / / /
/ / / | / / / /
/ / / |/ / / /
---*---*---*---*---*---*---*>
0 ->| |<-
| abs(d)
The euclidean definition nicely produces the two's complement! And it
allows negative-digit, negative-radix number representations without
case distinction.
Let's take clock arithmetic which is---you guessed it---modulo -12.
Thus 11 + 2 == 1 because of 13 == (-1) * (-12) + 1. Note that the string
'12' is the zero digit because 12 == (0) * (-12) + 12. "A quarter past
midnight" is just -12 + 0.25 while "a quarter past noon" is 0 + .25.
So the 24 hour day goes from -12.0 to +11.9... that is +12 is the -12
of the next day. And 0.0 is noon. And of course the clock is rotating in
mathematically negative direction :)
I just see arithmetic regularity.
--
TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
Hi, You have to either supply an initial value or refactor your logic not to allow an empty @array (as in the first case). If you want it some other way, there are far too many special cases we have to work with, some of which are just mathematically impossible. I think `fail`ing is the best bet. I haven't read the whole thread, so I'm sorry, if it was before. I think that a fail is a good idea. Or maybe it should be a warning, and the return value should be undef. I mean: [<[EMAIL PROTECTED] === undef < undef; [EMAIL PROTECTED] === undef * undef; etc. Bye, Andras
Re: Unicode Operators cheatsheet, please!
xOn 5/31/05, Sam Vilain <[EMAIL PROTECTED]> wrote: > Rob Kinyon wrote: > > I would love to see a document (one per editor) that describes the > > Unicode characters in use and how to make them. The Set implementation > > in Pugs uses (at last count) 20 different Unicode characters as > > operators. > > I have updated the unicode quickref, and started a Perlmonks discussion node > for this to be explored - see http://www.perlmonks.org/index.pl?node_id=462246 As I replied on Perlmonks, it would be more helpful if the Compose keys were listed and not just the ASCII versions. Plus, a quick primer on how to enable Unicode in your favorite editor. I don't know about Emacs, but the Vim documentation on multibyte is difficult to work with, at best. Thanks, Rob
Re: reduce metaoperator on an empty list
On 6/1/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Wed, 1 Jun 2005, Luke Palmer wrote: > > >$ordered = [<] @array; > > > > If @array is empty, is $ordered supposed to be true or false? It > > certainly shouldn't be anything but those two, because < is a boolean > > operator. > > I read that (mathematically) as "for all i, for all j such that j-i=1, > a_i
Re: construction clarification
Carl Franks wrote: However, if I allowed the default 'new' to handle that case, then the BUILD submethod has to be aware of that. I thought it would be cleaner to 'document' the special case with a seperate constructor, and also not require any special-case logic in the BUILD submethod. Is that really off the wall? Not at all. It's entirely reasonable. As I mentioned in my previous message, I simply missed your original intent. Damian
Re: construction clarification
Carl Franks wrote: The universal new() would handle the one-argument call exactly the same as your overloaded new() does. Is that correct? S12 says... All classes inherit a default new constructor from Object. It expects all arguments to be named parameters initializing attributes of the same name. ... which seems to contradict. Apologies. I hadn't noticed that you were intending to call it with a positional argument. In which case, yes, you would indeed require the separate constructor definition. Damian
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005, Luke Palmer wrote: $ordered = [<] @array; If @array is empty, is $ordered supposed to be true or false? It certainly shouldn't be anything but those two, because < is a boolean operator. I read that (mathematically) as "for all i, for all j such that j-i=1, a_i Why should I read the fucking manual? I know how to fuck! In fact the problem is that the fucking manual only gives you theoretical knowledge which is useless in practice ;) - Giuseppe "Oblomov" Bilotta in a bunch of usenet groups.
Re: construction clarification
> The universal new() would handle the one-argument call exactly the > same as your overloaded new() does. Is that correct? S12 says... All classes inherit a default new constructor from Object. It expects all arguments to be named parameters initializing attributes of the same name. ... which seems to contradict. Carl
Re: reduce metaoperator on an empty list
Deborah Pickett wrote: You are going to see empty lists more often than you think in expressions like $product = [*] @array; and having to write that as $product = [*] 1, @array; just to protect against a common case doesn't exactly flaunt Perl's DWIMmery to me. I *have* to write 1 there, or otherwise the reduce meta-operator isn't calculating the product when there are items in @array. This hardly makes sense from a Huffman perspective. Someone please convince me otherwise. The problem is that writing 1 there is still wrong in the "no arguments" case. The product of zero numbers cannot possibly be one in any common sense interpretation. (And, yes, I'm perfectly well aware of the mathematical interpretations in which it does make sense...that's not the point.) What you want is: $product = ([*] @values err 0); Or: $factorial = ([*] 1..$n err 1); So what you want is not an identity value as default (which isn't even possible for many operators, as Luke pointed out), but a predictable failure value as default, so you can intercept that failure and choose your own outcome in the edge case. Damian
Re: reduce metaoperator on an empty list
On 6/1/05, Deborah Pickett <[EMAIL PROTECTED]> wrote: > I'm still in the camp of those wanting each operator to know its own identity > value (perhaps in terms of a trait). The identity of multiplication (say) is > always 1, after all, and it doesn't change depending on when you do > multiplication in your own code. In mathematical terms, it's a property of > the operator, not of how it's used. Also, in mathematical terms, many operators have no identity. Also, if we suppose that every operator does have an identity (a silly thing to do), then we can't just return that. It doesn't even make sense for operators like < whose return type is different from its argument types (but reduce itself doesn't make a lot of sense for such operators unless they're list-associative). For something like: $ordered = [<] @array; If @array is empty, is $ordered supposed to be true or false? It certainly shouldn't be anything but those two, because < is a boolean operator. Coming back to our identities issue, consider: $mods = [%] @array; If @array is empty, what is $mods supposed to be? There's no reasonable integer that it could possibly be. You have to either supply an initial value or refactor your logic not to allow an empty @array (as in the first case). If you want it some other way, there are far too many special cases we have to work with, some of which are just mathematically impossible. I think `fail`ing is the best bet. Luke
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005 13.19, Joe Gottman wrote:
> > Juerd asked:
> > >>2+ args: interpolate specified operator
> > >>1 arg: return that arg
> > >>0 args: fail (i.e. thrown or unthrown exception depending on use
> > fatal)
> >
> > > Following this logic, does join(" ", @foo) with [EMAIL PROTECTED] being 0
> > > fail too?
> > No. It returns empty string. You could think of C as being
> > implemented:
> > sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b }
> > "", @list
> > }
> >
> > Just as C is probably implemented:
> >
> > sub sum ([EMAIL PROTECTED]) { [+] 0, @list }
>If this were the case, then
> join '~', 'a', 'b', 'c'
> would equal '~a~b~c' instead of 'a~b~c'
Another broken symmetry. Ah, Perl 5's full of them, and I see that Perl 6
will be no exception. Excuse me while I find my cynic hat . . ah, here it
is.
I'm still in the camp of those wanting each operator to know its own identity
value (perhaps in terms of a trait). The identity of multiplication (say) is
always 1, after all, and it doesn't change depending on when you do
multiplication in your own code. In mathematical terms, it's a property of
the operator, not of how it's used.
You are going to see empty lists more often than you think in expressions like
$product = [*] @array;
and having to write that as
$product = [*] 1, @array;
just to protect against a common case doesn't exactly flaunt Perl's DWIMmery
to me. I *have* to write 1 there, or otherwise the reduce meta-operator
isn't calculating the product when there are items in @array. This hardly
makes sense from a Huffman perspective. Someone please convince me
otherwise.
Multiplication's an easy example, in any case, and any programmer will know
the identity is 1. But look at the confusion here on this list among people
over the identities for <, >, ** and other beasts. I've already forgotten
some of them.
(On another note: I had a thought the other day: [op] produces one thing from
a list, and »op« produces a list from a list. When I squint with hindsight,
it makes more sense to me for »op« to be the one that converges a list to a
single point, and [op] to do listy things to lists. I'm not seriously
suggesting a switch - there's probably parsing issues with the thought - I'm
just sayin', is all.)
--
Debbie Pickett
http://www.csse.monash.edu.au/~debbiep
[EMAIL PROTECTED]
Re: construction clarification
> It's *a* correct way. But redundant in this particular case.
> The universal new() would handle the one-argument call exactly the same
> as your overloaded new() does. Presumably, however, the one-argument variant
> would do something else as well.
Some people will need to call the constructor with a whole host of options:
my $foo = Foo.new(
date => '2005-06-01',
other => 1,
params => 1);
For the typical case though, rather than forcing people to have to write
my $foo = Foo.new(
date => '2005-06-01);
they should be able to write
my $foo = Foo.new('2005-06-01');
However, if I allowed the default 'new' to handle that case, then the
BUILD submethod has to be aware of that.
I thought it would be cleaner to 'document' the special case with a
seperate constructor, and also not require any special-case logic in the
BUILD submethod.
Is that really off the wall?
Carl
Empty hash
Two questions:
Should {} be an empty hash rather than an empty code?
Why did we change { %hash } from making a shallow copy of a hash to
the code that returns %hash?
Luke
