search

ozra / onyx-lang

The Onyx Programming Language
Other
97 stars 5 forks source link

Request: property setting shorthand #63

Open stugol opened 8 years ago

stugol commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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:

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:

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:

stugol commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

I did suggest ! for that purpose.

ozra commented 8 years ago

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