<kmagdsick>
the former is to avoid confusion when reading and typing URNs by hand
<kmagdsick>
it avoids O -> 0, 1 -> I mixups
<schlick>
I suppose. :P
<schlick>
Well, those seem like good reasons to follow the usual math rules. I don't really have a problem with how erlang did it. I just worry that if I let people do everything in base 15 then some jerk will write all his code that way "because he can, and it's easy". :P
<schlick>
But to some extent you can't stop jackassery I suppose.
vodka-goo has quit ["Connection reset by by pear"]
<schlick>
Any clue about the regions thing?
<kmagdsick>
regions?
<schlick>
Region based memory management.
<kmagdsick>
I'm not familiar with region based
<kmagdsick>
unless it's another name for generational
<schlick>
Supposedly it always leaks. MLton's site makes the claim anyway, and apparently ML Kit added a garbage collector to cope with it.
<schlick>
It's not.
<kmagdsick>
is it another name for conservative gc?
<schlick>
No.
kmagdsick is now known as kmag|out
<schlick>
It's apparently a way a compiler can compile garbage-collected-style allocation/deallocation on the heap down to raw calls to malloc and free, so there's no overhead.
<kmag|out>
sorry. gtg. dinner.
<schlick>
Take care.
<kmag|out>
oh... that makes sense
<kmag|out>
malloc on entering a scope
<kmag|out>
and on exit, free every pointer that was never passed to another scope
<schlick>
Supposedly it always leaks.
<schlick>
Just trying to find out if that's so from people that know more.
<rillig>
I've written a little program solving the Towers of Hanoi problem. Can you tell me whether it conforms to the common style guides and actually looks like an OCaml program?
<schlick>
Think most people are idle now. I'm not familiar enough yet to help you.
<rillig>
schlick: thanks for the reply.
<rillig>
If no one else answers I will try again tomorrow.
<schlick>
All I could recommend is I know the OCaml page has some tutorials so you could probably get a idea from them. There's actually a surprising amount of stuff out there in various forms of ML (mostly Standard ML of New Jersey and OCaml), I dunno how easy most of it would be to go through since most of it is compilers and static checkers it seems.
<rillig>
I'm reading the ocaml-3.0.9-manual.pdf
<rillig>
Let's see how far I get before falling asleep. :)
<schlick>
Heh. It doesn't seem too bad. I find ML pretty readable.
<rillig>
me too.
<schlick>
But I've played with forth and scarier things so maybe I'm not a good judge any more.
<rillig>
The first thing I read was the implementation of the Str module.
<rillig>
The syntax is _very_ brief, and I'm still wondering about some things that must be deduced implicitly by the interpreter.
<rillig>
But I liked especially the notation for types.
<rillig>
type X = foo | bar | baz
<schlick>
The type inference thing is neat. It leaves me a bit uneasy. But it's interesting.
<schlick>
Only thing that bothers me about it is I've noticed every time a computer tries to figure out what a person means they seem to do a bad job. But I'm withholding judgement at this point. :P
<rillig>
:)
<rillig>
good night for now. I'm tired.
rillig has quit ["exit(EXIT_SUCCESS)"]
mlin has joined #ocaml
mlin has quit [Client Quit]
mlin has joined #ocaml
KrispyKringle has joined #ocaml
Raziel has quit ["Yo soy goma. Tú eres cola."]
Raziel has joined #ocaml
pango_ has joined #ocaml
pango has quit [Read error: 110 (Connection timed out)]
pnou_ has joined #ocaml
Raziel has quit ["Yo soy goma. Tú eres cola."]
shirogane has quit [Read error: 104 (Connection reset by peer)]
pnou_ has quit ["Lost terminal"]
magnus__ has joined #ocaml
mfurr has joined #ocaml
mlin has quit []
Snark has joined #ocaml
joshcryer has joined #ocaml
Skal has joined #ocaml
_fab has joined #ocaml
mfurr has quit ["Client exiting"]
vincenz has quit [Connection timed out]
MisterC has joined #ocaml
Skal has quit [Read error: 110 (Connection timed out)]
vincenz has joined #ocaml
pango_ has quit [Remote closed the connection]
magnus__ has quit ["BitchX: now with 15 percent fewer calories!"]
pango has joined #ocaml
m3ga has joined #ocaml
ppsmimou has joined #ocaml
_JusSx_ has joined #ocaml
haakonn_ has joined #ocaml
haakonn has quit [Read error: 104 (Connection reset by peer)]
Raziel has joined #ocaml
Revision17 has joined #ocaml
revision17_ has quit [Read error: 110 (Connection timed out)]
<schlick>
The reason I'm wondering is I'm reading about several tools that use it and I'm wondering if I should mark that off as a bad idea.
<schlick>
No idea vincenz?
<vincenz>
schlick: it all depends on the program, and why are you looking at memory management
<schlick>
It's important for correctness.
<vincenz>
schlick: of what
<schlick>
Memory leaks are bugs (as are double frees, etc).
<schlick>
Of programs in general.
<vincenz>
....
<vincenz>
schlick: WHAT are you tryinig to do?
<schlick>
Learn about static analysis.
<vincenz>
typically the GC is not part of the analysis
<vincenz>
cause it's in the underlying system
<schlick>
Regions aren't garbage collection though.
<vincenz>
in a way they are
<schlick>
They're a different way of achieving something similar.
<vincenz>
schlick: but I honestly fail to see what this has to do with static analysis
<vincenz>
schlick: try to focus a bit on what you are trying to achieve
<vincenz>
gc is never included in the analysis of programs
<schlick>
Well, the idea is to detect or prevent bugs. Memory leaks, double frees, writing to freed memory, etc. are all common sources of bugs. So it's interesting to me to see different ways of achieving it. However if something is as dangerous or more than manual memory management (without detecting errors), then I don't want to invest much time in it.
<schlick>
What I'm trying to achieve is design a programming language that's tied to a static analyser that prevents and/or catches as many bugs as possible automatically.
<vincenz>
schlick: for what language?
<schlick>
So, yes, regions are relevent.
<vincenz>
schlick: no
<vincenz>
schlick: regions are how you supply the programming langue with memory
<vincenz>
and the region manager or gc is always "under the hood"
<schlick>
And there are various ways of doing that.
<vincenz>
yes
<vincenz>
but that is "under the hood"" and not part of the language
<schlick>
manual memory management (huge source of bugs, hence, bad idea where avoidable), regions (looks good, not sure if it leaks, some people say it does), and garbage collection (many flavors, seems to work fairly well, bad implementations cause horrid performance).
<vincenz>
schlick: who says gc has bad performance?
<vincenz>
there's been studies that gc performs at par with manual mamangement
<schlick>
The language has to deal with the issues of memory allocation/deallocation, if you're trying to prevent bugs related to that, you need to know your options, and choose the best one.
<vincenz>
schlick: no it doesnt
<schlick>
Read what I said.
<vincenz>
the runtime environment has to enable a way to give memory to the programmer
<schlick>
I said /bad/ implementations cause horrid performance.
<vincenz>
schlick: then use a good one...
<schlick>
I'm aware.
<vincenz>
schlick: yo only design your ruuntime system once
<schlick>
Why are you so hostile to having me ask questions.
<vincenz>
that has little to do with the static analysis of the program
<vincenz>
schlick: cause you're asking questions that are unrelated
<schlick>
Regions is a lagitimate alternative. I'm just trying to figure out if it's a safe one.
<schlick>
Ok, let me use imprecise terminiology then "I want to make a language that stops bugs".
<schlick>
Dealing with memory management is a part of that.
<schlick>
So I want to know my options, and right now I know the issues with manual memory managment and garbage collection in a fair amount of detail.
<schlick>
I don't know much about regions. There isn't much on them. They seem to be a popular research topic. MLton' folks claim it has inevitable leaks. If this is so I need to know. Looking for confirmation from more knowledable folks.
<Smerdyakov>
schlick, you don't have to design the language! We already have Coq! :-D
<vincenz>
schlick: designing a language and designing it's runtime system are two separate issues
<vincenz>
focus on the language and it's correctness
<vincenz>
and then just make sure to implement ap roper runtime system that doesnt' break assumptions
<schlick>
Smerdyakov: As far as I can tell you can't use Coq for general purpose programming or systems programming. i.e. you can't see if it has a problem, then just compile it if not, you have to translate to another language to interface with the rest of the world.
<schlick>
vincenz: this doesn't help me know more about regions.
<vincenz>
schlick: because it is irrelevant to what you said you want to cover, program correctness
<Smerdyakov>
schlick, you can use it for general purpose programming. You have to do some work to use it with a C-like approach, though, but that's relatively unimportant, because there shouldn't be that much code total of a C-like style.
<schlick>
vincenz: if it leaks, it's incorrect.
<schlick>
Manual memory management tends to leak.
<schlick>
Regions might, still waiting around for confirmation/denial, and people to stop telling me "don't ask things!"
<Smerdyakov>
schlick, take my word for it that I have the "systems programming" covered with my research, and focus on the general purpose stuff, where Coq or a small adaptation with convenience features is the right way to go. ;)
<schlick>
Garbage collection looks like a viable option though it does have some overhead, it can be pretty small.
<schlick>
Smerdyakov: I trust you about that. It's just you can't check it and then compile it with no translation to other languages. I was hoping to stop flaws by a combination of language design and static analysis. Kind of like Vault to pick a existing project. ACL2 will also let you compile/run the code you analyzed (a subset of Common Lisp).
<schlick>
Coq is interesting though.
<schlick>
It's just not exactly what I had in mind. And even if it was I'd still want to understand the issues involved.
<Smerdyakov>
I don't know what you mean about "check and then compile."
<schlick>
I mean the specification language is also executable.
<Smerdyakov>
Everything in Coq is executable.
<schlick>
And can interface with the OS (make system and library calls).
<Smerdyakov>
The fact that there is no direct Coq compiler isn't practically relevant.
<schlick>
Howso?
<Smerdyakov>
Because there is extraction to a number of other languages, where people have already worked on good optimizing compilers.
<schlick>
I suppose that's true, but it seems like the gap between the proven code and the translated code would be cause for concern.
<Smerdyakov>
Why aren't you worried about the gap between a C program and its compiled version?
<schlick>
I suppose if you did it the way your papers mentioned you could show that the two were equivalent.
<Smerdyakov>
Program extraction from Coq is much more trivial than any traditional compilation task.
<vincenz>
schlick: any correctness proving assumes the tool and the runtime system work as described
<schlick>
Smerdyakov: The initial plans were to make a language that somewhat resembles Eiffel (it's close to what I have in mind) with several changes made. Start out by trying to write a prover for it and turn it into C just to get it off the ground, then go straight to assembly. Specify what the various instructions do in terms of software, test it against the hardware, then reason about the equivalence automatically.
<schlick>
software, test it against the hardware, then reason about the equivalence automatically.
<vincenz>
schlick: otherwise you'd be proving your way down to the pipeline stages of hardware
<schlick>
This is true.
<vincenz>
schlick: the memory management is part of the runtime system
<vincenz>
either you choose gc or manual
<vincenz>
if you choose gc, you know certain aspects that rae true for your code and use those in your correctness proofs
<vincenz>
if you use manual
<vincenz>
you add extra steps in your correctness proofs that deal with freed pointers
<schlick>
Initially I'm hoping to get it to just work. I'm sure GCC has bugs, but at least it should be less if the source is ok. After that's working I can try to go down to the assembly level. Since I can't do anything about flawed hardware I'm writing that off as something to not worry about.
<vincenz>
schlick: don't forget cosmo-rays
<schlick>
vincenz: manual, gc, or regions (I haven't heard of anything else, though I'm guessing some other alternative could exist).
<vincenz>
regions are never used
<schlick>
vincenz: and alpha particles
<vincenz>
they're a patch to manual
<vincenz>
when you know your program works in a phased way
<schlick>
vincenz: not worried about things that can't be handled, trying to stay practical, but very anal.
<vincenz>
it's either manual or gc
<schlick>
Still curious about the regions thing, since nobody's confirmed or denied if the leaking statement on MLton is true. Maybe nobody knows.
<vincenz>
schlick: no serious system uses regions as part of their generic runtime system
<Smerdyakov>
schlick, I think Coq is a better choice than Eiffel.
<vincenz>
gcc uses regions internally
<schlick>
vincenz: some people are looking at it because it removes the overhed of garbage collection.
<vincenz>
cause it knows it will have to free many related things at once
<vincenz>
schlick: under very strict assumptions
<vincenz>
too strict for a generic programming language
<vincenz>
unless you want to use regions insidie your gc, which means you basically have a gc, from correctness point of view
<schlick>
Smerdyakov: As is, I'm convinced you're correct. Eiffel has nice amenities for programming. It would just be nice if a automatically checked implementation existed. Galatea (may have mispelled that) doesn't seem to be intended quite so much for programming as describing programs in a way that can be proven.
<flux__>
I view region inference as a performance optimization for gc
<flux__>
(but cool one, nevertheless ;))
<vincenz>
flux__: yeah
<vincenz>
flux__: or a programmer time optimization for manual freeing
<vincenz>
such as in gcc
<flux__>
well, gc as whole is programmer time optimization?
<Smerdyakov>
schlick, I don't think Eiffel has the right amenities. I don't think it compares with ML as far as facility for abstraction.
<vincenz>
flux__: gCC
<flux__>
I read you correctly
<vincenz>
oh
<vincenz>
flux__: true, but that only really works for languages that don't have pointers and all that
<flux__>
yeah
<vincenz>
well they have a boehm gc for c++
<schlick>
Smerdyakov: I mostly like the clean notation, the handling of connecting separatly developed parts (making sure that they're not connected in ways that invalidate the assumptions the author made).
<flux__>
does gcc have region inference?-o
<vincenz>
but it of course has lots of assumptions on how you use the data
<flux__>
or just programmer maintained pools?
<vincenz>
flux__: no it has a region memory manager
<flux__>
well, lots of stuff has those
<flux__>
for example apache
<vincenz>
manual regioin freeing
<flux__>
and they can be very convenient
* vincenz
nods
<flux__>
but region inference is much cooler ;)
<Smerdyakov>
schlick, ML/Coq support that much better.
<schlick>
Smerdyakov: Some people claim syntax doesn't matter, so just use <their preferred environment>. I'm not convinced of this. For a common example, C's choice of syntax for assignment and equality is a common source of bugs.
<Smerdyakov>
schlick, this is beyond syntax. Eiffel is weak on semantic constructs.
<flux__>
smerdyakov, btw, do you think coq will some day have code extractor for C/C++?
<vincenz>
schlick: don't mistake syntax with semantics
<vincenz>
semantics matter, syntax doesn't
<Smerdyakov>
flux__, no. The user community is satisified with ML/Haskell/Scheme extractors, since everyone would prefer to use one of those over anything else. ;)
<schlick>
Smalltalk handles the assignment vs equality thing really well. The difference is easy to spot. It also handles mathematics in a way I like (it avoids operating on floating point where possible, and has decent notation for such).
<schlick>
I think both matter.
<flux__>
smerdyakov, but it would give more footstep for writing embedded software in coq ;)
<vincenz>
syntax maters much less for correction proving
<schlick>
A language that you couldn't get "confused in" that still looked like APL-11 might have clean semantics, but would still look like you opened a executable in a text editor.
<flux__>
I suppose bigloo could be used in embedded environments
<Smerdyakov>
flux__, it would basically be an ML compiler, since Coq is an extension of ML, so why not output ML in the first place and let the traditional compilers try to create output that runs on constrained platforms?
<schlick>
And nobody would use it due to it resembling Klingon more than English.
<vincenz>
schlick: I thought you wanted to do correction proving,
bd_ has joined #ocaml
<vincenz>
schlick: then what it LOOKS like to the programmer matters little
<schlick>
vincenz: What it looks like to the programmer matters a /lot/ from a maintenence point of view.
<Smerdyakov>
schlick, Eiffel doesn't support first-class functions with closures, right?
<schlick>
vincenz: And training. And when code is hard to read and think about, people make mistakes.
<flux__>
smerdyakov, as you said, generating code from coq is a trivialish process, so the less (potentially more complex) steps in-between the better ;)
<vincenz>
....
<vincenz>
schlick: focus on one topic at the time
<vincenz>
schlick: syntax is easily changed
<schlick>
vincenz: All the topics are relevent to language design.
<Smerdyakov>
flux__, making ML run without garbage collection is hard, and it doesn't matter much at which stage you stick this difficulty.
<Smerdyakov>
vincenz, I think you are out of line in claiming that his questions are inappropriate.
<vincenz>
schlick: yeah but you should focus on one at a time instead of hopping around from limb to limb, thereby confusing issues
<vincenz>
Smerdyakov: That's great
<Smerdyakov>
schlick, Eiffel doesn't support first-class functions with closures, right?
<schlick>
vincenz: I know, for some reason, you seem really hostile to my idea, despite ML folks commonly writing compilers, and being into static checking. I'm just doing what most people are doing here. I'm basically looking at a lot of languages, see what I like, see where they fowled up, and trying to tack together all the good and dodge all the bad (where doing so can be conceptually clean prolog+lisp isn't...)
<vincenz>
schlick: no
<schlick>
and dodge all the bad (where doing so can be conceptually clean prolog+lisp isn't...)
<vincenz>
schlick: but we're talking about one thing, I make a claim, and you suddenly dispute it base on a completely different otpic
<vincenz>
schlick: that'll get us nowhere
<flux__>
smerdyakov, hmm.. maybe coq could be extended to provide memory consumption information, and for example use region inference or 'manual' collection as required.. atleast so that after you enter and exit a coq-generated function you know what you will need to release in your code (propably the object the function gave you back)
<flux__>
but, that is an advanced topic I imagine ;)
<schlick>
vincenz: I haven't made any claims other than what a language looks like matters.
<schlick>
vincenz: The only question I've asked is if regions inevitably leak.
<schlick>
So far nobody has answered my questions, and has berated me for asking, and switched the topic umpity ump times.
<Smerdyakov>
flux__, it's no different from general issues of compiling ML, so there's no reason to duplicate effort in both Coq extraction and ML compilation.
<vincenz>
schlick: regions leak only so far as you'll let them leak
<Smerdyakov>
schlick, we don't know the answer, so you can forget about it for now.
<schlick>
Leaks bad. Schlick want to know options for stop leaks. Regions good option? Regions leak? :P
<Smerdyakov>
schlick, can you answer my question now?
dylan has left #ocaml []
<schlick>
Smerdyakov: I need to take the mail out soon. What is it you wanted to know? Something about Eiffel handling first class something?
<Smerdyakov>
schlick, Eiffel doesn't support first-class functions with closures, right?
<schlick>
Possibly not.
<Smerdyakov>
Then I would never want to use it, and I know a lot of good programmers who feel the same way.
<schlick>
It's basically Ada cut down, cleaned up, with a nice assertion annotation, and design by contract support built in.
<Smerdyakov>
You are making unjustified claims that the syntax of Eiffel is superior to ML synax.
<Smerdyakov>
I'm sure you'll find plenty of people here to disagree ont hat.
<schlick>
Smerdyakov: Could be. Lot of programmers won't use languages without goto, or without shorthand syntax.
<Smerdyakov>
I claim that the best programmers will be more productive with ML than with Eiffel, and that's all that matters to me.
<vincenz>
I back that claim
<Smerdyakov>
It seems to me that you are trying to design new tools without sufficient experience with what's already been designed.
<schlick>
Smerdyakov: I think all languages have their place. I like some things about ML. I'm sure I don't know all it's dark corners, I don't of most languages I've been learning about. I may not ever learn them all (e.g. I may not ever learn exactly how every string function in C works). Overall there are some things about several languages that are good. ML's nested comments are good.
<schlick>
I have yet to see anybody handle math better than Smalltalk, other than possibly bases other than 10.
<Smerdyakov>
schlick, then you haven't seen type classes. :)
<schlick>
And honestly I'm not sure what would be a clean notation for that. Erlang's handling seems decent.
<vincenz>
Smerdyakov: heh I'm hoping for a language with those but without haskell's laziness :)
<schlick>
Smerdyakov: ML computes in floating point for things not handlable as integers. I don't like that.
<schlick>
Almost every other language does it too. Smalltalk doesn't. It results in higher precision, and you can force it into floating point to display it for humans when you're ready.
<Smerdyakov>
schlick, ML also has enough support for you to compute with whatever number types you please just as naturally
<vincenz>
Smerdyakov: do you happen to know what the irreconciable problem is between the module system and type classes?
<flux__>
vincenz, eager haskell? btw, what's the problem with laziness, it gives you all kind of good stuff?-)
<Smerdyakov>
vincenz, scoping. When do type class instances in a module apply to the current context?
<Smerdyakov>
vincenz, and it's not irreconcilable. I think Alice ML has type classes.
<vincenz>
flux__: except for perofmance
<schlick>
Smerdyakov: Maybe I haven't seen it, the ML tutorials show people using floating point however.
<vincenz>
Smerdyakov: really? Hmm I looked but didn't seem em
<flux__>
vincenz, well yeah, that's too bad
<Smerdyakov>
schlick, you don't understand. What you are saying is like this:
<flux__>
but eager haskell tries to fix that
<vincenz>
flux__: I have an issue with haskell syntax :/
<vincenz>
flux__: I prefer ml
<Smerdyakov>
<schlick> I used Fib++ and saw its excellent built-in support for computing Fibonacci numbers. This is an advantage over ML, where you have to write your own Fibonacci calculation function.
<schlick>
Smerdyakov: Not exactly.
<Smerdyakov>
schlick, what's the difference?
<schlick>
Smerdyakov: It's "built in" to Smalltalk (on the other hand there isn't anything that isn't, so yeah, it's kinda cheating). The notation is clean and readable. There aren't function calls sprayed all over the place to deal with things the language couldn't handle natively. You /can/ do everything in Brainfuck (a raw turing machine programming language), but I sure wouldn't want to.
<schlick>
turing machine programming language), but I sure wouldn't want to.
<schlick>
It's another one of those things about whether the language is easy to reason and for humans to think about.
<Smerdyakov>
schlick, you don't seem to realize that ML and Haskell support user-defined infix operators.
<vincenz>
Smerdyakov: fraid that alice doesn't have it :(
<schlick>
Smerdyakov: I admit to not knowing you can define your own.
<schlick>
That would make tacking things onto it a lot more tolerable.
<Smerdyakov>
schlick, forget "not tolerable." Tell me one reason why you can't implement, _in_the_language_, a numeric system just as good as the one you're describing.
<schlick>
Anyway this wasn't about me ripping on ML. Since I think it's probably the best language for doing what C does, without blowing both the programmers' legs off at the crotch. It was just me asking about regions, which seems to have turned into some sort of interrogation/flame-war cross. :P
<vincenz>
besides, doesn't ocaml have bignum? Just open bignum and all your operations will be in bignum
<vincenz>
schlick: and I said 3 times already, regions or not are irrelevant to program correctness
<flux__>
vincenz, but it's PIA to handle all ints, Int32s and Bignums in one module :(
<vincenz>
flux__: true enough, that's why I want typeclasses
<Smerdyakov>
vincenz, of course they're relevant. Lack of space leaks can be the property you want to prove.
<schlick>
Smerdyakov: There probably isn't one. One wonders how well the type system handles people redefining operators (if such is possible) or multiple definitions of the same operator however. But again, this is a question of how much do I have to do to make it work, vs having it standard.
<vincenz>
Smerdyakov: well regions are just an IMPLEMENTATION issue
<vincenz>
you choose manual or gc
<vincenz>
and that defines how your program works
<vincenz>
semantically
<Smerdyakov>
schlick, to handle that well, you want type classes.
<Smerdyakov>
vincenz, no.
<vincenz>
Smerdyakov: how so
<Smerdyakov>
vincenz, in the ML Kit, region allocation information is present in your code. It can be inferred (non-uniquely) if you don't want to write it.
<schlick>
vincenz: Ok, so they're not related to program correctness. This is great. I heartily agree and shake your hand. The war is over.
<schlick>
vincenz: So are leaks avoidable in regions? [notice I didn't say /a word/ about correctness]
<vincenz>
schlick: you're asking me wethere to get chrome wheels or iron wheels when you're still in the phase of designing a generic car
<vincenz>
schlick: leaks are as avoidable as in any manual system, it's purely dependent on how programmer uses them
<schlick>
vincenz: Consider it a ca we're selling it to someone who's a asthete then. :P [notice I'm not arguing, nor am I willing to veer off the topic, I'm trying to find out if what the MLton page says about leaks being unavoidable in regions is true]
<vincenz>
schlick: they're as unavoidable as how the programmer uses them. REgion based memory management is quite simplle
<vincenz>
you allocate from a certain region and then when you're done with all the data, you free the entire region
<vincenz>
if the programmer doesn't free the region, it leaks
<schlick>
vincenz: Ok, I'm curious then, why is it the stack based system discussed on MLton's page said to have unavoidable leaks for some programs?
<vincenz>
if you use region memory management in a gc
<vincenz>
then you have to make sure that one variable is not kept alive in a region that is dead for the rest
<vincenz>
cause that'd be a 'leak' as well, though not a real leak
<vincenz>
schlick: regions are only really useful for applications that work in a phased way
_JusSx_ has quit ["leaving"]
<schlick>
I can see that, like retaining a reference in a garbage collected language accidentally. I'm more curious about why it's said to be unavoidable.
<vincenz>
schlick: hardly as a generic memory manager for a generic programming language
<vincenz>
so regions: no
<schlick>
Most things aiming at being C replacements are using regions (Cyclone, Vault), which is cause for concern if leaks are unavoidable.
<vincenz>
schlick: I'm afraid I'm not familiar wiith cyclone or vault
<vincenz>
either way, unavoidable is a strong claim
<vincenz>
it all depends if you want a region based gc or a region based memory manager
<vincenz>
I assume gc, cause a region based memory manager is just an implementation choice of a system that'll allow you to do malloc and free
<vincenz>
in the case of gc, I assume the difficulty comes in making sure that short term data is regioned together with other short term data
<vincenz>
such that you don't have some long term data in a region with lots of dead short term data
<vincenz>
thereby making the region unreclaimable
<schlick>
vincenz: The claim on http://mlton.org/Regions is that they are theoretically and practically unavoidable. How they arrived at this conclusion is what I'm curious about.
<schlick>
Overlaps is all I could come up with and that doesn't make much sense.
<vincenz>
schlick: they're basically saying it's too difficult to determine what data is short term and which long term
<vincenz>
thereby making any implementation of ar egion based gc inefficient
<vincenz>
schlick: I would forego regions, they're just an optimization that works in some cases
<vincenz>
schlick: the question you want is: gc or manual
<vincenz>
and in the case of gc, just get yourself a local copy of a generational g
<vincenz>
..gc
<vincenz>
schlick: and they are theoretically and practically unavoidable for how mlton uses the gc
<vincenz>
if your program has different semantics, regions might turn out to be good, but again, it's an optimization decision, so I'd leave it for later
<schlick>
vincenz: You seem to have some interest in the plans I have for the language. <sigh> Ok, the idea is first to develop a language that I can stand to read and write that force me into good habits (yes I know people will scream this is terrible, they'd do the same if I told them I was implementing a language to be uglier than APL-11 and force me into bad habits, whatever).
<schlick>
Then write a OS in it.
<schlick>
Now people will complain it's totall impractical and stupid. Again, whatever.
<schlick>
There is a problem in that garbage collection does not work well with systems programming in many cases. Namely, implementing a garbage collector in a garbage collected language is impossible as far as I can tell.
<vincenz>
schlick: either way your runtime system will haveto be done once in c
<schlick>
Therefore the language will have at least two modes. One will be manual, one will be garbage collected. The manual mode will be used (hopefully only) to implement the garbage collector. This is, hopefully, nicer for the programmer than having to write in two languages with totally different syntax (which, yes, is a practical concern, it's that much more time they'd have to waste learning new syntax).
<schlick>
practical concern, it's that much more time they'd have to waste learning new syntax).
* vincenz
needs to go home to work further on his paper
<schlick>
The runtime system could be done in anything, including a interpreted language.
<schlick>
I will want it eventually to compile to assembly.
<schlick>
And be self hosting.
<schlick>
The curiousity in regions is, using Vault for inspiration for the manual-ish memory management mode, it might be better than a more C like approach. However, I definatly /don't/ want to commit to that if it means some programs I write will always leak.
<Schmurtz>
just to give my 2cents :
<Schmurtz>
in some case, it may be useful to allocate local variables on a stack
<Schmurtz>
it suppresses many trivial garbage collections
<schlick>
So now that I've gotten everybody all upset about not wanting to write everything in ML, and having some curiosity about a memory managment topic called regions, I'm still wondering if leaks are unavoidable with regions and why. And as a side note for people in the "everything in ML!" group, I say "Ok, great, ML doesn't bug me much, but show me how to write a garbage collector in it".
<schlick>
doesn't bug me much, but show me how to write a garbage collector in it".
<schlick>
Schmurtz: I've come up with a cutesy way of doing garbage collection in a kernel (but, unfortunatly, I still can't write a garbage collector in a garbage collected form of the language :/ ). Systems level programmers need pretty strong controls on when memory is allocated and deallocated. This is one reason they claim garbage collection is evil and we should all be leet haXors.
<schlick>
garbage collection is evil and we should all be leet haXors.
<flux__>
btw, there's an operating system written in haskell
<Schmurtz>
it may be not optimal
<flux__>
'house hop haskell' will find you more information about it
<flux__>
what is?
<Schmurtz>
garbage collection is something the main performance issue
<Schmurtz>
(it also really depends on your coding style)
<schlick>
Schmurtz: My current plans for the mode that is garbage collected is to have allocation and deallocation start /immediatly/ (no waiting around). In theory this is slower, in practice, it isn't (try to beat C at memory management overhead in /real/ software). It also means people that have to care about the timing know what's happening. People that /don't/ care can treat it just like a usual GC'ed language.
<schlick>
what's happening. People that /don't/ care can treat it just like a usual GC'ed language.
<schlick>
Schmurtz: I also hope to have it done in a separate thread, so it won't "stop the world" on big allocations/deallocations. This requires some pecularities in language design to cope with the asynchronisity of allocation.
<flux__>
language design? surely not, but maybe in its compilation, or runtime
<schlick>
flux__: Oh yes it does! :P
<schlick>
What do you do when you say "new fooobject", and then fooobject isn't there?
<schlick>
Most languages assume when you say "make me a object" it does it there. To do that, allocation has to be synchronous.
<Schmurtz>
schlick, one idea is to have a reference count system
<flux__>
there can be many reasons why creation of an object fails
<schlick>
You basically have to treat this like asynchronous I/O but for memory allocation/deallocation. Which actually /does/ become I/O when you consider swap.
<Schmurtz>
you add 1 each time you get a pointer to the object, and suppress one each time you release it
<Schmurtz>
schlick, yes, but it may be a good workarround
<Schmurtz>
it depends on what you want
<schlick>
Schmurtz: Current plans (if regions are actually bad) are to do a mark and sweep garbage collector, just have it start doing its work immediatly, but do it asynchronous, to try to come off with a decent blend of performance and control.
<Schmurtz>
ok
<schlick>
Schmurtz: Primary goals for the language (most to least): catch as many bugs as theoretically possible at compile time, make the language really easy to read and maintain, make using the associated tools as effort-free as possible (e.g. I don't want to run one tool, manually insert its results into some source, then hand feed that into another tool, then translate it into some other language...).
<schlick>
hand feed that into another tool, then translate it into some other language...).
vodka-goo has joined #ocaml
<schlick>
I suspect initially I'll be doing a heck of a lot of hand translating and hand verifying. That's to be expected, I just don't want the end result to be like that.
kmag|out is now known as kmagdsick
<schlick>
Bugs that can be avoided by just not making them possible in the language should be handled that way (e.g. C's weak type system is a source of a lot of these kinds of problems), so long as it doesn't cripple the language (that's the hard part... hey, at least you can drop goto safely :P).
_JusSx__ has joined #ocaml
<schlick>
flux__: BTW, I really like that Daikon tool you pointed out.
ppsmimou has quit ["Leaving"]
code17 has joined #ocaml
kmagdsick is now known as kmag|lunch
code17 has quit ["leaving"]
smimou has joined #ocaml
Oejet has joined #ocaml
robajs has joined #ocaml
<robajs>
hello
kmag|lunch is now known as kmagdsick
<schlick>
Hi.
pango has quit ["Leaving"]
pango has joined #ocaml
<vincenz>
schlick: it's bullshit to expect that C is faster in memory allocation
<vincenz>
it still needs a memory allocator, and trust me, there is better than the default memory allocator (Which if you're interested in it is called lea in linux and kingsley in windows)
<Oejet>
vincenz: By memory allocator you mean e.g. malloc and xmalloc?
<vincenz>
Oejet: yeah
<vincenz>
lot of stuff going on behind that call or a free clal
<Oejet>
Administration of a free list and such?
<vincenz>
indeed
<vincenz>
coalescing and splitting of blocks
* vincenz
hmms
erik has joined #ocaml
<vincenz>
I wonder if you could make a dma targetted at garbage collection
<vincenz>
that would be neata
<erik>
hey, I'm having trouble linking together an ocaml object file with a regular gcc .o on amd64, the linker is complaining about relocation and saying I need to recompile with -fPIC
<erik>
I've fPIC'd everything I can think of that led to that link, is there a way I can test an object file for PICness?
gim has joined #ocaml
<flux__>
good question
<flux__>
maybe objdump will tell
<flux__>
or maybe the objdump's disassembled output, if you know what you're looking for? I wouldn't ;)
Raziel has joined #ocaml
Oejet has quit [Read error: 104 (Connection reset by peer)]
_JusSx__ has quit ["leaving"]
quamaretto has joined #ocaml
shirogane has joined #ocaml
<schlick>
vincenz: I'm still going to claim that C's manual memory handling is faster and less overhead than a garbage collector. The garbage collector involves executing more code than manual memory management, this will take some time, and use some memory, by definition. The manual method doesn't do it. The garbage collector can never be smarter than the programmer.
<quamaretto>
schlick: " The garbage collector can never be smarter than the programmer." False.
<schlick>
vincenz: This isn't to say that garbage collection is bad. I plan to have it in my language. However, it is a very good argument for trying to make it possible for the programmer to control it as much as possible, if they need to.
<schlick>
quamaretto: The programmer knows the meaning behind what they're trying to get done, and if it's a good idea to allocate or free memory at the moment. The garbage collector just does its work as a side effect of what's going on in the program. Being a program, it has no idea whether it particularly matters or not when it allocates or frees large amounts of ram.
<schlick>
One example would be doing something where pauses due to paging would be irritating, such as video or sound playback.
__DL__ has quit ["Bye Bye"]
<quamaretto>
schlick: One, programmers may *think* they know where it is best to allocate and deallocate memory.
<quamaretto>
That does not make it true.
<schlick>
This is true, but having the garbage collector try to outsmart them tends to not work very well.
<quamaretto>
schlick: What is your evidence?
<schlick>
Such as the situation I just mentioned.
<schlick>
quamaretto: The main evidence I have (though I see no reason to present any since you haven't) is that video and sound players are almost never written in a garbage collected language.
robajs has quit [Read error: 110 (Connection timed out)]
<flux__>
what kind of evidence is that?-o
<schlick>
This isn't to say that they can't be. And as everything gets faster, more will be, I'm sure.
<quamaretto>
So your evidence is that you have no evidence.
<schlick>
Nope, just gave the evidence.
<quamaretto>
What is that evidence of?
<flux__>
I think there are video players written even in java
<quamaretto>
I was asking for evidence that manual garbage collection is *faster*, not that manual collection is *fast enough*
<mellum>
Well, people certainly wouldn't choose an inappropriate language. There would be millions of Visual Basic and PHP coders otherwise.
<quamaretto>
XD POINT!
<flux__>
:-)
<schlick>
People don't use garbage collecting when pauses matter. Garbage collectors rarely give the programmer much control. If they decide they're going to dump a huge load of objects (because you just removed the last reference to the one the others are hanging off of) and you're doing something with real time video or sound, it's going to jerk and skip.
<quamaretto>
schlick: How do you *know* that?
Raziel has quit ["Yo soy goma. Tú eres cola."]
<quamaretto>
You have stated it without presenting evidence.
<quamaretto>
A statement is not a proof.
<flux__>
hey, he's got a point, garbage collectors for realtime environments are a research area?
<schlick>
quamaretto: from using said applications? From using Linux, which has video and sound players? The current Windows Media Player isn't in CLR or Java bytecode either.
<flux__>
but pauses don't mean that they are slower, only that the slowness is unevenly distributet
<flux__>
ted
<mellum>
realtime demands are *way* more strict than what you need for video or audio not to skip
<kmagdsick>
schlick: incremental garbage collectors can be used in real-time environments
Raziel has joined #ocaml
<kmagdsick>
schlick: you can do a partial garbage collection, say for 1/100th of a second
<quamaretto>
schlick: I am talking about evidence that manual mm is FASTER THAN garbage collection.
<quamaretto>
You have proved that manual memory management is USED IN AT LEAST ONE PROGRAM. GOOD FOR YOU.
inkedmn has joined #ocaml
<schlick>
quamaretto: see the line where I pointed out manual is hard coded (it involves no reasoning at runtime), garbage collection requires additional code. Given no code executes instantaniously, garbage collection will have to be slower.
<quamaretto>
schlick: You have not proven *that*.
<schlick>
The practical concern isn't quite so much the garbage collection, but the lack of control and predictability most of them give the programmer.
<schlick>
quamaretto: Ok, let me know when you invent a garbage collector that involves no code.
<quamaretto>
Let me know when you write a manually memory managed program without any memory management code.
<mellum>
Well, allocating memory always takes code. When would it ever not take code? I don't understand that point.
<quamaretto>
"no reasoning" is inherently false unless it takes 0 time to allocate and deallocate memory.
<schlick>
garbage collection involves the requisite allocation and deallocation that manual memory management does, but it also requires the actual /garbage collector/ built on top of it.
<schlick>
The latter is additional overhead.
<quamaretto>
schlick: You have not proven that.
<schlick>
Though, as I said, the primary problem is the lack of control and predictability.
<quamaretto>
You cannot demonstrate that a garbage collector cannot predict what a human can.
<schlick>
quamaretto: common sense says nonexistant programs don't exist (observe: tautaology). Garbage collectors that have no code, and manage to work, don't exist.
<flux__>
schlick, you know, it's not all losses with gc, gc can also release larger groups of allocation in one operation, while you need to match multiple mallocs with multiple frees
<mellum>
schlick: but allocation is vastly simpler, for example. Allocating something takes about 3 instructions with Ocaml's GC. I don't believe C's malloc compiles to 3 instructions.
<flux__>
mellum, that's pretty nice
<vincenz>
re
<quamaretto>
schlick: The rest of the program acts as a garbage collector in a non garbage-collected program.
<vincenz>
schlick: I can vouch for the fact that it's not true, you assume that the actual malloc and free are costless which they are not
<quamaretto>
schlick: You are saying that programs speed is EQUAL TO PROGRAM SIZE. STUPID.
<vincenz>
mellum: 3 instructions?
<mellum>
vincenz:
* vincenz
knows for a fact that allocation is a costly problem in manual allocation
<schlick>
flux__: I'm aware, it's one reason I was planning on using a garbage collector, however the main reason mine is a little weird (e.g. it deallocates as soon as possible) is due to the predictability and control issue. [control wise if you don't want it to deallocate immediatly don't remove the last reference]
<vincenz>
mellum: hmm... what's that say?
<flux__>
mellum, hmm.. camlTest is your function?
<mellum>
vincenz: check if the minor heap is full. If so. go somewhere to do some cleanup. Otherwise bump minor heap pointer.
<vincenz>
mellum: ah yeah :)
<vincenz>
mellum: but yeah, a malloc can go down to that if it's not checking quicklists
<schlick>
quamaretto: Nope, I'm not saying program speed is equal to code size. This brings into question which of us is stupid. I am saying that code that doesn't exist doesn't take time to execute. There's a quote here from a famous DEC person but I can't recall it. :P
<flux__>
vincenz, can it really?
* vincenz
designed several memory allocators and even a full buildingblock set of memory allocators
<quamaretto>
schlick: the program calling manual memory managements exists.
<vincenz>
flux__: but yeah, the std ones are not always super efficient
<vincenz>
hence our publishing papers on application specific memory allocators
<kmagdsick>
schlick: for extremely simple cases it's sure a human beats an automatic gc
<vincenz>
kmagdsick: that's not a given
<vincenz>
kmagdsick: people assume that malloc and free a costless
<schlick>
vincenz: I'm not assuming malloc and free are costless, only that code built atop them to figure out when to allocate and deallocate things at runtime costs. If it's hard coded, it's figured out at compile time (usually by the programmer), rather than spending time at runtime.
<kmagdsick>
schlick: but for very complex cases, with manual gc, you end up making your own ref count or mark-and-sweep
<vincenz>
schlick: no
<vincenz>
I mean yes
<vincenz>
schlick: but with a gc you're freeing many things at once, reducinig the free cost
<quamaretto>
schlick: A program runs according to an algorithm which determines when memory is allocated and de-allocated.
<kmagdsick>
yes, cache locality is very important
<quamaretto>
schlick: This is true of both garbage collected and manually collected programs.
<schlick>
vincenz: there's nothing about garbage collecting that says you have to do it that way, but yes, that's the way most of them do it. It's also the reason a lot of programmers don't like it. Garbage collection tends to result in large amounts of allocations and deallocations (often effecting paging) that the programmer (usually) has no control over.
<vincenz>
schlick: gc don't allocate
<vincenz>
allocations are decided at compile time
<vincenz>
let a = .... (allocate an a)
<quamaretto>
schlick: That's a matter of optimization. Maybe it can be done by a human, maybe not. Maybe by a computer, maybe not.
<schlick>
vincenz: Depends on your implementation. Garbage collected objects are on the heap. Those are handled at runtime, unlike those on the stack.
<kmagdsick>
there's no reason gc has to be either-or
<kmagdsick>
it's conceivable that you could implement a free() function in an automatic gc language
<kmagdsick>
and add some danger
<schlick>
It's been done before.
<kmagdsick>
but increase controll
<kmagdsick>
and get away with less frequent gcs
<quamaretto>
schlick: Are you saying that the best place for an object to be deallocated is a function of the rest of the program code? Because if not, a human CANNOT decide the absolute best place, and if so, a computer can. So you cannot prove that a human is an inherently better memory manager.
<vincenz>
quamaretto: even when you free, it's sitll being handled by a memory manager for all intents of purposes could be a gc :P
* vincenz
adds a 'which'
<quamaretto>
vincenz: That's what I'm saying.
<vincenz>
ah cool :)
<quamaretto>
THat' PART of what I'm saying.
<vincenz>
anyway
<schlick>
vincenz: Humans have to be smart enough to write the code. The code can check itself. But it only knows how, because of the human. Until computers are self aware, I don't expect this to change. If a human can't describe how to do something, or how to figure out how to do something (e.g. genetic programming fitness functions), then the computer can't do it. Thus, yes, the programmer is always smarter.
<vincenz>
non-gc is only for languages that typically pass values by copy
<schlick>
fitness functions), then the computer can't do it. Thus, yes, the programmer is always smarter.
<vincenz>
if everythiing was passed by reference I'd vouch for a gc
<quamaretto>
schlick: What do you feel is "special" about a human programmer that cannot be replaced by a computer?
<vincenz>
quamaretto: dumb people write compilers :P
<quamaretto>
A computer which is taught to do arithmetic can do so much faster than a human.
<quamaretto>
A computer which is taught to write memory management code can do so better than at least *some* humans.
<schlick>
In any case I was responding to vincenz statement which seems sort of random. Everybody else is off "zOMG! He criticized garbage collection (in widely recognized ways)! Must defend ML's honor!" And then continue to ignore that I didn't say garbage collection was bad, just the way it's usually done is too unpredictable, and often too slow, for many programmer's uses.
<vincenz>
schlick: I was responding to somethin said earlier
<vincenz>
schlick: there's been studieis that prove that gc and manual allocation are at par
<schlick>
quamaretto: See previous statement about right now humans having to explain everything to computers. This is what is "special" that a computer can't do for itself.
<schlick>
[Yet, anyway]
<quamaretto>
schlick: What is that a computer can't do for itself?
<quamaretto>
schlick: You haven't pointed out anything that a computer can't do, when taught how. If you can teach it to program itself or other computers, then it can do that.
<schlick>
quamaretto: Determine how to solve a problem a programmer does not know how to solve, or how to arrive at a method to solve (metaprogramming).
<vincenz>
a computer doesn't have to be selfaware, just have a performant gc implementaiton
<schlick>
It can't find out new ways to program itself.
<quamaretto>
schlick: You can't prove that a computer can't be taught to do that.
<schlick>
The human has a need.
<schlick>
The computer is a tool.
<quamaretto>
schlick: You can't prove that a computer can't be taught to introspect.
<schlick>
The human has to program the tool to satisfy the need.
<vincenz>
introspection is hardly necessary to solve memory management issues
<quamaretto>
schlick: You can't prove that a human can solve the problem better than another human can program a computer to solve the problem FOR them.
<schlick>
quamaretto: You can't prove the sun will rise tomorrow! *armflail* Whatever. You're being silly. It's obvious computers CAN be taught to introspect. Human brains are basically a glorified unreliable, highly parallelized, analog computer. Thus a digital computer (which has already been used to simulate large parts of the human brain, such as the visual cortext)
<schlick>
the human brain, such as the visual cortext) can be used to simulate the whole deal... In theory.
<schlick>
Most likely by the time you get to that point the computer is no longer a tool and thus not much use. I have no need for machine people, but yes, in theory, it's doable.
<mellum>
pango: so, does it pause all the time due to GC? ;)
<schlick>
People make problems. Computers fix some of them.
<schlick>
[once you tell them how]
<quamaretto>
schlick: I disagree with your blanket statements about garbage collection, and you have attacked it on the basis that humans are inherently superior to computers.
<pango>
mellum: not as far as I can tell :)
<vincenz>
schlick: you're making a lot of blanket statements
<vincenz>
schlick: I -know- that gc and manual allocation are at par
<schlick>
vincenz: I tend to work off common sense rather than logical formalism for everything. Logic says that assuming all dogs are blue, and Rover is a dog, rover is blue. However, all dogs are not blue, as observation and common sense dictate.
<vincenz>
schlick: and I did part of my phd on memory management and have done extensive literature study on the subject
<quamaretto>
schlick: Common sense is wrong in many, many cases.
<pango>
a language that will both allow for a lot of control, and at the same time prevent programmers from writing bugs... mmmh
<vincenz>
pango: typed assembly?
<schlick>
vincenz: it has occured to me that (barring issues with external code, where the theory breaks down) you could compile and optimize a garbage collector into raw calls to allocate and free memory. In practice they are probably "on par" by some definition of "par". In practice, most implementations don't give the programmer much control, resulting in unpredictable memory usage and noticable pauses when they allocate/deallocate larg
<schlick>
programmer much control, resulting in unpredictable memory usage and noticable pauses when they allocate/deallocate large amounts of memory.
<vincenz>
quamaretto: yeah especially on modern architectures where it's hard to know how the memory hierarchy will affect all details, hence making tools better than humans
<schlick>
Humans have to figure out how to make the tools.
<kmagdsick>
quamaretto: come on... it's intuitively obvious that given enough thrust and fuel, we could send a probe to Alpha Centauri in about 5 minutes, and looking at things doesn't change them
<schlick>
Thus it's still humans.
<vincenz>
schlick: generational collectors don't have pauses
<vincenz>
schlick: humans made computers
<pango>
vincenz: or rather, not unbound pauses
<vincenz>
right
<vincenz>
but any free call has some pause tooo
<vincenz>
and undecided memory usage
<schlick>
All the human is doing is observing some patterns about proper behavior, then forcing them on the system. They say "when you see this, it's wrong, or do this". A programmer trying to catch every error by hand, or handle every case by hand, will, yes, make mistakes occasionally (according to studies about once every 200 to 2000 lines of code).
<schlick>
But programmers still write the rules by which garbage collection functions.
<vincenz>
schlick: andn?
<schlick>
And it is likely unwise to remove your control over such things. When it's needed, you can improve on it.
<quamaretto>
schlick: Humans have to create algorithms. Computers can run algorithms faster than humans can.
<vincenz>
schlick: are you trying to support your case or contradict it?
<vincenz>
l
<schlick>
vincenz: I'm not really sure what you expect my case to be, other than the obvious observable phenomena that most garbage collectors in common use have noticable pauses the programmer can't do much about (because they give no control to them). Hey, you can go argue with the Java VM if you want. :P
<vincenz>
schlick: no adding 'control' would only ruin assumptions these algorithms make to work effciieintly or correctly at all
<vincenz>
schlick: you're basing yourself on java?
<vincenz>
it's known through literature that java has a bad gc
<kmagdsick>
vincenz: you mean the current Sun JVM
<vincenz>
kmagdsick: correct
<pango>
not to mention they're more than one kind of gc (sequential/parallel/...)
<pango>
for different uses
<pango>
so arguing about "gcs" in general is rather pointless
<schlick>
I've already said garbage collection isn't inherantly bad. It can't, I'm fairly sure, be optimized down to raw calls to allocate and deallocate memory, due to that eliminating your ability to have external code (outside your compilation unit) which also uses the garbage collector. You can give the programmer control over them to eliminate most of the problems. The main thing it does is reduce mistakes in manual memory handling.
<schlick>
them to eliminate most of the problems. The main thing it does is reduce mistakes in manual memory handling.
<vincenz>
schlick: I think that adding this control would only complexify the gc thereby making the totalilty slower not faster
<schlick>
vincenz: Great, Java has bad GC. Cool. :P I think we agree.
<schlick>
Holy shit, that means you're stupid too! [joking]
<vincenz>
schlick: then don't use it as cannonfodder to back your statement
<quamaretto>
schlick: Why do you think that it can't be optimized down to raw calls?
<quamaretto>
Whatever "raw calls" means.
<schlick>
quamaretto: If you optimize the garbage collector away to nothing, there is nothing for the external code to make calls to.
<pango>
I'd really like to know what those raw calls are, too
exa has joined #ocaml
<vincenz>
quamaretto: not even a memory manager for non gc can be taken away to nothing
<schlick>
quamaretto: "raw calls" means "we deallocate whenever the garbage collector would have said for us to, but it's calculated at compile time rather than run time".
<vincenz>
unless you have an unlimited amount of memory
<quamaretto>
schlick: Why couldn't a garbage collector produce the same code as the best human?
<pango>
schlick: what is allocated and what is not depends on memory manager own structures, there's no "raw calls"
<quamaretto>
You are assuming that garbage collection must be done in a manner fundamentally different from the way a programmer manages memory.
<schlick>
quamaretto: current state of technology doesn't allow garbage collectors to figure out how to write themselves, thus some human has to figure out what the "best" (by some definition) is, and then apply it to programs. Unfortunatly, one mechanism is rarely ideal for all programs.
<pango>
quamaretto: or rather, fundamentally the same (as in "build on top of malloc/free)
<vincenz>
pango: and for instance the windows one is really bad for embedded systems cause it tends to leak huge amounts of space
<quamaretto>
schlick: You assume that humans writing code do not work in a way which can be codified.
<schlick>
quamaretto: No, you're trying to make me say things so you can argue with me and win. ;) All I'm saying is if you have a garbage collector, it's deciding when to free things (usually... usually there's no control by the programmer), if you don't have one, the programmer decides when to free things. Additional code execution at run time (e.g. the garbage collection) takes some time (we've been over this before).
<schlick>
execution at run time (e.g. the garbage collection) takes some time (we've been over this before).
<flux__>
I have one program where gc takes 40% of cpu. it did drop somewhere around 20% after tuning gc parameters.
<schlick>
quamaretto: if it can be codified it can also be hard coded.
<flux__>
it would've been a lot faster had I not used lists but instead fixed length arrays
joshcryer has quit [Connection timed out]
<quamaretto>
schlick: Why do you say that garbage collection takes "some time" that a program written by a human does not spend?
<schlick>
quamaretto: Whether doing so has practical problems or not is another matter (e.g. the issue with external code).
<flux__>
but that itself is no claim against gc; traditional memory management could easily have been slower
<erik>
GC algos are potentially faster than manual dealloc
<schlick>
quamaretto: You seem to have some problems reading what I'm saying. Go back and try again.
<erik>
the kind of manual dealloc that is reasonable to perform at least
<vincenz>
erik: yup
<erik>
can free in larger blocks, fewer syscalls etc
<vincenz>
erik: tho... sadly performance is no longer a viable measure and I wish people would get off the speed horse
<flux__>
also region inference would've so kicked ass in that application
<erik>
vincenz: i'm just trying to say it's both faster *and* better :)
<vincenz>
erik: :)
<flux__>
because each iteration shared almost nothing with the previous one
<vincenz>
the main issue now is power consumption
shirogane has quit [Remote closed the connection]
<quamaretto>
schlick: You do not understand what a computer program is. It is a set of statements. A program with garbage collection has the set of statements determined differently. That does not mean it has *more* statements.
<vincenz>
flux__: right and if you had an extra year you could gain 2% after tuning a handcrafted allocator
SmerdyOffice has joined #ocaml
<schlick>
vincenz: Honestly it's not the speed of the GC algorithm that's the problem, it's the predictability. If you start allocating or freeing large amounts of memory you hit swap. That's slow. Yes you can try to guesstimate how to avoid doing this I know. You can also make it predictable to the programmer. You can mix and match. You can have manual freeing (has been done to work around the issues with GC).
<schlick>
match. You can have manual freeing (has been done to work around the issues with GC) in addition to GC.
<vincenz>
schlick: you assuming that freeing data manually has predictable behaviour
<flux__>
vincenz, well I don't think it would've taken me a year to optimize a few hundred lines :)
<schlick>
vincenz: This is very true, and it doesn't always.
<vincenz>
schlick: it never does
<flux__>
(to reuse memory)
<schlick>
vincenz: You get decent guarantees in kernelspace, which is where a lot of these issues matter. If you tell the memory handling mechanism of a kernel to free memory, it better do it NOW, and it better do it /fast/. Not try to guess what it should do and outsmart you.
<vincenz>
unless your memory allocator is : malloc (int) {char * p = mem; mem+= int; return p} free(void *) {;}
<schlick>
vincenz: From userspace, the kernelspace handling of memory allocation usually gets "clever" to try to improve overall performance, and ends up being somewhat unpredictable, though not nearly as bad as popular garbage collection implementations that tend to allocate and free huge chunks of memory.
<schlick>
[which just ends up firing off lots of calls to the, already unpredictable, tricky kernel allocator]
<vincenz>
schlick: incorrect, the advantage of those huge chunks is a lot less free calls that each have smaller but more numerous impredictabilities
<schlick>
This is true depending on how swap is handled. Huge chunks may well be swapped out, especially if they aren't used for a while.
<schlick>
Then things get nasty.
* vincenz
gives up
<vincenz>
anyone familiar with the lstlistings package of tex?
<vodka-goo>
mmm, reminds me of another question... anyone ever did some (pie)charts with latex ?
<vodka-goo>
maybe this isn't the right place ;)
<vincenz>
vodka-goo: you a specialist in type inference?
<mellum>
Mhhm. Pies and latex.
<vincenz>
anyone know what the problems are between a module system and a type class system that makes the two somewhat either or
<vodka-goo>
vincenz: nope.. why do you think so ?
Snark has quit ["Leaving"]
<vincenz>
vodka-goo: I always thought that was the case
<vincenz>
can't remember but I thought I heard something to that extent
<vodka-goo>
can't remember either.. maybe I said something about implementing type inference in lambda prolog ?
<vodka-goo>
anyway
<vincenz>
just wish that ocaml had type classes :D
* vincenz
drools
<vodka-goo>
we can try to discuss about that, I'm interested in OO in FP languages ;)
<vincenz>
vodka-goo: it's not oo
<vodka-goo>
vincenz: what do you need from type classes ?
<vodka-goo>
vincenz: yeah, but I got interested in Oo and people told me Haskell had the clean answer instead of Oo..
<vincenz>
vodka-goo: type-sensitive overloading
<vodka-goo>
it looks like restricted Oo, less (but still) runtime resolving of methods, cleaner inheritance (I don't like OCaml's btw)
<vincenz>
vodka-goo: no, typeclasses are compiletime resolved
<vincenz>
unless you allow for heterogeneous containers
<vodka-goo>
vincenz: if Ocaml's int and float where represented by objects, you would have this overloading right ?
<vincenz>
vodka-goo: it's got nothing to do with objects
<vincenz>
vodka-goo: I don't want the runtime dispatching
<vincenz>
hence typeclasses
<schlick>
flux__: you there?
<vincenz>
vodka-goo: basically instead of just having +: 'a -> 'a -> 'a
<vincenz>
you'd have
<vincenz>
for all Num 'a:: 'a -> 'a -> 'a
<vincenz>
but then if it sees it's an int
<vincenz>
it would call the int version
<vincenz>
and this is decided at compiletime
<vincenz>
if you want your type to respond to +
<vincenz>
you say it inherits from num
<vincenz>
then write the + func
<vincenz>
and it sees you doing yourtype + yourtype
<vincenz>
it'll call that + func
<vodka-goo>
vincenz: if you have two implementations of a typeclass (two extensions maybe ?) and a function taking a value in this class, then how does the system resolve the calls ?
<vincenz>
vodka-goo: typing?
<vodka-goo>
in general I don't think it's possible
<vincenz>
vodka-goo: it's like specialized templates
<vincenz>
vodka-goo: as long as you don't allow a container
<vincenz>
vodka-goo: see the big trick is here
<vodka-goo>
sometimes it's optimized (no runtime resolution) but not in general
<vincenz>
wait
<vincenz>
I have thought about it
<vincenz>
and realize the ONE stumbling block that reqiures runtime dispatching
<vodka-goo>
I'm not comfortable with that container.. what the idea ?
<vincenz>
vodka-goo: you can't store different kinds of num in one container
<vincenz>
vodka-goo: can't have Show 'a list
<vincenz>
for different 'a
<vincenz>
they all have to be one 'a
<vincenz>
or in this case Num a
<vodka-goo>
ok
<vincenz>
ifi you don't allow that
<vincenz>
it can be completely inferred at compiletime
<vincenz>
vodka-goo: only real ooc languages allow that
<vincenz>
like the ocaml oo system
<vodka-goo>
but let's go back to your Num example.. what if the function is polymorphic and you don't know yet which type will have the arg ?
<vincenz>
vodka-goo: instantiate it for each call
<vincenz>
vodka-goo: like c++ templates
<vodka-goo>
ok
<vincenz>
just like it's done now with 'a funcs
<vodka-goo>
how does it scales to separate compilation, library compilation ?
<vincenz>
except you specify the 'a
<vincenz>
to having a more specific 'a
<vincenz>
vodka-goo: not certain how it works with modules, hence me asking
<vincenz>
I overheard once that modules and typeclasses are complementary
<vincenz>
except that typeclasses do cut on fingertyping
<vodka-goo>
I agree runtime dispatch is not se nice, but it's not so bad too.. and these multiple instantiations worry me quite as much
<vincenz>
vodka-goo: ocaml already does multi instantiation
<vincenz>
just that we can't restrict 'a to a certain set
<vincenz>
or a certain type class
<vodka-goo>
?
<vincenz>
well right now
<vincenz>
the + has type int -> int -> int
<vodka-goo>
when would OCaml do that ?
<vincenz>
vodka-goo: it doesn't?
<vodka-goo>
I don't think so
<vincenz>
hmm
<vodka-goo>
a polymorphic function is a single piece of code
<vincenz>
even in assembly?
<vodka-goo>
I'm quite sure
<vincenz>
so what if you have an 'a ref list
<vodka-goo>
since you can build a lib with real polymorphic funcs
<vincenz>
I always thought it instantiated per type
<vodka-goo>
vincenz: then you won't be able to apply these 'a refs to much funcs ;)
<vincenz>
I guess it's a trade off between runtime cost and code-size
<vincenz>
but you're not forced into runtime dispatching with type classes
<vodka-goo>
btw, it won't be a 'a ref list but a '_a ref list
<SmerdyOffice>
vincenz, in general, type classes require runtime dispatch.
<vincenz>
SmerdyOffice: I thought only if you allow heterogeneous containers
<vodka-goo>
vincenz: that's the point, one more tradeoff
<SmerdyOffice>
vincenz, type classes have nothing to do with containers.
<vincenz>
SmerdyOffice: my point is that at any call of a method that takes a type classes, you know which type you're actually passing so you know whiich specifiic instance you need to call
<vincenz>
hence runtime dispatching is not -required-
<vodka-goo>
on the other hand the runtime dispatch is lighter with type classes than with ocaml's objects
<vincenz>
vodka-goo: how so?
<vodka-goo>
with ocaml you hash the method's name and get the code from an array
<vodka-goo>
in haskell you don't have any string, you already know the index of the method
<vincenz>
hmm
<vincenz>
vodka-goo: what if you have a type that instantiates multiple type classes?
<vodka-goo>
the whole thing is because typeclasses are about classes, whereas Ocaml's objects can have the same type but come from different classes
<vodka-goo>
if all the extensions are made from the same base, then you can enforce the order of methods
<vodka-goo>
basically you build an array of methods in chronological order
<vodka-goo>
in ocaml no such thing is possible
<vodka-goo>
this hash thing is worrying.. you can exen trick it if you use *really* long method names ;p
<pango>
isn't hashing done at compile, or at least at linking time ?
<kmagdsick>
vodka-goo: I would hope that it uses the hash codes in a hash map
<vodka-goo>
I'm quite sure the hashing is done at runtime
<kmagdsick>
vodka-goo: and still ends up doing a string comparison
exa has quit [Remote closed the connection]
<pango>
vodka-goo: I don't really see the point, method name doesn't change at runtime
exa has joined #ocaml
<vodka-goo>
but there is also some Map stuff, I'm not sure about this
<vodka-goo>
pango: considering the fact that ocaml is not class-based how would you statically map the names to int ?
<vodka-goo>
actually I have some dirty code involving CamlinternalOO that demonstrates that stuff