<jemfinch`>
basically, the ideal way to do C FFI is to have a program handle everything for you.
<TimFreeman>
...reading...
<jemfinch`>
and that's what smlnj works on.
<jemfinch`>
the only thing is that doing that is *a lot* of work.
<jemfinch`>
O'Caml says, "we don't want to wait for the ideal way to do it, so we'll pick something that works now" -- and thus, it has more C libraries :)
<TimFreeman>
Um, why is doing it in a separate process ideal?
<jemfinch`>
no, not doing it in a separate process.
<jemfinch`>
using a program to write the initial mappings, them compiling them.
<jemfinch`>
it's all in the same process -- it's just that instead of writing the interface by hand, a program would do it.
<TimFreeman>
So in that URL you cited, smlnj isn't the new jersey approach, right?
<jemfinch`>
no, I don't think so :)
<jemfinch`>
let me check...
<TimFreeman>
Jargon clash. Odd, C and SML of NJ are from AT&T in New Jersey, right? Oh well, the paper says "the new jersey approach" is a caricature anyway and I ought to drop the issue of what happens in New Jersey.
<jemfinch`>
it's been a long time since I actually read it :)
<jemfinch`>
no, smlnj isn't the NJ approach.
<jemfinch`>
it's the MIT approach.
<TimFreeman>
Do you know when the paper was written? It says "...in 1995 we will have...", but the file is modified in 2002.
<jemfinch`>
TimFreeman: that's the slightly extended version of the paper.
<jemfinch`>
it was originally written in 1991, it notes.
<jemfinch`>
well, I think I'm off to do some chemistry.
<TimFreeman>
Have fun.
<jemfinch`>
thanks :)
<jemfinch`>
you have fun with O'Caml :)
<TimFreeman>
Are you still there? The paper says "continuations remain an ugly stain on the otherwise clean manuscript of Scheme." Now I'm all confused about this New Jersey approach thing again.
<jemfinch`>
TimFreeman: well, the additions to that page are by a guy named Erik Naggum.
<jemfinch`>
he's a *VERY* outspoken (that's the code word for "rude" or "obnoxious" Lisp advocate)
<jemfinch`>
you'll find that the people who like Lisp a whole lot generally don't like continuations.
<TimFreeman>
I see.
<jemfinch`>
I, personally, like them...or at least I think I do, having not had the oppurtunity to really use them yet :)
<TimFreeman>
I really like compile-time type checking. How do the lisp people think they can win when you have to discover type errors by exhaustively testing your code?
<jemfinch`>
well, a lot of successful systems are built with dynamically typed languages.
<jemfinch`>
cf. erlang, which is dynamically typed but created explicitly for the purpose of robust, reliable systems.
<TimFreeman>
I don't know much about erlang. I should check.
<jemfinch`>
one thing the Lisp people gain from their dynamic typesystem is the ability to reload code.
<jemfinch`>
if they write a function with a type error, and they wrote their code in a manner that allows them to interactively reload functions and whatnot, then they can fix the type error without ever bringing down the process.
<jemfinch`>
I wish there was a good way to do that in ML.
<TimFreeman>
You can relink modules in sml/nj, and I presume OCAML too, without having to bring down the interpreter. I agree that it might take a while, though, and you may not be able to continue execution very easily from where you ...
<TimFreeman>
were before the error.
<jemfinch`>
TimFreeman: but can you take a running program, perhaps a server, and say "replace this function with this new version"?
<jemfinch`>
that's what you can do in Lisp and Erlang, and I think their dynamic typesystems make that possible.
<TimFreeman>
Hmm. No.
<jemfinch`>
I think that's the main reason Erlang is dynamically typed -- because it needed to be able to do that.
<jemfinch`>
that and handle marshalling over the network safely and easily.
<TimFreeman>
Maybe if you did object oriented design right in OCAML you could replace a factory object on the fly. Hmm.
<jemfinch`>
dynamic typesystems seem to have their place.
<jemfinch`>
until we figure out how to do everything they can do in a static typesystem :D
<TimFreeman>
If you're always making things by following a reference to a factory object and then invoking a method on the factory
<TimFreeman>
object, you could load a new definition of the factory into a running system.
<TimFreeman>
Haven't tried this yet, though.
<jemfinch`>
you could do the same things with references to functions, I think.
<jemfinch`>
but then you lose polymorphism.
<TimFreeman>
Ya, at the cost of lots more references running around. One of the things you lose in that case is interprocedural optimization.
<jemfinch`>
and polymorphism :)
<jemfinch`>
# let r = ref List.map;;
<jemfinch`>
val r : (('_a -> '_b) -> '_a list -> '_b list) ref = {contents = <fun>}
<jemfinch`>
# !r (fun x -> x * 2) [1;2;3];;
<jemfinch`>
- : int list = [2; 4; 6]
<jemfinch`>
# r;;
<jemfinch`>
- : ((int -> int) -> int list -> int list) ref = {contents = <fun>}
<TimFreeman>
Yeah, I had to cope with polymorphism in my thesis.
<jemfinch`>
what'd you do your thesis on?
<TimFreeman>
A type system for an ML-like language. Type inference took much too long. Not really useful.
<jemfinch`>
why wasn't it useful?
<jemfinch`>
(is type inference a really time consuming thing?)
<TimFreeman>
It let you get type errors in a few more cases than the straight ML type system, at the cost of much slower compilation and more declarations. You can set up type inference systems that are undecidable (although mine ...
<TimFreeman>
wasn't), so they can take as much time as you want.
<TimFreeman>
Real languages have fast type inference, though.
<jemfinch`>
I'm getting ready to write another interpreter in ML, and I want it to be statically typed, and you've scared me that type inference might take too long :)
<TimFreeman>
installing erlang...
<TimFreeman>
No, ML type inference is fine. It won't be a problem.
<jemfinch`>
well, this is a bit different.
<jemfinch`>
do you know Python?
<TimFreeman>
Used it for a while. Dynamically typed, kind of lisp-ish with different syntax.
<jemfinch`>
yeah, I used it before I came to ML.
<jemfinch`>
anyway, the interpreter I'm going to write, I want to be statically typed, because one of the reasons I left Python was that I just got too annoyed with runtime errors.
<jemfinch`>
but I don't want to lose genericity at all.
<TimFreeman>
What exactly do you mean by genericity?
<jemfinch`>
so "type" in this language will really just be a synonrm for "set of methods"
<TimFreeman>
You want polymorphism?
<jemfinch`>
TimFreeman: if a function takes and object, and invokes on that object methods a, b, and c, I want *any* object with methods a, b, and c to be allowed as an argument to that function.
<jemfinch`>
ad hoc polymorphism, though, not parametric polymorphism.
<TimFreeman>
Called subtype polymorphism. Is there anything that you want to be able to do that ocaml can't?
<jemfinch`>
well, I'm not particularly fond of O'Caml's object syntax :)
<TimFreeman>
(Not to imply I know everything about what ocaml can do...)
<jemfinch`>
and I also want to be able to reload code on the fly, and integrate it into my irc bot.
<TimFreeman>
They have a preprocessor. You could change the syntax, I think. But reloading on the fly... Hmm...
<TimFreeman>
So if you have a definition of f and you want to load in a new one, how do you decide which types you'll accept for the new f?
<TimFreeman>
So maybe every value in your language is mapped to a reference value in OCAML, and you're dereferencing every time you reference a value?
<TimFreeman>
Is there any problem with compiling your language into OCAML?
<TimFreeman>
Looks like you got distracted with something else. That's okay.
jemfinch` has quit [Connection timed out]
TimFreeman has left #ocaml []
Yurik has joined #ocaml
kjs3 has quit [Connection timed out]
Jiriki has quit [Read error: 104 (Connection reset by peer)]
Jiriki has joined #ocaml
Cryptor has joined #ocaml
GnuVince has joined #ocaml
GnuVince has left #ocaml []
Cryptor has quit ["Leaving"]
Yurik has quit [Remote closed the connection]
Yurik has joined #ocaml
TimFreeman has joined #ocaml
malc has joined #ocaml
malc has quit ["no reason"]
Yurik has quit [Remote closed the connection]
Yurik has joined #ocaml
Yurik has quit [Remote closed the connection]
Yurik has joined #ocaml
samx has joined #ocaml
TimFreeman has left #ocaml []
TimFreeman has joined #ocaml
TimFreeman has left #ocaml []
Verbed has joined #ocaml
koyuki has quit [carter.openprojects.net irc.openprojects.net]
samx has quit [Read error: 110 (Connection timed out)]