@BlackATTR feels that being able to write code as
operation(arg) with no space is critical to the SQL dialect. While we haven't expressly prohibited that yet, it is lossy:
>> [operation(arg)] == [operation (arg)]
app[.width] = "curly quew"
Also still legal at the moment, but also still broken apart...and being two separate elements means it couldn't be quoted as a unit on the left (e.g. by an assignment-oriented equal):
>> app[.width] = "curly quew" == [app [.width] = "curly quew"]
One of the reasons we'd discussed making these kinds of constructs illegal would be to free them for new meanings. Given that people want more density, might we think of this as a new datatype... like a PATH! or a TUPLE!, that simply has no delimiter?
(Once this was proposed as PACK!, but now packs are something different... so let's just call this the "scrunch proposal")
>> p: 'operation(arg) == operation(arg) >> type of p == #[datatype! scrunch!] ; or whatever, this syntax has tons of thinking needed >> first p == operation ; a WORD! >> second p == (arg) ; a GROUP! with one element
Not every type would be able to participate in a scrunch. As with PATH! and TUPLE!, only the scrunch as a whole could have a decoration (SET-SCRUNCH!, GET-SCRUNCH!, etc.).
Also, while # is a legal "empty issue", it's also a modifier. So the #[a] probably shouldn't be a SCRUNCH!. Unless there's some way that would fit into a broader master plan, by virtue of what that scrunch would mean... e.g. if # = first scrunch would mean something was typically a datatype...
Let's think about other things first.
There's a bit of a problem in that we've been saying you could write (a)(b) and [a][b] and have it mean the same thing as (a) (b) and [a] [b]. I use this frequently, because I do not like the spacing gap you get when braces follow each other.
f: func [ some-arg [integer!] ] [ the gap there bothers me ] f: func [ some-arg [integer!] ][ without the gap looks better ]
That would suggest the rules for scrunching would disallow adjacent GROUP!s and BLOCK!s, which would rule out interesting scrunches that might represent multidimensional array access:
>> [foo[x][y]] == [foo[x] [y]] ; would have to be a scrunch and a block?
Ladislav was always rather adamant that spaces should be everywhere because spaces had signifiance. So he wasn't in favor of the aesthetic gap-closing. If SCRUNCH! turned out to be truly useful, then it might vindicate his belief. I dunno.
So this would give a whole range of things that today have no meaning in the evaluator. If we were to accept choosing out of arrays by index with array[n], how bad would that be...when BLOCK!s have other meanings? It would still be a BLOCK... just one that happens to be in a SCRUNCH!, like array/[n] is inside a PATH! or array.[n] is inside a TUPLE!.
Having foo(bar) be a function call might appeal to certain users, if that was a stylistic choice they could make. Maybe it could even use COMMA! to delimit arguments.
The rule for TUPLE! is that the dots bind more tightly than the slashes. So a.b/c.d is a 2-element PATH! with a 2-element TUPLE!s on the left and right... not a 3-element tuple with a path in the middle.
What would you get with a.b/c.d[e f] ? How about a.b[c d]e/f ?
My general instinct would be that the SCRUNCH! would be the outermost.
a.b/c.d[e f] => to scrunch! [a.b/c.d [e f]] ; 2-element scrunch a.b[c d]e/f => to scrunch! [a.b [c d] e/f] ; 3-element scrunch
But that's not based on any particular evidence of utility. I'm just saying that there has to be a rule...and that's the one that seemed the most natural to me on first glance.
If numbers are allowed, you are going to run into trouble with things like how
1e... leads into exponential notation, and the fact that you get problematic reversals with 1a and a1. The first seems like a candidate for being a SCRUNCH!, while the second is what we'd see as a normal WORD!
You couldn't merge a/ and [b] to get a SCRUNCH!, because a/[b] is a PATH!. This may be a feature and not a flaw...no clue.
Anyway, a lot to think about. But if people are dug in and insistent that they have to have these notations, then we should give consideration to the idea.