"Data blocks" syntax specification draft

[bartc]

On 22/05/2018 03:49, Mikhail V wrote:
> On Mon, May 21, 2018 at 3:48 PM, bartc <bc at freeuk.com> wrote:

>> But I have to say it looks pretty terrible, and I can't see that it buys
>> much over normal syntax.

> 
> # t
>     # t
>        11  22  33
> 

Is this example complete? Presumably it means ((11,22,33),).

> You get the point?
> So basically all nice chars are already occupied.

You mean for introducing tuple, list and dict literals? Python already 
uses (, [ and { for those, with the advantage of having a closing ), ] 
and } to make it easier to see where each ends.

The only advantage of your proposal is that it resembles Python block 
syntax a little more, but I don't know if it follows the same rules of 
indentation and for inlining content.

> Proposing Unicode symbols -- that will probably will be
> dead on arrival (just remembering some of such past proposals).
> Leaving out symbols could be an option as well.
> Still the structure needs a syntactical entry point.

Note that Python tuples don't always need a start symbol:

    a = 10,20,30

assigns a tuple to a.

> E.g.
> 
> data = ///
> t
>     t
>        11  22  33
> 
> Hmm. not bad. But I must think about parsing as well.

Have you tried writing a parser for this? It can be stand-alone, not a 
full parser for Python code. That could help reveal any problems.

But think about when t could be the name of a variable, and you want to 
construct the tuple (t,t,t):

  ///t t t t

That already looks a little odd. And when the /// is omitted:

  t t t t

Is that one tuple of (t,t,t), or a tuple of (t,(t))?


Also, is ///t ///t ///t a b c allowed, or does it have to be split 
across lines? If it is allowed, then it's not clear to which tuple b and 
c belong to, or even a, if an empty tuple is allowed.

I think this syntax is ambiguous; you need a more rigorous 
specification. (How will it parse ///.3 4 5 for example?)

> So I can change types of all child nodes with one keystroke.

Suppose you only wanted to change the top one?

> 
>>
>> The ///d dictionary example is ambiguous: can you have more than one
>> key:value per line or not? If so, it would look like this:
>>
>>    ///d "a" "b" "c" "d" "e" "f"
> 
> ///d   "a" "b"    "c" "d"    "e" "f"
> 
> Now better? :-)

Not really. Suppose one got accidentally missed out, and there was some 
spurious name at the end, so that you had this (dispensing with quotes, 
these are variables):

    ///d a b c e f x

The pairing is a:b, c:e, f:x rather the a:b, c:d, e:f that was intended 
with the x being an error. Use of : and , add useful redundancy. It's 
not clear whether:

   ///d a b
     c e
     f x

is allowed (I don't know what the terminating conditions are), but in a 
very long dict literal, it's easy to get confused.


I think this is an interesting first draft of an idea, but it doesn't 
seem rigorous. And people don't like that triple stroke prefix, or those 
single letter codes (why not just use 'tuple', 'list', 'dict')?

For example, here is a proposal I've just made up for a similar idea, 
but to make such constructors obey similar rules to Python blocks:

  tuple:
      10
      20
      30

  list:
      list:
          10
          tuple: 5,6,7
          30
      "forty"
      "fifty"

So, the keyword prefixes are followed by ":"; entities can follow on the 
same line, but using "," rather than ";", and the end of a sequence is 
just like the end of a 'suite'.

But even here there is ambiguity: the '5,6,7' forms a tuple of its own 
in normal syntax, so these could be a tuple of one tuple of 3, rather 
than a tuple of 3. (I may need ";" here rather than ,")

-- 
bartc