<gasche>
everybody discovering the tool has fun with them for a few minutes, hours for the youngest
<gasche>
and then we're past them, fortunately
eikke has joined #ocaml
ygrek has joined #ocaml
ggole_ has joined #ocaml
sjohnson has left #ocaml []
<orbitz>
gasche: Not me, I make a Coq joke every chance I get :)
ggole has quit [Ping timeout: 252 seconds]
ontologiae has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
<yezariaely>
orbitz: do you have a good one at hand? ;-)
<orbitz>
I don't know if you could handle the whole thing
Yoric has quit [Ping timeout: 260 seconds]
Fnar has quit [Quit: Client exiting]
Neros has joined #ocaml
osnr has quit [Quit: Leaving.]
hkBst has joined #ocaml
hkBst has quit [Changing host]
hkBst has joined #ocaml
eikke has quit [Ping timeout: 248 seconds]
cago1 has joined #ocaml
ontologiae has joined #ocaml
talzeus has quit [Remote host closed the connection]
cago has quit [Ping timeout: 252 seconds]
talzeus has joined #ocaml
jbrown has joined #ocaml
raichoo has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
eikke has joined #ocaml
BlankVerse has joined #ocaml
<BlankVerse>
is it possile to get autocompletion in ocaml interprete
<BlankVerse>
r
<sgnb>
BlankVerse: there are alternative toplevels such as lwt-toplevel (in lwt) or utop that do that
eikke has quit [Ping timeout: 245 seconds]
<BlankVerse>
sgnb: thanks , i am using the standard interpreter ocaml, open Str;; Str.quote "abc";; gives me error "Error: Reference to undefined global `Str'
<BlankVerse>
am i using open wrong?
<ygrek>
rlwrap -t dumb -r -m -c ocaml
<rks>
BlankVerse: you need to load the lib before you can open it
Vinnipeg has joined #ocaml
<rks>
BlankVerse: # #load "str.cma";;
<rks>
# Str.quote "abc";;
<rks>
- : string = "abc"
<rks>
(and, if you « open Str » you can just use « quote » directly, no need to prefix it with « Str. »)
<BlankVerse>
thanks :)
eikke has joined #ocaml
Vinnipeg has quit [Remote host closed the connection]
Vinnipeg has joined #ocaml
Vinnipeg has quit [Client Quit]
stomp has quit [Ping timeout: 264 seconds]
stomp has joined #ocaml
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
osnr has quit [Ping timeout: 256 seconds]
cago1 has quit [Ping timeout: 248 seconds]
mcclurmc has quit [Ping timeout: 248 seconds]
troydm has joined #ocaml
Yoric has joined #ocaml
cago has joined #ocaml
eikke has quit [Ping timeout: 240 seconds]
talzeus has quit [Remote host closed the connection]
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
talzeus has joined #ocaml
osnr has quit [Ping timeout: 240 seconds]
eikke has joined #ocaml
beckerb has joined #ocaml
mcclurmc has joined #ocaml
zpe has quit [Remote host closed the connection]
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
jonafan has quit [Ping timeout: 252 seconds]
Neros has quit [Ping timeout: 256 seconds]
osnr has quit [Ping timeout: 252 seconds]
dsheets has joined #ocaml
jonafan has joined #ocaml
Drup has joined #ocaml
thomasga has joined #ocaml
q66 has joined #ocaml
<ousado>
in -ppx extension points, is there any way to interact with the typer?
<ousado>
as in: build an expression, send it to the typer, check whether it unifies with another type?
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
<ousado>
I wouldn't care if I could do this by jumping through a few hoops, by the way, it doesn't have to be supported via a nice API that exists for exactly that purpose.
darkf_ has joined #ocaml
ulfdoz has joined #ocaml
darkf has quit [Ping timeout: 246 seconds]
osnr has quit [Ping timeout: 245 seconds]
Neros has joined #ocaml
Drup has quit [Ping timeout: 248 seconds]
darkf_ is now known as darkf
yacks has quit [Ping timeout: 260 seconds]
_andre has joined #ocaml
yacks has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 252 seconds]
hkBst has quit [Remote host closed the connection]
hkBst has joined #ocaml
hkBst has quit [Ping timeout: 252 seconds]
ollehar has joined #ocaml
Fnar has joined #ocaml
talzeus has quit [Remote host closed the connection]
Drup has joined #ocaml
ygrek has quit [Ping timeout: 248 seconds]
zpe has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
hkBst has joined #ocaml
Neros has quit [Ping timeout: 240 seconds]
hkBst has quit [Ping timeout: 248 seconds]
hkBst has joined #ocaml
eikke has quit [Ping timeout: 252 seconds]
eikke has joined #ocaml
raichoo has quit [Read error: Operation timed out]
ulfdoz has quit [Read error: Operation timed out]
raichoo has joined #ocaml
raichoo has quit [Ping timeout: 252 seconds]
raichoo has joined #ocaml
Kakadu has quit []
Kakadu has joined #ocaml
Neros has joined #ocaml
Neros has quit [Ping timeout: 245 seconds]
hkBst has quit [Read error: Connection reset by peer]
hkBst has joined #ocaml
oriba has joined #ocaml
ollehar has quit [Ping timeout: 240 seconds]
hkBst has quit [Remote host closed the connection]
hkBst has joined #ocaml
hkBst has quit [Changing host]
hkBst has joined #ocaml
hkBst has quit [Ping timeout: 256 seconds]
<ousado>
looks like merlin has implemented that
<gasche>
you can do that already with compiler-libs
<gasche>
in all fairness, this is an aspect hongboz enmphasized
talzeus has joined #ocaml
<ousado>
gasche: is that documented somewhere?
mye has joined #ocaml
<gasche>
ousado: I don't think it is
<gasche>
nobody wants to encourage people to call the type-checker from their own program; it was not designed for this and the interface is meh
<ousado>
well, this is from within the compiler
<gasche>
I think at some point people considered adding a -ppx-like feature at the typedtree level: letting people add filters from typedtree from typedtree
<gasche>
but the typedtree itself was not designed as a clean intermediate language for program manipulation, rather for type inference
<flux>
I think a world with type-directed language extensions is going to be a lot different :-o
<gasche>
so I don't expect this to be comfortable
<flux>
for example, you could probably implement type-based overloading
<ousado>
flux: exactly, I do that in haxe all the time
<gasche>
Fabrice Le Fessant had some design for it
<flux>
and interfaces for interacting with dynamic types that doesn't involve explicit constructor/function calls
<gasche>
I'm personally dubitative this is a good idea unless people do the work of having a typed representation that is actually nice and safe to manipulate
<ousado>
I don't care for the interface if it's possible at all, to be honest
<gasche>
Alain Frisch has been working on the Parstree to make it better to manipulate, and that's an important amount of work
<gasche>
the typedtree would be much harder, I think
Drup has quit [Quit: Leaving.]
<ousado>
I'm not sure how much of the actual typedtree I'd need
<pippijn>
helper functions and simple syntax extensions can probably make the typedtree a lot more comfortable
<ousado>
so I'll just look into compiler-libs and see whether I can find suitable interfaces, I guess?
<gasche>
ousado: what are you trying to do?
<ousado>
gasche: I'm considering a rewrite of (quite some) haxe code in ocaml
Drup1 has joined #ocaml
<gasche>
do you mind talking about the reasons for that change?
<ousado>
gasche: why ocaml istead of haxe?
<gasche>
(I have a good opinion of Haxe, despite having never used it, out of respect for Nicolas Cannasse)
<gasche>
yes
<gasche>
I'm also interested (and it's more on topic) on what extension you have in mind, to facilitate that change, that needs typing information
<ousado>
well, first, haxe is great, no doubt about and so much for that.
<ousado>
but it also has some shortcomings
<ousado>
standard library, not much emphasis on functional programming, libraries
<ousado>
nothing a great dedicated community couldn't change, though
<gasche>
looks a bit like OCaml's issues :-'
<ousado>
well, there's no janestreets core for haxe
<ousado>
but when I look at ocaml, the sophistication, the community, the individuals using it, for what *kinds* of projects - well, there's just much more I can learn here
smondet has joined #ocaml
<ousado>
when I read through ocamllabs project list it's about the future
<ousado>
haxe is mostly used for games.
<ousado>
I'm not planning a full migration, btw, I want to make the essential parts interoperable
hcarty has joined #ocaml
<gasche>
ousado: so what about this extension that needs the type-checker?
<ousado>
about which extension(s) I have in mind, there's quite a few, I'm using type-driven code generation throughout my projects, which meansfor everything database <-> application server <-> client-side
<ousado>
type-safe (de)serialization, generation of the database code, communication, mapping from types to UI-interfaces
<ousado>
(back in a few)
<gasche>
have you had a look at ocaml-ty?
<gasche>
(or type-conv for that matter)
<Drup1>
most of the syntax extension that use type I know of are using the syntactic representation of the type. Can't you use this for the part that generate the db from the type ?
<Drup1>
\nick Drup
<gasche>
Lexifi made relatively large changes to the language to facilitate this kind of things
<orbitz>
they encodethe type in their bytcode right?
<Drup1>
the other way is to wait a bit and use runtime type :D
Drup1 is now known as Drup
<gasche>
runtime types, as a technique coming from Lexifi
<Drup>
gasche: ocaml-rtt is independent from ocaml-ty, isn't it ?
<gasche>
yes, it's something different
ttamttam has quit [Ping timeout: 256 seconds]
osnr has joined #ocaml
<ousado>
there's no way I'm going to use runtime types
<ousado>
also I'm compiling parts of this to other languages
<gasche>
why not?
<ousado>
well, why pay at runtime for something I can specialize for at compile-time?
osnr has quit [Ping timeout: 245 seconds]
<gasche>
because that makes the whole software stack simpler, and maybe the costs are not actually a problem for the kind of usage you have
<gasche>
(but maybe they are)
<ousado>
also, I really need the type information, the database uses language-native types
<gasche>
(I would then try to have a look at MetaOCaml; I heard some people are trying to mix it with runtime types, but then the whole software stack is maybe not that simple anymore)
<ousado>
yes, I've looked at metaocaml, I don't understand what they're doing there
<ousado>
that "multi-staged" thing with runtime dynamic code generation
<gasche>
what I don't understand myself is why you "really need the type information", as opposed to what type-conv or deriving are currently doing (ie. generating code from the syntax of the type declaration)
<gasche>
I see there are cases where you may want more, but I can't tell if "language-native types" means something like that
<gasche>
do you have an example?
<Drup>
ousado: maybe you can do an ugly cheat that is done in eliom : you use a syntax extension with a dummy meaning, ask the compiler to type the file generated and then use the type information to do the real generation
<ousado>
Drup: that's an idea
<Drup>
it's completely ugly :/
<gasche>
at this point compiler-libs maybe sounds like a good option :p
<ousado>
hehe
<ousado>
gasche: ok, example: I have some type, defined in the language, somerecords, with some ADTs, some of which have special meaning: they are "database-types" themselves
<Drup>
but I agree with gasche's point about deriving the type from its syntactic representation
<ousado>
now, I need lots of information about thses types, which types depend on which others
<ousado>
to generate code for relations/contraints etc.
<ousado>
if I use the syntactic form I'll basically reimplement the typer
<ousado>
I don't think that's a good idea
<ousado>
it's a very different thing to ask the real compiler which type does field "a" of that type have
<ousado>
or to type it yourself
<ousado>
in many cases it doesn't make a real difference, in others it does
<gasche>
but then how would the OCaml type-checker know which type have a special meaning?
<ousado>
well, that's what the code that invokes the type-checker knows
<gasche>
how does it know?
<Drup>
what kind of relations do you have ? you're modeling nosql if I remember correctly.
<gasche>
it looks like you're looking for user annotations, kept in the type environment
<ousado>
Drup: I'm not modelling anything that has a name, as far as I'm aware
raichoo has quit [Quit: leaving]
<ousado>
gasche: well, in haxe I have some descriptors, that reuse regular haxe-syntax for that
<ousado>
I could use annotations as well
beckerb has quit [Quit: Konversation terminated!]
beckerb has joined #ocaml
<gasche>
ousado: so you have, say
<gasche>
type 'a dont_serialize = 'a
<gasche>
and then you say that (foo dont_serialize) has a special meaning that is recognized by your code generator?
<gasche>
(hm you'd need dont_serialize to be abstract in some way so that the type-checker doesn't remove it right away)
<ousado>
well, I can feed regular haxe classes to a macro, that can interpret it as whatever it likes
<ousado>
s/classes/code
<ousado>
(whatever I want, really)
<gasche>
but how do the code says that this or that type is database-type, do you have an example?
<Drup>
this whole thing sounds a bit like typeclasses.
<ousado>
yes, it's a static-dispatch approach to type-classes, as far as I get them
<ousado>
gasche e.g: class Descriptor { var dbtypes:ALL<A,B,C<D,E>,F,G>; }
tane has joined #ocaml
<Drup>
and how do you have relations and contraints with that ?
<ousado>
that above would just list the types
<ousado>
the constraints are partially derived automatically, but can also be introduced by declaring certain types
<Drup>
you can do this exemple that with type-conv like approach
<ousado>
Drup: well, I also need to be able to check whether applying some function to values of some type result in a type that's contained in some set of types
<gasche>
so you're using this as an annotation, right?
<Drup>
ousado: maybe look at the implementation of this : https://github.com/mirage/orm, this may be close to what you want, eve if I'm not sure what you want exactly :)
<Drup>
even*
<gasche>
I mean, Descriptor is useless as a class, but your macro is giving it a special meaning
<ousado>
well, I want a lot of things, I don't have a single use-case
<ousado>
yes, Descriptor doesn't exist at runtime
<Drup>
does it have to be an ocaml type ? Can't you use a syntax extension as a DSL to describe it ?
<ousado>
I could, but I don't want to
<gasche>
if I understand correctly, ousado wants the convenience of the db-to-language conversions to be implicit because type-directed
<gasche>
more examples of the things you actually do in Haxe would help
<ousado>
(sorry, got a call)
<gasche>
no problem, I'll have to leave soon as well
<gasche>
my gut feeling is that you want a bit too much: you have a precise idea of what the solution must look like, and are not ready to use something more explicit for the benefit of using simpler tools
<ousado>
gasche: I'll try to make a summary of the requirements
<gasche>
but then, I know that sometimes quantitative change (this is a bit more convenient) turn into qualitative change (goes from "not doable in practive" to "doable")
<gasche>
if you posted more concrete examples of the thing you want, detailed enough, people could try to approximate this with simpler techniques, and we could discuss which one actually work or do not
<ousado>
well, there are many nice applications for simply being able to say "these types do not match" programatically
<ousado>
if only for user-friendly error-repoting
<gasche>
I tend to think library design is easier to get right than language design, or even language extension design
<gasche>
there are definitely upsides in staying in library-land rather than extension-land
<gasche>
but I agree that there are also nice things about extension-land
<gasche>
(and a lot of programming language research is about moving stuff from extension-land to library-land)
<ousado>
I often encounter situations in which I think "I could do it this way, but the amount of boilerplate is prohibitive"
<gasche>
maybe you're right, but maybe good abstractions can reduce the boilerplate
<ousado>
often, yes
<ousado>
maybe even always
<ousado>
maybe I'm just not smart enough :)
<gasche>
you've got a point about the error messages in any case
<ousado>
and I think that code generation is very efficient in terms of programming-effort
Neros has joined #ocaml
<gasche>
it can be more problematic for the user, though
<gasche>
you start writing code that will be tweaked by the extensions in ways that are possibly unclear and under-documented
<gasche>
and it becomes more and more like magic, or at least a system you don't understand precisely enough
<gasche>
libraries are a kind of contract between the provider and the user: to use them, you need to know the language
<ousado>
that db-generator, for exampl - it build a database.
<ousado>
if I use mysql or mongo or whatever, it's a black box anyway
<ousado>
unless I read it
<ousado>
and code-generators can produce trivial code
<ousado>
good abstractions tend to be very complicated
mika1 has quit [Quit: Leaving.]
cago has left #ocaml []
<Drup>
ousado: I think that, if they are complicated, they're not "good"
<gasche>
you should write a blog post about the kind of stuff you do right now, asking for advice about how to do similar stuff in OCaml
<gasche>
Drup: but sometimes you can't spend the effort to find the perfect abstraction, because it's very hard
<Drup>
gasche: of course, but a good abstraction is the least complicated abstraction that can express what you want. And that's obviously very hard to come with.
<ousado>
gasche: I'm thinking about writing to the wg-camlp4 list
<gasche>
Drup: that's the *best* abstraction
<gasche>
sometimes you have to aim for good enough
<Drup>
hum, true
<gasche>
ousado: as you wish
<Drup>
gasche: but the goal to be simple remain, that's my point.
<ousado>
hm. I think monads are very good abstractions
<ousado>
and I'd also say that they're not exactly trivial to grok
<Drup>
I really dislikes monads but I feel I'm the only one. :)
oriba has quit [Quit: oriba]
<ousado>
Drup: interesting
<ousado>
but you agree that they capture a wide range of common use-cases, right?
<Drup>
to be more precise, I dislikes monad combinators
<Drup>
monad are great as long as you have only one of them
<Drup>
ousado: I do
<rgrinberg>
Drup: you mean in OCaml right? I also find that your code turns into a sea of local module opens
<Drup>
rgrinberg: no no, in general
<rgrinberg>
Drup: at least it `looks` clean in haskell
<Drup>
you still have to write combinators do have the "order" right
<Drup>
to*
<rgrinberg>
yep, it's not too bad in practice but without tooling it would be impossible to work with which makes me doubt that it's such a good feature
<rgrinberg>
by tooling i mean getting the type at a point
<Drup>
the "order" make sens for some monads (list, option, ...) but not for some other (IO, Lwt ...) and I don't want to have to write combinators for those when this don't make sens. Effects are better suited for this
<Drup>
and my english start to be terrible again, sorry.
<gasche>
Drup: we don't have much better than monad combinators so far if you want to mix explicitly-typed effects
<gasche>
I don't consider, say, Disciple to be user-ready
<gasche>
there is some very nice work by Daan Leijen on row-polymorphism for effect inference
<gasche>
and then we have the "algebraic effect" gang(s)
Yoric has quit [Ping timeout: 248 seconds]
<Drup>
gasche: I have done my previous internship on links, so I know of the "algebraic effect" gang =)
<gasche>
with maybe the exception of Daan's work (and barring some pending ICFP submissions that may turn to be really a step forward), it's still very experimental
* companion_cube
happy that ocaml is impure
<Drup>
I do agree that it's not ready yet
<Drup>
(even if it does the job very well in links)
<Kakadu>
Guys
<Kakadu>
I have infix operator >>=
<Kakadu>
in module M
<Kakadu>
Why M.(>>=) is not an infix operator than?
<gasche>
I agree this is a limitation, but that would be quite difficult to parse
<gasche>
what OCaml currently recognize is
<gasche>
expr operator_symbol* expr
<Kakadu>
to parse by user or compiler?
<gasche>
here you have something much more complicated, because while parsing the module path there is no indication that this is actually an infix operator
<gasche>
by the compiler
<gasche>
besides, that would be an ambiguity
BlankVerse has quit [Read error: Connection reset by peer]
<gasche>
(apply M.(>>=) m f) is currently understood as (((apply M.(>>=)) m) f), not (((M.(>>=) apply) m) f)
<gasche>
so Kakadu, what you should consider using instead of (foo M.(>>=) bar) is M.(foo >>= bar)
<gasche>
or (let open M in foo >>= bar), which may work better in the case of (>>=)
<gasche>
(but then you have to be careful if M may shadow stuff used in foo or bar)
<Kakadu>
I can't open module because I need to deal with two monads
<Kakadu>
I have tried M.(foo >>=) bar but it doesn't work
<Kakadu>
I will try your advice, gasche
<gasche>
well you can always use M.(>>=) foo bar
pkrnj has joined #ocaml
<gasche>
if you have to mix two different >>= , you could rebind one of them to a different infix
<gasche>
but frankly I have no idea how to convey a sense of which is which
ttamttam has joined #ocaml
<Kakadu>
`Splendeurs et misères des courtisanes^Wmonads`
<Drup>
(using the same operator for two different monads in the same code feel like an unreadable mess for me.)
<Drup>
(no offense !)
<gasche>
I think in this case reverting to the non-infix "bind" operator may make sense indeed
<eikke>
if you need multiple >>='s, chances are you want a transformer ;-)
<Kakadu>
Drup: I know a difference between JS's null and underfined but it's semantics is the same in my program, IMHO
<Kakadu>
eikke: I have two values which are two different monads, I don't have 'a monadA monadB type. It seems that I don't need transformers, do you?
<Drup>
Kakadu: yeah, merging >>= for js's opt and optdef make sense
<Kakadu>
s/do you/do I/
<eikke>
Kakadu: sure
<Kakadu>
Ah, I can conert Opt.t to Optdef.t in the beginning and user only 1 monad!