"Data blocks" syntax specification draft

[Dan Strohl]

First of all, I suggest splitting this into a separate proposal (new thread) that way you will avoid confusion for people who are still considering the older proposal, and for the (probably many) people who have stopped reding the old thread due to some of the more heated conversations in there.

> 
> Though hard-coded knock-out is also very useful, e.g. for this:
> 
> data = /// s4
>         First line indented more (8 spaces)
>     second - less (4 spaces)
> rest code
> 
> So this will preserve formatting.
> 

True, but in everything, there is a balance between flexibility and complexity.  Nothing else in python (that I can think of) forces people to use 4 spaces, that's merely a style thing.  If I want to use 2 spaces, I can, I've seen modules that use 3 spaces for indenting and it works fine.  So, the flexibility of adding the ability to further indent the first line seems to me to be outweighed by the added complexity of this being "different".

> 
> >> data = /// "???"
> >> ??? abc foo bar
> >> ???
> >>
> >> - defines indent character by string: crazy idea but why not.
> >>
> >
> > Nope, don't like this one... It's far enough from Python normal that
> > it seems unlikely to not get through, and (personally at least), I struggle to
> see the benefit.
> 
> Heh, that was merely joke - but OTOH one could use it for hard-coded indent
> sequences:
> 

Yeah, I get it (now <grin> ), I would caution against making jokes in the middle of an already controversial thread.  When they are missed, they tend to be used against your suggestion.


> data = /// "    "
>         First line indented more (8 spaces)
>     second - less (4 spaces)
> rest code
> 
> A bit sloppy look, but it generalizes some uses. But granted - I don't see much
> real applications besides than space and tab indented block anyway - so it's
> under question.
> 
> 
> >> Language  parameter, e.g.:
> >> data = /// t1."yaml"
> >>
> >> -this can be reserved for future usage by code analysis tools or
> >> dynamic syntax highlighting.
> >>
> >
> > I can see where this might be interesting, but again, I just don't see
> > the need,
> 
> I think you're right  - if need a directive for some analysis tool then one can
> make for example a consideration to precede the whole statement with a
> directive, say in a comment:
> 
> # lang "yaml"
> data = /// t
>     first line
>     last line
> rest
> 
> 

Again, you're complicating the thought without really providing enough benefit to it to justify the complication.   Something to keep in mind when you look at most languages, the simpler the language primitives the better, added flexibility can (and should) be added later in modules and functions.  But primitives should have as few caveats as possible, they should work pretty much anywhere with very little needed documentation.  To me, the idea of an indented TQS idea (data-string, data block, whatever) Is interesting.  Extra features are fine, but when they start making it "more complex" to use, then you should back off.

> 
> 
> Also I am thinking about this - there might be one useful 'hack".
> One could even allow single-line usage, e.g.; (with a semicolon)
> 
> data = /// s2:  first line
> 
> - so this would start parsing just after colon :
> "pretending it is block.
> This may be not so fat-fingered-proof and 'inconsistent', but in the end of the
> day, might be a win actually.
> 
> 

If you are thinking about this road, what about instead making another reserved word and approaching it like class or def, for example;

datablock data:
    first line
    second line

Then you can also add functions without "breaking" python approaches like:

datablock data(foo, bar, blah):
    First line
    Second line

(*having thrown this out, I don’t know the parser/compiler well enough to know if this would cause more problems or not).

Being honest, I'm not sure that even these would be enough to get it added without a stronger case, but the further you stray from the python norms, the less likely it is to even get consideration.