Omit module declarations in OCaml snippets

[hmemcpy]

Perhaps I should have asked this earlier, but better late than never :)
Dear @ArulselvanMadhavan @mseri, do you think we can omit the module declarations? Some things feel a bit noisy to me (but I don't know OCaml, so... I don't know what I'm talking about :))

What if we moved some of the common definitions to the first chapter (notes from the editor), and keeping the snippets smaller?

WDYT?

[mseri]

This is the way OCaml allows to abstract over common signatures, there are no typeclasses.
One could use first class modules instead of module functors but it would not work for all cases.

For examples like compose, one could just write

let compose g f : ‘a -> ‘c = fun x -> g (f x)

But for other examples is unavoidable.

[mseri]

I’ll have a read as soon as I can, likely in a couple of weeks, to check all that could be simplified. But in most cases I think we have to leave with the verbosity

[yawaramin]

Definitely looks too verbose to me :-) I've just started reading the OCaml code examples and they declare a lot more than the Haskell versions do. E.g.:

-- Haskell
f :: A -> B

(* OCaml *)
module type Polymorphic_Function_F = sig
  type a
  type b

  val f : a -> b
end

The equivalent OCaml should be:

val f : a -> b

As for the composition example, it would be:

let (<<) g f x = g (f x)
g << f

Note that I reversed the direction of the angle brackets. OCaml doesn't ship with these operators, but in F#, the direction of the brackets indicates the 'data flow', so a flow of 'g after f' would be g << f.

[EDIT: my key point with the OCaml code examples is that they declare too much. Way more than the Haskell equivalent code declares.]

[hmemcpy]

Perhaps we could add a Prelude chapter, defining all the helper operators and modules?

[yawaramin]

Maybe. It would essentially turn the Prelude chapter into an OCaml re-implementation of certain parts of the Haskell Prelude :-)

[XVilka]

Interesting idea about Prelude, it is indeed more practical approach.

…

On Sat, Feb 15, 2020, 14:52 Yawar Amin ***@***.***> wrote: Maybe. It would essentially turn the Prelude chapter into an OCaml re-implementation of certain parts of the Haskell Prelude :-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#237?email_source=notifications&email_token=AABRT7PV5ZX4XVLSMDCXNHLRC6GJ5A5CNFSM4KVPO2CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3DOGI#issuecomment-586561305>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRT7PFJU6DKQEUJVS6VRLRC6GJ5ANCNFSM4KVPO2CA> .

[mseri]

The Prelude is a good idea, indeed. I think it would be worth even if it will not help once you deal with the chapters on Monoid/Monad/Comonad/Fix/... where you really need the functorial implementation (or a first class module) with the signature available somewhere close by, as it is part of the chapter content itself

[mseri]

Concerning the composition, I think you may also want to have a look here: #201 (comment)

[mseri]

There is also one more question here.

The fist chapter contains lots of module types to make te code fully compilable ocaml, where type signature go separate from the implementation on interface files or module signatures.

We could decide to make a compromise to the sake of readability and allow to just show the signature even though it is not compilable ocaml and not the correct thing to do. We would need to explain this in the prelude and, again, this change would not “fix“ many other snippets

[yawaramin]

@mseri it's not just the first chapter. My question is–why does the OCaml code need to be fully compilable? The Haskell code is not, as I pointed out above. I assumed that was originally done for pedagogical reasons–i.e. the goal was to sketch out how the concepts would look in code form, not to provide full working implementations. Why doesn't the OCaml version follow that pedagogical principle?

We would need to explain this in the prelude

The explanation would need to be provided for the Haskell code too then, I guess.

[yawaramin]

Hey folks, I am on chapter 4 now, I am noticing also that the Haskell and OCaml code samples are 'out of sync'. I've cloned the repo and made some changes locally from chapters 1 to 4 to what I think is a closer match of the Haskell code. Would a PR be welcome?

[hmemcpy]

Always! ❤️ I think there was one snippet in Haskell I unified from 2 separate ones, and it screwed up the order. If you can find it, it would be awesome!

…

On Thu, Feb 20, 2020, 07:00 Yawar Amin ***@***.***> wrote: Hey folks, I am on chapter 4 now, I am noticing also that the Haskell and OCaml code samples are 'out of sync'. I've cloned the repo and made some changes locally from chapters 1 to 4 to what I think is a closer match of the Haskell code. Would a PR be welcome? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#237?email_source=notifications&email_token=AAESY5V4IX6S6UTMS7WZ46LRDYFABA5CNFSM4KVPO2CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMKXXGY#issuecomment-588610459>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESY5TKK5RPQKUCFR3DJ7DRDYFABANCNFSM4KVPO2CA> .

[yawaramin]

Thanks, sent #242 . I believe this will re-sync the code samples. Since I'm reading through the book as well, syncing them up as I go.

[ArulselvanMadhavan]

@mseri it's not just the first chapter. My question is–why does the OCaml code need to be fully compilable? The Haskell code is not, as I pointed out above. I assumed that was originally done for pedagogical reasons–i.e. the goal was to sketch out how the concepts would look in code form, not to provide full working implementations. Why doesn't the OCaml version follow that pedagogical principle?

We would need to explain this in the prelude

The explanation would need to be provided for the Haskell code too then, I guess.

@yawaramin I haven't been following the discussion completely but I can answer the question on writing compilable OCaml code. I chose to do it that way because it was easier for me to make changes and still be confident that I haven't introduced any errors, as I discovered OCaml syntax subtleties along the way. Part of my reason for translating the book was to force myself to learn OCaml

[XVilka]

In my opinion, it is better to go the opposite way - make Haskell/Scala code compilable too, instead of reducing the quality level of OCaml flavor. It will be beneficial for these languages as well, and easier to spot the mistakes.

[yawaramin]

Hi @ArulselvanMadhavan thank you for your efforts. It's a massive achievement for sure. The reason I've been recommending that the code stay close to the Haskell samples, is for teaching reasons. When people are learning, we shouldn't force them to immediately deal with the software engineering concerns of compilation–and the more complex code that comes with it. We want them to get the basic ideas first. Once they have those, they can figure out how to turn the samples into actual production code.

This makes it more difficult for the authors and translators but I think it's important to make it easier for learners, than for ourselves.

Hi @XVilka , I had assumed that the Haskell samples were designed by Dr Milewski to get his ideas across as simply as possible, and their point was not really to be production-level code.

[hmemcpy]

I don't have good input on this, but one thing to consider is the book length. The maximum number of pages for a print book is 480 (on Blurb, at least), and each page increases the overall cost of printing.

[XVilka]

Compilable code will make updating the book more straightforward, in case of OCaml or Haskell language syntax improvements. And judging by the last few years, both languages are quite active at changing/improving the syntax. Anyway, just my two cents.

[hmemcpy]

I'm sure there'll be a separate Scala 3 version of the book at some point, once all syntax has been finalized. My goal was always keeping the original text and snippets intact, changing it as little as possible. That said, this is a "live" document, it can be updated with the new syntax as languages evolve.