seanmcl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
badon has joined #ocaml
travisbrady has joined #ocaml
rgrinberg has joined #ocaml
rfk has quit [Quit: leaving]
larhat has quit [Quit: Leaving.]
seliopou has quit [Quit: whaaaat]
travisbrady has quit [Quit: travisbrady]
manizzle has quit [Remote host closed the connection]
seliopou has joined #ocaml
manizzle has joined #ocaml
madroach has quit [Ping timeout: 250 seconds]
madroach has joined #ocaml
t4nk812 has quit [Ping timeout: 246 seconds]
manud has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
travisbrady has joined #ocaml
NoNNaN has joined #ocaml
cesar has joined #ocaml
cesar is now known as Guest64162
q66[lap] has quit [Read error: Connection reset by peer]
Guest64162 has quit [Ping timeout: 250 seconds]
q66[lap] has joined #ocaml
jao has quit [Ping timeout: 255 seconds]
manizzle has quit [Ping timeout: 256 seconds]
travisbrady has quit [Quit: travisbrady]
MrScout has joined #ocaml
MrScout has quit [Remote host closed the connection]
SethTisue has joined #ocaml
MrScout has joined #ocaml
SethTisue has left #ocaml [#ocaml]
Simn has quit [Quit: Leaving]
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
seanmcl has joined #ocaml
MrScout has quit [Ping timeout: 265 seconds]
darkf has joined #ocaml
darkf has quit [Read error: Connection reset by peer]
darkf has joined #ocaml
q66[lap] has quit [Read error: Connection reset by peer]
q66[lap] has joined #ocaml
araujo has quit [Ping timeout: 250 seconds]
hausdorff has joined #ocaml
seanmcl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
araujo has joined #ocaml
ygrek has joined #ocaml
travisbrady has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
BitPuffin has quit [Ping timeout: 258 seconds]
travisbrady has quit [Quit: travisbrady]
BitPuffin has joined #ocaml
q66[lap] has quit [Read error: Connection reset by peer]
manud has quit [Quit: Be back later ...]
q66[lap] has joined #ocaml
nickemery has quit [Ping timeout: 250 seconds]
badon has quit [Quit: Leaving]
emery has joined #ocaml
badkins has quit [Remote host closed the connection]
hausdorff has quit [Remote host closed the connection]
travisbrady has joined #ocaml
BitPuffin has quit [Ping timeout: 240 seconds]
cesar has joined #ocaml
cesar is now known as Guest82323
manud has joined #ocaml
kdef has quit [Ping timeout: 265 seconds]
Guest82323 has quit [Ping timeout: 265 seconds]
hausdorff has joined #ocaml
travisbrady has quit [Quit: travisbrady]
<Drup>
whitequark: would the "not pulled by unless needed" feature of module aliases works with C bindings ?
<Drup>
(like for, let's say, llvm ...)
<Drup>
( -by)
q66[lap] has quit [Read error: Connection reset by peer]
q66[lap] has joined #ocaml
hausdorff has quit [Remote host closed the connection]
kdef has joined #ocaml
seanmcl has joined #ocaml
oscar_toro has quit [Ping timeout: 265 seconds]
seanmcl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pierpa has joined #ocaml
cesar has joined #ocaml
cesar is now known as Guest12441
jabesed has quit [Ping timeout: 255 seconds]
hausdorff has joined #ocaml
hausdorff has quit [Ping timeout: 240 seconds]
ygrek has quit [Ping timeout: 250 seconds]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
samrat has joined #ocaml
hausdorff has joined #ocaml
ygrek has joined #ocaml
manud has quit [Remote host closed the connection]
claudiuc has quit [Remote host closed the connection]
<Drup>
whitequark: I want implicits for llvm_safe
<Drup>
it would make things so much simpler ...
struktured has joined #ocaml
pii4 has quit [Ping timeout: 245 seconds]
pii4 has joined #ocaml
shinnya has quit [Ping timeout: 245 seconds]
MrScout has joined #ocaml
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
samrat has quit [Quit: Computer has gone to sleep.]
MrScout has quit [Ping timeout: 240 seconds]
jao has quit [Ping timeout: 264 seconds]
q66 has quit [Quit: Leaving]
samrat has joined #ocaml
samrat has quit [Quit: Computer has gone to sleep.]
govg has quit [Quit: leaving]
rgrinberg has quit [Quit: Leaving.]
nojb has joined #ocaml
Guest12441 has quit [Remote host closed the connection]
AltGr has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
Muzer has quit [Ping timeout: 245 seconds]
Muzer has joined #ocaml
mcc has joined #ocaml
<mcc>
is the ocaml compiler smart enough that a side-effect-free expression in a let which is not used in a particular code path might not be evaluated?
<mcc>
like, if i say let rest = line::lines in ... , and ... is a match which only uses "rest" in some branches, will rest be evaluated lazily?
<nojb>
mcc: no - the compiler has no way of knowing which match branch will be taken ...
<Drup>
mcc: assume the compile don't optimize.
<Drup>
+r
<mcc>
'k!
<Drup>
(it's not exactly true, but for most of it, it is)
nojb has quit [Quit: nojb]
pierpa has quit [Ping timeout: 264 seconds]
araujo has quit [Quit: Leaving]
<Drup>
mcc: I'm curious (and I missed you last time you talked about it), can you show your post (or something) about the design of emily ?
<mcc>
that's sort of the goal... it's from early this summer, there's a couple things in it that are either vague or contradictory
<mcc>
here's the most compilcated Emily program that has ever been executed https://twitter.com/mcclure111/status/470094709919334402 ... on the sort of failed-attempt interpreter, implementing a somewhat minimal (no macros) version of the language
nojb has joined #ocaml
<mcc>
(one thing that's in the original spec, but which i'd given up on by then, is the idea that (^x + 1) could be a anonymous function for (fun x -> x + 1) … i don't think that's possible with some of the other things i claim about the simplicity of the parser)
manizzle has joined #ocaml
<Drup>
fib in SKI combinators, ewww
ygrek has joined #ocaml
<Drup>
you do realize that "I want OO" and "I want simplicity" are *completely" contradictory ?
<mcc>
i'm not surprised to hear you say so yes
<mcc>
the twitter account currently describes it as an "oo ∩ fp language"
<Drup>
your atoms are totally enums/sum types :D
nojb has quit [Quit: nojb]
<mcc>
yes, that's the goal
<mcc>
or, well, they're probably most like erlang atoms because they'll all be in one big namespace
<mcc>
…that might come back to bite me
<mcc>
anyway when you read this spec what you're mostly looking at is "i wish python had all the cool stuff i remember from sml/nj" :P
<Drup>
Why do you insist on calling functions "block" ? :D
<mcc>
it… that was a bad idea. i've dropped it.
<mcc>
basically, everything in the language is a function.
<mcc>
but some of the functions act like functions and some of them act like objects.
<mcc>
so i was trying to find a word to describe the everything-that-exists-is-one-of-these concept that wouldn't then get confusing when i wanted to say "and then a normal function is just a particular type of [X]"
<mcc>
so i went with block by analogy to smalltalk.
<mcc>
this was very confusing especially because most people think of a block as being one of these { }
<mcc>
i *could* say everything in the language is a combinator
<mcc>
but… i mean who's going to understand that
<Drup>
and anyway, they are functions, you do not introduce any difference with the notion of a function
<Drup>
so, iiuc, "object" here is "a function from atoms to something"
<mcc>
yes. that's the goal.
<Drup>
ok
<mcc>
but i am trying to communicate this idea to people who are maybe not very familiar with functional languages.
<Drup>
so, what if I tell you I implemented this language already, just that I didn't use the same vocabulary ? :D
<mcc>
haha
<mcc>
i'd believe it
<mcc>
it is a somewhat simple set of ideas!
<mcc>
what language did you use?
<Drup>
Haskell
<mcc>
oh, i mean, what vocabulary did you use
<Drup>
oh
<Drup>
type theory :)
<mcc>
makes sense
<Drup>
you are sort of barking the wrong tree
<Drup>
it's not your fault, the community in FP design are completly disjoint
<Drup>
(it's making me so mad, you have no idea)
<mcc>
do you care to explain further
<Drup>
PL design*
<Drup>
there has been a very long ""quest"" in the community of dependently type theory
<Drup>
to come up with a very minimal language that servers as, what they call "foundation of mathematics"
<mcc>
heh
<Drup>
it's like the smallest possible thing that is 1) a logic 2) sound 3) Turing complete
<Drup>
it's obviously dependently typed
<mcc>
sure
<Drup>
and it happens to contains pretty much all you want
<Drup>
It's just ... slightly type hairy. :D
<Drup>
There is a big overlook in article, which is "how the hell do I type that"
<mcc>
ok, you're saying that this is a thing that exists already
<mcc>
yes. i'm not sure any of this is typeable.
<Drup>
well, I just told you it is, but it's not easy :D
<mcc>
and it is likely that if i figure that out, the type system will be constructed in a way many functional ppl would consider unsound
<mcc>
heh
<Drup>
(I'm taking about active research area here)
<mcc>
i'm sure!
<mcc>
so i am doing all this with, in the end, practical goals.
<Drup>
anyway, give me a sec
<mcc>
i want a language which is expressive enough to lash, say, python or lua or actionscript on top of it.
<mcc>
and abstract enough that I can shove c++ objects underneath it without having to change the interstice's semantics.
ggole has joined #ocaml
<Drup>
also mcc, I suppose you know about 1) the GHC's IR 2) the encoding of OO in Haskell ?
<Drup>
GHC's IR is quite minimal
<mcc>
i'm aware of the STG although i only have a vague sense of what it's actually doing. building then resolving thunks, right?
<mcc>
i found the original STG paper at some point.
<mcc>
"encoding of oo in haskell" refers to typeclasses?
<Drup>
but maybe it could be made practical, if it was bolt down into the language
<mcc>
i think i am trying to stay away from anything that is impractical D:
<mcc>
so the *very* little i've gathered about how the STG functions seems to imply that it's sort of geared to stateless languages. would you agree with this?
<Drup>
and lazyness.
<Drup>
but when I was talking about the IR, no, I was not talking about the stg
<ggole>
Speaking of IRs, I failed to get rid of all the Any wrappers in that GADT SSA thing I was playing with
<mcc>
That sounds ominous D:
<ggole>
Can't seem to get existentially qualified things in an array.
<Drup>
ggole: ah yes, I wanted to ask: where is the code ? :D
<ggole>
Oh, I'll stick it up somewhere
<mcc>
"system f"
<ggole>
mcc: forget about GADTs and it shoudln't be a problem :)
<mcc>
is f# related to system f?
<Drup>
not really
<mcc>
GACKT
<Drup>
well, It's probably a play on the name
<Drup>
but that's all
<Drup>
(well, except the fact that system f is a very simple functional language, and f# is a functional language)
<Drup>
mcc: anyway, that was the functional part of the state of the art. Every language design should start by an thorough state of the art investigation. :]
<mcc>
I have been trying to research things. But my practical experience lies more with oo langs
Guest33553 has quit [Ping timeout: 255 seconds]
<Drup>
Yes, I'm not surprised.
<struktured>
mcc: join the club :). even in OO language though yo ucan be functional
<ggole>
I should pull the table out and document it a bit, maybe that could be useful
<Drup>
do a repository already, instead of gists x)
<ggole>
Eh, it's just a toy
<Drup>
and ? can't you have toy repositories ? :D
<ggole>
I guess so.
<whitequark>
Drup: re module aliases: yes, I think it would work
<Drup>
mcc: regarding the notation "(^x + 1)" you evoked earlier
<Drup>
the issue is not really the grammar but more "how much do I expand the body of the function
<mcc>
i … think that sounds right, yes
<Drup>
let me take an example : "(^x.foo.bar.baz)"
samrat has joined #ocaml
<Drup>
is that "(^x -> x.foo).bar.baz" "(^x -> x.foo.bar).baz" or "(^x -> x.foo.bar.baz)"
<Drup>
you need an heuristic, or a syntactic marker :/
<mcc>
right, yes.
<mcc>
i'd be a little more worried about, like...
guest652 has joined #ocaml
<mcc>
^x ( 3*(x + 1) )
kandu has quit [Ping timeout: 245 seconds]
<mcc>
if i tried to use the in-context-^ syntax that would be ( 3*(^x+1) ) ... wait... is the inner parens the function or the outer parens? how do you tell
<mcc>
then there's the horrible question of currying
<mcc>
(^x + ^y)
<mcc>
"x" is the first argument? why? because it appears earlier in the function?
<mcc>
ghastly
<Drup>
since the name is worthless, you can just use "_" instead of ^x
<Drup>
(I mean, you can't use the x, can't you ?)
<mcc>
anyway, that was a bad idea, but gosh ^x(3*x+1) is ugly and does not seem like it is fitting my goal of "appeal to python programmers more so than ppl who love FP already"
<Drup>
\x.(3*x+1) is already much more familiar =')
<Drup>
or "fun x -> 3*x+1" for ML/symbol-allergic people
<mcc>
yes, well, i'm TRYING to be a LITTLE more clear than that :P
<mcc>
i actually did go with \ in the first drafts
<mcc>
but then i found myself writing \(x = x + 1) everywhere
<mcc>
looked ... not good.
<Drup>
you can use the rust/ruby syntax too
<Drup>
I find it ... shockingly horrible
<Drup>
but at least, ruby programmers know it.
<mcc>
the parser generator in my head has troubles with ruby.
<mcc>
not sure why.
<mcc>
actually, emily is shockingly similar to ruby.
<mcc>
maybe i should just be writing ruby…?
<Drup>
you mean that it doesn't have a type system ? :D
<mcc>
except ruby is not deployable in the environments i'm interested in
<mcc>
it has… aspirations to a type system.
<Drup>
ahah, aspirations :p
<Drup>
emily doesn't sound similar to ruby to me, but I don't know ruby all that much (and I'm happy that way)
<Drup>
well, at least whitequark's war stories about ruby's parser are funny.
<mcc>
yeah D:
<Drup>
mcc: the only thing I have to say about the grammar is: make it LALR or LL*
<mcc>
i don't have a grammarrrr
<Drup>
well, you should.
<mcc>
the parser is a left-to-right scanner
<Drup>
not having a grammar is the first step into C++.
<whitequark>
hahahahaha
<mcc>
i… ow.
<mcc>
drup. that cuts deep.
<Drup>
I should kept this quote, it was not indented, but it might serve in the future.
MercurialAlchemi has joined #ocaml
<Drup>
keep* ~~
<Drup>
mcc: sorry, but no sorry n__n
<Drup>
I happen to be having the first draft of a JIT-based language using sedlex and menhir, would you like to see it ? :D
<mcc>
i'd be happy to look but i am suuuuper sleepy and just about to go to bed
<Drup>
no problem, it's not really ready anyway, the codegen is broken
<whitequark>
you need to run constant folding before codegen
<Drup>
Oh.
<whitequark>
better, just use Llvm_passmgr_builder.
<mcc>
whitequark: thank you!
<whitequark>
it scares me somewhat that I can debug LLVM failures by just looking at the errors, even not source code
<mcc>
oh hm geez and working i even have ~~state~~
<mcc>
.set works
slash^ has joined #ocaml
<mcc>
i wanna hurry up and get to closures so i can be turing complete
<mcc>
i was thinking
<whitequark>
state is a tool of oppression, you should embrace haskell, the only true stateless language
<whitequark>
(ahem)
<mcc>
oh, let's not joke about that :(
<whitequark>
okay
<mcc>
i was thinking, maybe i could use ppx to inline emily code (i.e. inline some emily and it returns a closure value) into the emily interpreter itself :D
<Drup>
the idris guy did a whole talk about a (mostly) pure functional language without saying the m- word.
<mcc>
hahaha
* mcc
had some not great experiences with the haskell community.
<whitequark>
mcc: you sorta could, but that creates a problem
<whitequark>
namely bootstrapping
<mcc>
whitequark: oh, well, what i mean is
<whitequark>
you need to build the ppx extension in order to build emily, and you need to build emily...
<Drup>
well, you don't need emily
<mcc>
whitequark: the PPXed code would just turn into a parse tree
<mcc>
but i can just tell the macro system "gcc -E this please" and it will spit out something that looks more like java
<ggole>
(It can be in Lisp, though.)
<mcc>
whitequark: lol
<mcc>
actually, when i was…
<Drup>
mcc: it contradicts you "there is only one way to do it"
kandu has joined #ocaml
<Drup>
your*
<mcc>
drup: did i say that?
<Drup>
you praised python's mantra, so I assumed you wanted the same
AltGr has left #ocaml [#ocaml]
<mcc>
i like python a lot.
<mcc>
but, well, there is a reason i am not writing in it.
<Drup>
and it is ?
<mcc>
okay, there are several reasons. no types, embeddability is *very* poor, language does not allow well for what i consider higher-level abstractions, scopes and closures are more awkward than they could be, string manip is more awkward than it could be, *very* serious performance problems emerge if you try to use the builtin types to for example store intermediate data if doing something binary-oriented such as image manipulation
<mcc>
…oh, and the GIL.
<mcc>
should i keep going?
<Drup>
so, hum, why do you like it in the first place ? :D
<mcc>
tulip seems nice
<mcc>
It's CLEAN
<mcc>
and it's not perl or sh.
<Drup>
isn't lua as clean and less fucked up ?
<mcc>
it just feels good. i like the way python feels. i think that feel is worth trying to reproduce
<mcc>
yes, i spent most of the last two years writing lua
<jerith>
Many of the reasons I like Python are the exact opposite of many of the reasons I like OCaml.
<mcc>
lua is really lovely
<ggole>
Well implemented, too
<mcc>
luajit's c ffi is a revelation
<jerith>
But both Python and OCaml are languages that feel comfortable to work with.
<Drup>
I personally can't write a line of code in Python
<Drup>
I keep trying to typecheck the code in my mind
<Drup>
and I can't do it
<mcc>
do not worry, you can typecheck the code at runtime, in production
<Drup>
that's not how I write code. :)
<mcc>
i actually spent about two years writing almost nothing but lua outside work, and then about one year ago i stopped and suddenly realized i didn't like programming anymore
<jerith>
That's what tests are for. ;-)
<mcc>
… actually, come to think of it, i spent two years writing nothing but objective-c at work and nothing but lua at home. and then immediately ater that i designed emily. maybe this explains something :P
<Drup>
jerith: may I insert swearing ? :)
<mcc>
oh, the ^ / block syntax is a little stolen from objc.
<mcc>
but that's cuz objc thinks it's smalltalk.
<ggole>
I find it hard to forgive python for conflating assignment and binding.
<ggole>
Which is pretty snobbish of me, cos I don't think it's actually all that important.
<ggole>
But still, AARGH
<mcc>
drup: you don't think it's reasonable to expect 100% code path coverage so you can be sure you didn't misspell a variable?
<jerith>
Tests are important even if you have a decent type system.
<jerith>
You just need more of them if you don't.
<Drup>
whitequark: I need one of your pictures, you know the ones for when you think about software.
<jerith>
I find that both Python and OCaml give me reasonably good tools for building useful programs. They're very different tools, though.
<mcc>
a thing i like about python is i never feel guilty for foisting a python program on someone.
<mcc>
like, i do not feel bad at all about leaving python scripts on the repository at work.
<jerith>
(I've read the first four chapters. Two of them are about emacs.)
<Drup>
still doing it.
<mcc>
okay i am going to sleep! it was good to talk to you all
<ggole>
o/
mcc has quit [Quit: >@> ... seriously ... it's a fish operator]
<Drup>
next time I'm writing a snippet of code to demonstrate a point, I'm definitely using this fish operator.
<ggole>
>-<@@%>
<ggole>
That's totally a flounder.
<Drup>
whitequark: ok, I'll just add this example in the tests in the llvm tree, and I'll let you fix the code, you know it better than me anyway, you should be the one rewriting it.
<Drup>
I'm a front end guy :<
<whitequark>
Drup: okay
<whitequark>
did you do anything to the tutorial text?
<Drup>
not yet
<whitequark>
ok
<Drup>
but a good part of it will burn
<whitequark>
ok, that's great
<Drup>
especially the part saying "hey, let's add custom priorities in our language, because it's so great to write a hand made parser"
<Drup>
in an llvm tutorial.
<Drup>
/me stares.
<ggole>
Now that's focus.
<Drup>
:]
nicoo has quit [Remote host closed the connection]
nicoo has joined #ocaml
<Drup>
ggole: why don't you replace insns by a gadt list ending by a control def ?
<ggole>
Its convenient to have the control insn directly available in a block, since it contains the info necessary to iterate successors.
<ggole>
As for the list, I'd like to have reasonable append.
<ggole>
(For things like PRE and SSA destruction.)
<Drup>
oh, didn't saw the ctrl separated, you are right.
<Drup>
as for insns, you want an ex, not a forall, but you knew that
<ggole>
Yeah
<ggole>
There's no good way to do that, is there
<ggole>
(Apart from the any wrapper.)
<Drup>
I'm afraid not.
<ggole>
Apart from the match duplication and that issue though, this is fairly reasonable.
<Drup>
there is a thing you don't solve here, it's the notion of user/uses, which is the one causing me troubles for the llvm typesafe api
<ggole>
Ah, I don't keep def->use lists
<Drup>
yes.
<ggole>
My approach at the moment is to avoid maintaining them by building them explicitly only for passes which need that info.
<ggole>
Eg, sccp
<ggole>
...but as soon as I actually did that I would run into the same problem.
<Drup>
yes
<Drup>
and creating geters and setters is not very nice.
<ggole>
Mmm.
<ggole>
How are you planning to tackle that one?
<Drup>
that's precisely the issue, I don't know
<Drup>
if it was immutable, I would have smart constructors
MercurialAlchemi has quit [Ping timeout: 258 seconds]
<ggole>
Mmm, mutation ruins everything
<Drup>
oh, also
* nicoo
mutates ggole with the foul powers of the Warp
<ggole>
I can justify myself if pressed: the same sort of cheap bullshit is used by Cliff Click in one of his papers
<Drup>
on that, and before nicoo repaint the chan with blood and vomit, I will go to bed.
<ggole>
That means it's OK!
<nicoo>
Yes, slightly evil (hash Add(a,b) = hash Add(b,a) and so on)
<nicoo>
Drup: It's not that bad :þ
<nicoo>
'night
<Drup>
nicoo: the non randomisation is
samrat has quit [Ping timeout: 264 seconds]
<ggole>
nicoo: actually I canonicalise the defs in another function rather than the equality/hash
<Drup>
it's completly deterministic, hence bad bucket distribution, all that
<nicoo>
Drup: It is, but some people (who sound like inanimate characters from a Valve franchise) dream up justification for them
octachron has joined #ocaml
samrat has joined #ocaml
cesar has joined #ocaml
<Drup>
("hash Add(a,b) = hash Add(b,a)" is actually desirable for hash-consing purposes :p)
cesar is now known as Guest90038
<ggole>
Right, numbering is basically hash-consing for an IR.
<Drup>
anyway ggole, if you come up with an idea for users, I'm very interested
<ggole>
And much like hash-consing, the SSA property means that equality has run for operands before they are considered in the definition
<ggole>
It's quite a neat correspondence.
<ggole>
Drup: OK. I wouldn't hold my breath though. :(
Guest90038 has quit [Ping timeout: 255 seconds]
koderok has joined #ocaml
<Drup>
ggole: well, the thing is, either I have a solution for implicit user graph construction, or I use an immutable IR.... but I can't use an immutable IR with "name=instruction" (or, at least, I don't see how to tie the knot)
<Drup>
I don't consider the option "not build the user graph" as really acceptable.
ollehar has joined #ocaml
<ggole>
Yeah, you need to build def->use lists at some point.
<Drup>
and having an explicit build step for an mutable IR is asking for troubles
bezirg has joined #ocaml
hausdorff has quit [Remote host closed the connection]
<whitequark>
"You might want to prepare a sick bag. If your initials are X.L., you'd better stop reading this post right now." hahaha
samrat has quit [Quit: Computer has gone to sleep.]
<ggole>
It's a clever hack all right, but... Ritchie would have called this "unwarranted chumminess with the implementation".
MercurialAlchemi has joined #ocaml
<ggole>
I'm not quite sure how to think about mutable things and identity-versus-structure, to be honest.
<ggole>
Sometimes you want one and sometimes the other.
_whitelogger has joined #ocaml
Simn has joined #ocaml
govg has quit [Ping timeout: 240 seconds]
govg has joined #ocaml
govg is now known as Guest4390
<companion_cube>
Drup: don't you ever sleep?
<Drup>
sure, I'm going to bed now
Guest4390 has quit [Client Quit]
govg_ has joined #ocaml
<companion_cube>
(btw, did you really quadrarotadid a JIT language?)
kakadu has joined #ocaml
koderok has quit [Ping timeout: 240 seconds]
* companion_cube
wondering whether Chambart's inlining work includes some purity annotations
shinnya has joined #ocaml
<whitequark>
purrrity
<companion_cube>
hmmm
<ggole>
Is that inlining stuff still in the pipeline? It's been a long time.
<companion_cube>
a long time indeed :/
guest652 has quit [Ping timeout: 250 seconds]
ygrek has quit [Ping timeout: 272 seconds]
libertas has quit [Ping timeout: 272 seconds]
libertas has joined #ocaml
q66[lap] has quit [Read error: Connection reset by peer]
q66[lap] has joined #ocaml
hausdorff has joined #ocaml
thomasga has joined #ocaml
hausdorff has quit [Ping timeout: 255 seconds]
fraggle_ has quit [Remote host closed the connection]
govg_ has quit [Quit: leaving]
eni has joined #ocaml
<eni>
# List.nth [1;2;3] 3
<eni>
;;
<eni>
Exception: Failure "nth".
<eni>
is this normal ?
<mrvn>
only if you can count (starting with 0)
<eni>
oh
<eni>
haha
<eni>
thanks
<mrvn>
np
cesar has joined #ocaml
cesar is now known as Guest12572
eni has quit [Ping timeout: 265 seconds]
Guest12572 has quit [Ping timeout: 264 seconds]
eni has joined #ocaml
eni has quit [Client Quit]
fraggle_ has joined #ocaml
bezirg has quit [Quit: Leaving.]
kakadu has quit [Quit: Konversation terminated!]
kakadu has joined #ocaml
ygrek has joined #ocaml
rand000 has joined #ocaml
Submarine has quit [Ping timeout: 264 seconds]
samrat has joined #ocaml
contempt has joined #ocaml
samrat has quit [Ping timeout: 250 seconds]
Anarchos has joined #ocaml
oscar_toro has joined #ocaml
samrat has joined #ocaml
Anarchos has quit [Client Quit]
axiles has joined #ocaml
BitPuffin has joined #ocaml
cesar has joined #ocaml
cesar is now known as Guest86174
seanmcl has joined #ocaml
samrat has quit [Ping timeout: 240 seconds]
samrat has joined #ocaml
Guest86174 has quit [Ping timeout: 272 seconds]
fraggle-boate has joined #ocaml
hugomg has joined #ocaml
dsheets has quit [Ping timeout: 240 seconds]
contempt has quit [Remote host closed the connection]
lordkryss_ has joined #ocaml
mfp has quit [Ping timeout: 244 seconds]
contempt has joined #ocaml
jabesed has joined #ocaml
hausdorff has joined #ocaml
Thooms has joined #ocaml
q66 has joined #ocaml
hausdorff has quit [Ping timeout: 255 seconds]
samrat has quit [Ping timeout: 265 seconds]
octachron has quit [Quit: Leaving]
samrat has joined #ocaml
<hugomg>
Is there a way, from my linux machine, to compile my ocaml program into a windows executable? Right now I'm trying to to install WODI on Wine but I have no idea if thats gonna work or if its something sensible to do lol.
Simn has quit [Ping timeout: 244 seconds]
<adrien>
sensible -> not
<adrien>
debian and fedora have packages
<adrien>
there are patches floating around too
<adrien>
but might not be less work than doing it on windows
<MercurialAlchemi>
you could also port your program to F# :)
<hugomg>
adrien: what packages are you talking about?
<adrien>
cross-compiler
shinnya has quit [Ping timeout: 256 seconds]
ygrek has quit [Remote host closed the connection]
ygrek has joined #ocaml
seanmcl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<companion_cube>
whitequark: [%ord (int,_)] is a great idea
<whitequark>
yup
pyon has quit [Quit: restart]
pyon has joined #ocaml
<hugomg>
ah, ocaml-mingw-w64-x86-64 looks like it. Do you know if I'll be able to integrate this into opam somehow? I'd get hopelessly lost without ocamlbuild being able to find packages on its own :)
<companion_cube>
oh, Str is for building structures
<whitequark>
although, hm, you can't put attributes on structure items, rather only on value bindings?..
cdidd has quit [Ping timeout: 265 seconds]
samrat has quit [Quit: Computer has gone to sleep.]
Anarchos has joined #ocaml
hausdorff has joined #ocaml
wwilly has joined #ocaml
hausdorff has quit [Ping timeout: 244 seconds]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
travisbrady has joined #ocaml
lordkryss_ has quit [Quit: Connection closed for inactivity]
samrat has joined #ocaml
samrat has quit [Client Quit]
darkf has quit [Quit: Leaving]
samrat has joined #ocaml
travisbrady has quit [Quit: travisbrady]
contempt has quit [Remote host closed the connection]
Simn has joined #ocaml
travisbrady has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
travisbrady has quit [Quit: travisbrady]
rgrinberg has joined #ocaml
hausdorff has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
hausdorff has quit [Ping timeout: 265 seconds]
cesar has joined #ocaml
cesar is now known as Guest86292
Guest86292 has quit [Ping timeout: 256 seconds]
govg has joined #ocaml
hausdorff has joined #ocaml
rgrinberg has joined #ocaml
jabesed has quit [Ping timeout: 264 seconds]
jabesed has joined #ocaml
manizzle has quit [Remote host closed the connection]
travisbrady has joined #ocaml
travisbrady has quit [Client Quit]
jao has quit [Ping timeout: 255 seconds]
willy_ has joined #ocaml
ygrek has joined #ocaml
wwilly has quit [Ping timeout: 272 seconds]
cesar has joined #ocaml
cesar is now known as Guest7213
demonimin has quit [Ping timeout: 244 seconds]
jabesed has quit [Quit: Konversation terminated!]
koderok has joined #ocaml
koderok has quit [Client Quit]
contempt has joined #ocaml
guest652 has joined #ocaml
oscar_toro has quit [Quit: Leaving.]
gdsfh has quit [Ping timeout: 250 seconds]
dav has joined #ocaml
yomimono has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
kdef has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
kdef has quit [Quit: peace]
nicoo has quit [Ping timeout: 250 seconds]
nicoo has joined #ocaml
gdsfh has joined #ocaml
pgomes has joined #ocaml
Hannibal_Smith has joined #ocaml
struktured has quit [Ping timeout: 265 seconds]
emery has quit [Remote host closed the connection]
ygrek has quit [Ping timeout: 258 seconds]
struktured has joined #ocaml
rgrinberg has joined #ocaml
martintrojer has quit [Ping timeout: 255 seconds]
dav has quit [Quit: leaving]
martintrojer has joined #ocaml
yomimono has quit [Ping timeout: 255 seconds]
myst has quit [Quit: Leaving]
ygrek has joined #ocaml
myst has joined #ocaml
travisbrady has joined #ocaml
mfp has joined #ocaml
<struktured>
is there a quick and dirty (command line) tool to derive an mli file stub from a compiled ml module?
<Drup>
ocamlc -i
<struktured>
Drup: cool, that seems simple enough thanks
<nojb>
Drup: you need the .ml for that, right ?
<Drup>
yes
<struktured>
nojb: thats fine in my case. now I just need a smart way to add it to it omake as some sort of build target or side effect
<Drup>
hum
travisbrady has quit [Quit: travisbrady]
<Drup>
what's the point ?
<nojb>
Is there a way to print the .mli from the .cmi ?
mcc has joined #ocaml
<struktured>
Drup: I find maintaining mli cumbersome when the signatures are in flux. like the idea of generating later, then annotating the generated version.
<struktured>
somehow I find myself wishing ppx could hide certain things from modules or make them more abstract, then just code gen the mli during build time
<Drup>
right, you would like .mlis to be integrated in .mls
<struktured>
I still think u publish the mli though. def see th value in that
<ggole>
(More convenient ascription *would* be nice...)
<ggole>
...although I'm saying that after just gone through an experiment involving first class polymorphism, which might have coloured my view on that.
<Drup>
well, the issue with gadt's is that inference is undecidable so ... :p
<Drup>
(but the typechecker could be made more convenient for that)
tane has joined #ocaml
<ggole>
Sure, you need annotations. So it would be nice if annotations didn't involve a bit of syntactic juggling.
rgrinberg has quit [Quit: Leaving.]
<struktured>
I wonder how long the ppx extension wish list is. I am impressed with what's out there already, but there's so much you can still do with it
pgomes has left #ocaml ["Leaving"]
<struktured>
Drup: is anyone working on integrating mli definitions into ml source files with extensions or otherwise? or is this frowned upon?
<Drup>
I don't know about anyone working, and I think "frowned upon" is an accurate description
sinelaw has joined #ocaml
guest652 has quit [Ping timeout: 245 seconds]
ygrek has quit [Ping timeout: 264 seconds]
hugomg has quit [Ping timeout: 245 seconds]
lordkryss_ has joined #ocaml
demonimin has joined #ocaml
expo873_ has joined #ocaml
mrvn_ has joined #ocaml
expo873 has quit [Ping timeout: 265 seconds]
mrvn has quit [Ping timeout: 265 seconds]
mcclurmc_ has joined #ocaml
<whitequark>
Frisch has an example that does exactly this
<whitequark>
but I don't really think it's a good idea, too.
srcerer_ has joined #ocaml
dmiles has joined #ocaml
fraggle-boate has quit [Ping timeout: 265 seconds]
nojb has quit [Quit: nojb]
fraggle-boate has joined #ocaml
hcarty_ has joined #ocaml
cojy has quit [Ping timeout: 265 seconds]
pyon has quit [Quit: stupid emacs]
dmbaturin_ has joined #ocaml
clog_ has joined #ocaml
pyon has joined #ocaml
ggherdov has quit [Ping timeout: 265 seconds]
cojy has joined #ocaml
nickmeharry has joined #ocaml
Mercuria1Alchemi has joined #ocaml
Snark_ has joined #ocaml
vincom2_ has joined #ocaml
<Drup>
what I would like is that "_" would be recognized as "infer the type and use it" in mlis, including deep into a signature (int -> _ for a function, for example
brendan_1 has joined #ocaml
<Drup>
there are some types, especially when manipulating polymorphic variants, that I don't want to spell out ...
srcerer has quit [Ping timeout: 245 seconds]
dmiles_afk has quit [Ping timeout: 245 seconds]
hcarty has quit [Ping timeout: 245 seconds]
mcclurmc has quit [Ping timeout: 245 seconds]
segmond has quit [Ping timeout: 245 seconds]
vincom2 has quit [Ping timeout: 245 seconds]
ggole has quit [Ping timeout: 245 seconds]
dmbaturin has quit [Ping timeout: 245 seconds]
brendan has quit [Ping timeout: 245 seconds]
clog has quit [Ping timeout: 245 seconds]
tov has quit [Ping timeout: 245 seconds]
Snark has quit [Ping timeout: 245 seconds]
MercurialAlchemi has quit [Ping timeout: 245 seconds]
nickmeha1ry has quit [Ping timeout: 245 seconds]
<companion_cube>
I'd rather have "module type S = ..." in the .ml, that would copy the realy definition from the .mli
<Drup>
companion_cube: ppx import !
<companion_cube>
meh
ggole has joined #ocaml
<Drup>
It's dubious to be ever added in the core language, so it's not a bad solution
tov has joined #ocaml
<Drup>
especially since there seem to be a trend of "not adding things in the language that can be done equally good as a ppx (cf nonrec)
<companion_cube>
currently I just use a Foo_intf module where I put modules types of Foo
<Drup>
yes, I do that too
hugomg has joined #ocaml
Khady_ has joined #ocaml
engil1 has joined #ocaml
rks`_ has joined #ocaml
bobpoekert_ has joined #ocaml
mekaj_ has joined #ocaml
guest652 has joined #ocaml
bgianf_ has joined #ocaml
bitbckt_ has joined #ocaml
Asmadeus_ has joined #ocaml
bobpoekert has quit [Ping timeout: 265 seconds]
engil has quit [Ping timeout: 265 seconds]
bgianf has quit [Ping timeout: 265 seconds]
gperetin has quit [Ping timeout: 265 seconds]
mekaj has quit [Ping timeout: 265 seconds]
rks` has quit [Ping timeout: 265 seconds]
struktured has quit [Ping timeout: 265 seconds]
rossberg has quit [Ping timeout: 265 seconds]
Asmadeus has quit [Ping timeout: 265 seconds]
__marius______ has quit [Ping timeout: 265 seconds]
iZsh has quit [Ping timeout: 265 seconds]
averell has quit [Ping timeout: 265 seconds]
Unhammer has quit [Ping timeout: 265 seconds]
mawuli has quit [Ping timeout: 265 seconds]
hbar has quit [Ping timeout: 265 seconds]
Khady has quit [Ping timeout: 265 seconds]
bitbckt has quit [Ping timeout: 265 seconds]
fraggle_ has quit [Ping timeout: 265 seconds]
rwmjones has quit [Ping timeout: 265 seconds]
bobpoekert_ is now known as bobpoekert
smondet has quit [Ping timeout: 265 seconds]
smondet has joined #ocaml
__marius______ has joined #ocaml
segmond has joined #ocaml
struktured has joined #ocaml
demonimin has quit [Ping timeout: 265 seconds]
iZsh has joined #ocaml
averell has joined #ocaml
gperetin has joined #ocaml
esden has quit [Ping timeout: 265 seconds]
<struktured>
whitequark: do you have a link to the frisch's example ?
hausdorff has quit [Remote host closed the connection]
flux has quit [Ping timeout: 272 seconds]
flx is now known as flux
* Mercuria1Alchemi
wonders how long code.google.com will last before it gets assimilated
* struktured
thinks same thing about sourceforge
badkins has joined #ocaml
<Leonidas>
Mercuria1Alchemi: assimilated into what
<Leonidas>
report bitstring? where? To the ppx-police? ;9
<Mercuria1Alchemi>
Github, obviously
vbmithr has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
<Leonidas>
Mercuria1Alchemi: don't think so, because that would be Google giving control to someone else. My bet is for it to turn into a half-dead zombie, SourceForge-style
mcclurmc has joined #ocaml
<bobpoekert>
I filed a bug report on the google code project but there haven’t been any bugs fixed since 2008 so I’m not optimistic
iZsh has joined #ocaml
<Leonidas>
I heard there is only one guy on it, just keeping it running and that's it.
slash^ has quit [Read error: Connection reset by peer]
<Mercuria1Alchemi>
Leonidas: I'd imagine they'd close it down or leave it as read-only, something like this
<Mercuria1Alchemi>
Nobody made a VCS in OCaml?
c74d has joined #ocaml
<Mercuria1Alchemi>
Haskell has Darcs...
<Leonidas>
i think we got enough VCSes in this generation :-)
<Leonidas>
darcs is pretty dead if I remember correctly
<Drup>
darcs died by over-haskellism
seliopou has joined #ocaml
<Drup>
"what, I need to install a 2Go compiler to fetch the repository ?"
<Mercuria1Alchemi>
I think it never got really good performances (or if it did, it got there too late)
<Drup>
that too
<Mercuria1Alchemi>
bah, who's counting
<Drup>
sad, because it's much cleaner than git
<Mercuria1Alchemi>
hm, I guess some people have metered Internet these days
<companion_cube>
doesn't its cleanessness make it slow?
<Drup>
not really, no
<Mercuria1Alchemi>
never tried it
<companion_cube>
you have to make more and more patches commute
<Mercuria1Alchemi>
does it let you rewrite history?
<Drup>
it's much better than that
<Drup>
basically, everything comutes
<Drup>
the notion of rebase doesn't even exist, since you can pile up things on top of each other in anyway, or even "filter" a repository (that's how you got the equivalent of branches)
<Drup>
(ocsigen was using it, before we went to github)
<Mercuria1Alchemi>
right
<sirGrey>
@bobpoekert, issue 24 is fixed July 2014, alive enough me thinks
<Mercuria1Alchemi>
so it doesn't really care about ordering patches unless they have dependencies
tristero has joined #ocaml
* Mercuria1Alchemi
reads about Darcs and stumbles upon GNU Arch by accident
<Mercuria1Alchemi>
"replaced by bzr"
<Mercuria1Alchemi>
guys...
<Mercuria1Alchemi>
anyway, sounds interesting
<Mercuria1Alchemi>
don't know how intuitive it is in practice though
<companion_cube>
maybe darcs could be reimplemented in ocaml and conquer the world :>
<companion_cube>
I'm couting on you, Drup
<Mercuria1Alchemi>
while Git's UI is an abomination, it's quite powerful
<bobpoekert>
oh it only shows open issues by default
<bobpoekert>
ok
<Mercuria1Alchemi>
is OCaml itself stuck with SVN?
bytbox has quit [Remote host closed the connection]
<companion_cube>
probably, but then ocaml is stuck with many old things
Fullma has quit [Read error: Connection reset by peer]
<companion_cube>
at least the compiler is getting smaller and things that are split from it can evolve quicker
<Mercuria1Alchemi>
I was thinking the other day that maybe something like OCaml Platform could be a thing
<companion_cube>
yes, but not from Gallium
<Mercuria1Alchemi>
a blessed set of compatible libraries to get started on
<companion_cube>
people have been discussing it
<companion_cube>
there's even a mailing list if I recall correctly
srcerer_ is now known as srcerer
<Mercuria1Alchemi>
Gallium, that's the team of maintainers?
<companion_cube>
yes, the team from Inria that wrote and maintains OCaml
<Mercuria1Alchemi>
would they oppose that?
<companion_cube>
they don't want to have to maintain too big things, afaik
<companion_cube>
that's why the "standard library" doesn't grow
<Drup>
Mercuria1Alchemi: it's actually ... easier to use.
<Mercuria1Alchemi>
Drup: Darcs?
mcclurmc_ has joined #ocaml
<Drup>
but anything is easier to use than git
<Mercuria1Alchemi>
well, the underlying system is quite decent, but the CLI...
<Mercuria1Alchemi>
"let's have one command to do five different, unrelated things, this will confuse the enemy"
<companion_cube>
how complicated is darcs' theory?
<Drup>
it's understandable
hausdorff has joined #ocaml
<Drup>
at least it has one
mcclurmc has quit [Ping timeout: 245 seconds]
<Mercuria1Alchemi>
companion_cube: well, it would be a matter of making sure it works together, not maintaining the libs themselves
<companion_cube>
yes
<Drup>
"the ocaml plateform" was a thing at some point
<Drup>
ask adrien
<companion_cube>
I think ocamlpro, janestreet and others have been talking about ocaml platform
<Drup>
he has a strong opinion about it
<companion_cube>
Drup: is it dead?
<companion_cube>
anyway, nowadays' platform is ocamlopt+opam
<companion_cube>
the rest is easy
<Drup>
well, it was based on GODI, I think, so, hum ...
<companion_cube>
ôO
<Drup>
anyway
<Drup>
once opam bundle is out
<Mercuria1Alchemi>
godi?
<Drup>
everyone would be able to create it's own set of pretty packages
<Drup>
in a self contained bundle
<companion_cube>
opam bundle.... hmmm
<companion_cube>
I'm more impatient to get opam-doc
<Drup>
I think it would be much better named "opam bento"
<Drup>
but maybe it's just me.
<companion_cube>
pffff
<adrien>
I strongly dislike an "XXX platform" as a dump of binaries
<Mercuria1Alchemi>
adrien: why?
<adrien>
I don't dislik it as much as "we settled for such components at such versions and we're going to make sure they're fully maintained for at least that long"
<adrien>
Mercuria1Alchemi: because it's a dump of binaries? :)
<Mercuria1Alchemi>
and I was more thinking opam-package with dependencies
Khady_ is now known as Khady
<adrien>
or the alternative quite often: copy-paste other projects' sources in your code
<companion_cube>
well you can submit an opam package named "platform" with the dependencies you want
Khady has quit [Changing host]
Khady has joined #ocaml
<adrien>
and sure it's all about how it's done
<adrien>
but until we see it done properly...
<Mercuria1Alchemi>
having an installer for people on these other platforms with pre-built binaries could be a bonus, but that's not what I'd find interesting
<adrien>
companion_cube: that doesn't magically maintains components
<companion_cube>
no, sure
<Mercuria1Alchemi>
we could have a match of wits to determine the best stdlib
<companion_cube>
maybe I can do cc-platform :>>>>
<adrien>
and I somehow sense that such a platform will be done by a few players and will therefore exclude everyone else
<companion_cube>
as soon as "platform" includes Core, half of the community won't use the platform
<Mercuria1Alchemi>
yes, that's a problem
hbar has joined #ocaml
<Mercuria1Alchemi>
the stdlib situation is rather unfortunate
<companion_cube>
in fact there's no decent, comprehensive, consensual stdlib right now
<Drup>
except the other half of the community absolutely wants core :>
<companion_cube>
they're either 1/ too small 2/ not much maintained 3/ bloated and not portable
<companion_cube>
4/ any combination thereabove
<adrien>
I don't even understand why a "platform" would have to have only Core or only Batteries or ...
<Mercuria1Alchemi>
it would be preferable to have a single stdlib
mads_hartmann has joined #ocaml
<Mercuria1Alchemi>
a single, js_of_ocaml compatible stdlib
* companion_cube
coughs
<mads_hartmann>
Hi, has anyone tried using ocamldebug on a program that uses ocaml_cohttp? I seem to have problems configuring ocamldebug correctly so it can find all the modules in the opam package
<adrien>
so, first, define what "platform" would be
<Mercuria1Alchemi>
opam meta-package with a set of blessed dependencies, I guess
<Mercuria1Alchemi>
one blessed stdlib + additional packages
<companion_cube>
adrien: something that, once installed, provides enough libraries and tools for most ocaml developments
<companion_cube>
meaning a "normal" program would only have to add domain-specific libraries
ezrezrz has joined #ocaml
<companion_cube>
like, in python, you can write many useful things without other dependency than "python"
<Mercuria1Alchemi>
even if the some of the libs are pretty gnarly
<companion_cube>
indeed, they're not all good
tane has quit [Quit: Verlassend]
<adrien>
companion_cube: fine by me and in that case it doesn't put any requirement on having a single lib for task X
<whitequa1k>
mads_hartmann: ocamldebug cannot be in general used when you have side effects
<whitequa1k>
like network traffic
whitequa1k is now known as whitequark
<Mercuria1Alchemi>
adrien: well, you wouldn't want to have 5 different date libraries in the platform
<q66>
<companion_cube> like, in python, you can write many useful things without other dependency than "python" <<< sometimes you can write them 3 different ways, as python has 3 different modules in the standard library doing essentially the same thing
<companion_cube>
or 5 different vector types
<Mercuria1Alchemi>
but it wouldn't keep you from using a third-party one if you so desired
<companion_cube>
all incompatible
<mads_hartmann>
whitequark: That makes sense. I do think I hit a slighly different problem though. I have written a more detailed question here if you have the time to help out :) http://mads379.github.io/ocaml/2014/11/15/ocamldebug.html
<Mercuria1Alchemi>
q66: welcome to backward compatiblity
<q66>
Mercuria1Alchemi, and subsequent bitrot
<Mercuria1Alchemi>
well, sure
<Mercuria1Alchemi>
I think I'd live better with less backward compatiblity in OCaml than in Python though
<Drup>
I personally don't see the point of an ocaml plateform
<companion_cube>
well the platform is opam, now, and that's it
<Drup>
we have opam, just use that. Use opam bundle to create opam install without network.
<Mercuria1Alchemi>
that's not a platform, that's a distribution system
<Mercuria1Alchemi>
and a packaging system
<Drup>
why do you need more ,
<Mercuria1Alchemi>
I want "standard" basic data types
<companion_cube>
not going to happen :/
<Mercuria1Alchemi>
:(
larhat has joined #ocaml
<Drup>
I know only one instance of another language with a "plateform", it's haskell, and the main reason is that cabal is crap
<companion_cube>
some other languages come with "batteries included"
<companion_cube>
(including, ahem, "go")
<Mercuria1Alchemi>
the advantage of a "platform" is that you don't need a single team maintaining n different systems
expo873_ has quit []
expo873_ has joined #ocaml
expo873_ is now known as expo873
<whitequark>
mads_hartmann: btw, the search path thing should be fixed in 4.02 at least
<whitequark>
ocamlc now embeds paths in the executable
larhat has quit [Ping timeout: 258 seconds]
larhat1 has joined #ocaml
<whitequark>
regarding the rest... I think it's because it doesn't support -for-pack
<whitequark>
ocamldebug doesn't support executing arbitrary code at all.
<whitequark>
it's ill-suited for the task, too
cesar has joined #ocaml
cesar is now known as Guest62634
<Mercuria1Alchemi>
companion_cube: why ahem?
mcclurmc_ has quit [Remote host closed the connection]
jprakash has quit [Quit: leaving]
<mads_hartmann>
whitequark: I'm using 4.02.1. But sounds like ocamldebug it's the tool I was hoping for. Any idea where I can find more information on -for-pack?
srax has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
mrvn_ is now known as mrvn
araujo has joined #ocaml
araujo has joined #ocaml
<whitequark>
ocaml manual
larhat has joined #ocaml
nojb has joined #ocaml
<mads_hartmann>
whitequark: Thanks
Guest62634 has quit [Remote host closed the connection]
larhat1 has quit [Ping timeout: 245 seconds]
mcclurmc has joined #ocaml
<companion_cube>
Mercuria1Alchemi: I think Go is pretty bad
thomasga1 has joined #ocaml
thomasga has quit [Read error: Connection reset by peer]
<Mercuria1Alchemi>
companion_cube: I don't know about "pretty bad", but I mostly think it's uninteresting
<mads_hartmann>
whitequark: Do you know if it's documented anywhere that ocamldebug doesn't support -for-pack?
<companion_cube>
yes, it's pretty bad that such a language has been designed in 2011
mcclurmc has quit [Remote host closed the connection]
<Mercuria1Alchemi>
it's not "this language is intended to create bugs" kind of bad
<Mercuria1Alchemi>
it's just disappointing
<Drup>
having null pointers is "this language is intended to create bugs" kind of bad to me.
<companion_cube>
+1
<companion_cube>
nil, + lack of generics implying casts everywhere
<Mercuria1Alchemi>
that's a fair point, but I'll raise a Javascript
<companion_cube>
+ the terrible error handling
<companion_cube>
javascript is laughable, but it's older and wasn't supposed to be really used for programming
<Drup>
Mercuria1Alchemi: raise unvalid, it's not by showing a terrible language that you excuse the design of another terrible language
<Mercuria1Alchemi>
also, even Scala has NPEs
<Drup>
only with Java apis, no ?
<companion_cube>
Scala has null only because of java
mcclurmc has joined #ocaml
<Mercuria1Alchemi>
well, that's not going to help you next time you get one...
<companion_cube>
you can write thousands of lines of scala without null, which you probably can't in go
<Drup>
Mercuria1Alchemi: I mean that pure scala doesn't use nulls, you only get them when you interact with Java, isn't it ?
<Drup>
it's bad, but less bad than nil being "the idiomatic way to handle errors" according to the official tutorial.
<companion_cube>
null in scala is like Obj.magic in ocaml
<companion_cube>
Drup: also, encoding sums as products
<whitequark>
mads_hartmann: I think it's a bug actually
<companion_cube>
so... ugly
<whitequark>
no one really cares about ocamldebug
<Mercuria1Alchemi>
Drup: well, possibly
<Mercuria1Alchemi>
but when you put "interact seamlessly with Java libraries" as a big selling point...
<Drup>
anyway, nothing excuses Go's design
<mads_hartmann>
whitequark: Too bad. What the alternative? utop + #trace?
<Mercuria1Alchemi>
I don't know, it feels a bit like retro-programming
rand000_ has quit [Read error: Connection reset by peer]
<mcc>
mercurialalchemi: gonna be honest "interacts seamlessly with C# libraries" does make my ears perk up
<mcc>
mercurialalchemi: maybe i'd care about java if i cared about android
<Mercuria1Alchemi>
C#?
<Drup>
mcc: that's the game dev talking :p
<mcc>
Yes! It is!
<Mercuria1Alchemi>
mcc: you make games?
<Drup>
except everytime a new game is written in C#, small baby seals die and all the potential linux gamers cry salty tears.
<companion_cube>
the potential 1% of linux gamers?
<mcc>
basically everyone in my community has moved to Unity.
<Drup>
companion_cube: I think it's much higher than that
<mcc>
also, Unity is basically the only chance a modern game has of getting a Linux port.
<Mercuria1Alchemi>
that's a lot of them
<Mercuria1Alchemi>
Drup: I don't
<mcc>
mercurialalchemi: yup! turns out lua is REALLY GOOD for rapid prototyping.
lordkryss_ is now known as lordkryss
<Mercuria1Alchemi>
in fact, there was a thread about it by the people who made Frozen Synapse
<Drup>
mcc: unity works on linux now ? last time I tried, it was *theoritically* possible, and only that
<mcc>
if you wanna play just one i recommend "become a great artist"
<Mercuria1Alchemi>
saying basically "even with cross-platform tech, we're not making a Linux game because it will cost too much in support"
<Mercuria1Alchemi>
from people who have already made Linux games
<mcc>
drup: says here since unity 4. *editor* still does not run in Linux
<Mercuria1Alchemi>
and Unity works, I play Wasteland on it
<mcc>
mercurialalchemi: making a linux game is *really hard*! i am totally lost on how to build games for Linux.
<companion_cube>
wasteland 2 uses unity?
<Drup>
Mercuria1Alchemi: I'm pretty sure valve's change of direction will change that too
<Mercuria1Alchemi>
sure
<mcc>
i use super portable practice but i have no idea what friggin libc to use or whatever
<Mercuria1Alchemi>
companion_cube: it works pretty well on my older desktop with nvidia graphics
<mcc>
i used to have a old ubuntu 10 VM i'd just build everything on and everything seemed to accept its libc but then i moved to SDL2 and my carefully tuned setup stopped working
brendan_1 is now known as brendan
<mcc>
there's something called the steam runtime but it's not well documented how to actually use it
<companion_cube>
that's cool
<mcc>
just a big tarball valve dumped on their website
<Mercuria1Alchemi>
mcc: isn't Valve working to make that easier?
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<mcc>
it's valve! they don't know how to follow through on things
<Drup>
:D
<whitequark>
mcc: you can use musl-gcc.
<whitequark>
musl-libc can actually be linked statically
<Mercuria1Alchemi>
but, well, yeah, a lot of indies are on Unity nowadays
<whitequark>
in fact, you can use musl-gcc with ocaml. opam switch 4.01.0+musl
<whitequark>
uber-portable linux binaries!
* Mercuria1Alchemi
is waiting patiently for the next Torment game
<whitequark>
mcc: disregarding that, creating a portable linux game is relatively easy
travisbrady has joined #ocaml
<whitequark>
you need to build a glibc (and any other library you depend on) with the prefix /opt/yourgame
<mcc>
what is musl-gcc
<mcc>
whitequark: so you're saying i should bundle a glibc with my game
<whitequark>
it's a gcc that uses musl-libc
<mcc>
whitequark: i'm probably moving that way :/
<whitequark>
and musl-libc is a smaller libc, like uclibc, which is a bit less painful to embed
<whitequark>
mcc: well, there are two options.
<whitequark>
1) bundle libc
<mcc>
i think my primary dev os is gonna be linux in a month or so :/ how well does musl work with clang
<whitequark>
2) use a buildfarm to provide packages for major OSes plus option 1) for the rest
<Drup>
mcc: welcome, we have cookies \o/
<mcc>
WERE THAT THAT WERE TRUE.
<whitequark>
mcc: musl should work with clang exactly as well
<companion_cube>
yes, I'll be checking those cookies monday, Drup
<mcc>
cool
<whitequark>
I mean, neither gcc nor clang really have any special support for libc
<whitequark>
barring some GNU extensions to the language
<whitequark>
and clang is made to be as compatible with gcc as possible anyway
<whitequark>
the good thing about musl-gcc is that debian has cookies^Wpackages
<companion_cube>
gcc doesn't hve specific stuff for, say, memcpy ?!
<whitequark>
companion_cube: it's in the C standard
<companion_cube>
oh, ok
bytbox has joined #ocaml
<whitequark>
so all libcs must implement it in the way that the compiler can safely interact with
<adrien>
unlike uclibc, musl isn't awful for !embedded
<whitequark>
naturally, not all do
<adrien>
uclibc is nice if you like running with your feet tied together
<whitequark>
shitty proprietary vendors do very strange things with their libc that totally contradict the standard, despite the fact that shitty proprietary vendors are THE reason the C standard is the shit it currently is
hugomg has quit [Ping timeout: 264 seconds]
<adrien>
memcpy -> __builtin_memcpy in GCC
<whitequark>
giving you fun unexpected undefined behavior
<adrien>
_but_
<adrien>
you still have a memcpy() in the libc
<whitequark>
adrien: let's not talk about gcc builtin functions.
<adrien>
and you can tell gcc not to use its implementation
<whitequark>
-ffreestanding, yeah
<adrien>
whitequark: forced to: it's the first step
<whitequark>
I think clang actually detects memcpy() calls at IR level, and converts them with an IR pass
<adrien>
GCC normally generates special code to handle certain built-in
<adrien>
functions more efficiently; for instance, calls to "alloca" may
<adrien>
become single instructions which adjust the stack directly, and
<adrien>
calls to "memcpy" may become inline copy loops.
<whitequark>
without any specific frontend support
<whitequark>
mcc: anyway, if you ever have any linux compiling / portability problems you can ask me
<whitequark>
as a person who maintained a cross-compiled embedded distro for some time, I know way more about it than I wish to
<companion_cube>
what can we *not* ask you?
<whitequark>
companion_cube: .*(systemd|nodejs).*
<whitequark>
well, I mean, you can, but you probably should not
travisbrady has quit [Quit: travisbrady]
<whitequark>
it's not that I won't know the answer. it's that you will regret ever being born.
<mcc>
whitequark: thank you, i apprecate it.
<mcc>
also, what distro?
<whitequark>
I use Debian ever since I started using Linux
<whitequark>
naturally, I prefer it :p
<companion_cube>
whitequark: can you please reimplement systemd in node.js for better webscale ? :D
<mcc>
i think it is, important that systemd be web scale
<Drup>
companion_cube: peh.
<mcc>
can linux run on web?
<Drup>
you should implement systemd in ocaml with js_of_ocaml to nodejs
<companion_cube>
ppx_deriving_webscale
<Drup>
for typesafe webscale.
<whitequark>
*closes the laptop, walks away, looks at the beautiful dawn*
<whitequark>
companion_cube: lol
<whitequark>
I should add that as an eastern egg
<Mercuria1Alchemi>
bah, I'm sure systemd includes nodejs already
<companion_cube>
val foo : bar [@@webscale]
<whitequark>
Mercuria1Alchemi: you're joking, but
<companion_cube>
becomes val foo_webscale : bar
<whitequark>
policykit actually includes a JS runtime
<whitequark>
spidermonkey.
<whitequark>
because hurr durr XML for writing policy files is too inflexible
<Drup>
I wouldn't date use them, it's *his* specialty
* mcc
was planning to base most of this language's standard library on existing c libraries but y'all are making a good case for ocaml internal stuff :P
Asmadeus_ is now known as Asmadeus
<reynir>
>>= is the right-shift-assign operator
<companion_cube>
you're writing your own language?
<Mercuria1Alchemi>
:)
<Drup>
companion_cube, not in a cave, ever.
<Drup>
:D
<companion_cube>
I'm no caveman
<mcc>
companion_cube: if you're talking to me, yah, that's why i'm learning ocaml in the first place :)
<companion_cube>
(might be a cavecube though)
<companion_cube>
ok
<mcc>
it is named Emily because it is ML-y… … um… you see >_>
<Drup>
mcc: this seems to be a trend, sort of
<companion_cube>
mcc: hope there are typeclasses
<Mercuria1Alchemi>
oh, more puns
<mcc>
i'm so sorry
<Mercuria1Alchemi>
you'll fit right in
<companion_cube>
are you trying to make it compatible with ocaml, or are you just writing its compiler in ocaml?
<Drup>
mcc: don't bother !
<whitequark>
mcc: hahaha that's an excellent pun
<mcc>
companion_cube: yeah, you might not be very happy, it has a very conventionally OO approach to polymorphism.
<companion_cube>
awww
<Drup>
mcc: OCaml's ecosystem is literally pun land :D
<whitequark>
(which will probably not work along with the ML TS, so I'm waiting until she reconsiders :P)
<companion_cube>
OO and ML, everyone knows it's no good now :p
<mcc>
companion_cube: typeclasses are really neat tho and i'm still trying to understand their implications
<Mercuria1Alchemi>
Irmin looks interesting, but the wiki/readme don't really showcase what weird stuff you can do with it
<Drup>
whitequark: It will end like foundry :D
<mcc>
whitequark: hah
<whitequark>
Drup: depressing
<Mercuria1Alchemi>
apart from git stuff... with curl
<Mercuria1Alchemi>
well, I guess curl beats git cli
<whitequark>
I would beat git cli so hard
<mcc>
whitequark: i'm gonna try to make JUST the part which is the application engine and C++ FFI possible to break off and put your own lang on top of. ok? :P
<nojb>
Mercuria1Alchemi: there will be a simpler api soon
<Drup>
"simplicity" is not an idea strong or appealing enough to develop a community. =)
<Drup>
(that's my opinion, at least)
<companion_cube>
look at go
<whitequark>
mcc: that is something that should be a part of libclang by the consensus of LLVM devs
<companion_cube>
that's their main selling point
<whitequark>
mcc: so you will have a very good case for upstreaming it in clang
<companion_cube>
well, with "look it's designed by Pike"
<Mercuria1Alchemi>
nojb: you're an Irmin person?
<Drup>
companion_cube: except it's pushed by google, not by a single person :)
<mcc>
whitequark: yeah. although i'm at the moment planning on something slightly simpler than the original super-ambitious C++-in-libclang idea i had
<mcc>
whitequark: although i can still work up to that
<Mercuria1Alchemi>
Drup: never underestimate marketing
<mcc>
err AST-gen-in-libclang i mean
<whitequark>
mcc: I mean a C++ FFI in any form will be very welcome by clang folks
<nojb>
Mercuria1Alchemi: no, but I heard it from the Irmin dev
<Mercuria1Alchemi>
nojb: 'K
<mcc>
whitequark: *nods*. short-term plan is to start with a binding generator my interpreter knows how to talk to which uses only the existing parts of libclang, to parse headers.
<whitequark>
"look it's designed by Pike" and Pike has not learned anything whatsoever since 80s
<whitequark>
it's sad.
<mcc>
whitequark: maybe, i should actually, like… use libclang… before i try to modify it
Thooms has quit [Quit: WeeChat 1.0.1]
<companion_cube>
whitequark: exactly
Thooms has joined #ocaml
<companion_cube>
or he learned, and dismissed
<mcc>
there are some things i think are interesting about go
<Drup>
welp
<Mercuria1Alchemi>
nojb: is there a paper about it somewhere?
<Leonidas>
mcc: you can run Linux in your browser btw :p
<mcc>
leonidas: i believe it…
<whitequark>
mcc: that'll only get you to C though
<whitequark>
but, yes
<whitequark>
mcc: it's by Fabrice Bellard, the genius behind QEMU and many other things
<whitequark>
in fact it uses QEMU's x86 interpreter loop
<mcc>
comanion_cube: so i'm curious, when you say you want "typeclasses", can you define what it is you're interested in?
<whitequark>
which is why it's actually pretty fast
<companion_cube>
mcc: first, on irc, <tab> completes nicknames
<companion_cube>
then, I'm interesting into having overloading done cleanly
<mcc>
companion_cube: i only learned haskell typeclasses pretty recently, and i don't know haskell so well, so the thing that's important about it to me feels like the generic functions from CLOS with static typing
<mcc>
but i'm not sure if everyone else sees the same thing
<mcc>
companion_cube: apparently not on my very old version of xchat!
<companion_cube>
awww :(
<Drup>
companion_cube: you didn't use typeclasses enough to see how much they suck.
<companion_cube>
Drup: -_-
<Drup>
but it's true !
<whitequark>
Drup: yay implicits?
<companion_cube>
I can't believe they suck more than not having them
<Drup>
whitequark: confirmed.
<Mercuria1Alchemi>
companion_cube: agreed
<Drup>
actually ...
<companion_cube>
I'm really *tired* of combining printers by hand
<whitequark>
mcc: you can catch def` in a european timezone and he'll tell you more about typeclasses and implicits than you ever wanted to know
<companion_cube>
or equality functions, or comparison functions
<whitequark>
companion_cube: not even deriving helps you?
<companion_cube>
and yes, I still consider code generation a hack
* mcc
will do that someday
<Drup>
mcc: the bottom line being "you need some form of genericity"
<mcc>
although y'all have pointed me to enough resources in terms of libraries/people i am going to forget most of them by the time i start working on this in 2 months * _ *
<companion_cube>
I mean, List.sort or List.group are inherently bounded polymorphic
<Drup>
but 1ML+implicits ... that would make a fricking cool language.
<companion_cube>
and I don't know any other way to do it than typeclasses
<companion_cube>
Drup: sure
<companion_cube>
it's pretty close to typeclasses anyway
<mcc>
i'm not sure if y'all will like my plans for polymorphism, which are a weird combination of actionscript and go ^_^;
<whitequark>
/unfollow
<companion_cube>
:D
<mcc>
mwahahaa
<whitequark>
(not actually, mostly because I think you'll see for yourself the problems with that design)
<mcc>
anyway, right now my language is duck typed, and i will try to learn enough theory to talk intelligently about type systems when i have something that actually boots * _ *
<mcc>
we'll see.
<whitequark>
sounds like a good plan.
<Drup>
hopefully, your language will not be successful, so you won't increase the technical debt of humanity :<
<whitequark>
I started in a similar way
<mcc>
i need to actually learn Foundry at some point.
<whitequark>
mcc: please don't read the articles I have on my website
<Drup>
:D
<whitequark>
they're very bad
<whitequark>
better just ask
<whitequark>
I suck pretty hard at complex technical writing on topics I barely understand. but then again, who doesn't
<mcc>
hahaha
<Drup>
mcc: you can start by the book "Types and Programming languages".
<whitequark>
I'm not sure if that is a good suggestion
<whitequark>
TAPL is ... dense
<Drup>
yes
mcclurmc has quit [Remote host closed the connection]
<Drup>
but everyone who fancy himself as language designer should know its content.
<whitequark>
it's less terrible than recommending the dragon book as first reading
<whitequark>
but it's somewhere along that axis
<whitequark>
Drup: sure. but not *start* with it
<mcc>
drup: *nods* a friend of mine got a job on the Swift team… when they accepted the job they were basically given a copy of that book and told "now read this"
hugomg has joined #ocaml
* whitequark
respects the swift team very much
<Drup>
well, mcc doesn't seem to be completely unknowledgable in programming languages and typing.
<mcc>
There are some things I have a background in and some things I do not.
<whitequark>
well, no wonder, it's clattner and the rest of the team
<whitequark>
they couldn't possibly have made a bad language
<Drup>
when the language came out
<Drup>
the first thing I did is try to see how bad it was
<reynir>
will swift run on non-apple devices?
<Drup>
and it took me more than 5 minutes
<mcc>
reynir: still no signs there will ever be an open source implementation
<Drup>
which is *much* better than most languages created this years
<Drup>
so, I would say it's quite good :]
<Leonidas>
I was happy to see a copy of TAPL at my first day of work in the shelf
<whitequark>
swift would be beneficial even if an OSS impl never appears at all
<reynir>
that's too bad
<whitequark>
simply by virtue of educating developers
<mcc>
I glanced at swift, got VERY excited, and now am trying to avoid looking at it in case i accidentally incorporate patented ideas into my language …
<Drup>
whitequark: shame they screw up the GC part
<whitequark>
mcc: what.
<Drup>
mcc: there are literally no novel idea in swift
<Leonidas>
Drup: I wran into the fact that pattern matching is not an expression.
<mcc>
whitequark: i have an extreme fear of apple legal. more than most people maybe
<Leonidas>
that was pretty bad
<mcc>
drup: that has never stopped them before!
<whitequark>
Drup: well, they have to interoperate with the rest of code in objc
<Drup>
whitequark: is that really a good reason for making programming break Rc cycles with weak references ?
<mcc>
i've heard interesting but very vague rumors of what swift was like before the objc interop/runtime thing was added
<Drup>
*explicitely* ?
<Drup>
it's, ewwww
<whitequark>
Drup: gc is pretty bad for realtime, such as smooth animation
<mcc>
drup: ARC works surprisingly well and GC is potentially a big performance issue on mobile…
<whitequark>
Android *still* hasn't figured this
<whitequark>
I say if UI is your top priority, yeah, that's a good reason
<mcc>
well, what whitequark said
<Drup>
meh
<mcc>
there are perrenial problems with android that ios does not have for this reason
<whitequark>
maybe not the cleanest in a perfect world, but we aren't in a perfect world
<Drup>
color me not convinced that there is no better solution
<mcc>
although now they're supporting ~~~~ javascript ~~~~ as a language, last i heard, so good luck with that!
<whitequark>
Drup: there is no better solution that could be shipped fast enough.
<Drup>
hum, ok.
<mcc>
there actually used to be GC in objective c
<mcc>
apple removed it
<mcc>
because the developers preferred to use traditional refcount/autorelease
<whitequark>
I think they removed it because it interacted very badly with anything higher level than CF?
<mcc>
well, they removed it because literally no one used it.
<whitequark>
like, UIKit making assumptions about no GC all over the place
<mcc>
…i mean literally. the only major app in the *world* using objc gc was xcode
<adrien>
from what I've understood, its actual behaviour was tricky to understand
<Drup>
(I like Rust approach to the question, but it's clearly not the same goal anyway)
<mcc>
You probably mean AppKit, i don't think the gc ever worked on ios
<whitequark>
AppKit, yes
<mcc>
And yes, it probably did interact very poorly with other apis, i never used it tho
<whitequark>
I mean that's a chicken-and-egg issue. nobody would use it if it doesn't work, naturally
<whitequark>
so I don't buy this argument
<mcc>
anyway, gc and c interop in a single process is hard.
mads_hartmann has quit [Quit: rcirc on GNU Emacs 24.4.50.1]
<whitequark>
indeed
<whitequark>
precise GC especially
<Drup>
(again, Rust's solution)
<whitequark>
Drup: Rust actually never ever had a working GC
<companion_cube>
you mean RC?
<mcc>
someday i will understand rust enough to understand what its solution actualy is
<mcc>
because it seems like "we have a net of about four or five special cases that hopefully covers everything you'd ever do"
<Drup>
whitequark: well, that's because llvm's blocking issue, mostly
<Drup>
isn't it ?
<whitequark>
mcc: no, not at all
<whitequark>
mcc: at worst, you can encode your behavior in a special container, like Rc<> and Gc<> do themselves
<mcc>
hm
<whitequark>
this reduces the puzzle aspect considerably, though it's still there to a degree
<whitequark>
in practice you find that most well-behaved code fits very well in Rust's pattern
<whitequark>
there are some issues with closures, but they're going away
<mcc>
but it does impose a pattern, right
<whitequark>
mcc: think of it as GOTO. true, you can encode control flow with GOTO that you can't encode with structured control flow
<whitequark>
do you ever really want to? :p
<Drup>
this analogy is <3
<mcc>
i find myself wanting named breaks a lot…
<whitequark>
named breaks are still structured though
<whitequark>
mcc: oh, sure, it does, but so does everything else. all languages make some patterns easier and some patterns harder
<Drup>
mcc: that's pretty much called 'exceptions' nowadays
<mcc>
and in ocaml i am programming with GOTO (TCO IS GOTO!!!) and i am definitely finding it liberating in terms of what kinds of flow structures it allows me to create…
<Drup>
TCO is not goto :<
<whitequark>
you can't jump upwards in current scope using TCO
<mcc>
anyway, i think the way i'm looking at it is that it doesn't matter what is right, a language which imposes a pattern is not going to become popular outside a certain set if people just have it in their heads they want to program a particular way
<whitequark>
so while it may *compile down to* goto, rather than a full-blown call, it's not equivalent to a high-level goto statement
<whitequark>
it's true that in ANF, TCO is literally goto, but most code is not in ANF
<mcc>
and this sometimes has implications for language design, especially if you're apple
<mcc>
ok so… over the last couple years i have learned about the first 15% of about 8 different languages.
<whitequark>
oh, whoa, ANF was introduced by Felleisen in 1992
<whitequark>
Felleisen is like Fabrice Bellard of FP :D
<mcc>
what would you characterize rust's solution as? when i looked at it (and this was before gc<t>) it looked like there was this forest of pointer types, and each one was a promise to use memory in a particular safe way
<mcc>
and the theorem prover verified that you followed the promise. right?
<whitequark>
mcc: the key part in rust is regions
<Drup>
mcc: it's much cleaner now
<mcc>
hm
<mcc>
that might answer the next question i was going to ask
<Drup>
they basically get rid of most pointer types and sigils
<whitequark>
you can borrow a pointer for duration of a scope, and the borrow checker verifies that it never escapes the scope
<Drup>
and simplified the language a lot
<whitequark>
also, borrow checker verifies that there is only one "mut" pointer to given memory ever
<whitequark>
(it's called "mut" but it's not exactly describing mutability. "uniq" would be a better description)
<mcc>
ok, i think that makes sense
<whitequark>
the rest was ripped out
<mcc>
hm
<whitequark>
Gc<> Rc<> Arc<> and the rest are not special anymore
<whitequark>
just library
<Drup>
Rust boils down to "An ml programmer looked at C++ idioms, and frown upon it, so he decided to write a typechecker for them"
<whitequark>
yeah, that's not a bad description
<mcc>
so the big question that is intereting to me is how Gc<t> is able to talk back and forth with something that isn't in the Gc<t> pool
<Mercuria1Alchemi>
whitequark: on the other hand the old syntax was less verbose
<whitequark>
mcc: lol, well
<whitequark>
right now there's no working Gc<>
<whitequark>
at all
<whitequark>
there never was
<mcc>
bother
<mcc>
ok so when i looked at it, there was a pointer type they claimed was garbage collected
<whitequark>
but I can explain how it would work
<whitequark>
it wasn't.
<mcc>
what was it instead of garbage collected
<whitequark>
it was... literally never collected at all
<mcc>
…
<Drup>
well
<whitequark>
technically it's a garbage collector. "null collector"
<whitequark>
:D
<Drup>
Rc<> is working.
<mcc>
btw, is there still a handoff<t> or something if you really liked whatever weird pointer type was the handoff
<Drup>
so you can still explain that.
<reynir>
very imprecise garbage collector
<whitequark>
because they were going to integrate Boehm
<whitequark>
but never actually did
<mcc>
oh god
<whitequark>
so I can tell you how Gc<> will work, if it ever gets implemented
<mcc>
okay.
<mcc>
i'm curious.
<whitequark>
"if ever" because there is very small demand for GC
<whitequark>
Rc and RcWeak take care of cycles in structs
<whitequark>
I think Servo team wants GC, but not very much
<whitequark>
so
<Drup>
(important note that might interest you mcc, there is really big gamedev community in Rust)
<mcc>
that is a surprise to me
<mcc>
but ok
<whitequark>
the GC would be precise, it would know which location on heap and stack exactly is a managed pointer
jprakash has joined #ocaml
<whitequark>
and when you know that, interoperation is naturally not a problem
mcclurmc has joined #ocaml
<Drup>
what surprises you ?
<mcc>
mmm, not that ppl are using rust for gamedev but that makes a lot of sense, i am surprised that this happened without me already encountering these ppl
<Drup>
oh :)
<mcc>
whitequark: and it knows this because it collaborates with the prover for the rest of the language?
<whitequark>
I would imagine it will have to mark borrowed pointers somehow, yes
<mcc>
ok
<mcc>
i'm glad to hear that's apparently working or near working for someone