Feature request: Terse hash and array access

[stugol]

a Array[Int]
a:0 = 2
a:1 = 4
b Hash[Symbol, String]
b:name = "Fred"

[ozra]

Ah, yeah! I've been thinking of something like this. In Jytron it was some-obj!some-key (mimicked from VB [shudders...]). That symbol is of course problematic here.

The colon clashes with colon as a block starter: a = [1,2,3]; if some-fn a:1: do-stuff

If we demand block-starter colon (note, I am talking about a block of expressions, not the crystal-kind) to be followed by space, and access-colon to never be followed by space (before key [which is very reasonable]), then it would work out. But it would be preferable if we could find another symbol.

One idea is obj#key = 1; x = obj#key, since that is used for Tag's, and not a structural part of the language (which would cause much harder to find bugs when misused). In this scenario a call to a func with Tag param, where the space is missed (my-fun#some-tag) would resolve to my-fun["some-tag"] which would be rather quick to figure out. But still not really satisfactory.

Any other ideas for symbol or so?

For pure number indexing, an option is also my-list.1 = "Oi!", since there can never be functions or methods beginning with numbers. It also visually mimicks (with a liiiittle phantasy) sub-positioned numbers from mathematics. I've used that a lot in LS, and it's grown on me.

For keys of Tag or String the quest remains.

Also that: should the implicit key be Tag or String. Tag seems the obvious choice, but when considering situations of use, if they would more often be network related and JSON data for instance, then string could be better off, because Tag's are compile-time set.

So if this, along with "js-style" hash-notation could be concluded to be suitable type (and I'd think it'd lean towards string for these more dnyamic uses) it would be a really clean combo for that area of coding.

[stugol]

Yes, VB6 was awful. VB.NET is nice though. Or would be, if M$ hadn't broken the Windows platform entirely with 8 and above :(

If we demand block-starter colon to be followed by space, and access-colon to never be followed by space, then it would work out. But it would be preferable if we could find another symbol.

You seem to have strong views about whitespace; which is odd, considering Onyx is a whitespace-significant language. You objected to ?? with a space, and now : with a space; but the fact remains that these symbols make sense.

There are only a finite number of symbols. If we choose a new symbol for every task, we will rapidly hit a wall.

You refused to waste ' on char literals, because it's much more useful having multiple functions; and the same applies here. The ? and : symbols can totally have different meanings depending on context.

That said, # would be acceptable, and - as you say - kinda fits, given its use in tags. I propose the following:

hash#tag == hash[#tag]
hash:key == hash["key"]
hash.index == hash[index]
array.index == array[index]

It's elegant, and useful.

[ozra]

VB

Oh, the horror. I've been running Linux since '97, Amiga before that. But I have coded some years of VB Win for specific clients. Brrr. Haha. But that notation was one of the things that was good. There's silver linings to be found everywhere :-)

You seem to have strong views about whitespace; which is odd, considering Onyx is a whitespace-

Yes you're right, I have strong views on it: That it's delicate - veeeery delicate.

The significant indent is one thing - it's dead simple for anyone to relate to, that's how data, instructions, etc. are structured in "real world text bodies".

When it comes to other white space being significant, it becomes tricky fast.

For instance, currently the ' symbol is used for pragmas and specifically stating a type-annotation follows (rarely done in practise), this is along with my experimental ideas around mutability/immutability/etc and also for possible feature of requiring explicit assign of vars etc. Anyway: the point is - these two uses will very unlikely come in conflict and cause "cross-errors" (one mistake cause the compiler to be stumped as to what you might have meant, and gives a out-of-this-world error pointing in some entirely confusing direction)

So, of essence is:

• Really weighing if it's worth it (juxtaposition calls are so frequent, it's a go!)
• Ensuring that commonly occurring code constructs look clearly separated if they rely on the spacing as sole differentiator
• Opt for re-using symbols such that they give a logical similarity in "some way"
• Symbol re-use, when mistyping a space, should not lead to misleading confusing errors

That's why I worry that the "control-structure-colon" is dangerous to use as an indexing-symbol, since it can very likely be used in if-conditions and then there's a potential "wreck havoc on the whole structure" from one single space mistyped.

I simply want to clarify why it needs to be contested, twisted, torn and battle discussed first when it comes to these finicky things.

One way to very consistently and cleanly solve it is to follow Haskell: all "free" operators must be spaced. Then the habit will keep it clean, and it's the absolutely most favoured formatting of code anyway: a = 1 + 2, not: a = 1+2. Any more spaces doesn't matter - just that it is spaced. Then affinity-operators (just made up that word) are always much clearly different.

Now, aside from that: I really like the looks of the suggested notations. So, if we finally conclude : would not cause to much problem - it would be awesome. I'll sleep on it :-)

The colon really mirrors the fact of keys being String in JS-JSON notation in that case. Neat congruency.

Re-iterated:

obj#key == obj[#key]
obj:key == obj["key"]
obj.literal-index == obj[literal-index]

But, there's the question of, should these map to [] or []?. I think the Type? should be default.

So, perhaps also:

x = obj#key!
y = obj#key?  -- default anyway (?)
z = obj:key!
u = obj:key?  --  -""-
v = obj.literal-index!
w = obj.literal-index?

?

[stugol]

Actually, I reckon ! should be default. After all, it's the default pretty much everywhere else. Plus, we want to avoid nil unless we specifically request it - that's a general tenet of Crystal, I believe.

I think requiring spaces around free operators is a reasonable compromise. Besides, don't dashed identifiers already clash with non-spaced subtraction?

some-thing ->

some = 1
thing = 2
say some-thing          -- ???

If we mandate spaces around free operators, that means ?? is viable again too ;)

[ozra]

Yes, that is the de facto default, so you're right: it's stupid to diverge. The reason for the idea was for super simple value defaulting in case of non set - for option hashes and the like, but, it's just a ? away, so :-).

Yes, correct: you can never have alpha numerics before a hyphen without space, if it is to act as subtraction operator. Some "dash-languages", allow foo = 50; x = foo-47 => x = 3. I think it's very good to be able to name vars x-1, whatever-2 etc. so therefore it must always be spaced.

For those opposing dashes, that it would be "dangerously confusing", a few scans of sources bases has shown that non spaced subtraction almost never appear in code bases with good formatting.

I see nothing wrong with ?? as an operator at all - I just don't see it fitting for the nil-sugar-chaining.

[ozra]

Implemented numeric dot indexing.

[ozra]

What the hell. Implemented foo#bar and foo:bar also. Worked flawlessly with the :-control-char in the spec.

[stugol]

Awesome.

[ozra]

Made deliberate mistypings "both ways" and onyx was surprisingly helpful and good at handling it, so the : is no problem :-)