Suggestion for a "data" object syntax

[Ian Kelly]

On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>
>
>>> but I propose Tab-separated elements.
>>
>> We already have tab-separated elements in Python. It is allowed to use
>> tabs between any whitespace separated tokens.
>
> Yes, exactly. So in the proposed syntactic construct, it is *not*
> allowed to insert tabs between _any_ tokens.
> Namely if you will insert tabs _inside_ equations,
> like:
> a      + b

Then these are not ordinary expressions, are they? They're a different
type of expression and will require a modified parser. This adds
complexity.

>>> If I allow commas as well, this will become not so simple, probably.
>>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>>> for *work* an this can potentially help a lot of people in everyday
>>> work.
>>
>> /head-desk
>>
>> You: "I have invented amazing new syntax that cannot be exchanged by
>> email. Here, let me email some examples to you."
>
> "GvR have invented amazing new syntax that cannot be preserved
> by sending it by e-mail"!
> (not me)
>
> Do you understand that basically any python code sent by e-mail converts tabs to
> spaces, thus the only way to receive it - is to send binary file?

Um, no, this is false. We send Python code by email all the time.

There are essentially three cases of tabs that can occur in Python:

1) Tabs as indentation: Python permits the use of both tabs and spaces
as indentation, but it requires consistency; if one line is indented
with a tab and three spaces, then the next line in the same block must
also use a tab and three spaces. Therefore, if the tabs are converted
to spaces, they will be converted to the same number of spaces
throughout the block. Indents and dedents remain intact, indentation
is therefore not ruined, and the meaning of the program is not
changed.

2) Tabs as other whitespace: Other tabs in the program, such as in
expressions, don't matter at all. They can safely be replaced with
spaces, and the meaning of the program is not changed.

3) Tabs that appear in strings: This one I'll grant you. A replaced
tab inside a string may alter the meaning of the program. However,
note two things: tabs are rarely used in strings, and when they do
appear it's usual to write them as \t rather than with an actual tab
character.

In any case, the use of tabs is entirely optional. For the most part,
programs can be safely emailed whether they contain tabs or not, the
exception being tabs in strings which are better written as \t. In the
case of your proposed syntax however, the tabs are *required*, and it
is not possible to email a program containing such a construct at all.
Contrary to your assertion, this is *far* different from the status
quo.

>>> Also I don't know what kind of human thinks that this:
>>>  a + b
>>>  is two elements "a" and "+ b"
>>> What is "+ b"?
>>
>> It is unary plus followed by b.
>>
>> If you don't know Python's existing syntax, how can you possibly expect
>> to invent new syntax?
>
> Wow! Uncle Steven knows Python operators.
> My question was: why would you have "+ b" in
> the first place in your code? So you treat the worst-case scenario
> as a normal case - interesting approach  indeed!

When you're designing a language syntax, you need to account for *all*
the cases, not just the ones that you personally would use.

> By the way, since you are into unrealistic worst-case scenarios:
> Imagine you start with Python learning, how you'd like such constructs:
>
> L = [a     +     b, c, d]
> L = [a     +     b, (c, d)]
>
> For a starter, reading this will be quite painful.

I don't know, I find that much less painful than:

L === T:
        a + b   c       d

> Yes, I have told already that there are _some_ cases when
>  tabulation formatting can cause visual confusion.
> *But why do you blame me*?
> It just the issues with editor's incompleteness.
> Simple feature like "set the minimal tab size" would have solved
> this issue by 100%. Maybe it even exists in some editors,
> I would not be surprised at least.

That's great, but if I'm editing a file on an embedded system over a
serial port and the only editor I have available is nano, I should be
able to use it. You can't just assume that everybody has a fully
featured editor (and knows how to use it -- what was that point you
made just above about beginners?)

>  I hope you are not seriously thinking that there is good syntax
>  that gives retro-tools, wacky people, not wacky people,
>  pros, etc. same opportunities.

Why not? The existing Python syntax is fine for this.

> For instance, there is real demand on adding new control characters
> to syntax, so as IDE developers can utilize those for making
> better user experience. If you apply same one-sided principles here
> then you behave good to one group of people, but just ignorant
> to other group of people who want better new experience.

Please link the approved PEP that is going to add syntactically
meaningful control characters.

>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>> and "toggle show space" for that
>>
>> /head-desk
>>
>> You: "This syntax doesn't need tabs and spaces to be visible. Just use
>> the Show Tabs and Show Spaces commands on your editor to make them
>> visible."
>
> Yep!  Just toggle them if you want to find out. That's a good feature!

Needing to fiddle with editor settings in order to determine how the
code in front of me that somebody else wrote is organized doesn't
sound to me like a good feature. That sounds to me like poor
readability.

>>>> - the first one can include nested data structures, while
>>>>   the second cannot.
>>>
>>> Why it can't? did you read the original e-mail?
>>
>> Of course I did. You said:
>>
>>     "So the idea is to cover only first two levels of
>>     nesting of course."
>>
>> With bracket syntax, I can cover unlimited levels of nesting. Yours
>> cannot.
>
> Ok, that was a typo, it must be:
>
>     "So the idea is to _hide brackets for_ first two levels of
>     nesting of course."

In other words, this syntax is really not appropriate for more than
two levels of nesting due to the mental gymnastics required to keep
track of how the current level of nesting should be expressed.