00:01
<
Myrizio >
hi, just a confirmation, there is no way to work inductively with tuples (like with lists), is there?
00:08
<
zmdkrbou >
you break it or you don't
00:08
<
Myrizio >
zmdkrbou: eh, ok thanks for the answer :)
00:09
<
Myrizio >
still, i think it could be useful (with polymorphic functions)...
00:17
<
zmdkrbou >
mmh it would require a more powerful type system
00:18
<
zmdkrbou >
if you want a 'a * 'b * ... -> 'a * ('b * ...) function
00:19
<
Myrizio >
mh, i was just thinking about 'a -> ('b * ... * 'z) -> ('a * 'a * ... * 'z)
00:21
<
Myrizio >
but anyways yes, probably the type system should learn to match generic tuples to be able to do this...
00:21
<
zmdkrbou >
yes then you can code this yourself ... but you can't go up to an arbitrary high arity
00:22
<
zmdkrbou >
(anyway i never used a tuple of more than 5 or 6 elements)
00:24
<
Myrizio >
eh, i will try to code this as soon as i'll have finished learning ocaml :)
00:24
<
zmdkrbou >
Smerdyakov: :) i suppose you can also use metaocaml
00:25
<
zmdkrbou >
Myrizio: this is trivial code, let f3 (a,b,c) = a,(b,c) and so on :)
00:25
<
Smerdyakov >
I don't think the MetaOCaml approach works as well as mine.
00:26
<
Myrizio >
zmdkrbou: sure, i understand this code, i just tough you was thinking about extending the compiler :)
00:26
<
Smerdyakov >
I only care about two phases: compile time and run time.
00:26
<
Myrizio >
s/tough/tought
00:27
<
zmdkrbou >
huhuhu ok :) this, is not trivial :p
00:27
<
zmdkrbou >
Smerdyakov: i don't see other phases
00:28
<
Smerdyakov >
zmdkrbou, well, I know next to nothing about MetaOCaml, so maybe that comment was off-target. :)
00:29
<
zmdkrbou >
i know ... the same :) about metaocaml, i thought you were speaking of compilation in general
00:29
<
Smerdyakov >
I believe some of these multi-stage languages allow the runtime creation and execution of programs.
00:30
<
Smerdyakov >
Hmph... having a hard time finding a MetaML research paper.
00:30
<
zmdkrbou >
i don't think there's much
00:31
<
Smerdyakov >
Had to go to an author's personal site..
00:32
<
Smerdyakov >
Indeed, MetaML supports an arbitrary number of stages, according to the first sentence in the first paper on it. :)
00:32
<
mikeX >
Smerdyakov: indeed, but it's type safe from what I understand (metaocaml)
00:33
<
Smerdyakov >
mikeX, Laconic is also type safe.
00:36
<
mikeX >
hm, I have to say I can't make much about it from that demo
00:36
<
mikeX >
is it implemented in ocaml?
00:36
<
Smerdyakov >
No, SML.
00:36
<
Myrizio >
are MetaML stages at compile time? like generic, meta-generic, meta-meta, etc?
00:37
<
Smerdyakov >
Myrizio, I think some are at run time, but I can tell you better when I finish reading their PEPM'97 paper. :)
00:37
<
Myrizio >
uh, ok, thanks :)
00:38
<
mikeX >
poll: has anyone here ever used or would advocate the use of fortran for any type of application?
00:38
<
mikeX >
fortran77 in particular
00:39
<
zmdkrbou >
never use fortran :)
00:40
* zmdkrbou
wonders if mikeX is in the physics field to even get the idea of using fortran
00:40
<
mikeX >
well I won't be using it, that's for sure, I have a friend who does
00:40
<
mikeX >
he's in engineering
00:42
<
zmdkrbou >
the only thing about fortran is that it has the fastest libraries to work on matrix, floats, etc. i believe
00:42
<
Myrizio >
probably the only thing worse than fortran to program with is assembler
00:43
<
mikeX >
I think what's worse is the fact that he is thinking in fortran to solve his problem, he can't abstract the problem or it's solution in any way
00:43
<
Myrizio >
zmdkrbou: even if it has fast libraries, i'd still prefer to write a 2x slower program in half the time
00:44
<
mikeX >
Myrizio: still, what if your program takes 10 days to execute on a cluster?
00:44
<
Submarine >
Smerdyakov, Howdie.
00:45
<
Smerdyakov >
Submarine, howdie again. :)
00:45
jcreigh has joined #ocaml
00:45
<
Submarine >
My experience with physicists/engineers is that they make a lot of programming mistakes (bad choice of algorithm etc.) that may trump the linear speedups obtained by "fast" languages.
00:46
<
zmdkrbou >
boarf, C/C++ is almost as fast even where fortran is the top i believe, but hte solution is in the algorithm
00:46
<
mikeX >
yeap I think that comes from my earlier observation
00:46
<
Submarine >
I mean, if you are really concerned about speed, don't put tests in the innermost loop when you don't have to.
00:46
<
Submarine >
You don't even have to change the algorithm.
00:46
* zmdkrbou
totally agrees with Submarine
00:46
<
mikeX >
they are never taught how to program right
00:49
Submarine has quit ["Leaving"]
00:56
<
Smerdyakov >
Who is?
01:09
Submarine has joined #ocaml
01:09
Thlayli_ has joined #ocaml
01:11
jcreigh has quit ["leaving"]
01:26
Thlayli has quit [Read error: 110 (Connection timed out)]
01:27
khaladan has quit [Read error: 104 (Connection reset by peer)]
01:43
jcreigh has joined #ocaml
01:58
jcreigh has quit ["leaving"]
02:30
mauke_ has joined #ocaml
02:44
mauke has quit [Read error: 110 (Connection timed out)]
02:49
dark_light has joined #ocaml
03:14
Submarine has quit [Read error: 104 (Connection reset by peer)]
03:20
Myrizio has quit ["Leaving"]
03:37
mikeX has quit ["zz"]
04:01
jcreigh has joined #ocaml
04:30
jcreigh has quit ["leaving"]
04:33
Revision17 has quit ["Ex-Chat"]
04:42
Smerdyakov has quit ["Leaving"]
04:44
ketty has quit ["Leaving."]
04:53
Revision17 has joined #ocaml
05:30
ramki has joined #ocaml
05:31
ramkrsna has left #ocaml []
05:37
Tachyon76 has joined #ocaml
06:35
ulfdoz has quit ["Reconnecting"]
06:35
ulfdoz has joined #ocaml
06:37
_shawn has quit [Read error: 110 (Connection timed out)]
06:38
ulfdoz has left #ocaml []
06:38
_shawn has joined #ocaml
06:42
ulfdoz has joined #ocaml
06:45
ramki is now known as ramkrsna
06:52
soupz has left #ocaml []
06:57
Quinthius_ has joined #ocaml
07:06
ketty has joined #ocaml
07:15
Quinthius has quit [Read error: 110 (Connection timed out)]
07:52
YASP-Dima has quit [Read error: 104 (Connection reset by peer)]
08:18
* ayrnieu
creates an Impossible exception, for the case that, applied to a bound and listening PF_INET SOCK_STREAM socket, Unix.accept returns ADDR_UNIX
08:19
joshcryer has joined #ocaml
08:19
pango is now known as pangoafk
08:25
butthead has joined #ocaml
08:25
butthead is now known as YASP-Dima
08:25
pangoafk is now known as pango
08:34
zmdkrbou_ has joined #ocaml
08:34
zmdkrbou has quit [Read error: 104 (Connection reset by peer)]
09:05
revision17__ has joined #ocaml
09:07
<
ketty >
ayrnieu: you can allways use ignore to avoid "this expression should have type unit" warnings..
09:08
<
ayrnieu >
oh, thanks.
09:12
<
ketty >
ayrnieu: are your match statements working as expected?
09:12
<
ayrnieu >
yes, they seem to work.
09:13
<
ketty >
hmm... i have never come to understand how match statements are interpreted..
09:14
<
ayrnieu >
why, do they seem wrong to you?
09:14
<
ketty >
i would go paranoid and surround everything with (...)
09:14
<
ketty >
i mean surround every clause...
09:14
<
ketty >
or begin end
09:15
<
ketty >
how come you use begin end where you use it?
09:15
<
ayrnieu >
is there a way to avoid matching ADDR_UNIX ? I get warnings if I don't, but it's logically impossible.
09:16
<
ayrnieu >
oh, I don't know -- for a while I had syntax errors on the ;; of that expression, and was very confused.
09:16
<
ketty >
if your lazy you could write | _ -> assert false instead
09:16
<
ayrnieu >
ah, cool.
09:18
Revision17 has quit [Read error: 110 (Connection timed out)]
09:23
JKnecht is now known as Lycurgus
09:31
Skal has joined #ocaml
09:36
<
ayrnieu >
wow, is there no List.remove ?
09:36
<
ketty >
no there isn't... you have to use List.filter...
09:37
<
ketty >
i think it is weird that there is List.remove_assoc but not List.remove ...
09:37
<
flux__ >
the succinct representation being: List.filter ((<>) element)
09:38
<
ketty >
or.. wait..
09:39
<
ketty >
sorry.. i am confused :)
09:50
<
ayrnieu >
thanks for your help. I'll appreciate any other comments you have... tomorrow :-)
09:51
<
flux__ >
happy hacking :)
09:53
<
flux__ >
that's actually quite nicely written, I wouldn't write it much differently :)
09:57
<
flux__ >
(it could look nicer with monads)
10:20
Lycurgus has quit [Client Quit]
10:39
Snark has joined #ocaml
10:47
mauke_ is now known as mauke
10:55
mauke has left #ocaml []
10:58
slipstream-- has joined #ocaml
11:01
zmdkrbou_ is now known as zmdkrbou
11:22
slipstream has quit [Read error: 110 (Connection timed out)]
11:32
Skal has quit [Remote closed the connection]
11:56
mikeX has joined #ocaml
13:30
mikeX has quit [Read error: 110 (Connection timed out)]
13:33
mikeX has joined #ocaml
14:13
Thlayli_ has quit [Read error: 104 (Connection reset by peer)]
14:14
Thlayli has joined #ocaml
14:57
Thlayli has quit [Read error: 110 (Connection timed out)]
15:00
mikeX has quit [Read error: 104 (Connection reset by peer)]
15:01
mikeX has joined #ocaml
15:18
Tachyon76 has quit ["Leaving"]
15:45
Smerdyakov has joined #ocaml
16:09
_JusSx_ has joined #ocaml
16:33
Schmurtz has joined #ocaml
17:06
smimou has joined #ocaml
17:18
Submarine has joined #ocaml
17:31
pango is now known as pangoafk
17:44
pangoafk is now known as pango
17:48
mikeX has quit ["leaving"]
17:53
bohanlon has quit [Read error: 104 (Connection reset by peer)]
17:59
bohanlon has joined #ocaml
18:10
exa has joined #ocaml
18:19
bohanlon has quit [Read error: 104 (Connection reset by peer)]
18:25
bohanlon has joined #ocaml
18:33
<
_JusSx_ >
hi ocaml pp
18:37
<
_JusSx_ >
where are you from?
18:57
Submarine_ has joined #ocaml
18:58
Submarine has quit [Nick collision from services.]
18:59
Submarine_ is now known as Submarine
19:23
shawn has quit ["This computer has gone to sleep"]
19:39
Snark has quit ["Leaving"]
19:49
_JusSx_ has quit ["leaving"]
19:55
illya23b has joined #ocaml
20:13
__DL__ has joined #ocaml
20:24
shawn has joined #ocaml
20:35
Submarine has quit ["Leaving"]
20:42
illya23b has quit ["leaving"]
20:43
illya23b has joined #ocaml
20:48
lispy has left #ocaml []
21:07
multani has joined #ocaml
21:09
<
ulfdoz >
in a let-expression, if I have: "let foo = bar and baz = fcall foo" is foo still inbound in the second expression?
21:10
<
zmdkrbou >
what do you call "inbound" ?
21:10
<
multani >
unbound ?
21:10
<
ulfdoz >
I mean unbound, typo, sry.
21:10
<
zmdkrbou >
foo is not unbound
21:10
<
ketty >
# let a = 1 and b = a;;
21:11
<
ketty >
Unbound value a
21:11
<
zmdkrbou >
seriously ??
21:11
<
zmdkrbou >
you forgot the rec
21:11
<
ulfdoz >
yeah, I wondered about, too. Because haskell explicitly has this "and" to have foo bound.
21:11
<
zmdkrbou >
ulfdoz: did you forgot the rec intentionnaly ?
21:12
<
ulfdoz >
Yes. i think so, but it makes sense in this context.
21:12
<
ulfdoz >
Yes, the rec is it! thx.
21:13
<
ketty >
where to put the rec?
21:14
<
zmdkrbou >
let rec a = bla and b = a ;;
21:14
<
ketty >
# let rec a = 1 and b = a;;
21:14
<
ketty >
This kind of expression is not allowed as right-hand side of `let rec'
21:15
<
zmdkrbou >
yes, you can't use mutual recursion to create aliases
21:15
<
ulfdoz >
quite weird with this rec.
21:15
* zmdkrbou
doesn't really know the criteria for the let rec - and to be valid
21:17
<
ketty >
this gives the same error: let rec a = b and b = 1;;
21:17
<
ketty >
does anything work? :)
21:17
<
zmdkrbou >
it works with function
21:17
<
zmdkrbou >
# let rec a e = 1 and b e = a e ;;
21:17
<
zmdkrbou >
val a : 'a -> int = <fun>
21:17
<
zmdkrbou >
val b : 'a -> int = <fun>
21:18
<
zmdkrbou >
i don't know if it works for any non functional value
21:18
<
zmdkrbou >
(but the use of let rec and is in functions, so ...)
21:18
<
ulfdoz >
ok, now trapped into the "not allowed" thingy :)
21:19
<
ulfdoz >
ok, let's cascade let-in
21:19
<
zmdkrbou >
thinking of it, it's perfectly normal
21:20
<
zmdkrbou >
there's no meaning in defining data with mutual recursion if you don't have infinite data types
21:20
<
ketty >
yes you don't need recursion, since your values only depends on previously defined things...
21:21
<
ulfdoz >
cascaded let-ins compile fine.
21:21
<
zmdkrbou >
you shouldn't use "and" out of the mutual recursion context anyway
21:23
<
pango >
let rec a = 1 :: b and b = 2 :: a ;;
21:30
<
ulfdoz >
ok, I hit the first condition of statically constructiveness.
21:32
Schmurtz has quit [Read error: 104 (Connection reset by peer)]
21:33
Schmurtz has joined #ocaml
21:35
<
dark_light >
zmdkrbou, but when i want to define two things that are independent of each other (eg. inside a let), shouldn't i use and?
21:36
* zmdkrbou
finds more clear to keep and only for mutual recursion
21:36
<
zmdkrbou >
look at the questions we ask ourselves when using and when not needed :p
21:36
<
pango >
that can have unwanted effect (like turning a polymorphic function into monomorphic one, for example)
21:36
<
dark_light >
pango, why? there are some performance issue on this?
21:36
<
pango >
so don't use "and" just because you can
21:37
<
dark_light >
i find it clear enough o.o
21:37
<
pango >
no performance issue, I doubt it changes generated code
21:38
<
dark_light >
pango, i use and to say: "hey, a and b aren't dependent of each other", instead of in that says "b might depends the value of a"
21:38
<
dark_light >
maybe i don't used mutually recursion too much to find useful mark it only for mutual recursion o.o
21:39
<
ulfdoz >
I used and for shortening code.
21:40
<
ulfdoz >
I'm quite sure, it would have had correct semantics with the and. Perhaps compiler just can't decide....
21:42
<
pango >
it's better to stick to things the compile can decide, indeed
21:42
<
pango >
s/compile/compiler/
21:42
__DL__ has quit ["sleeping"]
21:45
<
pango >
# let rec id x = x and a = id 3 and b = id "hello" ;;
21:45
<
pango >
This expression has type string but is here used with type int
21:45
<
pango >
# let id x = x in let a = id 3 and b = id "hello" in (a, b) ;;
21:45
<
pango >
- : int * string = (3, "hello")
21:46
<
dark_light >
pango, thats because a and b uses the definition of id
21:46
<
dark_light >
... o.o
21:46
<
dark_light >
well, intersting
21:55
Quinthius__ has joined #ocaml
22:03
mikeX has joined #ocaml
22:12
Quinthius_ has quit [Read error: 110 (Connection timed out)]
22:18
<
multani >
if I bind a type to a parametric class, could I use a subclass of this type with an instance of this class ?
22:21
<
ketty >
do you mean: type 'a t = 'a class_name ?
22:24
<
multani >
hum no, I mean a class type, "as" in class c = object inherits [t] param_class end;; , where t is a class
22:27
<
ketty >
with parametric class, do you mean type parameters or "constructor"-parameters?
22:27
<
ketty >
i guess type parameters ^^'
22:31
<
ketty >
multani: how do you mean use a subclass of this type with an instance of this class?
22:31
<
ketty >
they are not interchangable...
22:32
<
ketty >
but.. thats probably not what you meant :)
22:32
<
multani >
well, i will try to be more clear :)
22:35
<
multani >
imagine I subclass this stack class, and I manually bound the 'a parameter to another class (let's call it D )
22:36
<
multani >
can i use an instance of this stack with an instance of a class derived from D ?
22:37
<
ketty >
if an object of type d_stack is interchangeable with other subtypes of stack?
22:37
<
multani >
euh no /D
22:38
<
ketty >
i guessed so :)
22:38
<
ketty >
i am a bit confused :)
22:38
<
ketty >
but you have a class d_stack that is a subclass of stack, right?
22:39
<
multani >
D1 is a subclass of D, could I use D1 objects with a d_stack object ?
22:39
<
ketty >
i finaly understand what you want :)
22:40
<
ketty >
you have to explictly "cast" the D1 object to D
22:41
<
multani >
(well, s/derived/inherits/ ...)
22:42
<
multani >
ketty, ah, that's why it doesn't work :D
22:43
<
multani >
wonderful !
22:44
<
multani >
hard to explain, but it works :)
22:44
<
ketty >
sorry i took so long to understand you..
22:46
<
multani >
well, my english isn't very good, and it was not not very clear at all ;)
22:50
<
multani >
another question, linked to the preceding one
22:51
<
multani >
now, D1 inherits from D, and from another class, and i still want to add it to my d_stack
22:52
<
ketty >
ahh.. D1 uses multiple inherition?
22:52
<
ketty >
that should not matter
22:53
khaladan has joined #ocaml
22:53
<
multani >
well, the compiler complains, that only the second type has a method xxx :/
22:54
<
ketty >
hmm... which is the second type? :)
22:55
<
dylan >
an xxx method? I don't wanna know what sort of object that is. XD
22:58
<
multani >
dylan, stop asking me in private what's those objects are, i will not tell you ;)
23:05
<
multani >
i give up :(
23:06
Schmurtz has quit ["Plouf !"]
23:06
<
dylan >
give up what? Smoking? XXX methods?
23:07
<
ketty >
multani: if you give a more detailed example, maybe we can help you...
23:07
<
ketty >
(allthou maybe i don't want to know to much details about the XXX methods ^^)
23:08
<
multani >
hmm, i know, but it's rather complicated (to explain, you had already seen what i am capable of :D )
23:08
<
ketty >
you could paste some code to a pastebin...
23:10
<
multani >
let's see ^^
23:16
<
multani >
(don't shoot, this is my very first ocaml application :o )
23:17
<
ketty >
ok, can you tell me what error you get, and where you get it? :)
23:17
<
multani >
quickly, it's some kind of xmlrpc server, which will communicate with a python client (throught xmlrpc)
23:18
<
multani >
i'm trying to implements the model of MVC into this "things", the view & the controller will be in the python client
23:18
<
multani >
so, the problem is at the end, line 50
23:19
<
multani >
(the observer and subject class come from the ocaml reference book, chapter 3.5 )
23:19
<
ketty >
where is figure defined?
23:19
<
multani >
the graph, figure and point class are defined in another module
23:20
<
multani >
we have to extend those functionnality, without opening this module
23:20
<
ketty >
point_subject don't seem to be a subclass of figure...
23:20
<
multani >
hmm, figure is an abstract class, point is one class which inherits from figure
23:21
<
ketty >
and the exact error that line 50 generates is: ?
23:21
<
multani >
and graph is a graph of figure (in mathematical term)
23:21
<
ketty >
which object has the XXX method? :)
23:21
<
multani >
This expression has type Figure.figure but is here used with type
23:21
<
multani >
< dump_xmlrpc : unit -> XmlRPCTypes.t; .. >
23:21
<
multani >
Only the second object type has a method dump_xmlrpc
23:22
<
multani >
(sorry all, no pr0n there :/ )
23:23
<
ketty >
this is weird...
23:23
zmdkrbou has quit [Remote closed the connection]
23:24
<
multani >
i'm not yet really familiar with compiler message
23:24
<
ketty >
can you try: (p : point_subject :> figure) ?
23:24
<
multani >
but as far as I understand, it wants a figure but it got a point_subject ? (or the inverse ?)
23:25
<
multani >
The type constructor point_subject expects 1 argument(s), but is here applied to 0 argument(s)
23:25
<
ketty >
ok, do this: let p = ... in let p2 : figure = (p :> figure) in ...
23:26
<
multani >
hmm, same problem :/
23:27
<
multani >
("This expression has type ..." problem ;) )
23:28
<
ketty >
i don't understand why this don't work
23:29
<
multani >
am I correct in the declaration of graph_subject ? (and point_subject as well)
23:29
<
ketty >
but a quick workaround could be to add a "to_figure" method in the figure-class
23:30
zmdkrbou has joined #ocaml
23:31
<
ketty >
are you 100% sure point is a subclass of figure? could you paste the exact error message?
23:31
<
multani >
hmm, that's all i got :/
23:32
<
multani >
however, point is not directly a subclass of figure, there's another virtual class between (but i don't think it can cause problems)
23:32
<
ketty >
this expression has type point_subject but is here used type figure ??
23:33
<
multani >
the inverse
23:33
<
ketty >
and the type of graph#add_sommet is?
23:34
<
ketty >
if you load this in the interactive toplevel and type "graph#add_sommet;;"
23:35
<
ketty >
what type does it tell you it has?
23:35
<
ketty >
maybe there is a problem in the definition of graph..
23:37
JKnecht has joined #ocaml
23:38
<
multani >
we have some unit test with this class, it seems to works, but i'm not really confident in the tests ....
23:39
<
multani >
here is a subset of graph :
23:39
<
multani >
class ['a] graph :
23:39
<
multani >
val mutable sommet_list : 'a sommet list
23:39
<
multani >
method add_sommet : 'a -> unit
23:40
smimou has quit [Read error: 110 (Connection timed out)]
23:42
<
ketty >
ok, i might see the problem..
23:45
<
multani >
i think i already try something like this, let's see
23:46
<
multani >
hum, it fails on line 5 with "The type constructor observer expects 1 argument(s), but is here applied to 0 argument(s)"
23:47
<
multani >
(line numbers from your pastebin)
23:47
<
ketty >
ok : inherit ['a] subject ("graph")
23:47
<
ketty >
and maybe add 'a as a class parameter
23:48
<
ketty >
ok.. now i really se the problem :)
23:49
<
ketty >
in graph_subject you use the "dump_xmlrpc"-method from point_subject...
23:49
<
ketty >
but you are storing figures, not point_subjects...
23:49
<
ketty >
and figure has no such method
23:50
<
multani >
hmm, i see
23:51
<
ketty >
so, if you want to use that method you cant store just figures...
23:51
<
ketty >
you must store a type that has that method...
23:51
<
multani >
yes, you're right
23:52
<
multani >
the subject class got it, since point_subject (and so on) inherits from it
23:52
<
ketty >
then maybe you could store subjects?
23:52
<
ketty >
or declare another class...
23:52
<
ketty >
dumpable or something :)
23:53
<
multani >
hmm, if i replace by subject, i got a "The type constructor subject expects 1 argument(s), but is here applied to 0 argument(s)" error
23:53
<
multani >
i'll try the dumpable thing ;)
23:54
<
ketty >
i guess the class subject is in the form: class subject param = object ... end
23:55
<
ketty >
so to get access to the object-type it seems like you have to supply a parameter...
23:55
<
multani >
(actually, this is : class virtual ['observer] subject (name:string) =)
23:55
<
ketty >
ooh... yeah... i forgot the the parameter... ^^
23:55
<
ketty >
(and the virtual part)
23:56
<
ketty >
but if you use your orginal version of graph_subject...
23:56
<
ketty >
and just change the cast at line 50 you should be safe
23:57
<
multani >
in what should I cast ? subject ?
23:57
<
ketty >
but you might want to change the names of the type-variables on graph_subject to something less confusing
23:57
<
ketty >
you could try :)
23:57
<
multani >
yes, i kept the name from ocaml book
23:58
<
ketty >
we know that we need a type that has at least the dump_xmlrpc method
23:58
<
ketty >
but there could be other method that are needed..
23:58
<
ketty >
it depends on the definition of graph..
23:59
<
multani >
casting to subject raise the same error : "The type constructor subject expects 1 argument(s), but is here applied to 0 argument(s)"
23:59
<
ketty >
ohh... right...
23:59
<
ketty >
since i don't know what argument subject expects i cant help you