Browse thread
Re: [Caml-list] Looking for collaborators on a hobby project
- szegedy@t...
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | szegedy@t... |
| Subject: | Re: [Caml-list] Looking for collaborators on a hobby project |
Dear Skaller!
Is the Vyper project public?
I could not find any version of Vyper on the net. :(
You have written, that the analyis of the type information
turned out be difficult. I can believe this. :)
However, this is something already solved. In fact,
this is solved in Ocaml! So, I would not have to solve it
directly.
Now, my idea is the following:
Suppose, we have the following Ruby class:
class A
def f(x,y)
x.g(y,@a)
end
def h(x)
f(@b,v)
end
end
Then the interpreter would simply transform it to the following OCaml
class:
type 'a myref = Nil | Obj of 'a
let use x = match x with
| Obj x -> x
| Nil -> failwith "Dereferencing nil"
class ['f_x,'f_y,'h_x,'a,'b] a =
object(self)
val mutable a:('a myref) = Nil
val mutable b:('b myref) = Nil
method f ( x : 'f_x) (y : 'f_y) = (use x)#g y a
method h ( v : 'f_x) = self#f b v
end
After that, OCaml would take care of all the typing stuff...
Of course using the myref class comes with a performance penalty also.
This can be eliminated if one does not allow nil at all: that is all
instance variables must have valid default value.
I think, this is a good idea anyway...
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners