<chenglou>
dpt89: do you have something concrete in mind?
<chenglou>
what would you like to make
<dpt89>
well, I'm following the tuts. I want to write a small library for form string tables, then handle some files, then a little HTTP. Like progressive stuff with just the smallest possible dependencies to get the work done.
<chenglou>
lol funny, one of the first things I've made in ocaml was an ascii table
<chenglou>
right, and you want to just include Core
<dpt89>
I could just change the Core dep with whatever equivalent there's in batteries. I don't mind the change while I learn, just want to go with Reason as soon as possible. I'm totally excited about it. It feels like having all the benefits of Swift without having to wait half a decade for it to be production ready.
<dpt89>
with reason if it compiles it should work just like written in ocaml, so it's a great guarantee with all the syntactical goodies
<dpt89>
yeap, I just want to include core to read from stdin (I think that only, not sure if the Float part also comes from Core)
<chenglou>
dpt89: I'd say go with Batteries for now
<dpt89>
(looking at the batteries link you sent to figure out how to install)
<dpt89>
so I install it with opam
<chenglou>
Batteries' installation should be conventional
<dpt89>
and just open it in the top of the file?
<chenglou>
`open Batteries; BatList.map ......`
<chenglou>
yeah
<chenglou>
lemme see if there's a CommonML Batterie
<chenglou>
s
<chenglou>
(nah, just use rebuild for now, sorry)
<dpt89>
I didn't understand that at all O_o but it's ok
<chenglou>
dpt89: are you familiar with js?
<dpt89>
yeap
<chenglou>
and npm I suppose?
<dpt89>
more than I like to admit I think!
<dpt89>
yes, sir
<chenglou>
if you don't mind not having Core/Batteries/Container, and work with currently zero third-party packages, you can try my jengaroot lol
<chenglou>
it uses npm
<chenglou>
so package management wise you already know how everything works
<chenglou>
just that there's no reason npm package you can install, that's all
<chenglou>
heck, I was thinking of writing the first ones...
<chenglou>
anyways that's only if you want. If you really need Batteries then ignore what I just said
<dpt89>
I really want the whole native compiled thing
Algebr has quit [Remote host closed the connection]
<dpt89>
I saw purescript and it has similar benefir to OCaml, but I really don't want any more JS
Algebr has joined #reasonml
<dpt89>
we have to use it because the browser has it, but I want to see if OCaml could replace our Ruby microservices in a nice way, so the dependencies do make sense even if I have to use Batteries while learning
<chenglou>
dpt89: my jengaroot does compile to native if that's what you were saying
<chenglou>
it just also compiles to js as an extra
<dpt89>
OK. I think I'm confused
<dpt89>
but if I have 0 deps then rebuild should work, right?
<dpt89>
I don't understand why I need jengaroot
<dpt89>
sorry if it's hard to explain things to me since I don't know anything about Ocaml.
<dpt89>
maybe it's obvious once I have used it.
<dpt89>
I really like Reason a lot
<chenglou>
no problem. If you have 0 deps then yes, rebuild works
<dpt89>
but it seems I should stick to OCaml for the time being
<chenglou>
so does jengaroot of course. Now if you have deps, and they come from opam, then stick with rebuild
<dpt89>
because I don't even know wha to ask or what challenges you are solving in the meantime, so I cannot understand most of your work and contributions for now I think
<chenglou>
dpt89: Reason, currently, is a new syntax on top of ocaml. All your existing tooling should work (beside adding a few extra compiler flags)
<chenglou>
it's not a compiled-to-ocaml thing
<dpt89>
do you know a link with batteries examples?
<dpt89>
I cannot even find an example in OCaml that I can compile
<dpt89>
I found BatIO and I see there something related to stdin
<dpt89>
but what do I need to put in `open...`?
<dpt89>
I had no luck googling something with batteries
<chenglou>
here's a bare minimum, no build system, no nothing else beside batteries, file
<chenglou>
no rebuild either. The very basic ocamlfind command to allow you to include batteries
<chenglou>
dpt89: tell me if that works
<dpt89>
it does!
<dpt89>
let me check if I can make my small script work with that example
<chenglou>
ok cool, so here are a few explanations
<chenglou>
first of all, your packages are installed with opam, and ocamlc by itself doesn't know where it resides
<chenglou>
they*
<chenglou>
ocamlfind is a command that wraps around ocamlc, that passes on most of the flags you see in that build.sh onto ocamlc
<chenglou>
except, for example, -package
<chenglou>
after which you pass the package and -linkpkg to find and link batteries (ocamlfind translates that into a bunch of configs then finally invokes ocamlc)
<chenglou>
you could ditch ocamlfind and use ocamlc by yourself, but then you'd need to know where batteries is installed, etc.
<dpt89>
I see
<chenglou>
is that clear so far
<dpt89>
yes, all clear. What do these flags do `-pp refmt -impl`?
<dpt89>
-pp is preprocessor I suppose?
<chenglou>
`-pp refmt -impl` is the reason part
<chenglou>
yes
<dpt89>
it calls rfmt on my path?
<dpt89>
or is it doing some other resolution?
<chenglou>
which says, instead of using the ocaml tokenizer & parser, use an alternative one
<chenglou>
in this case refmt is globally installed for you
<chenglou>
it is the reason tokenizer & parser
<dpt89>
I see, what does -impl do?
<chenglou>
-impl, as well as -intf, -intf-suffix (you don't have to worry about the letters for now), tell ocaml what source file it is
<chenglou>
tell `ocamlc`* I mean
<dpt89>
I see
<chenglou>
usually it sees that you've passed index.ml
<chenglou>
which it knows is an ocaml file
<chenglou>
but reason files have the extension .re
<chenglou>
so you pass an explicit flag saying "this index.re is the implementation file, aka your common source file"
<dpt89>
All clear
<chenglou>
(likewise `-intf` for .rei interface files)
<dpt89>
how would I import other files? For instance can I split the program in multiple files?
<dpt89>
I saw those in the example repo, what are those for?
<dpt89>
the .rei files I mean
<chenglou>
these are the interface files. `.rei` is to `.mli` what `.re` is to `.ml`
<chenglou>
in ocaml, you can optionally expose an "interface file" that contains type definitions
<chenglou>
like typescript TSC if I'm not mistaken, and flow
<chenglou>
during compilation of index.re, most of the time, when an index.rei can't be found, ocamlc will assume everything in your index.re is public
<chenglou>
and implicitly generate an index.rei which is just all the type definitions of your declarations in index.re
<dpt89>
ok, so I would use .rei to handle the scope of the parts of the code?
<chenglou>
you can write that index.rei yourself, exposing what you want, etc. That file is also what ocamldoc takes to generate these doc files you have been reading
<chenglou>
like javadocs
<chenglou>
except, instead of being inline, they're in a separate file
<dpt89>
but they're typechecked as well? If I write something in .rei that doesn't match the implementation in .re it'll catch it?
<chenglou>
right
<dpt89>
I like that, I've never been a big fan of inline docs.
<dpt89>
finally, can split things in multiple file with the manual ocamlfind example you sent?
<chenglou>
I'm ambivalent toward a separate interface file. It could be nice if you think of it as a markdown equivalent to docs
<chenglou>
where, if you don't have the rich HTML file generated, you can still read through the docs by reading .reis
<chenglou>
yeah sec
<dpt89>
yes, I see the point. But sometime inline docs just hide the real code amidst lots of comments, so it's harder to follow after your initial impression. Like inline docs are easy for me the first time I found them and totally annoy me as I read the file more times
<chenglou>
btw ocaml does allow inline signature too, so you can have both
<dpt89>
Oh, so I can either use interface files or put that inline?
<chenglou>
yeah
<chenglou>
sorry 1 sec, fixing something on my side
<chenglou>
if there's an error you don't understand, file that as an issue in BetterErrors please
<chenglou>
every confusing error is a bug
<dpt89>
lol, nice approach
<dpt89>
well, I'll take a couple days. OCaml is haaaard. Not so much for the lang, but the tooling and minor details, etc.
<chenglou>
using regex to parse english, hah
<dpt89>
why is there ocamlc and ocamlbuild? what's the difference?
<chenglou>
dpt89: and this is exactly what reason's trying to solve. Starting with the syntax
<dpt89>
that's what I thought. If the project makes it as simple as rust or go regarding tooling, and the syntax is as nie
<chenglou>
for newcomers who don't know ocaml at all this might be slightly confusing because "what's ocaml? What does reason do to it?"
<dpt89>
that's a dream come true
<chenglou>
it's a layer of abstraction that starts with syntax, yes
<chenglou>
but that also includes editor tooling (try our atom/vim/emacs integration... they're pretty sweet)
<chenglou>
better error reporting
<dpt89>
but the building, dependencies, etc. should be simplified later in the process as well? or is it out of scope?
<chenglou>
and better defaults for building
<chenglou>
definitely inside the scope
<dpt89>
great
<chenglou>
and being worked on
<chenglou>
with the jengaroot and all
<dpt89>
like, I'm still confused about opam
<dpt89>
is it like a global dependency installer? Can I have multiple version of a package installed? how does a single folder indicate what version to use?
<chenglou>
ocamlbuild is a build system that uses ocamlc. ocamlc is literally a compiling command
<chenglou>
ocamlbuild takes care of e.g. that dependency ordering for you
<dpt89>
I see, I thought they were competing tools.
<chenglou>
so that when you add new files and change the requires you don't go manually modify some ocamlc build commands
<dpt89>
they are just at different levels in the toolset
<chenglou>
right. You can't replace ocamlc. It's the compiler lol
<chenglou>
again, something we're working on polishing
<chenglou>
what about opam?
<dpt89>
opam installs globally, like apt does?
<dpt89>
or I can have per project dependencies that opam will resolve?
<dpt89>
I mean, is there something like package.json equivalent with opam?
<chenglou>
yes, an opam local swithc
<chenglou>
local switch*
<chenglou>
and tbh I don't know how to use it lol
<dpt89>
I see
<chenglou>
opam installs "globally" in the sense that it's one flat list I guess
<dpt89>
and in the whole Batteries vs Core is there some consensus? will reason have an opinion in this front?
<chenglou>
but it's really somewhat sandboxed by default. You might recall using `opam switch bla` at one point
<chenglou>
that creates a new sandbox
<chenglou>
but granularity, by default, isn't at your library level
<dpt89>
OK, it seems like reason is trying to solve many parts indeed. The standard library thing was the only one I saw being an outsider of the community
<chenglou>
as for stdlib, we're also checking our options. But Batteries, Core and Container are the ones people use
<dpt89>
I was very skeptical about this division, I don't understand how that plays in real life
<dpt89>
or if I should be very concerned about what club to join
<dpt89>
Jane Street being so visible about the language seems to move everything into the Core side, but I don't know anything else about the others
<chenglou>
dpt89: the default stdlib is minimal (overly so imo)
<chenglou>
I've used both Core and Batteries
<chenglou>
I'd say, since you're just trying out a few things right now, don't worry about it
<chenglou>
the conversion isn't hard anyway
<chenglou>
plus, you have the type system's help while you do it =)
<dpt89>
OK, nice
<dpt89>
ohh...the type system, I've been dreaming about the benefits for months now
<chenglou>
oooor, if you want to, you can also do like me and try both in the future, and voice your opinion when we decide on one
<dpt89>
we only have ruby on the back and I was in need of something viable. No one seems to learn haskell within a year, Rust is too complex, swift still raw...
<dpt89>
OK, cool. Thanks for all the help and openess
<chenglou>
np!
<chenglou>
also, speed
<chenglou>
you'll love it, lol
<dpt89>
I totally needed your help @chenglow
<dpt89>
*chenglou
<dpt89>
regarding speed
<chenglou>
my jengaroot builds faster than npm starts
<chenglou>
...
<dpt89>
How do you handle the lack of multicore?
<chenglou>
it's coming
<dpt89>
just deploying mulitple processes of the same app?
<chenglou>
in ocaml, in the future
<dpt89>
I mean today
<dpt89>
for instance multiple processes with a load balancer?
<dpt89>
I mean for real world deployments
<chenglou>
Multiple processes yes, on one host will work well.
<dpt89>
if it handles FB scale it works, I just don't know how or maybe it's irrelevant and a single process takes you far enough, I haven't tried
<chenglou>
Most people do message passing between processes.
<chenglou>
There's upcoming multicore work as well actively being worked on.
<dpt89>
yes, I saw that
<dpt89>
but is it reasonsable to see that released within a year?
<dpt89>
or is it like a very long endeavor?
<chenglou>
honestly? I don't know
<chenglou>
I don't think it's THAT long
<dpt89>
e.g. no body know about ruby 3
<chenglou>
within a year, maybe not
<dpt89>
OK, it's not that important any way
<chenglou>
taking into consideration that the community also needs to move toward that
<dpt89>
not building a game or image processing...
copy` has quit [Quit: Connection closed for inactivity]
<chenglou>
The upcoming multicore work allows *shared memory* parallelism within a single process.
<chenglou>
That's being worked on by OCamlLabs, KC in particular at the moment.
<dpt89>
OK
<dpt89>
before I go
<dpt89>
any good tutorials for Ocaml?
<dpt89>
I'm only reading Real World OCaml online
<dpt89>
but it doesn't talk much about the tooling
<chenglou>
that book is great. A great CS book in general
<dpt89>
OK, so I'll keep with it
<dpt89>
I was jsut checking in case there was something else I wasn't aware of
<chenglou>
nope. Stick with the book
<dpt89>
will do
<dpt89>
thanks again for the help @chenglou
<dpt89>
I really needed it
<chenglou>
any time! =)
<dpt89>
I'll try to stick around, I've also been proving some feedback on Reason via twitter
<chenglou>
cool, thanks
<dpt89>
good night! best of lucks and thank you so much for the work, I was totally missing something liek ReasonML
bsansouci has quit [Quit: Connection closed for inactivity]
iwan_ has quit [Ping timeout: 250 seconds]
pierpa has joined #reasonml
iwan_ has joined #reasonml
<iwan_>
How do you invoke default args in Reason?
<iwan_>
Example: `let add a::a b::b=0 => a + b;`
<iwan_>
Is this the right declaration?
<iwan_>
Can I set b to 0 when the user doesn't supply it
<iwan_>
?
<Khady>
yes you can, but I don't know the syntax for it
<iwan_>
Found the solution
<iwan_>
let add b::b=3 a::a => a + b;
<iwan_>
let y = add b::?None a::5;
<iwan_>
gives your y=8
<reynir>
looks weird
<iwan_>
it works though
<iwan_>
The fun thing about this syntax, is that optional arguments have to come first, otherwise the Compiler infers it as a partially applied function
copy` has joined #reasonml
iwan_ has quit [Ping timeout: 250 seconds]
spion has joined #reasonml
dakk has quit [Remote host closed the connection]
dakk has joined #reasonml
kassens has joined #reasonml
iwan_ has joined #reasonml
<iwan_>
How do you expose the type of the following: `let int_bumper: (module Bumpable) = (module Int_Bumper);`
<iwan_>
in OCaml you can write something like `let int_bumper = (module Int_bumper : Bumpable with type t = int);
yunxing has joined #reasonml
yunxing has quit [Remote host closed the connection]
yunxing has joined #reasonml
<iwan_>
Hmm`let int_bumper: (module Bumpable with type t = int) = (module Int_Bumper);` gets reformatted to `type t =int` (no spaces between = and int)
yunxing has quit [Ping timeout: 258 seconds]
kassens has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
iwan_ has quit [Quit: Page closed]
Guest24092 has joined #reasonml
jonasen has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bsansouci has joined #reasonml
kassens has joined #reasonml
Guest24092 is now known as Algebr
Algebr has quit [Read error: Connection reset by peer]
Algebr has joined #reasonml
bsansouci has quit [Quit: Connection closed for inactivity]