further amplify table row and cell requirments and recommendations

[ShimmerFairy]

I'm fine with the first part (since I'm not a fan of the whitespace-delimited form in the first place, seems reasonable to mention how it could mess up), but I'm not so sure about the second part.

When it comes to implementing tables off in my own reworking of Pod parsing, I fully intend to implement support for colspans/rowspans, which would be in contradiction to the second part. Of course for whitespace-delimited tables, representing those kinds of cells aren't possible, so in that case the "add extra cells" thing works. However, I believe my approach to that would be to signal an error in that case for whitespace tables, as with all kinds of malformed tables.

Basically, for tables delimited by non-ws characters, I would either view rows with not enough cells as either wanting colspan cells or being malformed, depending on if it's completely drawn out. And for whitespace tables, I'm of the opinion that badly-formatted tables should signal an error, since you can't reliably do tricky formatting in that style.

(And yes, I should really write down all my thoughts on Pod tables in particular somewhere.)

[tbrowder]

On Tuesday, July 5, 2016, Faye notifications@github.com wrote:

I'm fine with the first part (since I'm not a fan of the whitespace-delimited form in the first place, seems reasonable to mention how it could mess up), but I'm not so sure about the second part.

Great.

When it comes to implementing tables off in my own reworking of Pod parsing, I fully intend to implement support for colspans/rowspans, which would be in contradiction to the second part.

I would love to see that. I asked Damian about extending S26 tables and he said there is the capability to exten with one's own keywords, but I don't see how extending, and tightening, S26, while retaining reasonable compatibility with current Per 6 pod is a problem.

Of course for whitespace-delimited tables, representing those kinds of cells aren't possible, so in that case the "add extra cells" thing works. However, I believe my approach to that would be to signal an error in that case for whitespace tables, as with all kinds of malformed tables. Basically, for tables delimited by non-ws characters, I would either view rows with not enough cells as either wanting colspan cells or being malformed, depending on if it's completely drawn out. And for whitespace tables, I'm of the opinion that badly-formatted tables should signal an error, since you can't reliably do tricky formatting in that style.

I agree with you completely. My only concerns about requiring strict, consistent cell count now are:

1. how that would effect current pod, and
2. how to gracefully let the user know what and where the errors are.

I asked about how to throw an exception in nqp that would also point to the offending line but I, so far, have only found die which isn't very helpful.

Best regards,

-Tom

[ShimmerFairy]

Just to note, in general I think pull request is OK to be pulled in, I just wanted to point out where I would ideally make things different :) .

If you're talking about throwing errors from within Perl 6's grammars or actions, then Perl6::Grammar (via the STD role) has (from least to most severe) worry, sorry, and panic methods. Those are for simplistic "just throw a string error" conditions, with typed_worry etc. variants for throwing P6 exception objects.

If you want to see the work I've done so far on Pod parsing, there's the SUPERNOVA repository under my account. It's been dormant as I've been focused on other projects, but it could definitely use the help! (timotimo is another person who's expressed interest in SUPERNOVA). I just realized there's a dependency I need to re-upload for that, which I'll get to asap. I'll be happy to talk about it on IRC (or elsewhere perhaps) as needed. (In case you wonder, it's in its own repo to speed up the development/testing process compared to developing in-rakudo.)

Back on track a bit, I specifically only have support for tables using Unicode characters in my own project at the moment. (Without row/colspans, since my first try at tables got out of hand, and thus the current attempt takes things more slowly :) ).

As for compatibility issues, they're definitely worth keeping in mind, though I always felt S26 specifically could stand some breakage here and there (granted, this was before Christmas, so that's harder to get by with now). I'd be surprised if character-delimited tables had bad cell counts, but I can imagine that being the case for whitespace tables. I guess we'd need to look for and analyze whitespace tables to figure out how often badly-formatted ones pop up.

[tbrowder]

On Tuesday, July 5, 2016, Faye notifications@github.com wrote:

Just to note, in general I think pull request is OK to be pulled in, I just wanted to point out where I would ideally make things different :) .

I've modified the words a bit.

If you're talking about throwing errors from within Perl 6's grammars or

All my naive work has been inside Pod.nqp since I have just been trying to clean up the nqp handling of what I have seen as an incoming array of strings and arrays of strings. Thus I would like to see some way to fail and notify the user with a useful message, but I guess that's not possible.

Your project looks more sensible (and complicated!), and I guess able to throw such messages.

If I were doing all this my way, I would take the simple road and first clean up Pod.nqp to handle the current S26 (with the text changes you and I have suggested), and then work on a new format using html5 table markup, say between "=table-html5"/"=end-table-html5" lines.

If you want to see the work I've done so far on Pod parsing, there's the SUPERNOVA repository under my [ShimmerFairy] account. It's been dormant as I've been focused

I will fork it and will try it out.

As for compatibility issues, they're definitely worth keeping in mind,

We could also look at a changing spec for 6.d if breakage is a concern (which I don't believe should be for the stricter requirement for equal cells for all table rows).

[ShimmerFairy]

Looks good to me. I can't merge it in at the moment, but someone else definitely should :) .

[tbrowder]

So merged.