"Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> On 5/19/18 10:58 PM, Mikhail V wrote:
>>
>> I have made up a printable PDF with the current version
>> of the syntax suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further
>> re-considerations, e.g. element separation should
>> be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
> Mikhail, you have a completely different esthetic for syntax than the rest
> of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
      foo  bar

and even so:

tuple:
   tuple:
      foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.