-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a dictionary type #184
Comments
Before we address this issue, we should do some thinking about how we want the syntax to look. The property shorthands like Worse, the object literal syntax builds on object properties having string keys (which they do, and still will), but for dictionaries we will need something that doesn't assume string keys. This, in the end, is why Python doesn't have autoquoted keys, I suspect. |
This is easier than it might first seem. We don't have all that many hashable built-in types:
Hm, The biggest thing to watch out for is basically that |
Just as a data point... In Ruby, hash keys can be anything. However you might need to manually rehash if you change properties of the key: a = [ "a", "b" ]
c = [ "c", "d" ]
h = { a => 100, c => 300 }
h[a] #=> 100
a[0] = "z"
h[a] #=> nil
h.rehash #=> {["z", "b"]=>100, ["c", "d"]=>300}
h[a] #=> 100 |
Interesting. Perl 6 could essentially also have a Putting my language designer hat on, I think 007 has enough Python in it to want to disallow up front rather than go the route of re-hashing when things mutate. I grant that the question comes down mostly to taste. |
Vide this tweet and this tweet. |
Here's a summary of this issue, and an attempt to enumerate the forces that apply to the design. If you feel cognitive dissonance reading the below criteria, it's because they're mutually opposing in many cases.
Looking at the above, the path forward looks quite straightforward after all:
Also, it would mean the proposed syntax is now:
I started out calling the above type |
The |
What should looping over a dictionary do? In Python, it loops over the keys:
In Perl 6, it loops over the pairs:
In Perl 5, it loops over a flattened list of keys and values:
Finally in Java, you can't loop over a Since the designs are all over the place, I'm left to my own judgement on this. I kinda like Perl 6's approach, because it gives you both key and value without judging. Together with some kind of destructuring, that's quite enough. But I hadn't planned on giving 007 pairs, at least not at this point. So I think I'll go with the Java approach, which has the advantage of being the most boring and conservative one. At least then it'll be easy to upgrade to something nicer later. |
I suddenly realized that the main use case for this would be the |
I think dictionaries (like |
I added the "needs-more-design" label to this, because when I picture the So we probably need two slightly more different syntaxes to distinguish them. Needs more design. In completely unrelated news, back in November and December I started a branch for this issue, and got more or less stuck — basically the kind of stuck brought on by overwhelming changes without a really clear direction. |
I think this early requirement might have been a mistake. Even though using any hashable type for keys is nice, language-wise, the cost for it is pretty big. Notably, the syntax
in a language that only supports strings as keys is "free" to assume that
(Python, on the other hand, can't.) So firstly, it's nice to be able to skip quotes on dictionary keys. Secondly, the above syntax is strangely consistent with the short-hand:
For
That is
There is some other syntactic bit here that's also bugging me about not being able to to assume that keys are strings... related to object creation. But I can't quite put it into words now. |
I mean, this is all still true, it's just that the language design cost is higher than I expected. |
Oh, hey — add |
This... does not seem like a good idea. Not sure what I was thinking. 😄 If we make |
This seems to be resolving itself now, since we're moving in the direction of #307 and #308. Sure, with #299 in the mix we'll still have the colon in both syntaxes, but they'll be differentiated enough I think by the different contexts they occur in. Removing the needs-more-design label. |
It's more like Dict already than like Object. There are a few things to straighten out here that need to be fixed before this is mergeable to master -- notably, the whole `new` syntax needs to work with objects, not with dicts. But this is an encouraging start. Closes #184.
It's more like Dict already than like Object. There are a few things to straighten out here that need to be fixed before this is mergeable to master -- notably, the whole `new` syntax needs to work with objects, not with dicts. But this is an encouraging start. Closes #184.
It just occurred to me that we might be able to steal Perl 6's It's possible that this syntax need not be on my default. Maybe one can import it via a module. |
It's more like Dict already than like Object. There are a few things to straighten out here that need to be fixed before this is mergeable to master -- notably, the whole `new` syntax needs to work with objects, not with dicts. But this is an encouraging start. Closes #184.
As fell out of the discussion in #144.
I'm going to be difficult and say that we should probably aim for making the dictionaries take any hashable key, not just string keys. (Like in Python.) Without that extra requirement, I would slap a "low-hanging fruit" label on this issue, but with it, it's a wee bit bigger.
Why do I want that? Because experience shows that hashes are central to many other things one might want to build, and allowing anything-hashable makes some code a lot nicer. Sets, bags, graphs come to mind. And I know more than one reason to want to key on tuples/enums, once we get them. So the high road it is.
What should "hashable" mean for the purpose of this issue? Let's go with "has a
hash
method". Maybe some requirements should be placed on that method, but that can probably wait. Also, once 007 has interfaces, thenHashable
should probably be one. But all in due time.A number of methods that currently sit on
Val::Object
(fsvo "sit") ought to move to and/or be rethought forVal::Hash
:get
keys
has
update
/extend
Some of these should maybe be available in some form on
Val::Object
too? For example,Q::Postfix::Property
inruntime.007
is currently implemented as a hash indexing operation:This is clearly leaning on the "objects-as-hashes" confusion we're about to erase — in other words, there's already a relevant use case in user code that we don't want to erase completely.
I don't feel ready to propose a solution yet. Just noting that sometimes it's useful to treat an object as something slightly hash-like.
The text was updated successfully, but these errors were encountered: