<adrien>
I've been doing js_of_ocaml stuff again after several years without touching it and I've forgotten most of it except mayve the pain of "opt" and "optdef" types: are there good ways to deal with them?
<adrien>
basically, I wanted to "input##.files##item0" but "input##.files" is optdef and "##item 0" returns an opt so I'm calling Optdef/Opt.to_option on them and then Option.get
<adrien>
it doesn't look like I can chain them because one is Optdef, the other is Opt, so all the combinators in the corresponding modules can't be used
<discocaml>
<dinosaure> Yes to pattern match on effects like you can pattern match exceptions
<discocaml>
<contificate> Is the top-level syntax for defining effects also using that in 5.3, as it is in 5.1.1+effect-syntax
<adrien>
but there's no documentation and I'd appreciate to at least know what was the intent behind this
<discocaml>
<otini_> not sure what you mean
<discocaml>
<otini_> these all seem to be functions to deal with possibly null and undefined values in JS
<adrien>
in js_of_ocaml you have APIs to deal with potentially-null values and APIs to deal with potentially-undefined values but no link between them: in my case, ##.files might be null iirc and ##item 0 on top of that might be undefined
<adrien>
therefore I needed a different API for each of these and I had nothing to construct a chain in a monadic-style
<discocaml>
<otini_> Maybe you can hand-define a conversion operator ?
raskol has joined #ocaml
<adrien>
I'll probably go that way and the AOpt module I mentioned above might even be exactly what I'm looking for; I'm not sure what the semantics between null and undefined should be however (i.e. who wins between the two)
<octachron>
reynir, yes effect is a keyword in 5.3, and if you have an use case for disabling the keyword don't hesitate to chime in https://github.com/ocaml/ocaml/pull/13471
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 248 seconds]
pi3ce has joined #ocaml
pi3ce has quit [Client Quit]
Anarchos has joined #ocaml
<Anarchos>
For infinite lazy lists, should i use Seq or Set ?
pi3ce has joined #ocaml
<discocaml>
<xavierm02_> adrien: you can think of terms of JS as being `dyn ::= Undefined | Obj of potentially_null_obj | ...`, so Undefined is "less defined" than null, and should probably "win". I'd expect the lack of api that deal with both to be due to the fact that you often want to handle the none case as soon as it is detected (by raison an exception, or providing a default value) and rarely want to propagate the null-ness or undefined-ness
<discocaml>
<deepspacejohn> Anachros: the stdlib Set? I don't know how that would be possible...
<discocaml>
<deepspacejohn> Seq is well designed for that task though.
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Anarchos>
deepspacejohn yes Seq seems the way to go
<adrien>
xavierm02_: thanks, and that's a good point and indeed, not having "files" on an "input" element would be a final error while not having a file 0 (i.e. no file selected) could change over time
<adrien>
I'm barely starting jsoo stuff again so my point of view matches that, with the difference that I'm tempted to do something much bigger too afterwards
<adrien>
maybe I'll have a different take on the topic after that :P
gdiazlo has joined #ocaml
<reynir>
octachron: I don't really have a use case for disabling it (it was a local binding that I could easily change). But it would be nice to get a different error than syntax error when writing `let foo (effect : t) = ...`
<reynir>
I mean, it's a bit confusing that the colon is a syntax error
<octachron>
The issue is that "let foo (effect E, k)" is valid syntactically
<octachron>
Thus the syntax error is only inevitable once `:` has been read.
<octachron>
One day we will have nice menhir error messages.
<reynir>
yes :/
Anarchos has quit [Quit: Client closed]
<reynir>
maybe, in hindight, in earlier release(s) there could be a warning on variables "effect" that it will become a keyword in a near future release
<reynir>
s/hindight/hindsight/
<reynir>
Ah, with your proposal and maybe dune defaults we could have that I guess
spew has joined #ocaml
<discocaml>
<regularspatula> adrien: not sure if you have an existing code base to work with, but if not, I have enjoyed using brr rather than the jsoo library directly
toastal has left #ocaml [Disconnected: Hibernating too long]
Tuplanolla has joined #ocaml
gdiazlo has quit [Ping timeout: 252 seconds]
gdiazlo has joined #ocaml
gdiazlo has quit [Ping timeout: 260 seconds]
gdiazlo has joined #ocaml
anpad has joined #ocaml
gdiazlo has quit [Ping timeout: 265 seconds]
gdiazlo has joined #ocaml
gdiazlo has quit [Ping timeout: 260 seconds]
gdiazlo has joined #ocaml
gdiazlo has quit [Ping timeout: 252 seconds]
<discocaml>
<luck33> Hey! I'm just getting into OCaml and I stumbled onto Sid Kshatriya and osa1's blog posts on why/why not ocaml (respectively). One of the big things they point out is type classes. I'm curious, are there any working groups looking at this for OCaml? Are there widely used solutions to not having type clasess?
<discocaml>
<contificate> I might be in the minority here, as I get a mixed reception with this view, but: I have never once wanted type classes in OCaml. Engineering codebases with modules kind of subsumes it. What most people want is some kind of language-level deriving feature. Even in Haskell, typeclasses aren't amazing. Doesn't it just devolve into record passing style if you can't rely on a canonical instance? In which case, record specialisation (functors) a
<discocaml>
<deepspacejohn> There are people working on modular implicits, which would be similar to type classes for OCaml. I would not expect to see them become usable in the foreseeable future, though.
<discocaml>
<luck33> contificate: I think Sid and IIRC osa1 both touch on the point that it makes documentation difficult, and I wonder if it doesn't hurt the ecosystem in terms of codifying convention a little?
<discocaml>
<contificate> isn't Oleg's blog just "yeah, pass records around"
<discocaml>
<deepspacejohn> yeah, I wouldn't use that article as general-purpose advice. More of an interesting exercise that can be useful in situations.
<discocaml>
<contificate> we already effectively have a structured mechanism for dictionary passing style: modules
<discocaml>
<contificate> I can't speak to documentation, as I think designing a good interface and documenting that is better than what typeclasses can devolve into (Haskell envy everywhere)
<discocaml>
<octachron> My opinion is that the lack of typeclasses don't really hinder documentation writing, except if your target audience is Haskeller.
<discocaml>
<contificate> Haskell's documentation is actually actively hostile to beginners, because it presupposes they will get anything from "as X is a commutative adjoint functorial bijective semi-lattice, clearly.."
<discocaml>
<octachron> In my experience, OCaml libraries with a reputation for good documentation are not written with typeclasses in mind.
euphores has joined #ocaml
<discocaml>
<octachron> Functors are syntactically heavy, which tend to hinder library combinators that try to be as generalizable as possible.
<discocaml>
<octachron> That doesn't really necessarily hurts when you are writing an application.
<discocaml>
<deepspacejohn> The trick to writing good documentation is to actually write it, including explanations and examples. Don't let the interface alone act as the documentation for you.
<discocaml>
<luck33> octachron, (et al): I do want to clarify that I don't think it's impossible to write documentation without typeclasses! At all! But it can be nice to look at what specifically the developer was *intending* to implement
<discocaml>
<octachron> @deepspacejohn , are you implying that "integers are an initial object in the category of rings" is not a good documentation? I am shocked.
<discocaml>
<octachron> But the developer should write down its intention any way, a `bind` and `return` function in the monadic interface part of the interface is not harder to discover than an instance of the monad type class.
<discocaml>
<contificate> ability to nested `dune` projects so easily should make `examples` subfolders as common as possible
<discocaml>
<contificate> ability to nest `dune` projects so easily should make `examples` subfolders as common as possible
<discocaml>
<octachron> And if a module implemented your preferred interface by accident, then lucky you, you can use the structural nature of the module system to call the corresponding functors. Or you can switch one function implementation.
<companion_cube>
don't rely on chance…
<discocaml>
<octachron> ^ Which is why there is still a pressure towards consensual names, even if it is maybe a little less than in Haskell.
kurfen has quit [Ping timeout: 252 seconds]
<companion_cube>
bah. functors are rarely worth it compared to passing a record of functions or 1st class module…
kurfen has joined #ocaml
<discocaml>
<octachron> And lightweight functors will be even nicer in this context.
Anarchos has joined #ocaml
<companion_cube>
if you're carrying around a monad, functors are the lesser evil indeed :/
<companion_cube>
if you just want a monoid or something, they're terrible
<discocaml>
<deepspacejohn> does "lightweight functors" mean something specific?
<discocaml>
<deepspacejohn> ah, cool. I hadn't heard that term before.
<companion_cube>
(oh, "will be", right. wait and see…)
<discocaml>
<deepspacejohn> would that be "lightweight" in terms of the syntax? functor application would still be the same at runtime, I assume?
gahr has quit [Quit: leaving]
<Anarchos>
octachron by 'the' didier remy ?
<discocaml>
<octachron> For that one, I am willing to bet on "before 5.5" (ok without my release manager hat on)
gahr has joined #ocaml
<discocaml>
<octachron> functors are already simple functions at runtime
<discocaml>
<octachron> Anarchos, yes?
<Anarchos>
octachron i am still impress to see how the core ocaml team is productive year after year.
raskol has quit [Ping timeout: 272 seconds]
<discocaml>
<gooby_clown> I haven't understood integers until now but now it's clear, thanks
chrisz has quit [Ping timeout: 255 seconds]
chrisz has joined #ocaml
aljazmc has joined #ocaml
<discocaml>
<luck33> How generally do people feel towards Eio? It seems like it's positioning itself as to OCaml what Tokio is to Rust. Very new, so may be reading that very wrong.
<discocaml>
<dinosaure> different solutions exist 🙂 moonpool, fuseau, riot, eio & miou. picos also exists, as we said in general, "choose your poison" 🙂
<discocaml>
<gooby_clown> Picos is great, ccube mentioned it and now I'm fully supporting it
<discocaml>
<gooby_clown> Hopefully Eio switches to Picos
bartholin has joined #ocaml
<companion_cube>
🤞
Anarchos has quit [Quit: Vision[]: i've been blurred!]
szkl has joined #ocaml
Anarchos has joined #ocaml
<discocaml>
<barconstruction> Companion cube never misses a chance to say that functors are a niche feature lol