On Tue, May 22, 2018 at 1:25 PM, bartc <b...@freeuk.com> wrote:
> On 22/05/2018 03:49, Mikhail V wrote:
>>
>> On Mon, May 21, 2018 at 3:48 PM, bartc <b...@freeuk.com> wrote:
>>
>> # t
>> # t
>> 11 22 33
>>
>
> Is this example complete? Presumably it means ((11,22,33),).
Yep.
>
>> You get the point?
>> So basically all nice chars are already occupied.
>
> You mean for introducing tuple, list and dict literals?
No, I've meant the node (or whole data block) entry point chars ///.
So in such an language full of various operators, it is
just hard to find anything that does not clash with some
current meaning yet looks adequate and is ASCII.
A quick note: thanks for your comments, I'll just note that I've
moved to some more promising related proposal (see last posts in this thread),
so the original one will move to later considerations.
so the nuances will be reconsidered anyway.
> Python already uses
> (, [ and { for those, with the advantage of having a closing ), ] and } to
> make it easier to see where each ends.
Ehm, for inline usage - i.e. everywhere on a line - closing tags are necessity.
My whole idea was about indentation based data - so there it is redundant noise.
You may disagree as well, since I've noticed in some previous thread
that you prefer Fortran-like termination tags. So that's quite personal I think.
As for more objective points: currently many brackets are 'overloaded'
and moreover, they are all almost "homoglyphs" - very similar characters.
For an inline solution I'd prefer it e.g.
for a tuple:
{t 11 22 33}
nested:
{t 11 {t 11 22} 22}
Yes, it IS worse than:
{11 {11 22} 22}
But still one might need _various types_ so brackets only - has
limited potential in this sense.
>>> 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,
Not sure about your case, but it is up to you to format it to make it
more readable - whitespace / newline separation gives enough possibilities to
do so. And for me the lack of commas is of great benefit.
_Some_ punctuation can be added in some cases (see e.g. "node
stacking section" in original document - dicts may adopt this as well
but I see no necessity at least for this case)
> It's not clear whether:
>
> ///d a b
> c e
> f x
>
> is allowed ?
allowed, but i'd say merely discouraged for industrial usage. better start
newline at least for multiline contents.
> 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"
>
Cool, I've commented on similar option actually in some post before -
it might be ok
with type codes grayed-out and good coloring, but in black and white it is a bit
"wall of text" - not much emphasis on _structure_. But its ok - good option.
--
https://mail.python.org/mailman/listinfo/python-list
