Informally: each row in the sheet is a new line, and each cell is separated with a pipe (|). Cells can contain either values (various number formats supported) or formulas. Example:
```equalto
**Item** | **Cost**
Rent | $1500
Utilities | $200
Groceries | $360
Transportation | $450
Entertainment | $120
**Total** | =SUM(B2:B6)
``` Item | Cost
-------------- | -------------
Rent | $1500
Utilities | $200
Groceries | $360
Transportation | $450
Entertainment | $120
**Total** | `=SUM(B2:B6)`
https://github.github.com/gfm/#tables-extension-Getting rid of the vertical divider is nice but I'd rather think of it as a tiny modification to GFM than a distinct language.
Putting the in backquotes could make it look more like a formula and also it could be required for formulas to prevent accidentally invoking it.
It really is nice to have the horizontal bar gone, though. I think I might make my own format based on it. I tried to get rid of the bar but saw that you can't. In fact the only way you can have everything on one side of the bar is to only have a header (thead) when it would often be useful to only have a body (tbody).
FWIW original markdown requires pipes at the start and end of each row but not GFM.
At first sight, I think GFM's table extension and Sheet Markup have different goals. While the table extension is intended for displaying a single table of data, Sheet Markup for defining an interactive spreadsheet, including things like formulas. Such a spreadsheet might not really be a single "table" as such, it might be multiple separate logical tables. Also, I suspect that we will in future want to extend Sheet Markup with additional features which would be "even further" from what GFM's table extension supports.
But thanks, certainly food for thought!
External DSLs of course give you full flexibility, as you are no longer constrained by the language. https://javieracero.com/blog/internal-vs-external-dsl/
My past work and this gave me the idea to do something that sits between an internal DSL of markdown and an external DSL - to allow tables without row dividers, but put them in fenced code blocks with a different language name so they don't get displayed wrongly by existing markdown tools, instead displayed as code. And because this is the only difference, to make it display as a table using existing gfm tools, an empty header could be added, since normally it's not desirable to have the whole thing as a header.
Here's an empty header that at least on https://loilo.github.io/gfm-preview/ shows up shorter than a normal line:
[]()|||
-|
Rent | $1500 | paid
Utilities | $200 | unpaid
Though it isn't md I think I will have md in the name of the extension, much like jsonl has l in the name but a jsonl file with two or more lines of data isn't a single valid JSON document.Edit: here's one that displays on GitHub:
[]()|[]()|[]()
-|-|-
Rent | $1500 | paid
Utilities | $200 | unpaid... and it made me wonder if some other syntax would work better, which made me think that maybe something like this would work?
=sum(column | 2+ | above)
targets whole column "stream"
second item and later
above this cell
pipes manipulate the target "stream"
I'm waffling between rx-like and unix-like for terms though. Or something else. But a much more relative-and-whole-sheet-focused language seems like it could be a lot nicer than pinning cell IDs everywhere.As for why one would possibly ever want to use Sheet Markup for mode complex spreadsheets, one use is as a way to interact with an LLM. We've started to see some interesting results using GPT-4 to analyze various kinds of spreadsheets that have been encoded in Sheet Markup.
Very powerful, but I found it challenging to remember the syntax since I was only using them intermittently. Still, it could indeed form the basis of a more advanced spreadsheet markup syntax, supporting things like merged cells (which Sheet Markup does not, and probably never will, support).