<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 21, 2017 at 1:50 PM Joachim Durchholz <<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 21.11.2017 um 08:13 schrieb trent shipley:<br>
> Which one it is that you are interested in?<br>
> "Three-dimensional" as in "we have row, column, and layer", or as in "we<br>
> have hierarchical workbooks"?<br>
><br>
> They are not mutually exclusive. A workbook can contain sheets--just<br>
> like now. IN ADDITION, you can put workbooks in workbooks, until you<br>
> reach the root workbook, which is also a file.<br>
<br>
Not an answer that helps me understand your point.<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>One more try.</div><div><font face="monospace"><br></font></div><div><div><font face="monospace">+---+---+</font></div><div><font face="monospace">| | | Sheet. 2d. rows & colums.</font></div><div><font face="monospace">+---+---+</font></div><div><font face="monospace">| | |</font></div><div><font face="monospace">+---+---+</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"> +---+---+</font></div><div><font face="monospace"> / / /|</font></div><div><font face="monospace"> +---+---+ + </font></div><div><font face="monospace"> / / /|/|</font></div><div><font face="monospace">+---+---+ + +</font></div><div><font face="monospace">| | |/|/ Worksheet or Virtual Worksheet. 3d.</font></div><div><font face="monospace">+---+---+ + Stacked sheets. Maximum for mainstream spreadsheets</font></div><div><font face="monospace">| | |/</font></div><div><font face="monospace">+---+---+ </font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">root workbook (file)</font></div><div><font face="monospace">+---------------------------------------+</font></div><div><font face="monospace">| +---+---+ +---+---+ |</font></div><div><font face="monospace">| [0] / / /| / / /| [1] | </font></div><div><font face="monospace">| +---+---+ + +---+---+ + | </font></div><div><font face="monospace">| / / /|/| / / /|/| | </font></div><div><font face="monospace">| +---+---+ + + +---+---+ + + | </font></div><div><font face="monospace">| | | |/|/ | | |/|/ | </font></div><div><font face="monospace">| +---+---+ + +---+---+ + | </font></div><div><font face="monospace">| | | |/ | | |/ | </font></div><div><font face="monospace">| +---+---+ +---+---+ | </font></div><div><font face="monospace">| | </font></div><div><font face="monospace">+---------------------------------------+ </font></div><div><font face="monospace"> </font></div><div>File workbook "root" contains, rectangular (not jagged) virtual workbooks 0 and 1. It is 4d. Assuming a theoretical infinte machine, a root workbook could contain virtual workbook containers that contain virtual workbooks to an arbitrary depth. Virtual workbooks can contain either sheets, or virtual workbooks (or, at the application designer's option, both sheets and virtual workbooks. </div><div><br></div><div>A virtual workbook is just a container. Like arrays or matrixes virtual workbooks are a convenient way to model n-dimensions.</div><div><br></div><div>Note, that it would be convenient if the spreadsheet application numbered columns, rows, sheets, and virtual workbooks by default instead of naming sheets like Excel seems to do.</div><div><br></div><div>If you were to allow function libraries or objects in a spreadsheet application you could store them in workbooks or virtual workbooks, extending the concept of putting a proper function in sheet marked with the function property.</div></div><div><br></div><div>-------------------------------------------------------</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> > Also, if sheets can be marked as being functions, virtual<br>
> workbooks can<br>
> > support libraries of functions, or objects, if you want such things.<br>
><br>
> Sometimes I think Excel etc. got it all wrong.<br>
> People routinely reserve areas inside the spreadsheet for different<br>
> tasks: input, intermediate results, output. Increasing the size of each<br>
> area becomes a pain.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>You would need some objects. The idea of linked areas. I'm guessing that Excel tables, kinda do this, but only for one contiguous area on one sheet.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> I'd want to have a spreadsheet where it's easy to define multiple sheets<br>
> on the same "table". Extending the input sheet with another row<br>
> automatically extends the output sheet by a row (and if you have rollup<br>
> then we get more than one row). </blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>So this would be a three dimensional Excel table basically? It would involve the program taking a best guess at what you want in a lot of cases.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Intermediate sheets could be replaced by<br>
> a function definition.<br>
><br>
> It's a bit of an ergonomic challenge; functions are much more abstract,<br>
> and users will want to see how the results of applying a function to an<br>
> input area look like. So the mental model might be that we still have<br>
> intermediate sheets, but with just a single function, </blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>It has been suggested that you can write functions when you would want a complex chain of calculations. You would call the function like any other function. You would still have cell by cell replication, but the user defined function would be defined one, and called many times.</div><div><br></div><div>How would you bind one function to a column/row/range. You would need a visual representation of the binding. Current spreadsheets don't do that. (Except Emacs Org Mode spreadsheets have column functions.)</div><div><br></div><div>In the existing paradigm, you would try your best to generate a plausible solution, then copy it to each cell in the new range in the calculation layer(s). My intuition is to get that working, THEN conquer the single function bound to many cells problem.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and the<br>
> intermediate sheets can be create, destroyed, shown and hidden easily.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Are you hoping to autogenerate the functions?</div><div><br></div><div>Data -> range bound mono-function on intermediate function page -> Results</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The other challenge would be dealing with headers. Headers are<br>
> important, but for the intermediate we have just the function so it<br>
> needs to provide the headers. I.e. the function result would have to be<br>
> a named tuple, and if you want multiline headers, we get a hierarchical<br>
> named tuple.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Concatenated names, generated functions get numbers added to the concatenated name. I don't think you can make the names you generate terribly pretty or human readable.</div><div><br></div><div>The intermediate function guessed and generated for the addition isn't transient, it's durable data too. </div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Manipulating the column order would also manipulate the tuple<br>
> definition, i.e. you'd have to think about how GUI manipulation affects<br>
> the function definition.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>That's more heuristics, and UX/UI testing. Excel guesses wrong on this frequently, and when it does it's a pain. But mostly it's behaves well. I'd want to leverage the current engine that deals with GUI implications for the model.</div><div><br></div><div>I'm still not certain I'm on the same page as you, but that's a little more effort.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> (No longer Haskell discussion, but anything civil goes in Cafe)<br>
><br>
> Sounds both interesting and relevant, but I don't quite get it. Can you<br>
> provide a simple, concrete, narrative example--with pictures (ASCII<br>
> OK)--if possible.<br>
<br>
Nah, I'm only good at walls of text.<br>
And at answering directed questions - start asking about what exactly<br>
you didn't understand.<br>
Guessing what you might have not understood is going to be a waste of<br>
everybody's time.<br>
(Besides, if you need to tell where exactly you didn't understand may<br>
help your understanding. Well, the keyword being "may"; I know it worked<br>
for me on various occasions.)<br>
<br>
> There's pivot tables, so the difference between row and column isn't as<br>
> clear-cut as the above assumes.<br>
><br>
> Don't worry about pivot tables. Simple cases first.<br>
<br>
You have to design for the maximum complication.<br>
Otherwise, stuff will not fit in well, and you'll be stuck with either a<br>
half-assed solution, nothing at all, or a full rewrite.<br>
Trust me. I've been coding and designing software for decades.<br>
<br>
> There are a few more things to consider. It's firmly in the GUI<br>
> ergonomics area.<br>
> For this kind of stuff, you don't care whether the programming language<br>
> evaluation semantics matches the problem domain (spreadsheet functional<br>
> semantics is easy to do in any language, it was done in Assembler with<br>
> Lotus 1-2-3), you care whether it is easy to prototype GUI approaches,<br>
> which means GUI libraries that make it easy to create new widgets.<br>
><br>
> Any suggestions for a GUI library--that kind of implies C++ or Java.<br>
> Ideally your GUI would be cross platform.<br>
<br>
I know only the Java GUI landscape well enough to say anything.<br>
In that area, dialog boxes, menus and such will be easy enough with any<br>
lib, but you'll be mostly on your own for the grid. Also if you aim for<br>
unlimited size you'll get into a lot of hairy memory management issues -<br>
a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and<br>
you end with a memory footprint of a gigabyte. Evaluating a formula for<br>
each cell is going to get you a slideshow-like performance.<br></blockquote><div><a href="https://en.wikipedia.org/wiki/List_of_spreadsheet_software"><br></a></div><div><a href="https://en.wikipedia.org/wiki/List_of_spreadsheet_software">https://en.wikipedia.org/wiki/List_of_spreadsheet_software</a><br></div><div><br></div><div>With the usual cautions about Wikipedia, there is a chart relevant to your argument on this page. It's probably really out of date.</div><div><br></div><div>Does anyone know anything about Lotus Improv or Flexisheet?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So... managing which cells are actually needed and which aren't is going<br>
to be a major point of the software.<br>
<br>
Did I mention that coding a spreadsheet is a huge project? ;-)<br>
<br>
> > Programmers have to learn multiple languages, and most wind up liking<br>
> > it. They also have favorite languages. LibreOffice Calc has about<br>
> four<br>
> > bolt-on languages. As I recall, none of them are a functional<br>
> > programming language. Maybe a few programmers should get together and<br>
> > add one as a sub-project.<br>
><br>
> The problem is that any additional language needs to be installed. So<br>
> either the new language needs to be integrated in the LO project, or it<br>
> is not and anybody who passes on a spreadsheet in the new language needs<br>
> to tell the recipients how to install the plugin for the language.<br>
><br>
> Maybe that's the reason why only the four languages exist.<br>
><br>
> Doubt it.<br>
><br>
> A given plugin's installation could be automated and check for dependencies.<br>
<br>
Heh. Famous last words.<br>
The Java folks got a 90% solution working - just for managing<br>
dependencies, mind you; for some people it doesn't work at all because<br>
they don't know how to get past the corporate firewall. Besides, most<br>
corporate firewalls do a man-in-the-middle certificate nowadays and will<br>
inspect and reject some packets and not others, so any update mechanism<br>
must be able to deal with wilfully unreliable internet connections.<br>
<br>
So that's another area that's going to bind a lot of developer resources.<br></blockquote><div><br></div><div>The last few companies I've worked for had the policy: IT owns your tech. DON'T put software on it. If you need software we haven't given you, you don't really need it, but if you really, really need it, then it will go to the change committee who will evaluate your request, audit the software you want for security threats, price, and maintainability, and MIGHT give it to you in several months, if you are lucky. I can't imagine trying to maintain my own software stack it a big enterprise. That's some poor sys admin's job.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div></div>