Re: exponentiation of Duration's
I still have uses for Durations. For instance, I want to dispatch a different .Stringy method to Durations than to Nums. It's convenient to me that the difference between two Instants has a different type than the difference between 1654321681.123 and 1654321021.65438. I just think Durations should be Liskov substitutable for Rats. I don't give any credence at all to the school of thought that the language designer can think of every legitimate mathematical operation for the difference between two instants. But I still want to use the type system to do MMD. Cheers, Mason On Nov 17, 2010, at 08:56 AM, Carl Mäsak wrote: Mark (): I'm not convinced that the type system shouldn't be helping with dimensional analysis, but at least it shouldn't hurt. By all means, let the programmer raise a Duration to a power - but the type of the result should not also be Duration. In the absence of automatic dimension tracking, just return a plain number. 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. // Carl
Re: Packed arrays and assignment vs binding
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. Could you shed some light on that?
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
I'm honored that my letter generated so much activity, and thank you all for
your thoughtful responses. I'd like to address a few points.
On Monday, 8. November 2010 17:20:43 Jon Lang wrote:
Solomon Foster wrote:
Well, hyperoperators work fine on Hashes, they operate on the values,
paired up by key if needed. (That is, %hash++ doesn't care about
the keys, %hash1 + %hash2 sums based on keys.) I would assume
that Bag should work in the exact same way. Dunno how Set should work
in this context, though.
I would hope that Bags would not work the same way. If they do, then
you get things like:
Bag(1, 3, 2, 1) + Bag(2, 3, 1, 2) # same as Bag(1, 1, 1, 2, 2, 2,
3, 3)
With respect to Bags and » and «, the spec has something to say (somewhere in
S03):
in fact, an upgraded scalar is the only thing that will work for an unordered
type such as a Bag:
Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8)
This makes sense to me. I don't see how it could be otherwise. This code
snippet also makes it clear that » and « operate on the keys of a Bag, and not
the counts or pairs of a Bag. This also makes sense to me, since Bags ought to
act much more like their keys than either their values or an EnumMap of k,v.
Please note that my original post did not address » and «, but rather the
hyper keyword / adverb, as in hyper for { ... }.
On Nov 8, 2010, at 04:25 PM, TSa (Thomas Sandlaß) wrote:
snip
I'm generally very happy with the choice of sigil for Sets and Bags
because this is what they are: scalars as far as storage is concerned.
More important is to have the right set of operators that automatically
imply Bags: (1,2,3,4) () (2,3) === Bag(1,2,2,3,3,4).
Arrays and Hashes are about storage. In the abstract the memory of a computer
is one big array! Sets and Bags are about operations on them like the numeric
operations are on numbers or the string operators on strings. So it is very
important to keep the domains nicely separated by means of disjoint operators.
This is why we have ~ for concatenation and not overloaded +.
It makes of course sense to iterate a Bag. But indexing it doesn't. We are
also not indexing into strings: blah[2] is not 'a'.
snip
I have to disagree here. Arrays and Hashes may be about storage (I don't think
they are, though, since you can change the (storage) implemenation of an Array
or Hash via its metaclass and it can still remain an Array or Hash). But
sigils are definitely not about the storage of the underlying data. Your own
statement gives the contradiction - In actual storage in the memory of a
computer, everything is somewhere in a big array. But yet, we don't prefix
everything with an @ sigil. So clearly, sigils are about something else.
jnthn said today, in irc, that sigils are about an interface contract.
Everyone seems to agree that they imply the Positional role (i.e., the
postcircumfix:[] method), and that Rakudo heavily relies on this conflation,
so I'm withdrawing the suggestion that @ means does Iterable instead of does
Positional.
The most important part of the @ sigil, and the reason I preferred it over $,
is that @ flattens (moritz++'s word), when used in a list context such as
for @blah,
map {...}, @blah.
Having Bags flatten in list context is pretty crucial to their being as easy
and terse to use as arrays, because flattening is fundamental to how Arrays
are used, and Bags will be used like Arrays. Luckily, however, %, which
implies the Associative contract, also flattens in list context. If Bags and
Sets are sigiled with %, they should flatten, and all that remains is to make
sure they flatten into a list of keys, and not a list of enums.
Any thoughts on that?
Bag / Set ideas - making them substitutable for Arrays makes them more useful
I just implemented Bag to the point where it passes the spectests.
(https://github.com/masonk/rakudo/commit/2668178c6ba90863538ea74cfdd287684a20c520)
However, in doing so, I discovered that I'm not really sure what Bags are
for, anymore.
The more I think about Bags and Sets, the more my brain hurts. They're a half
an EnumMap and half an Iterable that does Associative but not Positional.
However, I'm starting to believe that they are more like Iterables than
EnumMaps. When I imagine using them, I think of Sets as a cute way to operate
on the unique elements of an Iterable. I think of Bags / KeyBags as a way to
remove ordering, which is a generally useful thing (everything that I'm about
to say applies to both Bags and KeyBags, but I'm going to only talk about Bags
for the rest of this post). This is because, most of the time, we don't care
about ordering, and having ordering on all of our collections even when we
don't need it increases program complexity in time in a way that could be seen
as analogous to the way in which unnecessarily global variables increased the
space complexity of Perl 5.
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.
With this one change to Bags, I could use them whenever I don't need ordering
in my lists - which is usually. Even though there are some side effects that
don't rely on ordering (e.g., incrementation), the majority of them do - so by
using this new kind of Bag, I would be reducing the complexity of my programs.
Now, since Sets already give us the distinct values, having Bags do the same
thing seems like redundant functionality, where we could be getting novel
functionality.
I'd like to anticipate one objection to this - the existence of the 'hyper'
operator/keyword. The hyper operator says, I am taking responsibility for
this particular code block and promising that it can execute out of order and
concurrently. Creating a Bag instead of an Array says, there is no meaning
to the ordering of this group of things, ever. Basically, if I know at
declaration time that my collection has no sense of ordering, then I shouldn't
have to annotate every iteration of that collection as having no sense of
ordering, which is nearly what hyper does (though, I readily admit, not quite,
because there are unordered ways to create race conditions).
I also have some convenience syntax suggestions. I do think this is important
because Bags and Sets are competing with Arrays. If they aren't as convenient
as Arrays to use, they won't get used - even though they're closer,
semantically, to what the developer wants in a lot of cases. First, we should
besigil Bags and Sets with @ instead of $. Without this convenience, I'm not
likely to replace my Arrays with Bags, because going through them in a loop or
map would be a pain compared to Arrays. If I have to say $bag.keys every
single time, forgettaboutit.
This, however, probably requires a change to S03, which says that the @ sigil
is a means of coercing the object to the Positional (or Iterable?) role. It
seems to me, based on the guiding principle that perl6 should support
functional idioms and side-effect free computing, the more fundamental and
important aspect of things with @ in front is that you can go through them one
by one, and not that they're ordered (since ordering is irrelevant in
functional computing, but iterating is not). My feeling is that we should
reserve the special syntax for the more fundamental of the two operations, so
as not to bias the programmer towards rigid sequentiality through syntax.
Second, I would be even more likely to replace my ordered lists with Bags if
there were a convenient operator for constructing Bags. I can't think of any
good non-letter symbols that aren't taken right now (suggestions welcome), but,
at least, b and s as aliases to bag and set would be convenient.
Bags and Sets thus updated would look like this in use:
C
my @array = a a b c ;
my @set = s...@array;
for s...@array { say $_ };
for @set { say $_ };# same thing
# b«»a«»c«»
# ordering undefined
# most common use case for sets, I think, is unique elements of @array, isn't
it?
hyper for @bag { ... };
# a«»b«»c«» a«»
# ordering undefined = less-thinking-required hyper
b a b c c === b c c b a
# Wouldn't this be the best way to make a comparison with these semantics?
# By the way, this useful idiom works as currently specced, but doesn't work in
my implementation
@bag{a}
# 2
@bag{a b z}
# 2, 1, 0
[+] bag @array{a b z}
# 3
# this is also neat for How many a's, b's, and z's do I have?
+...@bag
# 4
@bag[2]
# I can't think of a meaning for this - not Positional - S03 needs a change?
@bag.WHAT
# Bag()
@bag.pairs
# a = 2, b = 1, c = 1
# ordering undefined
@bag.values
# 2, 1, 1
# ordering undefined
Junctions:
Re: Lists vs sets
That sounds like a subclass of Bag to me. But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6. All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. On Oct 25, 2010, at 08:08 PM, yary wrote: +1 on this On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com wrote: As for the bit about sets vs. lists: personally, I'd prefer that there not be quite as much difference between them as there currently is. That is, I'd rather sets be usable wherever lists are called for, with the caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. I think of a list conceptually as a subclass of a set- a list is a set, with indexing and ordering added. Implementation-wise I presume they are quite different, since a set falls nicely into the keys of a hash in therms of what you'd typically want to do with it.
Re: Lists vs sets
Sorry: I meant capable *in theory*. It's not in the spec right now for Sets or Bags. On Oct 25, 2010, at 08:41 PM, Mason Kramer wrote: That sounds like a subclass of Bag to me. But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6. All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. On Oct 25, 2010, at 08:08 PM, yary wrote: +1 on this On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com wrote: As for the bit about sets vs. lists: personally, I'd prefer that there not be quite as much difference between them as there currently is. That is, I'd rather sets be usable wherever lists are called for, with the caveat that there's no guarantee about the order in which you'll get the set's members; only that you'll get each member exactly once. The current approach is of much more limited value in programming. I think of a list conceptually as a subclass of a set- a list is a set, with indexing and ordering added. Implementation-wise I presume they are quite different, since a set falls nicely into the keys of a hash in therms of what you'd typically want to do with it.
