azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
tom1212 has joined #ocaml
<tom1212>
Hello! is it possible to give a name to a first class module in signature, like so? https://tpaste.us/d1dj (doesn't typecheck with "unbound module F")
<discocaml>
<froyo> nope, sounds like you need a functor here
<tom1212>
I'd like to generate nice doc for those functions too, with https://github.com/realworldocaml/mdx, that I would partially scrap from the library official manual
Anarchos has joined #ocaml
<tom1212>
yeah! I'd like to demonstrate the power of ocaml with algorithms working on abstract structures, so that you can instantiate with various objects
<tom1212>
such as Pollard's p-1 factoring method that works on groups (Z/pZ, elliptic curve over finite fields)
<tom1212>
that would be cool :)
<companion_cube>
my naive advice on such a thing would be: keep the bindings as simple and direct as possible
<companion_cube>
and make a nicer API on top if you have the motivation — and that's where you can put abstractions and the likes
<tom1212>
great advice!
<tom1212>
sounds like you can just translate C programs to ocaml ones with the generated ctypes functions from little experiments
<companion_cube>
if you already have C code, then yes indeed! You'll just need to know how names map (but if you generated the bindings you'll know)
John_Ivan has quit [Quit: Disrupting the dragon's slumber one time too often shall eventually bestow upon all an empirical and indiscriminate conflagration that will last for all goddamn eternity.]
<tom1212>
exactly
<tom1212>
been thinking about different patterns for organizing the code
<companion_cube>
for some example of that, some of Bunzli's bindings are classic I think
<companion_cube>
tsdl, tgls, etc.
<tom1212>
one relies on functors, others on modules with parametric type
<companion_cube>
more opinionated advice: if you can avoid functors, avoid them
<companion_cube>
staying at the expression level is a lot easier
<companion_cube>
(that's my opinion)
<Anarchos>
companion_cube and objects are very rarely used.
<companion_cube>
true, true
<companion_cube>
the biggest drawback of objects is that half the community refuses to use them altogether
<companion_cube>
but you can use records of functions, or first-class modules, instead
<tom1212>
yeah avoiding objects because the late binding is not great for performance
<tom1212>
from a UX perspective you have to define all your modules beforehand with the functor approach, whether with the parametric type approach that's not needed (although I still enforce some invariants on the parametric type such as a special structure)
<companion_cube>
functors are a pain to use
<companion_cube>
especially if you have many of them
<tom1212>
their typechecking is unsound no?
<companion_cube>
hm, no
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<tom1212>
yeah functors are more for "programming in the large", not good replacement for OOP-like programming
<tom1212>
records of functions may be better suited
<companion_cube>
indeed
<companion_cube>
(at runtime, functors are also records btw)
<tom1212>
cool :)
<companion_cube>
(well. Functors are functions from records to records.)
<tom1212>
but still I'm not found of the parametric types 'a t because the type variable 'a has a restricted domain (in the API you build 'a polynomials where 'a = Ring.t for instance)
<tom1212>
fond*
<companion_cube>
so can't you build `Ring.t polynomials`?
<companion_cube>
so `create_poly` makes a polynomials whose coefficients are polynomials themselves?
<tom1212>
yep, you have the arity in the type this way
<tom1212>
rings of multivariate polynomials
<tom1212>
you'd loose this info if you build with `create (module Poly) [...]`
<tom1212>
I mean, in the type, the underlying library would still figure out that it's computing with a multivariate poly
ursa-major has joined #ocaml
<tom1212>
one thing that is very easy to do with loosely typed library is that you can add/multiply compatible types (rationals with integers for instance)
<tom1212>
with ocaml you'd have to explicitly embed an integer in a rational
<companion_cube>
right
<discocaml>
<._null._> one thing that is very easy to do with loosely typed library is that you can add/multiply incompatible types (rationals with strings for instance)
<tom1212>
that's a bit annoying, but hey that's the price to pay to use well-typed libs!
<tom1212>
yep
<tom1212>
still a language with overloaded operators could achieve this