nikki93 has quit [Remote host closed the connection]
malo has quit [Quit: Leaving]
vpit3833 has joined #ocaml
venk has quit [Ping timeout: 268 seconds]
maattdd has joined #ocaml
madroach has quit [Ping timeout: 252 seconds]
madroach has joined #ocaml
maattdd has quit [Ping timeout: 268 seconds]
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
<dsheets>
watermind, not quite as-is but close
<dsheets>
what do you want to support?
Simn has quit [Quit: Leaving]
refaktor has quit [Quit: Lost terminal]
shinnya has quit [Ping timeout: 265 seconds]
tlockney_away is now known as tlockney
<watermind>
dsheets: was wondering because I noticed the Rust guys had some failed attempt at producing one
<watermind>
dsheets: and it makes me wonder why reinvent the wheel
<dsheets>
watermind, i pondered this in a pub a few weeks ago
<dsheets>
but they appear to have retained the bundler dev now
<dsheets>
but yes, i agree, it would be nice to just adapt opam to rust
<dsheets>
and enable cross-language builds
<watermind>
indeed
<dsheets>
i think the primary components to focus on are switches, compilers-as-packages, and build-only dependencies
<dsheets>
there will also be a set of environment variables to be set, most likely
<dsheets>
these are much the same components we require to enable metaocaml, js_of_ocaml, ocamljava, jenga-builds etc
<watermind>
right
<watermind>
so my guess is it should definitely be way easier than producing something from scratch
<dsheets>
it depends if the rust community accepts our theory of packaging
<watermind>
well as of now they don't really have one, they had one that didn't work
<dsheets>
AltGr is the guy you should talk to, i'm sure he would love contributions to help make opam support rust/metaocaml/js_of_ocaml/ocamljava etc
<dsheets>
this is a common theme with package managers
<watermind>
I shouldn't get too involved in this, I wouldn't say I'm part of the rust community, it's just a cool language I've been looking at and learning as time allows
<watermind>
but who knows, if nothing changes and I get some more free time, that could be an interesting project
<dsheets>
watermind, it's mostly getting comfortable with opam development, i think
<dsheets>
nothing nearly as hard as writing a package manager for rust from scratch
<dsheets>
and i have a feeling that rust+ocaml will be a compelling combination
<watermind>
they're both really nice languages in their own ways
<dsheets>
rust's prototype was in ocaml
maattdd has joined #ocaml
lostcuaz has quit [Read error: No route to host]
lostcuaz has joined #ocaml
maattdd has quit [Ping timeout: 264 seconds]
<sheijk>
dsheets: i have more of a feeling that rust will offer more or less anything ocaml. what would you still need ocaml for?
<dsheets>
sheijk, rust's type and module systems will not be as featureful as ocaml's for quite some time
<sheijk>
ok, modules are a big point. and polymorphic variants of course. but i think rusts type system is already stronger
<Drup>
depends in what area
<Drup>
(and they don't have garanted TCO >_>)
<sheijk>
especially with respect to control over mutability
<Drup>
Sure, that's their main selling point :D
<sheijk>
what is missing in rust type system wise?
<Drup>
I haven't tested rust yet, so I don't want to say anything yet
<Drup>
I'm waiting for the 1.0 to try it out
<Drup>
the fact that's it's not yet stable makes everything a bit hard to see
<sheijk>
yeah. also unfinished and changing documentation of course.
<sheijk>
but i prefer them taking their time over rushing out another poorly thought out language
q66 has quit [Quit: Leaving]
<Drup>
indeed
`jpi has joined #ocaml
wizko has joined #ocaml
<watermind>
Rust is not higher order
<watermind>
it's not really a functional language
<watermind>
to be more precise you can't create lambdas
<watermind>
there's no currying
<watermind>
that alone makes Rust and OCaml very different
<watermind>
as for the type system being stronger it depends... it does have e.g. types that are affine which is nice, and it has haskell like classes
<watermind>
but it doesn't have GADT's
<watermind>
not first class modules
<watermind>
nor polymorphic vars.
<sheijk>
no lambdas? aren't they just restricted to not capture values of linear types?
<watermind>
nope
<Drup>
no polymorphism ? that seems suprising
<dsheets>
there is a lot of polymorphism
<watermind>
you can't write e.g. a curried plus function
<dsheets>
just not polymorphic variants
<watermind>
Drup: ?
<Drup>
oh
<Drup>
"vars"
<sheijk>
Drup: i think he means polymorphic variables like let e = [] in...
<watermind>
I meant polymorphic variants
<sheijk>
watermind: could you elaborate on the lambda issue?
<watermind>
sheijk: I'm not an expert... I know it's impossible because I kept trying and failing, and then in the irc they explained it's impossible and why...
<watermind>
sheijk: the reasoning had to do with predicting the live span of your objects
Dongyancai has quit [Ping timeout: 252 seconds]
<watermind>
sheijk: also note that they have two notions
<sheijk>
watermind: hm. there are definitively nested procedures that can capture locals. maybe they meant you can't arbitrarily capture stuff? or was this about partial application?
<watermind>
sheijk: functions and closures and they are different in many details... functions are declared at top level, closures are values and therefore declared localy in functions
Dongyancai has joined #ocaml
<watermind>
sheijk: a function cannot even refer to anything not passed as an argument, so you couldn't construct a curried function
<watermind>
sheijk: with closures it's trickier because you can indeed refer to values outside their scope, but then the reasoning I was given was precisely that then they couldn't determine their life span
<sheijk>
interesting. looks like i need to play with it for real now
<watermind>
watermind: since the life span of local values is determined via their scope
<watermind>
sheijk: but do take my explanation with a grain of salt... as I said I'm not an expert nor even close
<sheijk>
watermind: yep. but i would expect this restriction to not hold for things like shared pointers
imortalk has joined #ocaml
wizko has quit [Quit: Page closed]
<dsheets>
i don't yet see why they can't guarantee tco
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
<sheijk>
watermind: hehe, yeah. i thinked they changed the rules for closures a few times recently
maattdd has quit [Ping timeout: 240 seconds]
<watermind>
sheijk: yeah, one of the reasons I make Rust low priority for now is that it's still not that stable yet, and docummentation is lacking
<sheijk>
yep. it's currently more for playing around i think. and to inspire there might be some hope for systems programming :)
<watermind>
better invest my little free time in other more productive endeavours and leave Rust for when it's easier to learn quickly
<watermind>
there's plenty of hope, aside from Rust there's, Go which is not as ambitious in terms modern type systems and what not but a seemingly decent language anyway
<watermind>
and Microsoft is also developing a new systems language
<watermind>
although that's still a bit under the wraps
<Drup>
Go is crap.
<watermind>
not compared to C it isn't
<Drup>
I'm not even sure about that.
<watermind>
eh, what's so bad about it that is better in C?
<Drup>
And anyway, a language designed in the last century that don't have sum types doesn't deserve my attention
<Drup>
=)
<whitequark>
Drup: well, it is definitely progress compared to writing the same kinds of applications in C rather than in Go.
<whitequark>
I mean, at least it's memory-safe. (I think?)
<whitequark>
think "harm reduction" philosophy :p
<sheijk>
go is mostly 80ies state of the art language design executed very nicely
<sheijk>
whitequark: i'd argue that a language that focues on concurrency but does not control mutability in any way is nearly as bad as being memory unsafe
<whitequark>
sheijk: I completely disagree, from pure PLT point of view that's maybe true
<whitequark>
in practical terms it is the difference between a contrived bug and a remote code execution exploit straight away
<sheijk>
no. from pure practical point of view, too
<watermind>
Drup: true not having sum types is really awkward
<whitequark>
anyway, anything that reduces the amount of C code that is written is "good" in my book
<sheijk>
ok, security is another thing. although even a lack of locking could open up security issues when it happens with flags for access rights
<whitequark>
yes, I know. but the barrier is significantly higher.
<watermind>
Drup: apparently they can simulate them using interfaces and checking for the type of the argument at run type
<watermind>
but yeah...
<whitequark>
watermind: that's basically optional dynamic typing, not sum types, isn't it?
<sheijk>
whitequark: i'm not sure go will lead to less c (or c++) code. the people still sticking with it will most likely do it due to GC and control of memory allocation and go is as usable as java in those areas
<whitequark>
since you can't really restrict what people can pass as interface{}
<sheijk>
whitequark: yep @sumtypes/go inferfaces
<whitequark>
sheijk: well, at least Google developed it to migrate from a lot of C in-house
<whitequark>
I agree it is an open question whether Google and everyone else use Go in same way
<whitequark>
though... talking about security, go gets rid of shared libraries. which somewhat compensates for memory safety, because it means that vulnerable dependencies are harder to update.
* whitequark
shrugs
<sheijk>
whitequark: yep. but i don't see a reason they couldn't migrate to any other modern garbage collected language as well. think D, java, etc.
<whitequark>
I guess it's shit at the end
<sheijk>
hehe. let's just call it well executed but underwhelming :)
<whitequark>
sheijk: inertia?
<sheijk>
whitequark: but inertia wouldn't really favor going with a completely new language
<whitequark>
maybe they felt they wanted something like "garbage collected C". neither D nor Java suit that need well
<watermind>
whitequark: the approach he describes doesn't appear dynamic... I'd expect you not to be able to pass values that implement the given interface http://www.jerf.org/iri/post/2917
<sheijk>
i think more rob pike felt like designing such a language and then managed to push it inside google. and i'm not even sure to what degree they are really switching internally
<watermind>
whitequark: I doubt the switch expression over the argument type can be tested for completeness though
<sheijk>
watermind: you can't express a closed set of cases using go interfaces
<sheijk>
exactly
<whitequark>
watermind: it wouldn't. also this approach is different from what I've seen earlier.
<watermind>
yeap :/
<whitequark>
it's nice though a bit more complex
<whitequark>
nicer*
<sheijk>
and imho exhaustiveness checks are the real killer feature of match/tagged unions
<watermind>
true
<whitequark>
yeah
nikki93 has joined #ocaml
watermind has quit [Quit: Konversation terminated!]
watermind has joined #ocaml
<Drup>
watermind: Go is not memory safe
<Drup>
also I'm not sure why do you think Go is competing with C anyway, it's not the case
<Drup>
Go isn't that low level, it isn't super fast
nikki93 has quit [Ping timeout: 240 seconds]
`jpi has quit [Quit: WeeChat 0.3.2]
sheijk has quit [Quit: .]
yacks has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 255 seconds]
shinnya has joined #ocaml
dsheets has quit [Ping timeout: 245 seconds]
maattdd has joined #ocaml
michael_lee has joined #ocaml
maattdd has quit [Ping timeout: 264 seconds]
Don_Pellegrino has quit [Read error: Connection reset by peer]
Don_Pellegrino has joined #ocaml
bzzbzz has joined #ocaml
Don_Pellegrino has quit [Quit: Konversation terminated!]
Don_Pellegrino has joined #ocaml
bzzbzz has quit [Client Quit]
Don_Pellegrino has quit [Client Quit]
Don_Pellegrino has joined #ocaml
Don_Pellegrino has quit [Client Quit]
Don_Pellegrino has joined #ocaml
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ggole has joined #ocaml
lostcuaz has joined #ocaml
ebzzry has quit []
Don_Pellegrino has quit [Quit: Konversation terminated!]
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 255 seconds]
willy_ has joined #ocaml
Kakadu has joined #ocaml
axiles has joined #ocaml
divyanshu has joined #ocaml
yacks has quit [Ping timeout: 240 seconds]
maattdd has joined #ocaml
claudiuc has joined #ocaml
maattdd has quit [Ping timeout: 240 seconds]
yacks has joined #ocaml
<willy_>
bonjour
tlockney is now known as tlockney_away
angerman has joined #ocaml
divyanshu has quit [Ping timeout: 265 seconds]
tane has joined #ocaml
divyanshu has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 255 seconds]
claudiuc has quit [Remote host closed the connection]
Myk267 has joined #ocaml
zzing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vpit3833` has joined #ocaml
vpit3833 has quit [Ping timeout: 268 seconds]
maattdd has joined #ocaml
tane has quit [Quit: Verlassend]
maattdd has quit [Ping timeout: 265 seconds]
rand000 has joined #ocaml
willy_ has quit [Quit: Leaving]
Simn has joined #ocaml
avsm has joined #ocaml
Dongyancai has quit [Ping timeout: 255 seconds]
Dongyancai has joined #ocaml
WraithM has quit [Ping timeout: 268 seconds]
WraithM has joined #ocaml
pminten has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 265 seconds]
rand000 has quit [Ping timeout: 265 seconds]
avsm has quit [Quit: Leaving.]
Yoric has joined #ocaml
Yoric has quit [Ping timeout: 240 seconds]
knulp has joined #ocaml
knulp has quit [Quit: Leaving]
Yoric has joined #ocaml
fraggle_ has quit [Ping timeout: 246 seconds]
Hannibal_Smith has joined #ocaml
flx_ has joined #ocaml
flux has quit [Remote host closed the connection]
flx_ is now known as flux
willy_ has joined #ocaml
<gasche>
regarding Rust, I'm also not sure the compilation scheme will scale
<gasche>
on the other hand, I have the same reserves with C++ and that clearly doesn't stop people from using the language
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 240 seconds]
<gasche>
(the compilation of Rust itself peaks at 1.3Gib memory usage; when we found out for some version of OCaml that there was a peak at 700Mio we considered that an obvious bug that was tracked down and fixed)
<Hannibal_Smith>
gasche, well C++ alternative is C, so it's comprehensible why people use it
<adrien>
16GB RAM so you have disk cache apparently
Thooms has joined #ocaml
tani has joined #ocaml
tobiasBora has joined #ocaml
<ggole>
gasche: what's the issue? That Rust requires type information to compile polymorphic data structures and functions?
tane has quit [Ping timeout: 255 seconds]
Dongyancai has quit [Quit: leaving]
flux has quit [Ping timeout: 240 seconds]
avsm has joined #ocaml
avsm has quit [Client Quit]
shinnya has quit [Ping timeout: 265 seconds]
flux has joined #ocaml
shinnya has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 255 seconds]
pminten has quit [Quit: Leaving]
avsm has joined #ocaml
q66 has joined #ocaml
Hannibal_Smith has quit [Ping timeout: 240 seconds]
Yoric has quit [Ping timeout: 246 seconds]
talzeus has quit [Read error: Connection reset by peer]
watermind has quit [Quit: Konversation terminated!]
watermind has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 255 seconds]
studybot_ has joined #ocaml
maattdd has joined #ocaml
darkf has quit [Quit: Leaving]
flux has quit [Ping timeout: 246 seconds]
aurynj has joined #ocaml
pminten has joined #ocaml
flux has joined #ocaml
studybot_ is now known as talzeus
divyanshu has quit [Quit: Computer has gone to sleep.]
pango has joined #ocaml
dsheets has joined #ocaml
Yoric has joined #ocaml
chichimaru has joined #ocaml
teiresias has quit [Ping timeout: 245 seconds]
teiresias has joined #ocaml
divyanshu has joined #ocaml
<gasche>
ggole: I meant using specialization on types as the only option
<gasche>
I think there is a missed opportunity of letting people control specialization, but with a default semantics that doesn't generate so much redundancy
<ggole>
Mmm, there does seem to be a bit of a tradeoff
<ggole>
The C++ people used to use (manually applied!) hacks to try to control it
<ggole>
eg. one specialisation for vectors that would handle any pointer type.
<ggole>
One downside is that an implementation that uses tricks for which types are required to be known (tagless GC, for instance) run into trouble unless they cover everything, so having part of the program specialised and part not may be less attractive.
<ggole>
Dunno if that's the case for Rust though.
<mrvn>
or they use speculative GC, which sucks
<gasche>
a lot of things actually don't depend on the whole type information, but on restricted properties of types (eg. the type width in words)
<gasche>
of course it's easy to just say "we depend on the type" but I feel that this is a lazy way to do things
<ggole>
Yes, but once you get to the level of having to know, say, where the pointers are in something
<ggole>
A lot of the benefit has gone away
<gasche>
the proper one being to formalize more precisely the nature of the dependency and work out how it affects the language semantics (instead of hiding that as low-level optimizations or compilation choices)
<ggole>
OCaml's no-need-for-object-maps approach is highly beneficial there, although it requires tagging.
<gasche>
for example, type-classes / implicits / rust traits do rely on the identity of types, and not any of their properties
<gasche>
in my opinion this suggests that we should consider *different* ways to handle them than, say, value types, which are mostly about the width
<gasche>
instead of throwing everything in a large "depends on type" bin
<ggole>
Width isn't enough if you need to walk the object relocating pointers.
chichimaru has left #ocaml []
<gasche>
(for type-classes, implicits and traits, my guts would suggest a unique evidence-passing compilation by default, with profile-guided specialization or JIT for the cases that were found to be recurrent)
<ggole>
Well, for some objects it is.
struktured has quit [Ping timeout: 240 seconds]
pminten has quit [Remote host closed the connection]
<gasche>
on the other hand, there's the whole "pluggable type systems" point of view that took radically opposite positions
<ggole>
And there's also other cases of assumptions over object layout interfering with things an implementor may desire
<ggole>
For instance, assuming a GC tag exists before an object interferes with inlining
<gasche>
you mean inlining of memory representations?
<ggole>
(Unless you copy the thing on access: which works for some types, but not others.)
<ggole>
Yes.
<gasche>
ultimately I think I'm not as interested in this backend stuff as a lot of other people
ddosia has joined #ocaml
<gasche>
so maybe I should leave it to them -- there's already enough work on shaping good semantics for the frontend languages
Yoric has quit [Ping timeout: 255 seconds]
<gasche>
the problem is that I like to work with assumptions that some compilation strategies may break
<ggole>
There seem to be two "clean" solutions: tag everything and be able to know enough about layout without having access to (a reified) notion of type, or monomorphise everything and do away with tags.
<ggole>
Both allow you to simplify things in different ways. I think mixing them is problematic as a result (although I won't say it is impossible or something that shouldn't be explored).
Eyyub has joined #ocaml
<ggole>
gasche: which assumptions? Things like constructors-with-args can be distinguished with ==?
<gasche>
I like to assume that nominal abstraction, the fact of saying "I'm using a different name for the exact same set of values but I want my type-system to prevent me from mixing the old and the new" (Haskell's newtype of sorts) should be absolutely cost-free at runtime
<mrvn>
ggole: if you mix then you can't interrupt the monomorphised parts
<gasche>
it's actually not in presence of monomorphization as the only choice
<ggole>
gasche: hmm. I think this case depends on which exact type information is required by the runtime.
<gasche>
but it's rather insidious as the *results* of the program are as expected, it's only the size and cost of compilation that is affected; so you may very well think this doesn't matter for small enough projects
<ggole>
If you only require "layout" (size, ability to walk pointers), that particular case should not require copying any code/tables/whatever.
<gasche>
like Rust: they're doing fine today, their most important program takes 1.3Gib of memory wich is reasonable by today's RAM standards
<ggole>
Ah, compilation time. Right.
<gasche>
ggole: yeah but if you use monomorphization for impl/typeclasses as well, it gets problematics
<gasche>
-s
<ggole>
As opposed to dictionary passing style?
<gasche>
(you're making my point that in a lot of situations it's actually silly to specialize on the full type, you should abstract over your needs; true, but that doesn't always work, and if you *always* monomorphize nominal abstraction means duplication)
<gasche>
ggole: yes, for example
michael_lee has quit [Quit: Ex-Chat]
<ggole>
Yeah, that makes sense
maattdd has quit [Ping timeout: 255 seconds]
<gasche>
is the idea that nominal abstraction and extreme specialization don't go along well new (or at least "previously unnoticed") to interested people of the chan?
<gasche>
maybe I should write a blog post about that :-)
<gasche>
(one of my current problems is that I've more blog post ideas than time to write them)
<ggole>
On the other hand, we have a very successful example of an always-monomorphise design in C++ (blech)
<ggole>
I think they attack the problem by trying to do everything very lazily (at compilation time, that is).
<ggole>
Of course C++ compilation times are horrific, but that doesn't seem to interfere with adoption :/
<mrvn>
ggole: that taakes forever and wastes a lot of space
<ggole>
(This may have influenced the views of the Rust people somewhat.)
<gasche>
it's interesting though that most large-scale users of C++ have completely rewritten the tool ecosystem to manage compilation times
<gasche>
(I'm thinking of Facebook, Google, etc.)
<mrvn>
one should only monomorphise when it leads to different code
<ggole>
mrvn: sure, but the real design decision is whether to arrange the compilation strategy/runtime such that you have to/are able to produce different code or not
<ggole>
And that is something of a tradeoff
<gasche>
there was an attempt at extreme type-passing during the TIL project in the nineties
<gasche>
it was never efficient enough and failed because of that
<gasche>
I wonder if the current JIT techniques would have made that competitive
<ggole>
With type arguments at runtime? Don't you need to start doing things like concatenating records for that?
<mrvn>
the right thing is to have a subsets of types you monomorphise and a generic flavour for everything else.
<gasche>
on the other hand, nobody wants to condition the viability of one's design on the availability of those extremely complex techniques
<mrvn>
How those types should look likes is generally best left to the user
<ggole>
mrvn: that's probably ideal from a usability perspective
<mrvn>
Often it could be enough simply to annotate the types to monomorphise
<ggole>
But as mentioned above, mixing mono- and polymorphic code can lead to implementation issues
<mrvn>
ggole: you don't have to change the memory model ocaml uses
<ggole>
(It's less actually *implementing* things than being unable to take advantage of some trick because you are unable to assume that X property always holds.)
<ggole>
Or so it seems to me.
<ggole>
mrvn: then how would you specialise?
<mrvn>
ggole: like being able to use a simpler hash function for ints than generic 'a.
<ggole>
Right, you could do a few things like that.
<mrvn>
ggole: you specialize in 2 ways: 1) just annotate the type and let the compiler optimize, 2) provide different source for different types
<ggole>
But memory is a pretty important thing to optimize with modern CPUs, and OCaml's representation unfortunately gets in the way a bit :/
<gasche>
I suspect we may over-hype that though
<gasche>
during the discussion about having inline records for variants parameters
<mrvn>
1) would mean the compiler can call and inline other monomorphised functions
<gasche>
people made the experiment of turning their packed parameters into a tuple (with the indirection) and benchmark the result
<gasche>
as a way to measure "the potential gains of going the other way around"
<gasche>
and the results were like 10% slower
<gasche>
that's certainly non-neglectible
<mrvn>
ggole: I don't think the memory model is that bad. you can avoid a lot of it within a function. And if stuff gets too big it isn't worth it usualy.
<gasche>
but that's not as much as I would have believed
<ggole>
Mmm, 10% isn't that much
<gasche>
that's a context of adding more boxing to already tree-like structures
<gasche>
of course unboxing integers/float can be much more effective
<gasche>
but still that somehow lessened my interest in this representation stuff
<ggole>
Monomorphising variants might get you a bit more (or a bit less, depending)
<gasche>
I can understand the position of a hardcore language purist that would say "a 10% gain is not worth making the core of the type system uglier with redundant concepts"
<ggole>
Because you could do boxing as shifts if the argument is small enough to fit
<ggole>
Then the allocation goes away entirely rather than just becoming smaller
<ggole>
Well, I think that all this stuff would preferably be totally invisible at the type level.
<ggole>
And maybe you'd expose a special module for doing particularly low level stuff
<ggole>
Machine.record and Machine.array for C-style records and arrays (that you can point into)
<ggole>
And the base language unsullied.
<ggole>
I also feel that the distance between the people who care about performance and everybody else is slowly widening. So it may become increasingly uncomfortable to try to bridge the gap.
<gasche>
I'm not sure about a widening gap
<gasche>
but as soon as the performance features require to change the language, there is a tradeoff that doesn't *only* take performance into accont
<gasche>
also, maybe not all places are equal as ways to optimize performances
Yoric has joined #ocaml
<gasche>
providing, say, manual SIMD intrisics may be much more intereresting that hunting the last indirection, in term of compromise between (complexity of the change) and (performance gains in sensitive applications)
<gasche>
(of course SIMD mostly applies to plain-data handling programs, which may be a different audience that those that care about indirections in highly symbolic code)
shinnya has quit [Ping timeout: 268 seconds]
<ggole>
I dunno, the opaque nature of ML's data types make them pretty amenable to barrel-scraping optimisation
<ggole>
Regarding SIMD, that would be an interesting experiment
<ggole>
It's actually pretty hard to use SIMD manually, though
Yoric has quit [Ping timeout: 246 seconds]
<ggole>
People usually start to stumble when it comes to translating things they would usually write as conditional expressions.
<mrvn>
If you want to improve optimization in ocaml then the first thing you should do is implement inlining for closure arguments.
<ggole>
Closure arguments?
<mrvn>
as in: f (fun x -> x) should inline f and then inline the closure into that.
<ggole>
Oh, I see.
<mrvn>
ggole: any form of function as argument actually.
<gasche>
Pierre Chambart is trying to do that, feel free to help with the review of his code
<mrvn>
There are a lot of polymorphic functions that could be optimized a lot if the function argument where inlined so the compiler knows the type.
<mrvn>
monomorphising would get them too but would be much more complex.
<mrvn>
What do you think about making labels first class types? type r = { a:int; b:int; } let get r l = r.l let a = get r .a
<ggole>
Seems tough to implement
<ggole>
Javascript, Lua and the like implement that efficiently, but the required machinery is considerable
<ggole>
(From what little I know of their design.)
<mrvn>
ggole: memory wise it is just an int, the offset into the record.
<ggole>
Only if the label is indexed by type? Otherwise you need to have a map of some kind
<mrvn>
type wise is't a bit like <record> -> <type of label>
<ggole>
Ah, right. In that case, ignore my comment about efficiency.
<ggole>
I thought you were suggesting that it should work for any record type.
<mrvn>
for a different record type s you couldn't do "get s .a". That wouldn't type.
<ggole>
Hmm, seems a bit like first class constructors
<mrvn>
ggole: I miss those too
<ggole>
You'd have to index by both the type of the record and the type of the member, yes?
<mrvn>
ggole: no. you index by the offset. the type holds the type.
<gasche>
SML has #l (iirc) as a notation for (fun x -> x.l)
<ggole>
So what's the return type of let get r l = r.l
<mrvn>
.a is (0 : r . int) and .b is (4/8 : r . int)
<gasche>
in absence of polymorphic/extensible records, that's just syntactic sugar
<mrvn>
get : 'a -> 'a . 'b -> 'b
<mrvn>
gasche: simplifies having to pass a getter and setter closure
<gasche>
yeah, they're only getters in this case
<gasche>
that said, as already discussed, maybe Lenses are the way to go in terms of expressivity
<gasche>
(and in this case there may not be space in the *exposed* language design for a less expressive but more efficient notion; but maybe there is)
<ggole>
mrvn: right, that's what I though ("indexed by" meaning roughly "takes an argument of")
<mrvn>
let set r l x = r.l <- x should work too
struktured has joined #ocaml
<ggole>
This is vaguely appealing because it would allow incr and decr to be generalised to all mutable records.
<gasche>
(get 0) is well-typed, that's a bit ugly
<gasche>
(but such compromises are known to exist in the programming language theory of records)
<mrvn>
gasche: how? There is no type "int . 'a"
<gasche>
note my partial application
<mrvn>
gasche: ok, the type system lacks the syntax to restrict the first arguments to a record.
appleby has joined #ocaml
<mrvn>
gasche: The compiler could check wether the resulting type could potentially be populated.
<appleby>
hey flux? remember me? the guy questioning about paparazzi? can I ask you about my code in a while??
<mrvn>
(get 0) : int . 'a -> 'a can't have any member so it is an error.
<flux>
appleby, I guess :)
<mrvn>
gasche: still wouldn't get everything but everything that matters
<gasche>
mrvn: so does (raise Exit), so you'd have to be careful with the warning, but yeah, you can work around that with tooling
struktured has quit [Client Quit]
divyanshu has quit [Quit: Computer has gone to sleep.]
<mrvn>
gasche: (raise Exit) : 'a -> 'b. That is a perfectly valid type.
<mrvn>
-Exit
<gasche>
note my application :-'
<mrvn>
gasche: raise Exit has type 'a. perfectly valid.
<gasche>
just as (int . 'a -> 'a) ?
<gasche>
they're also both empty types
<mrvn>
gasche: no "int . " is an error
<mrvn>
int is not a record
<gasche>
so validity in your type system is not stable by instantiation? erk
<mrvn>
gasche: the problem is the lack of "'a constrained 'a is a record"
<gasche>
(what's the native english onomatopoeia for disgust? ^^)
<mrvn>
onomatopoeia?
<gasche>
"name whose semantics is carried by its pronunciation"
<ggole>
Blerg, maybe (w/drawn out er)
<ggole>
With a faint suggestion of vomit: bleeeeerrrrghhgh
<ggole>
(It's not actually an english word, though.)
<gasche>
it is if native speakers recognize it
<ggole>
Oh, they will if you say it right.
<ggole>
I imagine opinions on spelling will vary though.
appleby has quit [Quit: appleby]
<ggole>
In an unhappy coincidence, blerg happens to be the perfect word to describe the code I'm looking at now.
* adrien
has a machine named "blearg" :)
rand000 has quit [Ping timeout: 268 seconds]
tlockney_away is now known as tlockney
divyanshu has joined #ocaml
avsm has quit [Quit: Leaving.]
willy_ has quit [Quit: Leaving]
tobiasBora has quit [Read error: Connection reset by peer]
divyanshu has quit [Quit: Computer has gone to sleep.]
bjkeller has joined #ocaml
<pippijn>
ousado: ok, I took a bit of time and changed the AST
<pippijn>
ousado: the type checking algorithms are still poor :)
bjkeller has quit [Remote host closed the connection]
yacks has quit [Ping timeout: 268 seconds]
tlockney is now known as tlockney_away
q66 has quit [Quit: Leaving]
q66 has joined #ocaml
bjkeller has joined #ocaml
Tamae has quit [Ping timeout: 255 seconds]
q66 has quit [Ping timeout: 252 seconds]
q66 has joined #ocaml
Eyyub has quit [Ping timeout: 255 seconds]
struktured has joined #ocaml
Eyyub has joined #ocaml
Hannibal_Smith has joined #ocaml
appleby has joined #ocaml
appleby has quit [Client Quit]
caseyjames has joined #ocaml
<caseyjames>
Hi, brew installed ocaml here: /usr/local/Cellar/objective-caml/4.01.0_1, but opam switch can't find it. Any one know how I can set it to the homebrew version?
<Drup>
you don't have a "system" switch ?
<caseyjames>
I dont know what you meam
<Drup>
do you have an opam switch called "system" ?
<caseyjames>
Your system compiler has been upgraded. Do you want to upgrade your OPAM installation? [Y/n]... though I think I got it with 'opam init'
divyanshu has joined #ocaml
<Drup>
this switch should correspond to the ocaml you installed with brew
<caseyjames>
I'm getting this now, but I'm not sure if its point to the homebrew version
<adrien>
gasche: which bribe do you want in order to explain Set.S.diff in the documentation? the current explanation is "Set difference" and while it is correct, it was a bit unexpected to me
avsm has quit [Quit: Leaving.]
vpit3833` is now known as vpit3833
Yoric has quit [Ping timeout: 240 seconds]
appleby has quit [Quit: appleby]
Hannibal_Smith has quit [Quit: Sto andando via]
keen_ has joined #ocaml
bjkeller has joined #ocaml
bjkeller has quit [Remote host closed the connection]
Yoric has joined #ocaml
BiDOrD has quit [Quit: No Ping reply in 180 seconds.]
BiDOrD has joined #ocaml
Anarchos has joined #ocaml
ggole has quit []
nikki93 has joined #ocaml
Enjolras has joined #ocaml
jonh has joined #ocaml
<Anarchos>
how to verify if camlp4 is well installed ?
<adrien>
run it?
<mrvn>
.oO(use it or loose it)
<Anarchos>
adrien with the command «camlp4» ?
<adrien>
Anarchos: for instance
<Anarchos>
ok
<Anarchos>
so it is not installed here ...
angerman has quit [Quit: Gone]
<Anarchos>
my camlp4 folder doesn't update anymore with svn, how to force to update or checkout it ?
<adrien>
camlp4 has been split off
ollehar has joined #ocaml
<Anarchos>
oh ok
<Anarchos>
adrien so it was a residue in my ocaml source tree i guess
Myk267 has quit [Quit: Myk267]
mort___ has quit [Quit: Leaving.]
ahill-89 has joined #ocaml
nikki93 has quit [Remote host closed the connection]
avsm has joined #ocaml
mort___ has joined #ocaml
mort___ has quit [Remote host closed the connection]
appleby has joined #ocaml
mort___ has joined #ocaml
axiles has quit [Remote host closed the connection]
rrmk has joined #ocaml
tani has quit [Quit: Verlassend]
<appleby>
hey flux!
zzing_ has joined #ocaml
zzing has quit [Ping timeout: 240 seconds]
mort___ has quit [Quit: Leaving.]
mort___ has joined #ocaml
rand000 has quit [Quit: leaving]
q66 has quit [Ping timeout: 252 seconds]
maattdd has joined #ocaml
rrmk has left #ocaml []
S1100100` has joined #ocaml
S11001001 has quit [Disconnected by services]
S1100100` is now known as S11001001
Yoric has quit [Ping timeout: 246 seconds]
gasche has quit [Ping timeout: 253 seconds]
caseyjames has quit [Quit: Page closed]
q66 has joined #ocaml
avsm has quit [Quit: Leaving.]
tautologico has joined #ocaml
Thooms has quit [Quit: WeeChat 0.3.8]
Kakadu has quit [Quit: Konversation terminated!]
appleby has quit [Remote host closed the connection]
appleby has joined #ocaml
zzing_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
struktured has quit [Quit: Konversation terminated!]
struktured has joined #ocaml
nikki93 has joined #ocaml
divyanshu has joined #ocaml
nikki93 has quit [Remote host closed the connection]
divyanshu has quit [Ping timeout: 265 seconds]
zzing has joined #ocaml
nikki93 has joined #ocaml
mort___ has quit [Quit: Leaving.]
nikki93 has quit [Remote host closed the connection]
nikki93 has joined #ocaml
lostcuaz has joined #ocaml
maattdd has quit [Ping timeout: 240 seconds]
darkf has joined #ocaml
appleby has quit [Quit: appleby]
nikki93 has quit [Remote host closed the connection]
bjkeller has joined #ocaml
madroach has quit [Ping timeout: 252 seconds]
madroach has joined #ocaml
bjkeller has quit [Remote host closed the connection]
WraithM has quit [Ping timeout: 240 seconds]
NoNNaN has quit [Remote host closed the connection]
nikki93 has joined #ocaml
NoNNaN has joined #ocaml
nikki93 has quit [Remote host closed the connection]
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
zzing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]