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
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
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 Cjoin as being
implemented:
sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b }
, @list
}
Just as Csum 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: 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
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: 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
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_ia_j, which is certainly satisfied by an empty list. Michele -- 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
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: 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: 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_ia_j, which is certainly satisfied by an empty list. Yep, it sure is. Now tell Perl to read it that way for any operator. Luke
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
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: 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_ia_j, which is certainly satisfied by an empty list. 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: 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
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: 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ß)
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: 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ß)
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: 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
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: 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 before RULE and after RULE. 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: 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 before RULE and after RULE. 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:
myrule pattern # same as calling myrule(/pattern/)
myrule: text # same as calling myrule(qtext)
myrule(expr) # 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
