dakk_ has quit [Remote host closed the connection]
hdon has joined #ocaml
dakk_ has joined #ocaml
dakk_ has quit [Remote host closed the connection]
dakk_ has joined #ocaml
dakk_ has quit [Remote host closed the connection]
sh0t has joined #ocaml
hdon has quit [Ping timeout: 256 seconds]
jmiven has quit [Quit: co'o]
jmiven has joined #ocaml
pierpal has quit [Ping timeout: 245 seconds]
sz0 has quit [Quit: Connection closed for inactivity]
sh0t has quit [Remote host closed the connection]
sh0t has joined #ocaml
pierpal has joined #ocaml
sh0t has quit [Remote host closed the connection]
sh0t has joined #ocaml
barcabuona has joined #ocaml
pierpal has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #ocaml
dhil_ has joined #ocaml
<Ankhers>
I have just started going through the beta of Real World OCaml. I am trying to follow along with the examples in "OCaml as a Calculator". The first thing it does it "open Base;;". When I do that I get an unbound module error. I have already `opam install base`. Do I need to do something else to tell utop where to find opam installed modules?
<companion_cube>
`#require "base";;` if you're in utop
<Ankhers>
Thank you!
shinnya has joined #ocaml
sh0t has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
<freyr>
ok, I have a GADT which includes a first-class module
<freyr>
type (_,_) compose = (::) : (string * (module Convert with type t = 'a)) * ('b, 'c) compose -> ('a -> 'b, 'c) compose
<freyr>
which works just fine, til I start using functors
<freyr>
The type constructor Query.List(Query.String).t would escape its scope
<freyr>
Is there any workaround to deal with such things?
<freyr>
Does it mean that it is impossible to use functors in such case?
<Drup>
"ok, I have a GADT which includes a first-class module" My condolences.
<freyr>
Is it a bad idea?
<octachron>
freyr, "module List (E : Convert) : Convert" is the wrong type, you are making the type t abstract
<thizanne>
freyr | Is it a bad idea?
<thizanne>
that's actually two bad ideas.
<Enjolras>
Drup: could be worse, the GADT could be parametrized by an object type
<Drup>
Enjolras: I object!
<freyr>
I thought about objects
<Enjolras>
as long as you do itr with class, that's fine
FreeBirdLjj has joined #ocaml
<Drup>
(actually, you are right, even if I've done it at least twice)
<octachron>
freyr, another point is that with your current use cases, you could have a simple parametric record type with no loss of features
<freyr>
thizanne: could you elaborate?
<freyr>
octachron: you mean record with two methods instead of a module?
<freyr>
but not object/class?
<octachron>
yes, your module signature is equivalent to `type 'a t = { of_string:string ->'a; to_string:'a -> string }` at the type level
<Drup>
freyr: Do you check all the following cases: 1) You need subtyping 2) You need type abstraction 3) Are you really really sure ?
<Drup>
If you do not check all of them, you should use records or variants :p
pierpal has joined #ocaml
<octachron>
and since first-class modules of type (module Convert) are useless, there is little point to use first-class modules here
<freyr>
octachron: Besides, modules are predefined mostly
<freyr>
but I'll stick to records in this case, thanks alot
<octachron>
Drup, you should add that if you start having things like "sig type t val self:t val method_m: t -> int end", it is time to look at objects
sh0t has joined #ocaml
<Drup>
Ah, yes, that as well
<Drup>
I actually made that exact change for functoria/mirage. people looked at me funny
<Drup>
freyr: are you trying to make a typed sql abstraction ?
FreeBirdLjj has quit [Remote host closed the connection]
<freyr>
Drup: Nope, I'm trying to make a types rest abstraction
wklm has left #ocaml [#ocaml]
<Drup>
Ah, yes, so furl basically
<freyr>
Since we have a lot of time representations
<freyr>
and other custom types
shinnya has quit [Ping timeout: 268 seconds]
<freyr>
you haven't publish it, have you?
<Drup>
I haven't, I'm unhappy with the API and didn't got time to make it better
xaimus has joined #ocaml
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #ocaml
<freyr>
Atoms in furl are tyre regexps basically?
<Drup>
yes
<Drup>
that's the most flexible you can get while maintaining perfs, and you can add abstraction on top of it to make the API easier to digest
<Drup>
@ncthbrt is working on something related as well
<freyr>
And it works in both directions, for serialization too?
<Drup>
my version does
<Drup>
it works for matching, creating urls and routing
<freyr>
Oh, I see, Tyre.eval
<freyr>
I'll check it later on
<freyr>
Shame so many cool libs are not published in opam
<Drup>
there is a good reason furl is not published, it's a prototype, it's not usable
<discord3>
<hcarty> ZirconiumX: All in my experience - |> is most useful when there would be a lot of ( ... ) nesting and the steps read well sequentially. I find @@ to be less generally useful.
<discord3>
<hcarty> sin x reads more clearly than x |> sin, but read myinput |> process_input |> archive_result reads more clearly (to me at least!) than archive_result (process_input (read myinput))
<discord3>
<hcarty> No problem re: typos 😃
<ZirconiumX>
So |> can be viewed sort of as a unix pipe?
<ZirconiumX>
As in, you'd use it kinda where you'd use pipes in shell
<discord3>
<hcarty> Indeed
<ZirconiumX>
That's very helpful, thanks!
<discord3>
<hcarty> Sure thing! This should be in a FAQ somewhere, where it can get appropriately argued and bikeshed'd
<discord3>
<Bluddy> I use both |> and @@ liberally. I find them both to be useful.
<ZirconiumX>
It just kinda throws me, since OCaml is the first functional programming language I've ever used, and I'm still getting used to its idioms
Bronsa has quit [Ping timeout: 260 seconds]
<Drup>
The usage of @@ vs |> kinda depends on the style of the author (I use @@ more often in general .... except when I'm writing things that are linear long-ish pipelines, then I use |> over multiple lines)
Haudegen has joined #ocaml
barcabuona has quit [Ping timeout: 260 seconds]
hdon has joined #ocaml
<spew>
I never use @@
barcabuona has joined #ocaml
<spew>
in any situation where I would use @@ I just always use |>
kakadu has quit [Quit: Konversation terminated!]
pierpal has quit [Read error: Connection reset by peer]
<philtor>
ZirconiumX: In most deep learning contexts when you're doing inference all you need is a 16bit float
<philtor>
This makes things nice for vector processing
<philtor>
on GPUs for example
<philtor>
Of course, not entirely sure what the OCaml GPU programming story is like at this point
<philtor>
Maybe Owl has something?
sh0t has quit [Remote host closed the connection]
hdon has quit [Ping timeout: 240 seconds]
<discord3>
<Bluddy> Owl is the project to watch or contribute to
<discord3>
<Bluddy> Right now they're not doing GPUs fully yet
barcabuona has quit [Ping timeout: 256 seconds]
jao has joined #ocaml
<philtor>
Yeah, looks like they plan to do it through OpenCL
<philtor>
Not having a GPU option really limits OWL/OCaml's usefulness in this space
<philtor>
which is why I'm looking at Julia for this kind of thing
hdon has joined #ocaml
barcabuona has joined #ocaml
<discord3>
<Perry> I saw someone ask about 16 bit floats earlier. They're frequently used in computer graphics and other applications where performance needs trump accuracy needs. The x86 supports half floats in its various vector units.
pierpal has joined #ocaml
<discord3>
<Perry> One of the keys to optimizing floating point intensive code is picking the right precision etc. I've seen applications go far faster because someone moved from double to single precision for a few calculations where the precision wasn't needed.
dhil_ has joined #ocaml
tarptaeya has quit [Quit: Konversation terminated!]
pierpal has quit [Remote host closed the connection]
moei has joined #ocaml
dhil_ has quit [Ping timeout: 264 seconds]
<philtor>
Yeah, not a lot of languages give you that level of choice in precision. C/C++, Julia... not sure of any others.
<philtor>
Possibly Rust
steenuil has quit [Remote host closed the connection]
<discord3>
<Perry> Nothing in OCaml prevents it from allowing that degree of choice, it just isn't there.
kakadu has joined #ocaml
<discord3>
<Perry> It might be someday.
VermillionAzure has joined #ocaml
kakadu_ has joined #ocaml
kakadu has quit [Ping timeout: 276 seconds]
malina has joined #ocaml
heasummn has joined #ocaml
<heasummn>
I have a small design question. I'm writing a compiler, in the parsing stage, I only know about the location of each AST node. so I've got a record that looks like {data: expr_type; location: loc_type}
<heasummn>
I want to convert this into an AST node that also has type data
<heasummn>
at the moment, I'm creating a new record that has the added type data and creating a compiler pass that converts them
<heasummn>
this is slow and annoying and just seems wrong
<heasummn>
I feel records aren't the best thing to be used here. For instance, in C++, I would be representing AST nodes as classes, and to add type data, I would just implement a `type` function in each class
<heasummn>
what do you guys think I should use to represent my AST nodes?
<ZirconiumX>
I won't claim to be a top camler, but isn't this exactly what sum types are for?
<ZirconiumX>
Hell, I won't even claim to be a good camler
<ZirconiumX>
heasummn: ^
<heasummn>
I'm not a great camler either, the language is really nice to use though
<heasummn>
let me take a look
<VermillionAzure>
heasummn: You can't just create a generic type constructor for the new type-augmented structure?
<heasummn>
what do you mean by generic type constructor?
<VermillionAzure>
generic is probably the wrong word
<heasummn>
ZirconiumX, if I use variants, I will have to handle the typed AST in places where I don't need to deal with it, such as in the AST
<heasummn>
in the parsing*
<VermillionAzure>
but something like `annotate: (expr -> type_data -> typed_expr)
<VermillionAzure>
or something?
<heasummn>
that's what I'm doing right now
<heasummn>
but that's messy imo
<VermillionAzure>
What's the alternative?
<heasummn>
that's what I came here to ask for
<VermillionAzure>
You need to do a data transform, so you'll have to do a type transform
<heasummn>
I don't know of any better way
<VermillionAzure>
unless you instead make the data type more dynamic
<VermillionAzure>
e.g. using a dictionary or map for data bindings
<heasummn>
I'm going to look at some professional compilers and see how they do it
<ZirconiumX>
heasummn: Isn't the point of parsing to generate an AST? How do you generate an AST without handling AST?
<heasummn>
I meant handling parsing, that was a typo
<heasummn>
the parsing segment of my code doesn't care about the types. I don't want to burden it by having to handle them there
<heasummn>
and I would still need a method to convert between them, wouldn't I?
<heasummn>
If I used sum types
<ZirconiumX>
Why does your AST have to care about types?
<ZirconiumX>
The first stage of an AST is ordering lexer tokens into a tree, no?
<heasummn>
yeah
<ZirconiumX>
Lexer tokens don't have types
<heasummn>
at this point I guess it's not an AST at all
larhat has joined #ocaml
<heasummn>
I'm just comfortable with, for instance in a compiler written in C++. The AST is the source of all info, and as the compiler progresses you add information like locations and types to it
<ZirconiumX>
Well, a compiler is at heart a function that takes source code in and dumps executable code out
<ZirconiumX>
And it's a series of transforms
<ZirconiumX>
So, just create a new AST
<heasummn>
That is what I'm doing, it just feels a bit messy. I guess it's the cleanest way
<ZirconiumX>
Is it heresy if I mention the MLton internals wiki in #ocaml?
<VermillionAzure>
heasummn: The AST is not though
<VermillionAzure>
You also have symbol tables and unification restraint sets
<heasummn>
well yes, but the AST stores most of the info. That was a bit hyperbolized
<heasummn>
to give an imperative example, I'd have a node, say Add(expr1, expr2). This has methods such as type, codegen, location, etc.
<heasummn>
during the parsing stage, `type` would be null. It would be given a value once the semantic analysis happens
<heasummn>
although
<heasummn>
I guess it's a bit stricter in OCaml so that I know what information is available to each stage due to the type of syntax tree I'm dealing with
<heasummn>
if that makes sense
<ZirconiumX>
Then have the type field be an option type or something, and update it as you go
roygbiv has joined #ocaml
<VermillionAzure>
ZirconiumX: I agree
<ZirconiumX>
Or alternative have a "type not yet known" variant
<heasummn>
that does seem like a better way to do it
<heasummn>
atm, I've got two different types. I use polymorphism to keep the code for them minimal. I've got `ast` and `typed_ast`
<ZirconiumX>
Yup
<heasummn>
and then I've got a method that converts the ast to a typed_ast
<heasummn>
and this is what does all of the type analysis
<ZirconiumX>
Yeah, that sounds reasonable
<heasummn>
I guess that isn't too ugkly
<heasummn>
let me refactor the code because there's a lot of repetition
<heasummn>
okay
<ZirconiumX>
Essentially your AST traversal is naturally recursive anyway
<heasummn>
I guess I just needed to justify having two different types, or find a better solution
hdon has quit [Changing host]
hdon has joined #ocaml
<VermillionAzure>
It sounds like you don't need 2 tyeps
<ZirconiumX>
I would probably keep the two different types, honestly
<ZirconiumX>
For the sake of type safety
<heasummn>
yeah
<ZirconiumX>
YMMV, of course
<heasummn>
thanks!
<VermillionAzure>
heasummn: So do you want the easy fix or the correctness fix?
<heasummn>
correctness fix, but I think I've reasoned out that I don't really need a fix
<ZirconiumX>
So, to answer your original question: just use sum types, because that's what they're there for.
<ZirconiumX>
Compilers are very functional programs, if you want to look at it that way
<VermillionAzure>
ZirconiumX: Until you make them programmable too! <3
<ZirconiumX>
A lexer for things is a function from strings to lists of pairs of things and strings.
<ZirconiumX>
VermillionAzure: That or Futamura comes along to say hello
<VermillionAzure>
What if we wanted to do Futamura in the compiler by programming the compiler to program itself to program itself to do that?!
<ZirconiumX>
Then you'd need plenty of aspirin
Muzer has left #ocaml ["Leaving"]
<VermillionAzure>
ouch
<ZirconiumX>
Anyway, heasummn, happy to help
<VermillionAzure>
btw
<VermillionAzure>
Wikipedia is recruiting CS editors
<ZirconiumX>
Nobody appreciated the rhyme? For shame.
Denommus has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
<DrWhax>
57
<VermillionAzure>
42?
FreeBirdLjj has quit [Ping timeout: 260 seconds]
heasummn has left #ocaml ["Leaving"]
steenuil has joined #ocaml
neatonk has quit [Ping timeout: 268 seconds]
Denommus has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<DrWhax>
VermillionAzure: indeed
tane has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
kakadu_ has quit [Remote host closed the connection]
argent_smith has quit [Quit: Leaving.]
pierpal has joined #ocaml
navaja has joined #ocaml
pierpa has joined #ocaml
navaja has quit [Ping timeout: 248 seconds]
shw has joined #ocaml
gtrak has quit [Ping timeout: 260 seconds]
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
cbot has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
shinnya has joined #ocaml
exarkun has quit [Read error: Connection reset by peer]
Haudegen has joined #ocaml
exarkun has joined #ocaml
roygbiv has quit [Quit: ™]
navaja has joined #ocaml
spew has quit [Disconnected by services]
navaja is now known as spew
hdon has quit [Ping timeout: 264 seconds]
VermillionAzure has quit [Ping timeout: 240 seconds]