<olle>
Hm can <> operator only be used on strings?
<olle>
No
<olle>
I can compare sum types, no?
<olle>
type t = A | B;; if A = B then ...
<olle>
Yea works fine
<olle>
Error: This expression has type allocation_strategy
<olle>
but expected string
<olle>
But WHY does it expect string??
<olle>
lol `if 1 = 1 then ();` fails with same error, expect string ><
<olle>
Is this another `open Base` issue...?
<octachron>
base does shadow the polymorphic comparison operators
<olle>
It does?
<olle>
OK good info :D
<olle>
I mean it's crazy
<Armael>
I thought Base restricted comparaison operators on int, not string
<olle>
So how do I reach the native comparison? Caml.(=) ?
<octachron>
The base module does, but each module define its own comparison operators.
random-jellyfish has quit [Quit: Client closed]
<olle>
Not infix but seems to work. I think.
bobo_ has quit [Ping timeout: 252 seconds]
spip has joined #ocaml
jao has joined #ocaml
<olle>
I mean the number of facepalms caused by Base, I should really remove it from my project...
olle has quit [Ping timeout: 252 seconds]
<discocaml_>
<jaydub> I wanted to explore eio by following the examples on its repo. Things work great so far but with a little frustration with merlin. I'm using dune and Emacs. The code compiles fine with `dune build` but merlin shows errors in the editor. Like "Unknown module Eio" etc. What am I missing?
Serpent7776 has quit [Ping timeout: 260 seconds]
olle has joined #ocaml
<olle>
Is it taboo to critize Base lib?
<olle>
Considering it's a absolute minefield of weird error messages, I'd expect people to advice against using it, but no one is saything *anything*
<olle>
an*
bartholin has joined #ocaml
<discocaml_>
<dinosaure> olle: it's not a taboo, from my perspective you did not ask an opinion about base 🙂
<olle>
Hehe, true
<olle>
Hmmm
<olle>
9 [@@deriving show, sexp]
<olle>
sexp depends on `open Base`?
<olle>
Can't do Base.sexp, it seems
<olle>
Error: Ppxlib.Deriving: 'Base.sexp' is not a supported type deriving generator
<olle>
type sexp = Base.Sexp.t, and then [@@deriving sexp] won't work, because: Error: Unbound value compare_list
<olle>
open Ppx_compare_lib.Builtin
<olle>
This solves the compare issue
<olle>
open Sexplib.Std
<olle>
And that one solves sexp
Stumpfenstiel has joined #ocaml
<discocaml_>
<beajeanm> Olle: the consensus I've seen here (and that I share): it's fine, even good, if you know what you're getting into. It's terrible to expose it to newbies and give it a feel of official lib because of its use in rwo. And most people would be better served by learning about containers instead.
<olle>
Yeah, RWO was my trap... I'm not a newbie in OCaml but I don't use it professionally
<olle>
Getting rid of all `open Base` now, at least
Inst has quit [Read error: Connection reset by peer]
<discocaml_>
<beajeanm> It was the same for me, I already knew OCaml when I read it, but I thought I was missing something big and needed to migrate everything I do to the JS ecosystem, base, core, async, etc. Now I have the opposite stance, I need a really good justification to go anywhere close to it.
<olle>
Glad to hear I'm not alone xD
mro has joined #ocaml
azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
<discocaml_>
<Alistair> You’ve likely opened String somewhere
<discocaml_>
<Alistair> Base shadows the polymorphic compare (for good reason) with the equality operator on ints
sagax has joined #ocaml
<olle>
It's not about reasons, it's about predictability and googleability
<olle>
I also couldn't compare sum types
<olle>
But yes, I had open base and open string at top of file before
<olle>
#neveragain
<discocaml_>
<Alistair> Base shadows the polymorphic compare (for good reason) with the equality operator on ints
<discocaml_>
<Alistair> Base shadows the polymorphic compare (for good reason) with the comparison operator on ints
hackinghorn has quit [Ping timeout: 252 seconds]
mro has quit [Remote host closed the connection]
<discocaml_>
<undu> olle: I don't like base either, I want rid the project at work from it, it's used for a thousand-line module and it's a massive pull od dependencies for dubious benefit. I could understand using it 10-15 years ago with a much less mature ecosystem, not now
<olle>
Mm
Anarchos has joined #ocaml
anpad has quit [Ping timeout: 260 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
cedric has joined #ocaml
neiluj has quit [Ping timeout: 246 seconds]
<discocaml_>
<j1> When I try to figure some deep concept I often port from Haskell to Ocaml. Doing arrows now and I'm having a lot of difficulty recreating the typeclass taxonomy. Made me wonder if it would be possible to create a typeclass macro. Anybody know?
<discocaml_>
<Alistair> OCaml doesn't have typeclasses -- what would you expect the equivalent of a typeclass to be in OCaml?
<discocaml_>
<j1> Modules and functors
neiluj has joined #ocaml
<discocaml_>
<j1> It also doesn't really work (yet?) because some of the arrows implement conditional logic and that needs to be evaluated lazily.
<discocaml_>
<Alistair> You should write a comparison function for sum types then (or use [@@deriving equal]). I'd argue that base's approach for comparison functions improves predictability (no surprising comparison results from polymorphic compare). Also base taught you a valuable lesson there, avoid opening lots of modules at the top of a file
<discocaml_>
<Alistair> Translating typeclasses to modules and functors doesn't really scale nicely (as you're probably finding out)
<discocaml_>
<j1> Yes haha
<Anarchos>
what are typeclasses and why are they not in ocaml ?
<discocaml_>
<j1> It seems like everything CAN be done with the module system but it's very touchy. So I think a typeclass macro or something should be possible.
<discocaml_>
<j1> They are a way to provide multiple implementations of a function that depend on a type which is known at compile time.
<dh`>
typeclasses are a dynamic dispatch scheme basically
<discocaml_>
<j1> Not really dynamic dispatch.
<Anarchos>
isn't GADt for that ?
<discocaml_>
<Alistair> Typeclasses cannot be done with a simple macro without access to type information @j1
<dh`>
j1, sure it is
<dh`>
anarchos: no...? not sure I even understand the question
<discocaml_>
<j1> Okay but it's not dynamic
<dh`>
yes it is
<dh`>
you write polymorphic code, you call f, it dispatches to the right f implementation for the type you're handling
<discocaml_>
<Alistair> It is dynamic in the sense that you essentially pass a vtable around for your typeclass
<discocaml_>
<masterbuilder> dh`: typeclasses in for example Haskell I think are fully statically dispatched, same with most languages
<discocaml_>
<j1> show Int and show String are different functions at compile time. That's not dynamic simply because they have the same name.
<discocaml_>
<Alistair> But the feature is still being researched (with no eta on when it would be implemented in the language)
<discocaml_>
<j1> Okay I wasn't going to attempt it because it's beyond me but I wondered if it was possible.
<dh`>
j1: it is dynamic. if I am ghc and compiling a function with an argument of type Show t => t, how do I pick the right one statically?
<dh`>
answer: i can't, that's why there's a dictionary/vtable passed around
<discocaml_>
<masterbuilder> which disappears at runtime, usually, after you resolve the methods (which you can if your types are all static) there is no need for dynamism anymore
Anarchos1 has joined #ocaml
Anarchos has quit [Ping timeout: 268 seconds]
<dh`>
it will only disappear if the compiler can devirtualize it, which is no different from devirtualizing anything else
<discocaml_>
<Alistair> Only if you inline everything
<discocaml_>
<masterbuilder> it has nothing to do with virtual functions, if the compiler knows the type, and the type implements the interface, it can be statically resolved to a concrete function
<discocaml_>
<Alistair> How would you compile typeclass polymorphism then? As dh' points out, a function of the type `Show t => t -> ...` cannot be compiled without requiring an implicit dictionary as a parameter
<discocaml_>
<j1> Show t => t is not something that ends up in compiler output
<discocaml_>
<masterbuilder> instantiate it when it's used like C++ does for example
<dh`>
that's "inline everything"
<dh`>
you can easily have whole source files that are polymorphic over assorted typeclasses
<discocaml_>
<j1> Which will be compiled using concrete types...\
<olle>
Hello I would like to have an argument, please
<dh`>
j1, no
<discocaml_>
<j1> I think to some extent we're using different definitions of static and dynamic and I think it's pointless to discuss it further.
<discocaml_>
<Alistair> Anyway regardless, this is a minor semantic different and this argument isn't very fruitful to the original discussion
<dh`>
maybe, but it's a very simple question: is the call indirect through a function pointer
<discocaml_>
<j1> To me, it's like practically saying uhh map -> ('a -> 'b) -> 'a list -> 'b list is dynamic
<dh`>
no, it's not
mro has quit [Quit: Leaving...]
<dh`>
there's (ordinarily) only one compiler output for map
<discocaml_>
<j1> It's a constraint on what for example 'a can be.
<discocaml_>
<masterbuilder> it would be nice if ocaml had ad hoc polymorphism, though I understand why it doesn't
<dh`>
j1, it's also a way to call functions on 'a without 'a being a specific type
<dh`>
(a typeclass)
<dh`>
which requires multiple compiler outputs and selecting among them, and you can't always do that selection at compile time
<discocaml_>
<j1> Right, and that's another function with a constraint. But eventually concrete static types must be used in order to actually produce a program.
<dh`>
j1, no.
<dh`>
I can have a single piece of code that is parameterized by the typeclass dictionary to be polymorphic over lots of types
<dh`>
to make it static you'd have to replicate that code once for each type
<dh`>
at link time, too.
<dh`>
and you probably need a complete pointer analysis to do it, which is an unsolved hard problem
<discocaml_>
<j1> Right, we're on different definitions.
<Anarchos1>
dh` so how haskell do that ?
<dh`>
by passing around vtables
<dh`>
j1: i don't understand what definition you're using or what it means, but if you're ok with that, w/e
<discocaml_>
<j1> I don't care that much about the compiler output. I care about how the types are checked.
<dh`>
in that case static vs. dynamic isn't even a thing
<dh`>
unless you're thinking about dynamically typed languages?
<dh`>
which is 100% totally unrelated
<discocaml_>
<j1> So like I said, we're talking about different things.
<dh`>
I'm confused by how that's even relevant, but again, w/e
* dh`
wanders off
<discocaml_>
<NULL> No dynamic typing, but yes dynamic dispatch
zbroyar has quit []
<discocaml_>
<NULL> I'm curious about what the difference between modular implicits and typeclasses is
<olle>
Do you need a vtable? Isn't it enough with a function pointer in the type block?
<olle>
Maybe that's similar
<dh`>
a vtable is a bundle of function pointers
<dh`>
in general there's more than one function, so...
<olle>
Yeah buuuut
<olle>
Ah nevermind
<dh`>
iirc the haskell folks are (or were) careful to call them "dictionaries" and not "vtables" to avoid triggering C++ PTSD
<olle>
Hehe
<olle>
Also depends if they belong to the variable or the class, no?
<dh`>
possibly yeah
<olle>
Or wait, it's not dynamic unless it's passed around with the variable :d
<olle>
?
<dh`>
with typeclasses the dictionary floats around as a separate argument to polymorphic functions
<olle>
Oh
<dh`>
it's not an element of the value representation
<discocaml_>
<NULL> That's my intuition about modular implicits as well
<dh`>
because one of the important things about typeclasses and why they're better than inheritance-style virtual functions is that you don't have to wedge the typeclass into the original type definition
<dh`>
you can add typeclass instances for types after the fact
<dh`>
this also lets you have typeclasses that aren't bound to any one single type
waleee has joined #ocaml
Anarchos1 has quit [Quit: Vision[]: i've been blurred!]
<olle>
Alright :)
waleee has quit [Ping timeout: 248 seconds]
waleee has joined #ocaml
cedric has quit [Quit: Konversation terminated!]
waleee has quit [Ping timeout: 252 seconds]
trev has quit [Remote host closed the connection]
anpad has joined #ocaml
<discocaml_>
<froyo> > @psychokitty: I take it there's no way to get ocamllex to accept a modified lex buffer as part of a rule's semantic action(s)?
<discocaml_>
<froyo> what's your use-case? could you elaborate?
waleee has joined #ocaml
rf has joined #ocaml
waleee has quit [Ping timeout: 252 seconds]
olle has quit [Ping timeout: 248 seconds]
waleee has joined #ocaml
neiluj has quit [Ping timeout: 255 seconds]
bgs has quit [Remote host closed the connection]
bartholin has quit [Quit: Leaving]
waleee has quit [Ping timeout: 255 seconds]
Stumpfenstiel has quit [Ping timeout: 248 seconds]