- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Speculation, OT: Program a Spreadsheet
by Olaf Klinke 24 Nov '17

24 Nov '17

Yesterday I read in a slashdot thread [1] about Javelin [2], which was available shorty after I was born and before Excel existed. Telling from the wikipedia article, it did what I dreamed up in my previous post: instead of sheets, each logical piece of data occupied its own "variable". (Trent's virtual worksheet might be the equivalent here?) It also make the connections between data browsable. Is there anyone on this list who used Javelin back then? Care to share your experience? Olaf [1] https://news.slashdot.org/story/17/11/22/1525254/stop-using-excel-finance-c… [2] https://en.wikipedia.org/wiki/Javelin_Software

1 0

Re: [Haskell-cafe] Speculation, OT: Program a Spreadsheet
by Joachim Durchholz 23 Nov '17

23 Nov '17

Am 21.11.2017 um 08:13 schrieb trent shipley: > Which one it is that you are interested in? > "Three-dimensional" as in "we have row, column, and layer", or as in "we > have hierarchical workbooks"? > > They are not mutually exclusive. A workbook can contain sheets--just > like now. IN ADDITION, you can put workbooks in workbooks, until you > reach the root workbook, which is also a file. Not an answer that helps me understand your point. > > Also, if sheets can be marked as being functions, virtual > workbooks can > > support libraries of functions, or objects, if you want such things. > > Sometimes I think Excel etc. got it all wrong. > People routinely reserve areas inside the spreadsheet for different > tasks: input, intermediate results, output. Increasing the size of each > area becomes a pain. > > I'd want to have a spreadsheet where it's easy to define multiple sheets > on the same "table". Extending the input sheet with another row > automatically extends the output sheet by a row (and if you have rollup > then we get more than one row). Intermediate sheets could be replaced by > a function definition. > > It's a bit of an ergonomic challenge; functions are much more abstract, > and users will want to see how the results of applying a function to an > input area look like. So the mental model might be that we still have > intermediate sheets, but with just a single function, and the > intermediate sheets can be create, destroyed, shown and hidden easily. > > The other challenge would be dealing with headers. Headers are > important, but for the intermediate we have just the function so it > needs to provide the headers. I.e. the function result would have to be > a named tuple, and if you want multiline headers, we get a hierarchical > named tuple. > Manipulating the column order would also manipulate the tuple > definition, i.e. you'd have to think about how GUI manipulation affects > the function definition. > > > (No longer Haskell discussion, but anything civil goes in Cafe) > > Sounds both interesting and relevant, but I don't quite get it. Can you > provide a simple, concrete, narrative example--with pictures (ASCII > OK)--if possible. Nah, I'm only good at walls of text. And at answering directed questions - start asking about what exactly you didn't understand. Guessing what you might have not understood is going to be a waste of everybody's time. (Besides, if you need to tell where exactly you didn't understand may help your understanding. Well, the keyword being "may"; I know it worked for me on various occasions.) > There's pivot tables, so the difference between row and column isn't as > clear-cut as the above assumes. > > Don't worry about pivot tables. Simple cases first. You have to design for the maximum complication. Otherwise, stuff will not fit in well, and you'll be stuck with either a half-assed solution, nothing at all, or a full rewrite. Trust me. I've been coding and designing software for decades. > There are a few more things to consider. It's firmly in the GUI > ergonomics area. > For this kind of stuff, you don't care whether the programming language > evaluation semantics matches the problem domain (spreadsheet functional > semantics is easy to do in any language, it was done in Assembler with > Lotus 1-2-3), you care whether it is easy to prototype GUI approaches, > which means GUI libraries that make it easy to create new widgets. > > Any suggestions for a GUI library--that kind of implies C++ or Java. > Ideally your GUI would be cross platform. I know only the Java GUI landscape well enough to say anything. In that area, dialog boxes, menus and such will be easy enough with any lib, but you'll be mostly on your own for the grid. Also if you aim for unlimited size you'll get into a lot of hairy memory management issues - a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and you end with a memory footprint of a gigabyte. Evaluating a formula for each cell is going to get you a slideshow-like performance. So... managing which cells are actually needed and which aren't is going to be a major point of the software. Did I mention that coding a spreadsheet is a huge project? ;-) > > Programmers have to learn multiple languages, and most wind up liking > > it. They also have favorite languages. LibreOffice Calc has about > four > > bolt-on languages. As I recall, none of them are a functional > > programming language. Maybe a few programmers should get together and > > add one as a sub-project. > > The problem is that any additional language needs to be installed. So > either the new language needs to be integrated in the LO project, or it > is not and anybody who passes on a spreadsheet in the new language needs > to tell the recipients how to install the plugin for the language. > > Maybe that's the reason why only the four languages exist. > > Doubt it. > > A given plugin's installation could be automated and check for dependencies. Heh. Famous last words. The Java folks got a 90% solution working - just for managing dependencies, mind you; for some people it doesn't work at all because they don't know how to get past the corporate firewall. Besides, most corporate firewalls do a man-in-the-middle certificate nowadays and will inspect and reject some packets and not others, so any update mechanism must be able to deal with wilfully unreliable internet connections. So that's another area that's going to bind a lot of developer resources.

2 2

Arrows and streaming/piping
by PY 23 Nov '17

23 Nov '17

Hello, Cafe! There is a statement that Arrows can be used as streaming approach. Arrows are very new for me, so my question may looks stupid, but would somebody show me clean and simple example how it will look? Lets suppose we have function `getLines` which returns `IO [String]`, a lot of lines :) And I want to process them as I do it with streaming library (or pipes) - with constant space. If it's true, then I can use Arrows instead of pipes, right? === Best regards, Paul

2 1

Speculation, OT: Program a Spreadsheet
by trent shipley 22 Nov '17

22 Nov '17

I have a vision for a spreadsheet that is programmable as a spreadsheet itself. (Excel, for example, is programmable in VBA, but VBA requires switching modes to the VBA environment and using a non-spreadsheet idiom. Excel is not self-programmable as a spreadsheet.) First there one function in a cell or array can reference other cells and arrays, including those that contain functions themselves. Second, IF(boolean,then,else) functions provide for selection. Third, the Function local scope property for a sheet in a workbook, the PARAMETER() function, and the RETURN() function allow the spreadsheet programmer to write new functions, including recursive functions. * Is a spreadsheet you can program from the spreadsheet a reasonable goal? * Has it been done? (I don't have the academic CS chops to know what keywords to use, and how search CS publications in English.) I have written a 30 page essay on Scriptsheets, but the essence boils down to the above. (If you, for some inexplicable reason, actually want the draft of the essay I'd be more than happy to share it with the understanding that you would provide feedback). I call the proposal Scriptsheets. So the plan is to take something like GNUmeric or LibreOffice Calc and graft on a primitive function sheet interpreter. It would be natural to use C++, 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. * Would using a functional language as a basic language of the project save effort and intellectual load? 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. 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. * 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? 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, then sweet talk real developers to help out. trent1967.48(a)outlook.com (junk email address) See also the spreadsheet at http://orgmode.org/ it's cool.

5 13

[ANNOUNCE] GHC 8.2.2 released
by Ben Gamari 22 Nov '17

22 Nov '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.2 =============================================== The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. Notable bug-fixes include * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html How to get it ~~~~~~~~~~~~~ This release can be downloaded from https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

1 1

Re: [Haskell-cafe] Speculation, OT: Program a Spreadsheet
by Olaf Klinke 22 Nov '17

22 Nov '17

> Olaf, have you looked at Jupyter <http://jupyter.org/> at all? This now > has a backend for Haskell and supports many of the things you mention. Neil, I must have forgotten about Jupyter. That is exactly what I was takling about! I have become quite a fan of literate programming. Now I admit that Jupyter looks quite different from spreadsheets, so wont' fit the bill of what Trent was originally asking for. As I tried to express earlier, the strength of spreadseets in my eyes is the somewhat explicit data flow. (You need to highlight a cell to see its formula.) Hence I envision a Jupyter with data flow made explicit. You start by defining your input data. Single values, lists, matrices, whatever. You can define some functions, which will act as edges of your data flow graph. Then you combine these functions and apply to the data. For each (f.g)(x), all of x, g(x) and (f.g)(x) become nodes of a graph with (f.g)(x) hyperlinked to g(x) which in turn gets hyperlinked to x. Thus you can explore backwards from the result and see how the answer was derived. Of course a nicely written Jupyter notebook needs no hyperlinks. One can leave enough explanation in the markup cells. But not everyone is trained to read and understand such mixture of text and code. There might be an applicative functor (a variant of 'State SomeGraph') for what I'm after. Once I've defined it, I'll post it here. Olaf

1 0

Re: [Haskell-cafe] [ANN]: fin & vec
by Oleg Grenrus 22 Nov '17

22 Nov '17

Thanks for more references! I was quite sure I didn't found all packages around fin/nat/vec (and I feel a little bad for making "standards" problem worse :) - https://hackage.haskell.org/package/finite-typelits uses GHC.TypeLits.Nat (fair thing to do). - https://hackage.haskell.org/package/vector-sized builds on top of that and looks like a nice package too! I dislike GHC.TypeLits.Nat for doing induction over, yet for many things they (+ [1,2] or [3]) are great. I have to write that down in the description of the package(s). Hopefully the approaches: compiler built-in magic and DataKinds definition would be unified in the future. Cheers, Oleg. - [1] https://hackage.haskell.org/package/ghc-typelits-natnormalise - [2] https://hackage.haskell.org/package/ghc-typelits-extra - [3] http://hackage.haskell.org/package/constraints-0.9.1/docs/Data-Constraint-N… On 21.11.2017 15:20, Alexey Vagarenko wrote: > I wrote a package not long ago which also uses static inlining for > similar things: https://hackage.haskell.org/package/static-tensor > > There is also https://hackage.haskell.org/package/vector-sized which > is a wrapper around 'vector' library. > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> > > > > 2017-11-21 17:27 GMT+05:00 Oleg Grenrus <oleg.grenrus(a)iki.fi > <mailto:oleg.grenrus@iki.fi>>: > > I'm happy to announce two packages: > > - http://hackage.haskell.org/package/fin > <http://hackage.haskell.org/package/fin> > - http://hackage.haskell.org/package/vec > <http://hackage.haskell.org/package/vec> > > In short they provide following types: > > data Nat where Z | S Nat > > data Fin (n :: Nat) where > Z :: Fin ('S n) > S :: Fin n -> Fin ('S n) > > data Vec (n :: Nat) a where > VNil :: Vec 'Z a > (:::) :: a -> Vec n a -> Vec ('S n) a > > Main motivation for creating these packages is that I didn't found > anything > similar on Hackage. Before comparison with the alternatives, let me > mention few > highlights: > > - `fin` and `vec` support GHC-7.8.4 .. GHC-8.2.1; and I plan to > keep support > window as wide as possible. > > - `fin` package provides `Data.Fin.Enum` module to work > generically with > enumerations. It's (subjectively) more ergonomic than working with > `All ((:~:) a) xs => NS I xs` from `generics-sop` [1] > > - `fin` package defines `InlineInduction` class, > letting us trick GHC to unfold recursion. One general example is > > unfoldedFix :: forall n a proxy. InlineInduction n > => proxy n -> (a -> a) -> a > unfoldedFix _ = getFix (inlineInduction1 start step :: Fix > n a) > where > start :: Fix 'Z a > start = Fix fix > > step :: Fix m a -> Fix ('S m) a > step (Fix go) = Fix $ \f -> f (go f) > > newtype Fix (n :: Nat) a = Fix { getFix :: (a -> a) -> a } > > So, for statically known @n@, GHC's inliner will "simplify": > > unfoldedFix (Proxy :: Proxy Nat3) f = f (f (f (fix f))) > > - `fin` has very light dependency footprint: > `base`, `deepseq`, `hashable` (and transitively `text`) on GHC>=8.0 > > - `vec` has a little more dependencies, essentially `lens`. See > dependency > diagram in the readme. [2] > > - `vec` comes in three flavours: > > * __naive__: with explicit recursion. It's simple, > constraint-less, > yet slow. > > * __pull__: using `Fin n -> a` representation, which fuses well, > but makes some programs hard to write. And > > * __inline__: which uses `InlineInduction`, unrolling > recursion if the size of 'Vec' is known statically. > > Differences with other packages > ------------------------------- > > ### fin > > - [type-natural](http://hackage.haskell.org/package/type-natural > <http://hackage.haskell.org/package/type-natural>) depends > on @singletons@ package. `fin` will try to stay light on the > dependencies, > and support as many GHC versions as practical. > > - [peano](http://hackage.haskell.org/package/peano > <http://hackage.haskell.org/package/peano>) is very incomplete > > - [nat](http://hackage.haskell.org/package/nat > <http://hackage.haskell.org/package/nat>) as well. > > - > [PeanoWitnesses](https://hackage.haskell.org/package/PeanoWitnesses > <https://hackage.haskell.org/package/PeanoWitnesses>) > doesn't use @DataKinds@. > > - > [type-combinators](http://hackage.haskell.org/package/type-combinators > <http://hackage.haskell.org/package/type-combinators>) > is a big package. > > ### vec > > - [linear](http://hackage.haskell.org/package/linear > <http://hackage.haskell.org/package/linear>) has 'V' type, > which uses 'Vector' from @vector@ package as backing store. > `Vec` is a real GADT, but tries to provide as many useful > instances (upto > @lens@). > > - [sized-vector](http://hackage.haskell.org/package/sized-vector > <http://hackage.haskell.org/package/sized-vector>) depends > on 'singletons' package. `vec` isn't light on dependencies either, > but try to provide wide GHC support. > > - [sized](https://hackage.haskell.org/package/sized > <https://hackage.haskell.org/package/sized>) also depends > on a 'singletons' package. The 'Sized f n a' type is > generalisation of > linears 'V' for any 'ListLike'. > > - > [clash-prelude](https://hackage.haskell.org/package/clash-prelude > <https://hackage.haskell.org/package/clash-prelude>) > is a kitchen sink package, which has 'CLaSH.Sized.Vector' module. > Also depends on 'singletons'. > > Disclaimer > ---------- > > These are the "first released versions", i.e. `fin-0` and `vec-0`. > Don't be fooled by 0, we use them in production. > > We don't have (yet?) a use-case where proper full inlining would > matter, it > seems to work with simple examples. The `vec` package includes > simple dot > product benchmark, it gives sensible results: > > - *list* version sets the baseline, built-in fusion seems to kick in. > - using `vector` is 3x slower (?) > - naive `Vec` is even slower, not surprisingly > - `Data.Vec.Pull` approach is slower, *except* > - that without conversions it's up to speed with `vector` > - `InlineInduction` is *fastest*. > > Acknowledgements > ---------------- > > - *APLicative Programming with Naperian Functors* [3] has the very > similar > `Nat`, `Fin` and `Vec` (sections 2--4). I spotted few missing > functions in > `vec` by re-reading the paper (`vgroup` is `chunks` and `viota` is > `universe`). > I don't claim that my library is novel in any kind :) > - I learned *Pull array* idea from Josef Svenningsson talk at SmallFP > 2017 [4]. > See the video [5] if interested. > - Herbert Valerio Riedel for the idea to split `fin` out of `vec`. > It turned > out to be very light package. > - Andres Löh for discussions about `generics-sop` [1], and about > the static > inlining idea. > - Joachim Breitner for creating `inspection-testing` [6], which > really helps > validating optimisations working. > > Cheers, > Oleg > > > - [1] http://hackage.haskell.org/package/generics-sop > <http://hackage.haskell.org/package/generics-sop> > - [2] https://github.com/phadej/vec#dependencies > <https://github.com/phadej/vec#dependencies> > - [3] > https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf > <https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf> > - [4] http://clojutre.org/2017/ > - [5] > https://www.youtube.com/watch?v=5PZh0BcjIbY&list=PLetHPRQvX4a9uUK2JUZrgjtC_… > <https://www.youtube.com/watch?v=5PZh0BcjIbY&list=PLetHPRQvX4a9uUK2JUZrgjtC_…> > - [6] http://hackage.haskell.org/package/inspection-testing > <http://hackage.haskell.org/package/inspection-testing> > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> > Only members subscribed via the mailman list are allowed to post. > >

2 1

[ANN]: fin & vec
by Oleg Grenrus 21 Nov '17

21 Nov '17

I'm happy to announce two packages: - http://hackage.haskell.org/package/fin - http://hackage.haskell.org/package/vec In short they provide following types: data Nat where Z | S Nat data Fin (n :: Nat) where Z :: Fin ('S n) S :: Fin n -> Fin ('S n) data Vec (n :: Nat) a where VNil :: Vec 'Z a (:::) :: a -> Vec n a -> Vec ('S n) a Main motivation for creating these packages is that I didn't found anything similar on Hackage. Before comparison with the alternatives, let me mention few highlights: - `fin` and `vec` support GHC-7.8.4 .. GHC-8.2.1; and I plan to keep support window as wide as possible. - `fin` package provides `Data.Fin.Enum` module to work generically with enumerations. It's (subjectively) more ergonomic than working with `All ((:~:) a) xs => NS I xs` from `generics-sop` [1] - `fin` package defines `InlineInduction` class, letting us trick GHC to unfold recursion. One general example is unfoldedFix :: forall n a proxy. InlineInduction n => proxy n -> (a -> a) -> a unfoldedFix _ = getFix (inlineInduction1 start step :: Fix n a) where start :: Fix 'Z a start = Fix fix step :: Fix m a -> Fix ('S m) a step (Fix go) = Fix $ \f -> f (go f) newtype Fix (n :: Nat) a = Fix { getFix :: (a -> a) -> a } So, for statically known @n@, GHC's inliner will "simplify": unfoldedFix (Proxy :: Proxy Nat3) f = f (f (f (fix f))) - `fin` has very light dependency footprint: `base`, `deepseq`, `hashable` (and transitively `text`) on GHC>=8.0 - `vec` has a little more dependencies, essentially `lens`. See dependency diagram in the readme. [2] - `vec` comes in three flavours: * __naive__: with explicit recursion. It's simple, constraint-less, yet slow. * __pull__: using `Fin n -> a` representation, which fuses well, but makes some programs hard to write. And * __inline__: which uses `InlineInduction`, unrolling recursion if the size of 'Vec' is known statically. Differences with other packages ------------------------------- ### fin - [type-natural](http://hackage.haskell.org/package/type-natural) depends on @singletons@ package. `fin` will try to stay light on the dependencies, and support as many GHC versions as practical. - [peano](http://hackage.haskell.org/package/peano) is very incomplete - [nat](http://hackage.haskell.org/package/nat) as well. - [PeanoWitnesses](https://hackage.haskell.org/package/PeanoWitnesses) doesn't use @DataKinds@. - [type-combinators](http://hackage.haskell.org/package/type-combinators) is a big package. ### vec - [linear](http://hackage.haskell.org/package/linear) has 'V' type, which uses 'Vector' from @vector@ package as backing store. `Vec` is a real GADT, but tries to provide as many useful instances (upto @lens@). - [sized-vector](http://hackage.haskell.org/package/sized-vector) depends on 'singletons' package. `vec` isn't light on dependencies either, but try to provide wide GHC support. - [sized](https://hackage.haskell.org/package/sized) also depends on a 'singletons' package. The 'Sized f n a' type is generalisation of linears 'V' for any 'ListLike'. - [clash-prelude](https://hackage.haskell.org/package/clash-prelude) is a kitchen sink package, which has 'CLaSH.Sized.Vector' module. Also depends on 'singletons'. Disclaimer ---------- These are the "first released versions", i.e. `fin-0` and `vec-0`. Don't be fooled by 0, we use them in production. We don't have (yet?) a use-case where proper full inlining would matter, it seems to work with simple examples. The `vec` package includes simple dot product benchmark, it gives sensible results: - *list* version sets the baseline, built-in fusion seems to kick in. - using `vector` is 3x slower (?) - naive `Vec` is even slower, not surprisingly - `Data.Vec.Pull` approach is slower, *except* - that without conversions it's up to speed with `vector` - `InlineInduction` is *fastest*. Acknowledgements ---------------- - *APLicative Programming with Naperian Functors* [3] has the very similar `Nat`, `Fin` and `Vec` (sections 2--4). I spotted few missing functions in `vec` by re-reading the paper (`vgroup` is `chunks` and `viota` is `universe`). I don't claim that my library is novel in any kind :) - I learned *Pull array* idea from Josef Svenningsson talk at SmallFP 2017 [4]. See the video [5] if interested. - Herbert Valerio Riedel for the idea to split `fin` out of `vec`. It turned out to be very light package. - Andres Löh for discussions about `generics-sop` [1], and about the static inlining idea. - Joachim Breitner for creating `inspection-testing` [6], which really helps validating optimisations working. Cheers, Oleg - [1] http://hackage.haskell.org/package/generics-sop - [2] https://github.com/phadej/vec#dependencies - [3] https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf - [4] http://clojutre.org/2017/ - [5] https://www.youtube.com/watch?v=5PZh0BcjIbY&list=PLetHPRQvX4a9uUK2JUZrgjtC_… - [6] http://hackage.haskell.org/package/inspection-testing

2 1

problem with compiler error message
by Dmitry Olshansky 21 Nov '17

21 Nov '17

Hello cafe! It seems that this behavior is wrong: > class Foo a where { type Bar a; baz :: a -> Bar a } > baz zzz -- zzz is not in scope <interactive>:17:1: error: • Couldn't match expected type ‘Bar a’ with actual type ‘Bar a0’ NB: ‘Bar’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall a. Bar a As opposite - correct behavior: > :t negate negate :: Num a => a -> a > negate zzz <interactive>:19:8: error: Variable not in scope: zzz Best regards, Dmitry

2 2

Questions about Numeric.AD / Automatic differentiation
by Sean Matthews 21 Nov '17

21 Nov '17

I'm having some problems with Numeric.AD (translation, things are not working for reason that I don't understand). Note I don't have much experience with this package, so these are newbie questions, thus appropriate answers may involve pointing me to a document somewhere out there on the net. Anyway, here is my problem: I have a function (call it f x theta) which I have defined purely in terms of basic arithmetic functions (+/-/(/)/*/**) glued together using standard applicative functor operations has type f :: m1 (m2 Double) -> m3 Double -> Double f x theta = ... m1 m2 and m3 are all Traversable. f is defined purely in terms of basic arithmetic operations, (+/-/(/)/*/**) glued together using standard applicative functor operations, and m1 m2 and m3 are all pretty trivial record types (no recursion, even). I would like to write df x theta = grad (f x) theta But it refuses to type, even though (admittedly quite a lot) simpler versions do. So what am I missing? Does AD not go through Applicative? That seems unlikely to me. Any advice / suggestions, etc. gratefully received. Sean Matthews -- Sean Matthews seanmatthews1(a)gmail.com / +49 1515 800 1901

2 2