[Haskell-cafe] Speculation, OT: Program a Spreadsheet

[trent shipley]

Middle posting follows:

First there are a few things going on.

There is the language or languages used by the developers of the
spreadsheet product. There is the language of the spreadsheet itself. There
are the programming languages used by the developers of the spreadsheet
(say accounting power users), like VBA.

Case A:
So for Excel:

Implementation Language: MS C++ (my guess),
Spreadsheet Language: Excel,
Built-in Language VBA. (Excel HAS a programming language and tool.)

Case B:
For Emacs OrgMode spreadsheets (a weird little spreadsheet in a tool whose
main purpose is hardly being a spreadsheet.)
(See http://orgmode.org/manual/The-spreadsheet.html#The-spreadsheet )

Imlementation Language: Emacs Lisp (my guess),
Spreadsheet languages: Emacs Calc, and Emacs Lisp,
Built-in Language: I'm not sure it has one. Given the fact that you can
write ELisp in the cells, it may not need one. However, it also doesn't
look like a full-blown 3d spreadsheet.

Case C:
For the proposed Scriptsheets product:

Implementation Languages: Frege (?), Java, Haskell, C++, C, in that order.
Spreadsheet languages: Scriptsheets,
Bulit-in language: Scriptsheets. (Scriptsheets IS a programming language
and tool.)

Note that a spreadsheet product can have programming languages, it can be a
programming language, and it can interpret (or very quickly compile)
programming statements in a language such as ELisp or Haskell within the
cells of the spreadsheet itself. The features are not mutually exclusive.

I meant to imply that I was interested in Case C, and I believe Joachim
understood me to be interested in Case B (but not Emacs OrgMode as a
specific example of Case B).

Middle posting follows.


On Sun, Nov 19, 2017 at 5:07 AM Joachim Durchholz <jo at durchholz.org> wrote:

> Am 19.11.2017 um 08:05 schrieb trent shipley:
> > * Is a spreadsheet you can program from the spreadsheet a reasonable
> goal?
>
> I.e. use the same programming language for cells formulae and scripts?
> Yes, that's very much reasonable.
>

That is possible.

However, I am interested in programming scripts in spreadsheet, not say,
programming formula in Haskell.


>
> > * Has it been done?
>
> Not in any mainstream spreadsheet. Which boils down to two: Excel and
> Open/Libre Office Calc.
> Excel offers VBA.
> Calc is actually language-agnostic and uses URLs and XML to tie things
> together. It currently supports BeanShell (Java-without-types, it
> seems), Java, JS, Python, and OO Basic.
>
> > So the plan is to take something like GNUmeric or LibreOffice Calc and
> > graft on a primitive function sheet interpreter.
>
> The main point is that you'd have to replace the formular language.
> I do not think that Calc was made for that.
>
> > It would be natural to use C++,
>
> You'd instantly kill adoption with that. Only a minimal part of the Calc
> user base is even remotely capable of coding formulae in C++, and even
> of these, a substantial fraction would be able but unwilling.
>

Agreed. I was not thinking of programming cells in C++. I was thinking of
moving Scriptsheets from vaporware to proof of concept and beyond using C++
by the PROJECT developers (in large measure to appropriate existing FOSS
code).



>  > but the astute will note that a
> > spreadsheet basically does not rewrite cells (unless you use a circular
> > reference), so I'd also like to use a functional language, maybe Haskel.
>
> You don't want to inline the formulae of other cells anyway, because
> then the calculation will be done twice: Once to fill the referenced
> cell, and once as part of the referencing cell.
>
> So for reference cycles, you'll rely on whatever the spreadsheet is
> already doing to deal with them.
>

Exactly, at least until your forked product goes from, say, version 1.0 to
version 2.0.


> > * Would using a functional language as a basic language of the project
> > save effort and intellectual load?
>
> That depends on whether you're talking about the implementation language
> or the cell/macro language.
>

I was talking about implementation language.



> For the implementation language, you'll save the most time by using
> whatever you already know. Unless the project is going to last longer
> than, say, two years. And if you plan on getting other people to join
> the project, you'll want the language with the largest pool of
> interested and able people, which is essentially guesswork but I'd
> avoid, say, the VBA or PHP crowd ;-)
>

Would there be any advantage over preferring a functional over an
imperative language given that Scriptsheets (as a full blown product) would
itself be a functional language.


> For the user-facing language, do whatever is easy to use for a
> non-programmer. Haskell should work fine, but prepare to collect
> references to tutorials, and what does *not* work fine is performance
> predictions, particularly not for nonprogrammers. This probably means
> you need strict evaluation, which means even if it looks like Haskell
> it's going to be an entirely different language.
>
> > In the longer term I'd like as much of the spreadsheet programmable as a
> > spreadsheet to be written to run on the JVM.
> > As near as I can tell near future Java and typed functional languages,
> > include the following options:
> >
> > Eta,
> > Frege,
> > Kotlin and,
> > Scala.
>
> I don't know any of these well enough to make any recommendations.
>
> However, for the user-facing language, you need this:
> 1) As easy to learn as possible.
> 2) Scales well to a few thousand lines of code. The learning curve must
> not have bumps along that road, because with every bump, a substantial
> fraction of the user base will be deterred from progressing to more
> complicated tasks.
> 3) You'll need good support for large-scale programming if you want to
> enable "just calling" into third-party modules (which would be pretty
> appealing to people who use Calc for nontrivial stuff). The JVM excels
> at this, BTW, though if you don't use Java, a substantial fraction of
> Maven modules will be awkward to use.
>
> For (3), you'll need static typing.
> For (1) - and arguably (2) and (3) as well - you need something that is
> excellent at type inference.
>
> Type inference does not work well for updatable data structures, so you
> will want something that excels at handling immutable data. Which
> essentially rules out C++ or any other imperative language.
> The type system is a real problem. For many real-world situations you
> need dependent types, but these have complicated error situations so
> newbies will usually be unable to deal with it, which means a bump in
> the learning curve. I don't know of a good way to deal with that, it's
> just on the list of things that I routinely check if somebody asks me to
> take a look at his great new language :-) (Haskell people excel at
> bending its type system to simulate all kinds of things, and I wouldn't
> be surprised if nobody had tried to achieve most dependent-type benefits
> from Haskell's type system; however, people using such a type framework
> will need to know the Haskell type system and the internals of the
> framework to make sense of any error messages that come out of a type
> bug, so this is a variant of programmer's golf, not something you want
> for newbies and learners.)
>
> The JVM would be desirable, but typical .jar modules make heavy use of
> mutable data. So you need something that's alien to mutable data types
> but not incompatible with then; that's a relative fine line that the
> language design would have to strike.
> I'd probably use a language that allows mutables but disallows aliases
> to them. Clean does this via the type system, other strategies might be
> work. However, given that arbitrary modules from the JVM ecosystem might
> throw aliased updateable references left and right, all guarantees are
> off as soon as a computation relies on data provided from a JVM module,
> so maybe it's still not worth using that. (Java folks have been thinking
> about "value types", i.e. immutables, for a while now, but I don't see
> that coming any year soon.)
>
> Evalutation strategy is another issue.
> Non-strict has some nice properties, in particular you don't need to
> differentiate between an expression and its value. However, nonstrict is
> difficult to control performance-wise, and I still see people struggle
> if they see that their code is unexpectedly slow.
>
> > Note that a spreadsheet needs to give the satisfaction of immediate
> > results, or failing immediate results, the sensation of actively
> > working, so if the language could be interpreted that would be a huge
> help.
>
> +1
>
> > * Which combination of typed, compiled, interpreted, FOSS functional
> > language that runs on the JVM, JAVA, Haskell, C++, C, used in that order
> > of preference, makes the most sense for the Java compatible functional
> > language at the top of the preference hierarchy?
>
> C++ and C aren't worth it if you plan to go for the JVM.
> Don't know if there's a useful JVM port of Haskell.
>
>
I know Hadoop in in Java, except where speed is of essence, then Hadoop
uses C++ or sometimes C. I figure the same would be true for this project.

For Haskell on JVM see Eta and Frege. Frege is the older project. Neither
seem to be particularly mature.


> You *can* interface with OO using XML descriptors and such, so the JVM
> isn't your only option. You could even use (or invent) a language that
> compiles to binary, with LLVM that has become a realistic option.
> However, plan to invest some time into understanding LLVM.
>
>


> > Note also, that I have only the equivalent of an AA degree from a CIS,
> > not a CS, perspective, so the odds are the whole idea is vaporware,
> > unless I can determine feasibility and desirability,
>
> I suspect that no existing language fits the bill.
> Given your background, you'll need somebody with language design
> experience; language design is hard because of so many conflicting goals.
>
>  > then sweet talk
> > real developers to help out.
>
> That's a good plan :-)
>

Do you know any gullible developers with the chops?

Which do you see as more promising a real GUI spreadsheet for Case B or one
for Case C? Or would it make sense to be ambitious and try to do both in
the same project using a common spreadsheet core backend and largely shared
front end?


> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171119/75acff88/attachment.html>