wagle has quit [Remote host closed the connection]
wagle has joined #ocaml
_andre has joined #ocaml
pierpal has joined #ocaml
sgnb has quit [Remote host closed the connection]
gtrak has quit [Ping timeout: 276 seconds]
gtrak has joined #ocaml
_andre has quit [Remote host closed the connection]
govg has quit [Ping timeout: 255 seconds]
pierpal has quit [Ping timeout: 260 seconds]
mk9 has joined #ocaml
hdon has quit [Ping timeout: 256 seconds]
tarptaeya has quit [Ping timeout: 255 seconds]
pierpal has joined #ocaml
tarptaeya has joined #ocaml
xttraces has quit []
xttraces has joined #ocaml
silver has joined #ocaml
silver has quit [Max SendQ exceeded]
silver has joined #ocaml
silver has quit [Max SendQ exceeded]
silver has joined #ocaml
_andre has joined #ocaml
pmetzger has quit [Remote host closed the connection]
argent_smith has quit [Quit: Leaving.]
marsam has quit []
Gurkenglas has joined #ocaml
marsam has joined #ocaml
hdon has joined #ocaml
hdon has quit [Ping timeout: 248 seconds]
silver has quit [Quit: rakede]
silver has joined #ocaml
pmetzger has joined #ocaml
silver has quit [Client Quit]
silver has joined #ocaml
gareppa has joined #ocaml
<silenc3r>
Is there a shorthand for identity function? Not that (fun x -> x) is long, I'm just curious.
<leah2>
not in the ocaml stdlib
pmetzger has quit [Remote host closed the connection]
gareppa has quit [Quit: Leaving]
<silenc3r>
I've found one in containers: Fun.id
<companion_cube>
the function which preserves fun
<companion_cube>
what's not to have?
hdon has joined #ocaml
pmetzger has joined #ocaml
hdon has quit [Ping timeout: 255 seconds]
mk9 has quit [Quit: mk9]
FreeBirdLjj has joined #ocaml
shinnya has quit [Ping timeout: 260 seconds]
pmetzger has quit [Remote host closed the connection]
pmetzger has joined #ocaml
al-damiri has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
<malina>
:p
mk9 has joined #ocaml
mengu has quit [Quit: Leaving...]
mk9 has quit [Ping timeout: 248 seconds]
Haudegen has quit [Remote host closed the connection]
Gurkenglas has quit [Ping timeout: 260 seconds]
elfring has joined #ocaml
<silenc3r>
List.sort (fun x y -> (Int.compare x y) * (-1)) my_list
<silenc3r>
is it the right way to sort list in descending order?
<companion_cube>
`Int.compare y x` also works
<silenc3r>
oh, I'm so dumb
<companion_cube>
nah, it's only obvious in hindsifht
<companion_cube>
hindsight
hdon has joined #ocaml
muelleme has joined #ocaml
jnavila has joined #ocaml
sh0t has quit [Remote host closed the connection]
xutux_ has joined #ocaml
muelleme has quit [Ping timeout: 264 seconds]
sh0t has joined #ocaml
xutux has quit [Ping timeout: 268 seconds]
xutux_ has quit [Ping timeout: 255 seconds]
jnavila has quit [Ping timeout: 240 seconds]
<silenc3r>
is there a simple way to get $HOME var or I have to parse output of Unix.environment manually?
<companion_cube>
Sys.env or something, I guess?
<companion_cube>
Sys.getenv
<silenc3r>
thanks!
mk9 has joined #ocaml
<pmetzger>
One of the few things that's kind of neat about Perl (don't stare at me that way!) is that you can do tied hashes. Something that looks like a hash but behind the scenes it is handled by a differing implementation. So there's an ENV hash that is in fact the environment, and if you mutate it, child processes get the updated environment exactly as you expect. This is also used for dbm files and loads of other things. It's got pluses and minuse
<pmetzger>
s of course.
mk9 has quit [Client Quit]
<pmetzger>
In a language like OCaml, I'd implement it with modules and having an indexing operator that is differently implemented behind the scenes.
<pmetzger>
Given far future things like modular implicits this would be even nicer.
<pmetzger>
It turns out I wasn't the only one who didn't understand the difference between "type t = A of int * int" and "type s = B of (int * int)": https://caml.inria.fr/mantis/view.php?id=7783
pmetzger has quit [Remote host closed the connection]
jnavila has joined #ocaml
jnavila has quit [Ping timeout: 260 seconds]
muelleme has joined #ocaml
pmetzger has joined #ocaml
gtrak has quit [Ping timeout: 256 seconds]
gtrak has joined #ocaml
shinnya has joined #ocaml
pmetzger has quit [Ping timeout: 276 seconds]
sh0t has quit [Remote host closed the connection]
sh0t has joined #ocaml
sh0t has quit [Remote host closed the connection]
sh0t has joined #ocaml
cbot has joined #ocaml
jnavila has joined #ocaml
mk9 has joined #ocaml
Jesin has joined #ocaml
xutux has joined #ocaml
xutux_ has joined #ocaml
shinnya has quit [Ping timeout: 255 seconds]
xutux has quit [Ping timeout: 255 seconds]
malina has quit [Read error: Connection reset by peer]
pierpal has quit [Read error: Connection reset by peer]
malina has joined #ocaml
muelleme has quit [Ping timeout: 255 seconds]
jnavila has quit [Ping timeout: 240 seconds]
jack5638 has quit [Ping timeout: 260 seconds]
pmetzger has joined #ocaml
pierpal has joined #ocaml
pierpal has quit [Read error: Connection reset by peer]
argent_smith has joined #ocaml
jack5638 has joined #ocaml
Gurkenglas has joined #ocaml
kakadu has joined #ocaml
pierpal has joined #ocaml
pierpal has quit [Ping timeout: 260 seconds]
Jesin has quit [Quit: Leaving]
johnelse_ has joined #ocaml
pierpal has joined #ocaml
johnelse has quit [Read error: Connection reset by peer]
mk9 has quit [Quit: mk9]
<hdon>
what's the difference between t and s? (or A and B)
<hdon>
is the latter a tuple?
<companion_cube>
we shoudl just not talk about that
<companion_cube>
and only speak of inline records :3
<companion_cube>
type t = A of {x: int; y:int}
<companion_cube>
problem solved
elfring has quit [Quit: Konversation terminated!]
pierpa has joined #ocaml
<pmetzger>
hdon: so if you read the thread, "A" is a constructor that takes two ints. "B" is a constructor that takes a single tuple, which is a tuple of two ints.
<pmetzger>
These are _not_ the same. However, OCaml syntax for both is very similar and not very clear, even to someone who is an advanced beginner.
<pmetzger>
This needs to be documented better as a result.
zolk3ri has quit [Remote host closed the connection]
<octachron>
companion_cube, I am tempted; but then beginners would be scar(r)ed by escaping records
<companion_cube>
:D
<pmetzger>
There are things one might not want to talk about, but none the less one hits them often. Until I saw people talking about this yesterday morning I'd had mysterious problems (which weren't so mysterious) because I didn't understand the difference viscerally. In retrospect it's trivial.
<pmetzger>
But the * being used for both purposes was, I think, a bad syntactic choice. Too late now though.
jnavila has joined #ocaml
<pmetzger>
Then again, I've always had a distaste for many little things here. I don't like the fact that ML doesn't treat type constructors more like functions the way Haskell does. My ideal language would have 30% closer to Haskell's syntax (but not more than that!) and would have function types for variant constructors.
<pmetzger>
But I'm too much of a newbie and idiot to really know what the terrible implications would be, so I'll wait a few years before firming that opinion up.
<pmetzger>
(Like I'd prefer that rather than being an "'a list" if things were "list 'a" instead etc. More like Coq or Haskell. But I Probably Don't Know What I'm Doing.)
<octachron>
This a general problem with syntax, the gradient of design optimality is too flat, and it is very easy to get stuck in a local quasi-minima with a lot of small defects due to inertia/social group effect
<octachron>
I find the evolution of the syntax of rust or reason quite telling from this point of view
<octachron>
For OCaml, I thnik that indeed lot of people will agree now that list 'a would be more consistent than 'a list
<pmetzger>
octachron: what do you mean? (by "quite telling"?)
<octachron>
pmetzger, the first version of reason syntax was much closer to a revised OCaml, but then it got attracted by javascript
<pmetzger>
:(
<octachron>
similarly, Graydon's rust syntax was much closer to a ML, but then it got attracted by C++
<companion_cube>
rust didn't change that much, did it?
<companion_cube>
wasn't it always curly braced?
<pmetzger>
That's unfortunate. C++ is a negative example in syntax.
<pmetzger>
I don't know what early rust was like.
<companion_cube>
they removed lots of sigils because concepts became in-library rather than builtins
<companion_cube>
pmetzger: it's not really like C++, you can actually write a rust parser
<companion_cube>
and it's `foo : bar` ✔
<companion_cube>
it's really like ML with { }
<pmetzger>
Anyway, the "type t = A of int * int" syntax is confusing, because the "*" really makes people who know the tuple syntax think it's a tuple. Too late to fix.
<pmetzger>
(It made *me* think tuple! Not that I'm that smart, but I'm an exemplar.)
<companion_cube>
you should think *product*
<companion_cube>
because that's what it means
<pmetzger>
companion_cube: Which is like ML with {}?
<companion_cube>
rust
<octachron>
companion_cube, true, the change of syntax for rust was far less radical
<pmetzger>
Ah, but products make me think tuples. Sort of.
<companion_cube>
pmetzger: yes, because both cosntructors and tuples are products
<pmetzger>
They shouldn't in this case I know.
<companion_cube>
(multi-arguments constructors, that is)
<pmetzger>
Really what fixed it in my mind was thinking of the type signature. Even though there isn't a function type signature for constructors. Which sort of there should be.
<companion_cube>
yeah…
<pmetzger>
"A: int -> int -> int" fixes it for me in my head.
<pmetzger>
(vs "B: (int * int) -> int")
Haudegen has joined #ocaml
<companion_cube>
well it'd be like B actually
<companion_cube>
you can't partially apply a constructor :)
<pmetzger>
But I've also got a weird background. Coq was my first real strongly typed functional language. Before that I knew Lisp very well.
<pmetzger>
So going to OCaml is a bit odd for me.
<companion_cube>
what a transition
<octachron>
at the same time, for an impure language, int * int -> t is more precise than int -> int -> t
<companion_cube>
"I went from herbal tea to LSD"
<pmetzger>
companion_cube: Hey, that's a totally reasonable step! ;)
<companion_cube>
:D
<pmetzger>
But seriously, I knew lisp quite well, was aware of ML and Haskell but had never used them for anything, and then I took Pierce's class that turned into the Software Foundations book.
<pmetzger>
It was a really fun class.
<companion_cube>
heh, neat
<Drup>
companion_cube: which one is the LSD ?
<companion_cube>
Coq?
<Drup>
It could be lisp.
<pmetzger>
Both are LSD, really.
<companion_cube>
LSD vs meth
<Drup>
Are there people around here that are in Lyon for the WWW conference this week ?
jnavila has quit [Remote host closed the connection]
<octachron>
pmetzger, by the way, do you prefer to turn the discussion on discuss to a PR yourself or should I do it once it has settled a bit?
<pmetzger>
octachron: Which discussion?
<pmetzger>
The one I turned into a Mantis ticket as well?
<octachron>
yes
<pmetzger>
I think let it get discussed for another 24 hours on both discuss and Mantis and see where people land. The other question is, which portions of the manual should be updated? I think both the tutorial section and the reference need some language.
<pmetzger>
Once we've decided more or less what to do we can figure out who does the PR.
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
<octachron>
The wording in the language reference seems sharp-edged but exact
xutux_ has quit [Ping timeout: 255 seconds]
<octachron>
Maybe one could add an warning in the pattern and expression syntax that there is local potential ambiguity between unary constructor applied to a tuple and n-ary constructors
<mrvn>
octachron: you mean "type 'a t = Foo of 'a match x with Foo (1,2,3) ->"?
<pmetzger>
octachron: it might be exact, but I couldn't parse it. Perhaps very precise and slightly less difficult for the non-speciaist?
<pmetzger>
(When I read it, it didn't seem clear that this was the interpretation.)
<pmetzger>
I think a warning would be appropriate.
<mrvn>
Is there any way (apart from Obj.magic) to make a "type t = Zero of leaf | One of Node | Two of Node | Three of Node | .... | Sixtyfiythousandfivehundredthrityfour of Node"?
troydm has joined #ocaml
<octachron>
mrvn, compared to "type 'a t = Foo of ('a * 'a *' a) function Foo ((1,2,3) as t ) -> t"
<mrvn>
octachron: does that compile to %identity?
tarptaeya has quit [Quit: Konversation terminated!]
<octachron>
mrvn, there can be at most 240(?) non constant constructors since the constructor tag is stored in the block header
<mrvn>
octachron: only 8 bit? I thought it would be bigger on 64bit.
<pmetzger>
octachron: is that across all types, or across only one type?
malina has quit [Ping timeout: 268 seconds]
<octachron>
mrvn, I think so. And Foo t -> t is a field access, so not %identity
<octachron>
pmetzger, for one type
<pmetzger>
oh, good. For a moment I got scared.
<pmetzger>
What's the rule for polymorphic variants?
<mrvn>
octachron: right, sorry, the "as t" confused me.
<steenuil>
reminds me of a story I heard about a programming language that could only have 256 variables in the entire program
<steenuil>
or some other crazy number like that
<octachron>
pmetzger, as many as you want, up to the point that you hit an hash collision, then the compiler will raise an error
<companion_cube>
well writing a type with 240 non constants constructors is unusual
<companion_cube>
outside of generated code
argent_smith has quit [Quit: Leaving.]
<Drup>
note that the hash collision is only for variants that actually interact
<Drup>
if they live in separated part of the program, the compiler doesn't care.
<octachron>
mrvn, yes, it seems that it is still 8 bit on 64 bits, and all the new shiny bits went to the block size
<pmetzger>
btw, does the compiler do parametric polymorphism with polyinstantiation or does it do something that requires less global knowledge? (polyinstantiation is where you generate a specialized version of the function at every type that uses it.)
<Drup>
the limit in block size was hit fairly often with 32bits. The limit on the number of variants, less so ...
<mrvn>
Error: Too many non-constant constructors -- maximum is 246 non-constant constructors
<mrvn>
companion_cube: you were close
<Drup>
pmetzger: it's more general
malina has joined #ocaml
<pmetzger>
But then lower performance than polyinstantiation I'd imagine.
<mrvn>
pmetzger: it only makes one function unless it gets inlined.
<pmetzger>
separate compilation seems to be a primary goal so that would make sense.
<Drup>
not really, the perf is the same as variants
<Drup>
they are bigger in memory size
<pmetzger>
The state of the art in link time optimization was terrible until very recently.
<mrvn>
pmetzger: ocaml has always (as long as I remember) done link time optimization
<pmetzger>
to do things like inlining at link time?
<Drup>
mrvn: yeah, and ocaml has always done inlining as well
<Drup>
right
<Drup>
:3
<companion_cube>
it's more advanced nowadays, with flambda
<mrvn>
pmetzger: cmx/cma files contain an intermediate form of the functions that allow inlining. Basically what LTO does in gcc.
<pmetzger>
Interesting. Bluddy's suggestion of having a compiler walk through seems quite interesting to me. I would probably get a lot about the language that I don't know by seeing the implementation in depth.
<companion_cube>
♥ flambda
<pmetzger>
BTW, why is flambda optional? It seems a bit weird that the default is not to use it.
<mrvn>
pmetzger: stability. It's too new.
<pmetzger>
Gotcha.
<Drup>
no, that's not it at all
<mrvn>
dunot?
<mrvn>
Drup: not?
<Drup>
it makes the compiler slower and make the .cmx much bigger
<Drup>
that's pretty much the main reason
<pmetzger>
Yah, but I find the following surprising: for something like clang, you have a -O option that tells it to optimize, while for ocaml, you need to build a distinct ocamlopt to get flambda.
<Drup>
the fact that there is a rewrite of flambda in progress also means that we are waiting for the next version
<mrvn>
WTF? a) ocaml is fast. Not go fast but blinding fast compared to e.g. c++. b) who cares. disk space is cheap.
<pmetzger>
as terrible as c or c++ is, it's nice to be able to pick slow but optimized or fast compilation at will. :)
<pmetzger>
(without needing a distinct compiler binary.)
<pmetzger>
But that's because of instability? Or something else?
<mrvn>
ocaml is so fast I hardly ever remember to use ocamlopt.opt
<Drup>
no, it's really not a stability issue
<Drup>
mrvn: that's because you use ocamlopt.opt without knowing it
<pmetzger>
so why not one binary with a switch to say whether to compiler?
<Drup>
all the tools will pick it for you
<mrvn>
Drup: if it needs a rewrite then it wasn't stable yet.
<pmetzger>
er whether to optimize. sorry.
<Drup>
it needs a rewrite to optimizer more :D
<Drup>
well, need
<Drup>
I don't know, but that's what the flambda people decided to do
<mrvn>
stable as in not changing. Not stable as in not crashing.
<steenuil>
I think the Rust compiler has a --release mode that will optimize more and take much more to compile, but it's not turned on by default
<companion_cube>
Drup: I hope there will be good explanations of how flambda 2 is goin to work
<companion_cube>
in particular regarding pattern matches, and closures :p
<companion_cube>
(oh hello Seq)
<Drup>
anyway, pmetzger, talking about perfs of variants: pattern matching in OCaml is ridiculously optimized already
<mrvn>
There is ocamlc, ocamlc.opt, ocamlopt and ocamlopt.opt. Why not an ocamlf, ocamlf.opt, ocamlc.f and ocamlopt.f?
<companion_cube>
ocamlopt.af
<companion_cube>
I'm sure seliopou would do that
<pmetzger>
ROFL for ocamlopt.af
<Drup>
the pattern matching engine is *very* optimized, if you reach the point where that's the bottleneck, well, you can pat yourself on the back :p
<mrvn>
For distro packages having all 3 variants would be great. At least have the 3 compilers. Doesn't need to have each in the 3 optimizer variants.
<Drup>
pattern matching compiler*
<mrvn>
Drup: I've reached it quite often I think. Slow ram.
<mrvn>
A Raspberry PI with caches turned off is dead slowl.
<Drup>
mrvn: you tend to write code for very specific use cases that are quite different from the rest of the community :D
<mrvn>
maybe.
<mrvn>
But I think you ment that even if the pattern matching is the bottleneck then there usually isn't a way to make it better.
<Drup>
Actually, there was a post recently on HN about how Reason-with-bs's pattern matching was emiting very efficient code, and it was just a very basic test `| Foo | Bar -> true | Baz -> false`
<Drup>
I found it amusing
<companion_cube>
mrvn: what kind of code do you write??
<Drup>
when you know that the compiler can actually output weird bit masks to treat partial cases, and do test accross multiple words
<pmetzger>
ttyt
pmetzger has quit []
<mrvn>
Drup: like "sub %r0, #3" /* Baz == 3 */?
<Drup>
mrvn: the blog post was about js output, but yes
<companion_cube>
Drup: sounds as crazy as the `mod` trick
<companion_cube>
with a constant
<companion_cube>
the thing with a puzzling bug in it a few years ago
BitPuffin has quit [Remote host closed the connection]
<mrvn>
Does ocaml support x86_32? x86 in long mode but using LP32.
<mrvn>
(natively)
<companion_cube>
with 32 bits pointers? interesting question
<mrvn>
Limits everything to the lower 4GB of ram but 99% of the time that is just fine.
<mrvn>
half the memory footprint on the other hand, which is a big bonus.
<companion_cube>
I guess… I have no idea though, it'd probably require good support for cross compilation, unless the compiler itself is in x86_32 already
gtrak has quit [Ping timeout: 264 seconds]
<mrvn>
companion_cube: easy enough to build a x86_32-linux-gnu-gcc and put it in the PATH as gcc for that.
gtrak has joined #ocaml
<companion_cube>
you also need OCaml to be aware of that, for the word size
<mrvn>
indeed.
<mrvn>
code generation also needs to zero extends pointers on load so that might need some fixing too.
<companion_cube>
I suppose you can load them in 32 bit registers? or isn't there a mask for that?
<mrvn>
companion_cube: there is an opcode to load a signed 32bit or unsigned 32bit. You just have to pick the later.
<companion_cube>
nice.
<companion_cube>
I should seriously learn assembly one day
<mrvn>
companion_cube: maybe not x86 then. :)
<companion_cube>
sad thing is, that's the useful one :/
<companion_cube>
( I mean I should learn to read assembly, not write it)
<mrvn>
companion_cube: not so much. You want to write 99% of your code in C and only a critical 1% in asm if at all. The compiler is usualy better than you unless you really know what you do and it's worth the time to opimize by hand.
<mrvn>
companion_cube: ahh, reading isn't so bad.
iitalics has joined #ocaml
<companion_cube>
well it'd be nice to read perf's output ^_^'
<mrvn>
I would be happy if I could grock pxx data structures for classes.
<companion_cube>
and I'd rather write code in rust, if I had to do it
<companion_cube>
rather than C I mean
<mrvn>
still have to learn rust
gtrak has quit [Ping timeout: 268 seconds]
<malina>
ok done
<malina>
sorry wrong window ,p
_andre has quit [Quit: leaving]
kakadu_ has joined #ocaml
Haudegen has quit [Remote host closed the connection]
kakadu has quit [Ping timeout: 268 seconds]
malina has quit [Remote host closed the connection]
kakadu_ has quit [Remote host closed the connection]
moei has quit [Quit: Leaving...]
silenc3r has quit [Quit: Leaving]
sh0t has quit [Remote host closed the connection]
iitalics has quit [Quit: WeeChat 2.1]
exarkun has quit [Read error: Connection reset by peer]