Skip to content
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

Request: property setting shorthand #63

Open
stugol opened this issue Mar 23, 2016 · 6 comments
Open

Request: property setting shorthand #63

stugol opened this issue Mar 23, 2016 · 6 comments

Comments

@stugol
Copy link
Contributor

stugol commented Mar 23, 2016

May use x in place of x: x in a hash, when the key name is the same as the variable name, a la LiveScript:

name = "Fred"
age = 7
vars = {id: 1, name, age}
say vars      -- {id: 1, name: "Fred", age: 7}

FWIW, I often find myself doing stuff like {url: url, img: img, web_content: web_content} in Ruby, so this could be useful.

Should probably support symbol keys:

value = 1
say {value}       -- <value: 1>
say {#value}      -- <#value: 1>
@stugol
Copy link
Contributor Author

stugol commented Mar 23, 2016

While we're at it, how about the LiveScript flag syntax as well?

say {+debug, -live}       -- {debug: true, live: false}
say {+#debug, -#live}     -- {#debug: true, #live: false}

@ozra
Copy link
Owner

ozra commented Mar 23, 2016

Now you used the newly proposed Tup syntax, not Map (aka Hash) syntax, however, I assume you meant {...} so I've taken the liberty to edit your post for the benefit of discussing the issue, if I was wrong, re-edit and tell me!

Incidentally this will only be possible if I implement the new Tup(le) literal syntax (that you used in the example). The reasons for going with the new Tuple syntax are piling up, so I'll put the macro-work to the side and implement that next thing (probably today). Then these will be possible.

I like it:

  • It's very clearly understandable code
  • It's terser
  • DRY
  • Parallels the foo(@inst, @name) -> assignment.

Also supporting Tag-keys ("symbols") is a good idea too!

Now, what stands against it is Set
The main reasons I want to change the Tuple literal syntax is:

  • Tuples are never expressed with braces in mathematical notation - that's about the only hard rule.
  • Sets are very useful, and they are expressed with braces, and I miss using them smoothly.

Regarding the flag "lookup hash" sugar - I like that too - though the obvious construct to use for that is a Set in many cases (albeit then you'd only have "it is in the set" or "it's not in the set").
With above construction (which I do like, mind you), you have true|false|nil (not set), which also has its' uses.

Collisions with the intended Set-literal-notation:

  • Flags: that would create a Set containing positive value of variable debug and negative value of variable live.
  • Shorthand keying: It's straight up Set-notation.

And that means we just have to think a bit more, because I really like the suggestions. I'll make an example using Set, Map and Tup to get a bit of overview here:

id = 47
name = "Fred"
age = 7

my-tuple = ‹id, name, age›  --> ‹47 ,"Fred", 7›

my-set = {id, name, age}  --> {7, 47, "Fred"} (clarifying that sets are unordered)

my-map = {id: 1, name:, age:}  --> {id: 1, name: "Fred", age: 7}
-- alternatively:
my-map = {id: 1, : name, : age}  --> {id: 1, name: "Fred", age: 7}

my-flags = {+debug:, -live:}
-- alternatively
my-flags = {:+debug, :-live}

I think the "identifier in the key-pos", aka colon is suffixed, and value left out, looks better - less confusion for Crystaleers and Rubyists also.

Some words about Set:

  • Set in crystal-lib is currently implemented as a Map under the surface.
  • The most common use-case for Set is Tag's, Char's and Int's. This can be implemented with an IntSet type that is very efficient in comparison to CrLib Set. Which I intend to implement later on, then simple maths notation sets get a very good - and efficient - use case. (This would be very straightforward if specializations are implemented)

@stugol
Copy link
Contributor Author

stugol commented Mar 24, 2016

Now you used the newly proposed Tup syntax, not Map (aka Hash) syntax

Silly me.

Flags: that would create a Set containing positive value of variable debug and negative value of variable live

Technically you're talking about a HashSet, then. A true Set would only be true|false. Specifying {-blah} would be a no-op, unless blah already existed in the set.

If we're talking about a HashSet, we could add {!blah} to delete the item - that is, set it to nil, rather than false.

So you want { ... } for sets and hashes, then. I had forgotten that's why you'd changed the tuple syntax. In which case, strikes me { :name } makes more sense than { name: }, because the latter looks like a mandatory keyword argument with no default value; whilst the former simply looks like we've omitted the key for brevity. And fortunately, you've liberated the : from symbol usage, so we're free to use it here ;)

{ #value } could be either an auto-hash or a set of symbols, though. So we'd have to use { #:value }. Similarly { +:flag } and { -:flag } make the most sense to me.

The most common use-case for Set is Tag's, Char's and Int's.

Never use an apostrophe to denote a plural. Not only is it wrong, but I also find it horribly annoying ;)

@ozra
Copy link
Owner

ozra commented Mar 25, 2016

Technically you're talking about a HashSet...

No syntax decisions should be derived from the implementation detail in this case. Map is used for most Sets to store inclusion, a specific implementation will be used for intish Sets, but in all cases: it's really an opaque implementation detail, and should be expected to change at any time. A Set either contains a value or not, that's all "on the surface".

Regarding +/-, it would be good for the flag-hash, but not for removing items from a set. It should mean set key x to true|false and not "remove item with key x" / "remove value x from set" - different things, and subtly so in some use-cases which makes it even more dangerous.

Yes, either colon before or after seems good choices, they denote the key-relation, which is non-existent in Sets, thereby clearly separating them visually and syntactically.
I like both pre- and post-colon, but to me, post-colon seems more logical in more places, so let's keep thinking on that one. Both pre- and -post colon, interchangeably, will likely not be allowed. And yes, you're spot on: use-cases similar to this, and the fact that hash-tagging is a universal concept today where some of the reasons I changed Tag-syntax from Crystals Symbol-syntax :-)

Shuffling the notation and writing a few examples with a little context will give us a clearer picture of which choices to make regarding the details here.

Never use an apostrophe to denote a plural...

Ah, stupid mistakes like that crawl in when I get tired, thanks for the poke! (common mistake for us Swedes: suffix 's' always indicate possessive in Swedish, plural has (multiple) other endings)

@stugol
Copy link
Contributor Author

stugol commented Mar 25, 2016

Regarding +/-, it would be good for the flag-hash, but not for removing items from a set.

I did suggest ! for that purpose.

@ozra
Copy link
Owner

ozra commented Mar 25, 2016

My bad - totally missed that. I'll re-read and re-consider for further discussion before nailing and implementing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants