<sethk>
avlondono, Smerdyakov thanks, I'll read that now.
<sethk>
avlondono, wait, I've already read that
<sethk>
avlondono, it doesn't help
<avlondono>
wow you're fast
<sethk>
avlondono, no, I'm reading in order. :)
<sethk>
3 is before 5
<avlondono>
I think you should read again
<sethk>
3 can't tell me anything about self :: !ints, since the concept of self doesn't exist yet.
<sethk>
Is := described there?
<avlondono>
did you even try to search for :=?
<avlondono>
in the page I told you?
<sethk>
don't have any way to search
<avlondono>
huh? don't have?
<avlondono>
what are you using to read t hat?
<sethk>
pdf viewer
<sethk>
Let me see if any of the other viewers search
<avlondono>
beh, then get something that can search
<sethk>
ok, I see it now. Not sure how I missed that.
<Smerdyakov>
Besides which, I've already told you that the subject of interest is "references," so you don't need to search for ":=".
<sethk>
ok, this pdf viewer searches.
<sethk>
Smerdyakov, yes, that's why I said I found it
<sethk>
nothing here about a reference of something []
<sethk>
nothing here of the form xyz = !xyz
<Smerdyakov>
And I'm sure the section in arithmetic has nothing about the expression "4 + 145".
<sethk>
at least not if xyz is an array
<Smerdyakov>
But it describes all of the concepts you need for that.
<avlondono>
heh
<Smerdyakov>
Though I'd rather let you figure it out by reading the documentation, compassion compels me to remind you that [] has nothing to do with arrays in OCaml.
<sethk>
from the section on references: This includes the usual while and for loops, as well as mutable data structures such as arrays. Arrays are either given in extension between [| and |] brackets,
<sethk>
so, ok, not exactly []
<sethk>
but regardless, the list is essentially an array
<Smerdyakov>
No. Lists are immutable, and arrays are mutable.
<Smerdyakov>
Lists have constant time insertion, while arrays don't.
<Smerdyakov>
Arrays have constant time lookup and replacement, while lists don't.
<Smerdyakov>
Etc..
<sethk>
yes, I know that, but that's not relevant to whatever they are saying about object(self), and it doesn't say much about what ints := !ints would mean, and it doesn't help with understanding what self::
<sethk>
self::!ints might mean
<sethk>
it does say that everything visible in the scope where the class is defined is visible to the class
<Smerdyakov>
But the manual section on references ought to help with that.
<sethk>
which means that self::ints is ints
<Smerdyakov>
No no no.
<sethk>
I assume you mean the section on imperative features.
<Smerdyakov>
:: is not the C++ member operator at all.
<Smerdyakov>
It's one of the constructors of 'a list.
<sethk>
oh, ok...
<sethk>
it's putting itself onto the list?
<avlondono>
touche
<Smerdyakov>
That sounds right.
<sethk>
ok, except it's telling you that you can't. at least in this case.
<sethk>
I see what it means. It is saying you can't use base class references with an object that is actually a derived class.
<sethk>
or even that might potentially be a derived class
pango_ has joined #ocaml
TaXules has quit [Read error: 104 (Connection reset by peer)]
TaXules has joined #ocaml
pango has quit [Read error: 110 (Connection timed out)]
threeve has quit []
__DL__ has joined #ocaml
Snark has joined #ocaml
revision17_ has joined #ocaml
Gueben has joined #ocaml
Revision17 has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
vezenchio has joined #ocaml
pnou has joined #ocaml
m3ga_ has joined #ocaml
m3ga_ is now known as m3ga
m3ga_ has joined #ocaml
m3ga_ has quit [Read error: 104 (Connection reset by peer)]
pnou has quit ["zou"]
m3ga has quit ["disappearing into the sunset"]
__DL__ has quit ["Bye Bye"]
mattam_ is now known as mattam
clog has joined #ocaml
revision17_ is now known as Revision17
ramkrsna has joined #ocaml
crime_minister has joined #ocaml
<crime_minister>
hi
<crime_minister>
I was wondering, is anyone interested in using SCons (http://www.scons.org/) to build O'Caml software?
<Snark>
crime_minister: I wondered about it some time ago
<crime_minister>
cool! I'm an o'caml novice trying to do just that
<crime_minister>
so I'm writing a scons extension, or at least attempting to
<crime_minister>
trying to decide which functionality to dish off to external tools, and which to write in python using the SCons framework
<crime_minister>
e.g. ocamldep vs. implementing a SCons scanner
ramkrsna has quit [Read error: 104 (Connection reset by peer)]
<crime_minister>
anyways, if anyone has any input or interest in developing/testing such a thing, feel free to contact me:
<crime_minister>
robmed@jabber.org
<crime_minister>
robert.medeiros@utoronto.ca
<crime_minister>
ciao
crime_minister has left #ocaml []
Msandin has joined #ocaml
Demitar has joined #ocaml
mpc has joined #ocaml
mpc has quit []
mpc has joined #ocaml
<sethk>
Hello, all. I want to know if I'm understanding something correctly. It appear that the type of a method (that is part of a class) is restricted when the method is used. That is, the types deduced when the class is declared are not final, and when ocaml has more information (based on an argument type when the method is evaluated) it changes the type signature for a method.
<sethk>
Does that make sense?
Msandin has quit [Read error: 110 (Connection timed out)]
mpc has quit []
<mflux_>
it induces a type that has only the methods you use, so often it's more convenient to define functions with let foo (a : bar) = ..
<mflux_>
I do wonder how difficult it would be to make that work better, it does somewhat take the advantage of type inferring away if you still need to either annotate or cast the types down with very inconvenient type signatures..
<sethk>
Well, if the bias of your type checker is to always deduce the most restrictive type, then this behavior is consistent.
<sethk>
But the type signature shown by ocaml after the class definition is what you want.
<sethk>
and it isn't obvious (at least to me) when that type needs to be restricted to what it appears that it already is.
<sethk>
Maybe I'll see it better when I've used ocaml more.
<mflux_>
oh, I was actually talking about something else
<sethk>
what?
<mflux_>
like if you have a function that has an object argument, and it calls some methods of that object
<sethk>
What's the case where you were saying a type is not deduced?
<mflux_>
and the resulting type signature of the function will be incompatible with the one the developer was propably thinking
<sethk>
oh, the function type signature, but not a method of the class.
<sethk>
Is that specific to the fact that the method is from a class? Would the same thing happen if it were simply a function with the same signature?
<mflux_>
class equivalence is handled with structural equivalence
<mflux_>
if that's what you're asking
<sethk>
I'm not sure. I have to think about how that's relevant.
<sethk>
:)
<sethk>
I do better with a concrete example.
<mflux_>
hm, infact my understanding may be somewhat limited too
<mflux_>
I tried to write a minimal testcase, but for function let a b = b#foo it induces type val a : < foo : 'a; .. > -> 'a
<mflux_>
so that's still compatible with class foo = object method foo = () method bar = () end
<sethk>
what did you expect?
<mflux_>
that it would induce type < foo : 'a >
<__DL__>
No it induce an open type
<mflux_>
I wonder what my problem has been then
<mflux_>
as I have had some related issues..
<__DL__>
but a you can have conter example when using optional argument :
<mflux_>
(mainly when using the gtk bindings)
<__DL__>
let a b c = b #foo c
<__DL__>
and class foo = object method foo ?optional () = () end
<mflux_>
yeah, well optional arguments are something else then, and you don't need classes to introduce that sort of trouble (that you're propably trying to show)?
<mflux_>
or does that work?-)
<__DL__>
yes indeed, you did not need class for such a problem