Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhailwas at gmail.com> wrote:

>> *Example 1. Multi-line strings*
>>
>> data === S :
>>     this is multi-line string
>>     escape chars: same as in strings (\\, \\n, \\t ...) ,
>>     but "no need to 'escape' quotes"
>
> My reaction #1: why 'S'? Python strings have a name: it's 'str'.
> ...
> My reaction #2: what's the point of this construct? Python already has
> multi-line strings that can be used as expressions, not as statements
> only.

#1. I think passing multiline data structures as arguments
is not especially beautiful. Necessary? I don't know.
#2. What is the point? If introduce the new syntax _at all_,
- the cost of adding some additional common types is less -
IOW worth investigating some options?
About string type id - I agree it may be suboptimal with "S", since
it is not like tuples. But well, there must be something.

In this case:

s = """\
multi line string multi multi line string
multi line string multi line string"""

vs:

s === S:
    multi line string multi multi line string
    multi line string multi line string

Nothing revolutional, just a bit cleaner and with
an indent (which is not necesserily always a good thing
but IMO a bit more presentable).
The problem though, this will require editors to
modify their lexers for highlighting - this is a problem :/


> My reaction #3: Not a fan of adding an '===' operator. We already have
> '=' and '=='. Javascript is another language that uses '===' to mean
> something completely different from this proposal (it's another
> equality operator) and it's a mess there. Come up with something else.
>

"===" is just the least disturbing one I've come up with while
experimenting. I thought it should start with "=" at least.
E.g.
data =%  T :
data =\\  T :
(\\  now is syntaxError: unexpected character after line continuation)

I dont know - frankly I think its too early to start the game of
perfect operator choice.


>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>>     "foo bar"
>>     "hello world"
>>     "to be continued..."
>>
>> VS current:
>>
>> data = (
>>     "foo bar" ,
>>     "hello world" ,
>>     "to be continued..." ,
>>     )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

Well, in the above case you don't have to type tabs or commas.
As for what character is easier to type : commas or tabs :
I find that Tab key is maybe a bit harder when using together
 with upper number row keys - OTOH when using keypad -
it feels easier. On average I think its comparable.
Also if you type commas, usually you want to type
space after a comma, or  a Tab  ;-)
So Tab maybe will win this race.


>> and, whats more important - hard to notice missing commas.
>
> But it's totally easy to notice missing tabs, right? Not.

**Those are two different things** - commas must be there -
and the issue persists, you want it or not.

I still have feeling that you try to imply that commas have
some role apart from Disambiguation of closely positioned
tokens - that's what they are from reader's POV.
In other words, if inter-token spacing is solid - commas are nothing
but redundant noise.
Do you understand this or not?

Also there was a topic about string lists on 'Ideas' recently -
so thats not only me who notices it.

Issues with input of tabs is more of psychology &
experience I'd say. I haven't problems with that.
Normally I input 2 tabs to make it form a solid whitespace- it
gives me optimal look. And I don't bother too much with
perfect alignment usually.


>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>
> What about T/S? S/T? S/S? Are these allowed?

Not really. The idea is: to identify common cases
and data structures and try to find an optimal
set of ID's to represent them. But the slash
indicates that it's 2D case - so this one
is sort of explicit sign of higher dimension.

>
> Also, why is there a division operator here?

"slash"


>
>>     1    2    3    "hello"
>>     a    b    c + d    e     f
>>
>> is a synonym for:
>>
>> data = (
>>     (1, 2, 3, "hello") ,
>>     (a, b, c + d, e, f ) )
>
> If this is supposed to be a tabular format then why is the second row
> allowed to have a different number of elements than the first row?

why not ?

>
> What about named fields? Is there a proposal for extending this syntax
> to allow construction of dicts or namedtuples?

Maybe - though there already exist Python built-in methods to convert
e.g. tuples to dicts and lists.


>
>> The rule here is: TAB character is inner elements' separator, and the
>> new line is outer elements' separator. Line continuation
>> character is  \  (to help with long lines).
>
> So brackets and commas are too ugly, but line continuation characters
> are just fine?

Yes.


>> - implicit string concatenation disallowed
>
> So this would be a syntax error?
>
> foo === T:
>     "one" "two" "three"

Yes I think so.


>
> That seems reasonable, but what about this?
>
> foo === T/T:
>     "this is a very " \
>     "long string " \

This one not, I'd say it should give:
foo = (("this is a very ", "long string "))


M