On 22/05/2018 03:49, Mikhail V wrote:
On Mon, May 21, 2018 at 3:48 PM, bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list
