<MercurialAlchemi>
if you mean the slides, I didn't write that
<MercurialAlchemi>
But I do agree with the sentiment :)
<MercurialAlchemi>
(even if it's a bit of a footgun)
<ousado>
just wanted to ask whether smondet is another nick of zours
<ousado>
*yours
<flux>
I actually thought that kind of witness types weren't possible in OCaml
<MercurialAlchemi>
ousado: no :)
<MercurialAlchemi>
(I wish people gave me money to write ocaml)
<companion_cube>
ehe
<flux>
let's pool money! we could raise $1 or more for mercurialalchemi to write something useful in ocaml :-)
<MercurialAlchemi>
lol
<MercurialAlchemi>
the question hangs on what you define by "useful"
_2can has quit [Ping timeout: 265 seconds]
<ousado>
wow, that's some exciting domain
<ousado>
and a very cool presentation
_2can has joined #ocaml
<MercurialAlchemi>
as somebody who's written a couple of data processing pipelines, I like what I see in the presentation
<MercurialAlchemi>
ousado: the underlying tools they have to work with seem perfectly awful, though
<ousado>
the ones mentioned in the beginning of the presentation?
<ousado>
I thought they're replacing those
<ousado>
once again ocaml the choice for a killer app
<MercurialAlchemi>
yeah
<companion_cube>
at least they're wrapping awful tools with a clean PAI
<companion_cube>
API
<MercurialAlchemi>
having type-inference means you can make an edsl without users gouging out their eyeballs
<MercurialAlchemi>
or resorting to dynamic languages
<flux>
mostly B I guess
<flux>
because A would certainly be no-go :)
<ousado>
the "why not Haskell section" is worded quite strongly
<MercurialAlchemi>
the API doc could use some love
<MercurialAlchemi>
"Many functions may raise exceptions"
<ousado>
s/section"/" section/
<MercurialAlchemi>
then no exception-raising is documented
<MercurialAlchemi>
russian roulette programing
<companion_cube>
meh
<companion_cube>
@raise is by far the most used tag in my doc :D
<companion_cube>
(then it's @since)
<MercurialAlchemi>
:)
<MercurialAlchemi>
I think the stdlib doesn't use @raise much, or at all, but at least it's in the description
mrvn_ is now known as mrvn
AlexRussia has quit [Ping timeout: 245 seconds]
Algebr has joined #ocaml
skinkitten has joined #ocaml
ygrek has quit [Ping timeout: 265 seconds]
mort___ has quit [Quit: Leaving.]
<Algebr>
for the .ocamlinit, what's the difference between use, require and just writing what I guess is the module name?
<ggole>
#use essentially includes that file as source, #require loads a package
<Algebr>
and just leaving #thread or #camlp4o ?
<ggole>
Er, what do you mean by 'leaving'?
<Algebr>
I've seen .ocamlinits that look like:
mort___ has joined #ocaml
<Algebr>
# use foo
<Algebr>
#thread
<Algebr>
#camlp4o
<ggole>
Those turn the thread support and camlp4 on
<Algebr>
So a #require is basically like an open?
<ggole>
No, it's more like #load but with dependency chasing package support.
<flux>
open is about name spaces
<flux>
#require and #load are about code in memory
<flux>
#use is about textually including source code
<ggole>
It'd be nice if #foo without an argument gave a bit of help text.
<MasseR>
Also, because #use is like including text as is into the toplevel, there is no default module. If you want to test your code like a library client, I believe you need to compile it as a cma and then #load it
<ggole>
There's #mod_use now, which is sometimes useful for that
<flux>
it can even be more useful, because multiple #loads can cause version mismatch errors
Thooms has joined #ocaml
<flux>
I guess the interface is only loaded once or something.
<ggole>
I tend to build toplevels with ocamlbuild when it gets to that stage
<ggole>
Too annoying to deal with stale code otherwise
<MasseR>
ggole: any examples of that?
<ggole>
Of what, #mod_use? You say #mod_use "foo.ml" and get a module Foo with all the contents of foo.ml
<MasseR>
"I tend to build toplevels"
<ggole>
Oh
<ggole>
Um, nothing I could easily point at
yminsky has joined #ocaml
<ggole>
OCamlbuild has support for compiling + shoving a bunch of modules into a toplevel, which I use
<ggole>
Then I have an emacs command which does that and restarts the current toplevel, if any
<companion_cube>
ggole: I tend to compile my code into a library and use #directory and #load to use it
<companion_cube>
I suppose it's an alternative
<MasseR>
companion_cube: that's what I've done so far
<companion_cube>
it works well
<companion_cube>
basically, put the loading code into .ocamlinit, along with #install_printer directives
<ggole>
I've also being doing a half-assed livecoding thing recently, where I have test code that is automatically run by .ocamlinit
<ggole>
Then you can change code, hit the compile button, and the toplevel updates with the effect of the change
<ggole>
It's a bit annoying to set up
<MasseR>
companion_cube: is #install_printer for having printers for custom types?
<MasseR>
Inside modules
<ggole>
Yeah
<MasseR>
Neat
<companion_cube>
MasseR: assuming you wrote val Foo.print : Format.formatter -> Foo.t -> unit
<companion_cube>
#install_printer Foo.print will use this function to print values of type Foo.t
<ggole>
It has some annoying limitations, unfortunately
<companion_cube>
it plays well with ppx_deriving.show
<ggole>
(Although I think some of those are being addressed in the next patch.)
<companion_cube>
all this should disappear the day we have implicits :/
<MasseR>
Implicits..? hrr
<MasseR>
Do not want
Algebr has quit [Ping timeout: 264 seconds]
<companion_cube>
yes do :p
<companion_cube>
well, it would be awesome to simulate typeclasses
<companion_cube>
not for ugly stuff such as implicitly provide database handles and so on
<MasseR>
They're bad enough in scala
<companion_cube>
I don't think they would be as bad in OCaml
kapil__ has quit [Quit: Connection closed for inactivity]
tane has joined #ocaml
<MasseR>
companion_cube: how come? (I haven't done anything substantial with ocaml yet)
<companion_cube>
first, it would be implicit *modules*
<companion_cube>
then, it would be a bit more cumbersome to use (more verbose type signatures)
<flux>
I think not simply compiling will do the trick, if there has indeed been some changes in the marshalling format
<flux>
though I think OCaml does try to keep the format intact. maybe this is an OCaml bug?
enitiz has joined #ocaml
<flux>
the unison project would probably be well served by switching to a more explicit marshalling format instead of relying on Marshal, which is very memory-representation-based approach instead of type-based..
<flux>
..though actually making the first version that way so that it's compatible with old unisons would be a challenge of its own.
<moviuro>
flux: unison does not try to be cross-version compatible
<flux>
well, it could be :)
<flux>
at least it could not depend on ocaml version, should the marshalling format change
<flux>
as far as I know, it's not actually a documented format.
<flux>
..other than by its implementation, that could change
<flux>
even if the goal is not to change it :)
<moviuro>
flux: what is in your opinion a solution? have unison implement its own marshaling ?
<flux>
yes.
<moviuro>
(I am in a foggy environment; I know almost nothing of ocaml except that it makes unison work)
stygianguest has joined #ocaml
<moviuro>
flux: won't that be dangerous? isn't there any stable marshaling in ocaml?
<flux>
Marshal is the only marshalling provided by OCaml, and what I understand of it is that it basically walks the memory representation and serializes them on the way, while handling references and loops
<companion_cube>
no, Marshal is unsafe and can change with new versions
<companion_cube>
what flux said.
<flux>
so it's easy to take any value and just serialize it
<flux>
but if the memory representation of any value changes, so does the marshalled value
Thooms has quit [Quit: WeeChat 1.0.1]
<flux>
it also leads to that you can basically unmarshal any garbage and crash the program
<moviuro>
hmmm... given that unison is in a non-development state, it'll be difficult to implement, IMO
<flux>
(well there are headers involved so not just 'any' garbage)
<MercurialAlchemi>
in general, if you're going to serialize arbitrary things, making sure that at least you have a version number in your format is a good idea
<MercurialAlchemi>
I gather Marshal doesn't do that?
<flux>
probably not
<flux>
it would mean versioning all types
<moviuro>
MercurialAlchemi: if it does, it isn't very verbose about it
<Drup>
MercurialAlchemi: it doesn't
<flux>
you can just type type t = { a: int } and then serialize such a value
<flux>
how would it know if a next version has changed? marshal knows nothing about types.
<Drup>
MercurialAlchemi: and if something screw, it leads to segfaults
<Drup>
screw up*
<MercurialAlchemi>
flux: it could know the ocaml compiler version
<flux>
one approach for the solution would be for unison to report not only its own version but also the ocaml version
<rks`>
doesn't binprot handle this sort of stuff?
<flux>
mercurialalchemi, well ok, that would work for programs that only serialize ocaml data types, but how about if you serialize something from Batteries or something else?
<flux>
Marshal is a 'no effort required'-way for serializing/deserializing things
<MercurialAlchemi>
flux: good point
<flux>
I wouldn't personally choose to transmit it over the network, if I cannot also copy the binary running at the other host..
<moviuro>
flux: could unison replace marshalling with something else?
<flux>
moviuro, yes it could, but that would probably require some development effort
<companion_cube>
it's a not-effort, no-guarantee way for serializing, yeah
<flux>
as as I said, Marshal requires no effort, other approaches require some effort :-)
<companion_cube>
the credible alternative is code geenrators
<flux>
Marshal is the memcpy-serializer of ocaml ;-)
<flux>
type-directed serializers would probably be the way for Unison
<flux>
if it's ok for Unison to break compatibility with other versions of Unison, it'd be ok to make a clean break
<flux>
actually Unison has problems with 32-bit hosts with a large number of files, because it exceeds the 32-bit string size limit of 16 megabytes
<flux>
so that could be solved probably with the same effort as well :-)
<flux>
I wonder if Unison is even able to sync between 32/64-bit hosts..
<MercurialAlchemi>
it shuld be at least possible to detect if another unison version is trying to send marshaled data and complain
<moviuro>
flux: unison never was back/for-ward compatible, so that wouldn't be an issue, I think
<MercurialAlchemi>
segfaulting or silently failing is not nice
<flux>
I guess the problem in this case is that the format was changed but _unison_ version wasn't
<flux>
so what I said at xx:59:17 would apply :)
<flux>
I suppose technically it could be so that even ocaml compilation options could affect the serialization format.. though I doubt this is the case currently.
<companion_cube>
proper serialization could use a memory-map and bigarrays
<companion_cube>
or just output to a channel, at least
<companion_cube>
(and parse from a channel)
<flux>
it would be nice if Unison was updated in this way.. it is a nice tool if you need synchronization.
enitiz has quit [Quit: Leaving]
Thooms has joined #ocaml
<MercurialAlchemi>
yes
<MercurialAlchemi>
it's quite fast, too
<moviuro>
if anyone uses it, I don't understand what is needed to have the -watch option work. It's about some kind of "filesystem change watcher" but have no idea which tools I must install
<companion_cube>
probably inotify
<companion_cube>
or something similar
<adrien_znc>
gasche: btw, considering 4.01 is going to be in distros for some time, if there are serious issues, it might still make sense to have 4.01.1 (only a "btw" for now)
fraggle-boate has quit [Remote host closed the connection]
<adrien_znc>
this is a compat library but it might make more sense to use directly the underlying freebsd feature in unison
<moviuro>
adrien_znc: how do I use it? I didn't catch that :/
<adrien_znc>
that would need new code
<adrien_znc>
you can try with that libinotify though
<ousado>
moviuro: take a look at inotify-tools maybe
<adrien_znc>
that's linux however
<moviuro>
ousado: doesn't exist on FreeBSD
<moviuro>
I'll give it a shot
<ousado>
huh, I thought you're on linux, since you asked about libinotify
<moviuro>
ousado: server is FreeBSD, clients are linuxes
<moviuro>
but yeah, np ;)
huza has quit [Quit: WeeChat 0.3.8]
kapil__ has joined #ocaml
octachron has quit [Ping timeout: 240 seconds]
badkins has joined #ocaml
ggole has quit []
shinnya has joined #ocaml
darkf has quit [Quit: Leaving]
ygrek has joined #ocaml
Haudegen has quit [Ping timeout: 252 seconds]
AlexRussia has joined #ocaml
Haudegen has joined #ocaml
rand000 has joined #ocaml
octachron has joined #ocaml
thomas_ has joined #ocaml
thomas_ is now known as Guest4710
Guest4710 has left #ocaml [#ocaml]
Haudegen has quit [Ping timeout: 252 seconds]
destrius has joined #ocaml
Haudegen has joined #ocaml
Thooms has quit [Ping timeout: 240 seconds]
jlouis_ is now known as jlouis
fraggle-boate has joined #ocaml
scheduledpyon is now known as pyon-omega-sub
chouser has joined #ocaml
Thooms has joined #ocaml
yomimono has quit [Ping timeout: 250 seconds]
Hannibal_Smith has joined #ocaml
Denommus has joined #ocaml
BitPuffin has joined #ocaml
ggole has joined #ocaml
Thooms has quit [Ping timeout: 245 seconds]
dsheets_ has quit [Ping timeout: 264 seconds]
dsheets_ has joined #ocaml
destrius has quit [Quit: Leaving.]
uris77 has joined #ocaml
badkins has quit []
yomimono has joined #ocaml
jonludlam has quit [Ping timeout: 250 seconds]
Denommus has quit [Quit: Bye]
iago has quit [Ping timeout: 252 seconds]
chaptastic has quit []
rgrinberg has joined #ocaml
jneen|zzz is now known as jneen
dsheets_ has quit [Ping timeout: 255 seconds]
waneck has quit [Ping timeout: 265 seconds]
Thooms has joined #ocaml
slash^ has joined #ocaml
octachron has quit [Quit: Leaving]
ygrek has quit [Ping timeout: 246 seconds]
Algebr has joined #ocaml
badkins has joined #ocaml
<Algebr>
Is oscigen the most mature web framework currently available?
<rgrinberg>
Algebr: yes
<rgrinberg>
unless you count ocaml-cgi or ocamlnet :P
<Algebr>
I'm a little uneasy about how it bundles everything together, the server, client side code as well.
<Drup>
Algebr: it does that only if you want to
<Algebr>
I'm thinking about using it for a serious project, didn't want to go with python/ruby.
<rgrinberg>
Algebr: there's also my own little framework. But it's decidedly not as mature: https://github.com/rgrinberg/opium . I don't like calling it a framework even.
<rgrinberg>
Drup: definitely try eliom though
<Algebr>
rgrinberg: very nice looking, does it talk to nginx?
<rgrinberg>
Algebr: it talks to nginx like everything else, through a reverse proxy
<Drup>
Algebr: what do you want to do ?
<companion_cube>
rgrinberg: you should annotate the Readme's block code with "ocaml"
<companion_cube>
```ocaml
<companion_cube>
code here
<companion_cube>
```
<Algebr>
Build a web application
<rgrinberg>
companion_cube: will do
<Algebr>
and use ocaml instead of django
<rgrinberg>
Algebr: what kind of web application? :D
<Drup>
Algebr: that's a bit vague :D
<Algebr>
I'm not sure how to describe it beside a modern web app that would be made with either django/rails
<Algebr>
I'll need it to talk to postgres
<Algebr>
that usually would be made*
chaptastic has joined #ocaml
<Drup>
how dynamic is it, do you plan to have client code, do you have specific external dependencies ?
<Algebr>
yea, I expect substantial amounts of js.
<Algebr>
external dependency so far is just postgres
<rgrinberg>
Algebr: how much do you hate JS?
<Drup>
ahah xD
<Algebr>
enormously
<rgrinberg>
companion_cube: thanks I should do it
<rgrinberg>
then definitely give ocsigen a try
<Drup>
Algebr: write the client code in OCaml :3
<companion_cube>
does that require ocsigen?
<Algebr>
yea, I saw it had a ocaml to js compiler, but what about stuff like Backbone and others?
<companion_cube>
I suppose opium can be used with js_of_ocaml
<Drup>
companion_cube: you don't get the fancy client server integration
<companion_cube>
oh, ok
<companion_cube>
like shared functions
<companion_cube>
I see
<Drup>
not only shared functions
<Drup>
you have other fancier stuff, shared functions is the lvl0 :D
<rgrinberg>
Algebr: stuff like backbone would be painful to use
<Drup>
stuff like backbone is pretty useless once you don't use a bad language like javascript.
<rgrinberg>
other JS libs are useful though so be prepared to write bindings
<rgrinberg>
e.g. d3, strophe
<Drup>
d3 is not completely bindable :/
<Algebr>
the ocsigen tutorials are somewhat bare, or probably just my inexperience
<Drup>
(it would be done already otherwise)
jonludlam has joined #ocaml
<Algebr>
Why is d3 not completely bindable?
<Drup>
too dynamic
<Drup>
it's completely horrible to typecheck
pyon-omega-sub is now known as realizablepyon
<Drup>
it's using dynamic checking all the time and it's really hard to embed in the ocaml world.
lambdahands has joined #ocaml
<Drup>
you usually bind the little parts that you want, it's easier
ontologiae has joined #ocaml
<Algebr>
Drup: Hmm, sounds like for stuff like d3 that I might as well just write the js.
Thooms has quit [Ping timeout: 264 seconds]
<Drup>
yeah, you write the d3 glue in js
badkins has quit [Ping timeout: 252 seconds]
<rgrinberg>
i've been playing around with purescript lately
<rgrinberg>
feels like cheating on ocaml :D
<Drup>
x)
<rgrinberg>
their FFI story is really good imo
<Drup>
that's the main point, yes
<rgrinberg>
js_of_ocaml focuses on running existing ocaml code on JS but I don't care for that too much. Calling js libs from ocaml is what's interesting to me
<companion_cube>
rgrinberg: so, isn't the readme easier on the eye now? ;)
<rgrinberg>
companion_cube: yes it is. Somehow I keep forgetting that this exists
dsheets_ has joined #ocaml
stygianguest has left #ocaml [#ocaml]
vanila has joined #ocaml
Algebr` has joined #ocaml
Algebr has quit [Read error: Connection reset by peer]
Kakadu has quit [Quit: Page closed]
IbnFirnas has quit [Read error: Connection reset by peer]
tristero has quit [Read error: Connection reset by peer]
rgrinberg has quit [Quit: Leaving.]
Submarine has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 245 seconds]
rgrinberg has joined #ocaml
struk|work has joined #ocaml
AlexRussia has quit [Ping timeout: 245 seconds]
iago has joined #ocaml
swgillespie has joined #ocaml
MrScout has joined #ocaml
<struk|work>
sigh utop is segfaulting on 2/3 of my machines now.
swgillespie has quit [Client Quit]
Haudegen has quit [Ping timeout: 264 seconds]
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
chaptastic has quit [Ping timeout: 245 seconds]
mort___ has quit [Ping timeout: 245 seconds]
<Simn>
Just 1/3 to go.
MrScout has quit [Read error: Connection reset by peer]
MrScout has joined #ocaml
<struk|work>
ha, I am doing an opam update, hoping it magically fixes some things
rgrinberg has quit [Quit: Leaving.]
jwatzman|work has joined #ocaml
Haudegen has joined #ocaml
ptc has joined #ocaml
ptc is now known as ptc_
<ptc_>
What is the behavior of Marashal.to_channel on a closed pipe output_channel?
<ptc_>
It seems to hang indefinitely on linux
<Algebr`>
damnit, wish I knew ahead of time opam was broken on apt-get
<ptc_>
and doesn't seem to raise Sys.sigpipe as far as I can tell
<adrien_znc>
they're buffered I/O on top of standard I/O
Algebr` has quit [Read error: Connection reset by peer]
Algebr` has joined #ocaml
<adrien_znc>
so don't expect the same behaviour as standard I/O
Hannibal_Smith has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
<ptc_>
adrien_znc: yes, but does that mean Marshal.to_channel can hang indefinitely on a closed channel?
IbnFirnas has joined #ocaml
<ptc_>
adrien_znc: so does Pervasives.close_in/close_out not close the underlying file descriptor?
<ptc_>
seems like they do...
yomimono has quit [Ping timeout: 252 seconds]
AlexRussia has joined #ocaml
Hannibal_Smith has joined #ocaml
<adrien_znc>
but there is also an associated buffer
badkins has joined #ocaml
<adrien_znc>
I don't know how it does it, I'm only pointing out that SIGPIPE are not for channels typically
chinglish has quit [Quit: Nettalk6 - www.ntalk.de]
ptc_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
BitPuffin has quit [Ping timeout: 245 seconds]
Algebr`` has joined #ocaml
Algebr` has quit [Ping timeout: 264 seconds]
nullcat has joined #ocaml
Algebr`` has quit [Ping timeout: 256 seconds]
nullcat has quit [Ping timeout: 265 seconds]
mistym has quit [Ping timeout: 245 seconds]
realizablepyon is now known as realizable-pyon
seveneng has joined #ocaml
seveneng has left #ocaml [#ocaml]
Kakadu has joined #ocaml
mistym has joined #ocaml
realizable-pyon has quit [Quit: starting universe shutdown process...]
uris77 has quit [Quit: leaving]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
psy_ has quit [Read error: Connection reset by peer]
psy_ has joined #ocaml
MrScout_ has joined #ocaml
MrScout has quit [Ping timeout: 245 seconds]
<rgrinberg>
anybody got ppx_test to work with oasis?
<rgrinberg>
plx halp
leowzukw has joined #ocaml
Denommus has joined #ocaml
larhat has quit [Quit: Leaving.]
ontologiae has quit [Ping timeout: 250 seconds]
Denommus has quit [Remote host closed the connection]
ptc has joined #ocaml
Denommus has joined #ocaml
ptc is now known as Guest41429
dsheets_ has quit [Ping timeout: 244 seconds]
MrScout_ has quit [Remote host closed the connection]
MrScout has joined #ocaml
tristero has joined #ocaml
ggole has quit []
MrScout has quit [Ping timeout: 245 seconds]
Haudegen has quit [Ping timeout: 252 seconds]
rgrinberg has quit [Quit: Leaving.]
thegameg has quit [Read error: Connection reset by peer]
mistym has quit [Ping timeout: 245 seconds]
Haudegen has joined #ocaml
MrScout has joined #ocaml
rgrinberg has joined #ocaml
mistym has joined #ocaml
_andre has quit [Quit: leaving]
sinelaw has joined #ocaml
<sinelaw>
why can't we always generalize (infer forall's) in anonymous record fields?
<sinelaw>
instead of requiring the user to define the record type with an explicit forall?
<sinelaw>
hmm. never mind.
<sinelaw>
actually I take that back. why can't we?
q66 has joined #ocaml
uris77 has joined #ocaml
<mrvn>
sinelaw: because you can only do that if the function is universal
<mrvn>
let fun last = let t = ref None in fun x -> let res = t in res := Some x; res
mistym has quit [Ping timeout: 245 seconds]
<mrvn>
That example probably isn't suddle enough though.
mort___ has joined #ocaml
<flux>
sinelaw, what is anonymous record field?
<mrvn>
sinelaw: I wish ocamls type system would have a syntax for universal functions, like it has for inside records, objects or modules. But for some reason the type system always needs that extra boxing.
mistym has joined #ocaml
mistym has joined #ocaml
<flux>
sinelaw, or do you mean why is type t = { x : 'a.'a } different from type 'a t = { x : 'a } ?
rgrinberg has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
<mrvn>
(the former being rather useless as is)
<sinelaw>
mrvn, flux, well yeah, ocaml doesn't have anonymous records (or does it?)
<sinelaw>
but assume have them, and then: let bla = { f = fun x -> x }
<sinelaw>
should have type: { f : 'a. 'a -> 'a }
<flux>
correct, ocaml doesn't have anonymous records
<mrvn>
yeah, but due to some quirks of the type system infering can't tell that.
<flux>
well, that works given the correct type definition
<mrvn>
Which is why, given your above record type) you can't write: let make fn = { f = fn; }
<sinelaw>
For one, there's an issue with mutable fields
<sinelaw>
the type system will need to prevent assignments to properties with values that have less-generalized types
<sinelaw>
actually that part already works in ocaml
<sinelaw>
so not sure what the issue is.
<sinelaw>
if at all.
<Drup>
actually, objects are pretty much anonymous records
<Drup>
and inference of polymorphic methods for objects is indecidable, iirc
<Drup>
so ocaml doesn't do it.
<mrvn>
Drup: the question is why
<mrvn>
But that probably gets rather technical
<Drup>
why it's not decidable ? bleh
<sinelaw>
rank-n is generally undecidable
<mrvn>
I only wish one could annotate functions to be universal explicitly so one could provide a constructor function for records like the above.
yomimono has joined #ocaml
<mrvn>
function arguments that is
oscar_toro has quit [Ping timeout: 265 seconds]
MrScout has quit [Remote host closed the connection]
octachron has joined #ocaml
mistym has quit [Ping timeout: 245 seconds]
mistym has joined #ocaml
yomimono has quit [Ping timeout: 264 seconds]
Thooms has joined #ocaml
waneck has joined #ocaml
badon has joined #ocaml
leowzukw has quit [Quit: Lost terminal]
nicoo has quit [Remote host closed the connection]
nicoo has joined #ocaml
slash^ has quit [Read error: Connection reset by peer]
MrScout has joined #ocaml
struktured has joined #ocaml
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
<MercurialAlchemi>
grmbl
<MercurialAlchemi>
whatever ubuntu mirror opam's travis is using is down, it looks like
ontologiae has joined #ocaml
badkins has quit []
Thooms has quit [Quit: WeeChat 1.0.1]
Thooms has joined #ocaml
enitiz has joined #ocaml
uris77 has quit [Ping timeout: 264 seconds]
octachron has quit [Quit: Leaving]
tani has joined #ocaml
enitiz has quit [Quit: Leaving]
thegameg has joined #ocaml
tane has quit [Ping timeout: 244 seconds]
enitiz has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
claudiuc has joined #ocaml
hilquias` has joined #ocaml
hilquias has quit [Ping timeout: 245 seconds]
Guest41429 has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mort___ has quit [Quit: Leaving.]
rgrinberg has quit [Quit: Leaving.]
ptc has joined #ocaml
ptc is now known as Guest10372
rand000 has quit [Quit: leaving]
rgrinberg has joined #ocaml
Guest58361 has joined #ocaml
Guest58361 has quit [Changing host]
Guest58361 has joined #ocaml
Guest58361 is now known as realizable-pyon
yomimono has joined #ocaml
MrScout_ has joined #ocaml
realizable-pyon has quit [Quit: everything sucks]
Quintasan has left #ocaml [#ocaml]
MrScout has quit [Ping timeout: 264 seconds]
yomimono has quit [Ping timeout: 244 seconds]
MercurialAlchemi has quit [Ping timeout: 240 seconds]
sinelaw has quit [Ping timeout: 264 seconds]
matason has quit [Ping timeout: 255 seconds]
Sorella has quit [Quit: Connection closed for inactivity]
chaptastic has joined #ocaml
<dmbaturin>
If all functions in a module work with a single specific type defined in that module, is it still a good idea to expose it as abstract Mymodule.t in the signature?
<dmbaturin>
Also, if a module define multiple types, what is the best practice for exposing them in signatures?
Kakadu has quit [Ping timeout: 264 seconds]
<mrvn>
you have to expose the type for write the signature of the functions
<mrvn>
If you have multiple types then give them proper names or use submodules
enitiz has quit [Ping timeout: 245 seconds]
Hannibal_Smith has quit [Quit: Leaving]
iago has quit [Ping timeout: 240 seconds]
jao has quit [Ping timeout: 252 seconds]
tani has quit [Quit: Verlassend]
cdidd has quit [Remote host closed the connection]
cdidd has joined #ocaml
enitiz has joined #ocaml
enitiz has quit [Ping timeout: 245 seconds]
struktured has quit [Ping timeout: 245 seconds]
Simn has quit [Quit: Leaving]
jwatzman|work has quit [Quit: jwatzman|work]
chaptastic has quit []
Guest10372 has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
MrScout_ has quit [Remote host closed the connection]