vpalle has quit [Read error: 60 (Operation timed out)]
vixey has quit [Network is unreachable]
psnively has quit []
alexyk has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
alexyk has quit []
m3ga has joined #ocaml
hkBst has quit [Remote closed the connection]
alexyk has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
mfp has quit [Read error: 104 (Connection reset by peer)]
<alexyk>
I want to wrap external methods into a class; can I do method external ... ?
mfp has joined #ocaml
nuncanada has joined #ocaml
<alexyk>
hi mfp! do you how to wrap external functions into a class? I'm trying prepending method to external: method external, and it complains
Stefan_vK1 has quit [Read error: 104 (Connection reset by peer)]
Stefan_vK has joined #ocaml
johnnowak has joined #ocaml
caligula_ has joined #ocaml
<Optikal__>
Caligula.. little boots
<palomer>
I'm back!
<palomer>
man, I can't believed I sacrified a whole semester to that class
<palomer>
what a waste of time!
jeddhaberstro has quit []
nuncanada has quit ["Leaving"]
Kerris7 has joined #ocaml
meteoryte has quit [Read error: 145 (Connection timed out)]
fschwidom has quit [Connection timed out]
<palomer>
hrmph
<palomer>
what do you guys think of disallowing shadowing for scopes
<palomer>
ie (fun x -> (fun x -> x)) would flag an error
<Optikal__>
why!?
<palomer>
to avoid errors
<palomer>
I've had times when I thought I was referring to the binding in the outer scope when, in fact, I was referring to the binding in the inner scope
<palomer>
and...it isn't that big a restriction, really
<Optikal__>
you should be able to see your inner scope in less than 1 screen
<palomer>
I _did_ see my inner scope
<Optikal__>
and you thought you were referring to the outerscope?
<palomer>
I just didn't notice it
engstad has joined #ocaml
<palomer>
and when you have a type error, scoping isn't usually the first thing you look at
<palomer>
I don't see the purpose of shadowing
<palomer>
if someone could give me a legitimate reason, please do so
<engstad>
shadowing?
<palomer>
scoping
<palomer>
disallowing statements like (fun x -> (fun x -> x))
<engstad>
let x = 1 in let x = x + 1 in x?
<palomer>
that's really terrible
<engstad>
Well, that case is a bit misleading, perhaps calling for an optional warning (function argument not used) [fun _ -> (fun x -> x))
<palomer>
let x = 1 in let y = x + 1 in y
<engstad>
A lot of people use that idiom, so I don't think it can be changed easily.
<palomer>
the let x = 1 in let x = x + 1 in x idiom?
<engstad>
Yes. Obviously in a bigger context.
<palomer>
for example?
<engstad>
let x = 1 in ..... lot's of code.... let x = ... some other thing ...
<palomer>
forcing them to rename their inner variable doesn't seem like such a big deal
<engstad>
Seems unnecessary to me, what do you gain?
<palomer>
1) I prevent my users from making mistakes
<palomer>
2) by disallowing ANY kind of shadowing, my code becomes cleaner
<palomer>
instead of allowing shadowing in certain cases
<engstad>
On the other hand, you just made refactoring a whole lot harder.
<palomer>
how so??
<engstad>
I take a piece of code put it in where a variable is used, now I have to rename variables.
<palomer>
you have a point
<palomer>
but...renaming variables is a no brainer in emacs
<engstad>
On the other hand - I also agree with you ... it's bad style - so it would be nice if it was optional.
<palomer>
food for thought
* palomer
goes and munches this thoughtfood
<engstad>
I'd rather bitch and moan about not having native uint8, uint16, uint32, uint64 types...
<Optikal__>
what about uint128?
<Optikal__>
THINK OF THE FUTURE
<engstad>
As well as float32, and vector types. (Yes, uint128 is good too, but it isn't currently usable as an integer type, since machines aren't supporting uint128 + uint128, etc.
<Optikal__>
18446744073709551616 is not enough to uniquely index every grain of sand
<engstad>
F# has it, we should too.
<Optikal__>
F# has concurrency
<Optikal__>
and a billion dollar company behind it
<Optikal__>
we should have that
<engstad>
Yeah, that's true.
<engstad>
But... I don't believe F# has that much man-years behind it compared to e.g. OCaml.
<engstad>
I'm just baffled that they manage to write a compiler without having support for uint32 type...
<engstad>
Mono even managed to implement SIMD support... Pretty cool.
<thelema>
Optikal_: the ocaml devels don't believe SMP concurrency will win in the long run, so isn't worth spending hundreds of man-hours on.
<thelema>
as far as uint32, that mostly comes from the silliness of needing different + operators for int8, int16, int32, int64, int, uint8, uint16, uint32, uint64, uint
johnnowak has quit []
<thelema>
also, the way that GC would play with the values, they'd end up boxed or word-sized anyway.
<Kerris7>
hmm kubao is chugging away steadily at Camelia
<palomer>
choo choo
<Kerris7>
would anybody know of other alternative toplevels besides enhtop?
<thelema>
Kerris7: batteries has an enhanced toplevel with special help in it.
<Kerris7>
thelema: thanks, would it be straightforward to get batteries running on os x?
<Kerris7>
I do have a linux machine but that's somewhat inconvenient to lug around
<m3ga>
Kerris7: I haven't tried it, but I would be surprised if it was't trivial to get batteries running on OSX.
<thelema>
Kerris7: do you use godi on osx?
<thelema>
That's the easiest way to get batteries running for you.
ygrek has joined #ocaml
Optikal__ has quit [Read error: 110 (Connection timed out)]
Kopophex has quit ["Leaving"]
Kerris7 has quit [Read error: 60 (Operation timed out)]
cataska has joined #ocaml
seafood has quit []
apples` has quit ["Leaving"]
munga has quit [Read error: 145 (Connection timed out)]
m3ga has quit ["disappearing into the sunset"]
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
alexyk has quit []
<flx>
palomer, I don't think let x = x + 1 is bad style. for example I have a piece of code where I have a variable called state. state comes in, state goes out. also, there is a bunch of functions that take state in and give state out. so I thread state through.
<flx>
so the code is : let foo state = let state, v1 = bar state in let state, v2 = baz state v1 in let state = { state with n = state.n + 1 } in (state, v1 + v2)
<flx>
it is far from meaningful to rename those variables to state, state', state'' etc
<flx>
palomer, also, if one can reuse the name, it can prevent accidental reuse of the old name
<flx>
in my case, using an older state would most likely be an error
<flx>
I don't however see why shadowing values at different degrees couldn't have a warning you could enable
<flx>
for example, I've sometimes shadowed top-level values, and those have always been an error (well, unless I've been for example trying out different versions of a function and seeing that I don't need to comment the versions before the last one out - but that's really a very little use case)
<flx>
I don't see people doing x = x + 1 to top level bindings. does someone use that?
<flx>
and then there could be a separate warning when shadowing local bindings
flx is now known as flux
Palace_Chan has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
<Palace_Chan>
I use Tuared mode on emacs as an IDE for Ocaml on ubuntu, any recommendations on windows ?
Palace_Chan has quit []
sporkmonger has quit []
alexyk has joined #ocaml
<engstad>
Palace_Chan: F# on .NET?
<engstad>
Palace_Chan: Of course, you can still run emacs in Windows.
engstad has left #ocaml []
jonafan_ has joined #ocaml
jonafan has quit [Read error: 60 (Operation timed out)]
alexyk has quit []
ikaros has joined #ocaml
_zack has joined #ocaml
<palomer>
flx: let x = 1 in let x = x + 1 in x is bad styile
<palomer>
actually, I also think that let x = x + 1 is bad style
<palomer>
oh, flx changed to flux
<palomer>
flux, part of my goal is to make type errors clear to newbs
<palomer>
shadowing can become a source of confusion for newbies
<flux>
palomer, why would you say reusing bindings is bad style? I don't find it better to do let x = 1 in let x' = x + 1 in let x'' = x' + 1 in x'' .
<flux>
especially I would say the latter is more error prone.
<palomer>
let x = 1 in let y = x + 1 in let z = y + 1 in z
<palomer>
I find using longer, more descriptive variable names works best
<palomer>
let initial_sum = 1 in let intermediate_sum = initial_sum + 1 in let final_sum = intermediate_sum + 1 in final_sum
<palomer>
I don't know if this standard in industry
<flux>
so I have this code: perform state <-- (match state.s_latest, D.parse_event_data new_event_info.. (* uses state *); state <-- check_conn_events env state new_event_info; (state, new_trig_info) <-- if ..; return state;
<palomer>
errr
<palomer>
I can't even parse that
<flux>
it uses pa_monad
<palomer>
can you give it to me in haskell syntax
<flux>
another version: (match state ..) >>= fun state -> check_conn_events env state new_event_info >>= fun state -> if .. >>= fun (state, new_trig_info) >>= fun state -> .. return state
<flux>
haskell version would have perform = do, <-- = <-
<palomer>
ah, righto
<palomer>
so you do something like state <- foo ; .. ; state <- bar ; ... ; state <- baz ; ...
<palomer>
right?
<flux>
yes. foo, bar and baz take the previous state and produce a new one.
<palomer>
the state is usually implicit (which is the whole point of the monad, really)
<flux>
well, it's a different monad they are using
<flux>
there is a message passing monad
<palomer>
is the state a mapping? then you should query/update the mapping with helper functions which access the state
<flux>
state is local to the object performing operations
<flux>
state has different values relevant to the task
<flux>
for example, the list of data chunks to retrieve, the latest data chunk etc
<palomer>
what's the type of state?
<flux>
it's a record of about 10 fields
<palomer>
you're giving the programmer direct access to the record?
<palomer>
I would have a boatload of functions for updating/querying the record
<flux>
the state is local to the module
<palomer>
and then I would give descriptive names to whatever I retrieve
<flux>
external modules can't have access
<palomer>
still
<flux>
obviously the field names themselves are descriptive. what do I gain by providing setters/getters?
<palomer>
In all my monadic programming, I've never directly accessed the state if the state was a record or map
<palomer>
flux, clarity
<palomer>
for one, you don't have these variable names all called state
<palomer>
s/variable names/variables
<flux>
well, I would need to put them all somehwere
<flux>
I would hate to thread n values around instead of just one
<palomer>
I would also use liftM and liftM2 to avoid declaring new variables
<palomer>
if I _was_ forced to access the state (because other functions take it as arguments), I would call it state_after_read, state_after_second_read, and stuff like that
<flux>
state itself is not within the monad. I suppose I could put monad within a monad, but dealing with different monads is not that convenient in O'Caml
<palomer>
mtl!
<palomer>
someone should port the mtl to ocaml
<flux>
I'm not convinced the reader would feel the code is more readable with those names
<flux>
and again, I could accidentally use a previous version of the state
<flux>
by hiding the name I make it impossible
<flux>
actually what I'd like to see would be unique typing in O'Caml :)
<palomer>
uniqueness typing? never tried it
<palomer>
sounds scary
<flux>
in uniqueness typing you can have only one instance of a value.. sortof
<flux>
if you pass a value into a function, you cannot use that value anymore
<flux>
also you cannot make a value go away without giving it to a function
<palomer>
after fiddling with monads for 2 years, I'm scary of any new type system
ikaros has quit [".quit"]
<palomer>
s/scary/scared
<flux>
well, monads aren't a new type system?-)
<flux>
this way you can guarantee files get closed etc; the file descriptor cannot go out of scope without being closed, etc
<palomer>
monads are relatively new
<flux>
(unless they go inside another unique-typed value)
<palomer>
that must make certain tasks really hard
<palomer>
let a = "foo" in print a; print a
<flux>
obviously only certain values would be 'unique'
<flux>
not everything
<palomer>
the haskell people are like "forget about mutable values, just do everything with monads"
<palomer>
what a pain!
<flux>
well, how would you feel about using arrays safely in a functional language, if you just promised to thread the array properly around?
<palomer>
flux, oh, so the type system is something like types T = 'a | !T | C T_1 ... T_n ?
<flux>
I think that could be a useful feature, and that is what unique typing can give (or atleast that's been my impression)
<palomer>
thread the array?
<flux>
Clean has unique typing, but I haven't heard of other languages. and clean is commercial
<flux>
pass it to the functions that need the array etc
<flux>
also you can pass the array into a function that promises (well, and can't really) not to mutate the array
<palomer>
const?
<flux>
so you can do Array.get a 4, but you must do let a' = Array.set a 4 "hello"
<flux>
well, not const per se, but a modifier you can use when declaring functions that deal with those values
<palomer>
but...my errors aren't usually related to any of these issues
<flux>
I believe the idea is that the module providing the unique-typed value has full access, and the unique typing is required only from other modules. similar to information hiding via module signatures.
<flux>
palomer, the point of unique typing has been to allow side effects in a pure language. similarly to monads.
<flux>
well, not similarly, but an alternative approach
<palomer>
right, that's what they claim
<palomer>
and like monads, I'm betting it's a PITA
<flux>
but it doesn't need to be a replacement. monads can be built upon these - and you have a bug-free monad atleast in that aspect
<palomer>
but most ocaml programmers don't usually run into these bugs!
<palomer>
at least...that's my personal (anectodal) impression
<flux>
palomer, but it is somewhat more difficult in ocaml to make sure you release your resources, than it is in, say, c++
<palomer>
try/finally?
<flux>
try/finally helps, yes
<flux>
of course try/finally don't work in a monadific code, you need to use a monad-specific method
<flux>
nor do they work in cps-code
<flux>
but I suppose that's a minority of code :)
<palomer>
ugh, meta control structures
_zack has quit ["Leaving."]
<palomer>
anyways, static analysis goes a long way in ensuring that resources are released
<flux>
I personally have had bugs relating to sequencing database access and closing files. not many, but I've had them.
<palomer>
I think we need to gather 100 ocaml programmers and find out where most bugs come from
<flux>
I see unique typing as a tool for such analysis, enforced by the compiler ;)
<flux>
(and greatly simplifying the analysis)
<flux>
but I would like to see such a tool also
<palomer>
uniqueness typing IS a tool, but it involves changing the type system
<palomer>
which can lead to a gazillion man hours of work
<flux>
true
<palomer>
AND, it might limit programmers in some way
<palomer>
(probably does)
<flux>
yes, like O'Caml currently limits mutation of immutable values and other annoying things :P
<flux>
it's difficult to see how such a type system extension would play along with other o'caml features
<flux>
I guess we'll never see
<palomer>
well...compared to C++ it isn't a limitation
<palomer>
since C++ doesn't really have parametric polymorphism
<palomer>
(or Java)
<palomer>
oh, you weren't talking about the value restriction
<palomer>
ocaml's immutable values aren't a restriction! you can just say that const is the default
<palomer>
I've never felt limited in ocaml
<palomer>
except for sometimes ugly syntax
* palomer
shivers
<palomer>
well, I'm off to bed
<palomer>
night!
<flux>
hmm, clean is nowadays under lgpl
<flux>
(dual licensed)
<flux>
I wonder how long that's been the case
<flux>
good night.
asabil has joined #ocaml
rwmjones has joined #ocaml
_zack has joined #ocaml
asabil has quit [Read error: 104 (Connection reset by peer)]
asabil has joined #ocaml
mishok13 has quit [Read error: 104 (Connection reset by peer)]
jonafan has joined #ocaml
jonafan_ has quit [Read error: 60 (Operation timed out)]
mishok13 has joined #ocaml
asabil has quit [Remote closed the connection]
asabil has joined #ocaml
<flux>
cool, cuda-bindings to ocaml
<flux>
well, a start of
seafood has joined #ocaml
<gildor>
flux: indeed, it is cool
* gildor
wishing to have a NVidia card that support CUDA
Yoric[DT] has joined #ocaml
Kerris7 has joined #ocaml
Koordin has quit [Remote closed the connection]
vixey has joined #ocaml
gaja has quit ["Lost terminal"]
Kerris7 has quit ["Who is Candlejack? Is he going to c"]
rwmjones has quit ["Closed connection"]
Anryx has joined #ocaml
_zack has quit [Read error: 60 (Operation timed out)]
Snark has joined #ocaml
_zack has joined #ocaml
Anryx has left #ocaml []
hkBst has joined #ocaml
Gionne has quit ["Leaving"]
seafood has quit []
ygrek has quit [Remote closed the connection]
sporkmonger has joined #ocaml
Snark has quit ["Ex-Chat"]
olgen has joined #ocaml
olgen_ has joined #ocaml
olgen has quit [Read error: 104 (Connection reset by peer)]
olgen has joined #ocaml
olgen_ has quit [Read error: 104 (Connection reset by peer)]
willb has joined #ocaml
ikaros has joined #ocaml
yziquel has quit [Read error: 60 (Operation timed out)]
Yoric[DT] has quit ["Ex-Chat"]
ikaros_ has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
<flux>
gildor, anyway, the error (symbol list does not match symbol list) usually indicates you have been playing in the toplevel, and you have functions that use the old definition of symbol around
<Gionne>
it simply removes the constructor Prod
<flux>
for example: type a = Foo;; let a b = b = Foo;; type a = Foo;; a Foo;; will give a similar error
<Gionne>
in fact i was using toplevel
<flux>
put it into a separate file and ocamlc it
<flux>
or evaluate the whole file in the toplevel
<Gionne>
uhm
<Gionne>
the error changed ;)
<Gionne>
goin on
<Gionne>
thanx
<maxote>
is faster 3.11 than 3.10?
<flux>
I think there was one optimization that went in, but I would not expect any significant differences in real worl performance
<gildor>
flux: what the problem ?
<flux>
gildor, what what?
<gildor>
19:19 < flux> gildor, to_pair is not defined
<flux>
gildor, uh, I meant to talk to gionne
<gildor>
ok
Snark has joined #ocaml
sporkmonger has quit []
<Gionne>
I have this error: This expression has type Ast.symbol list -> Ast.symbol list
<Gionne>
but is here used with type Ast.symbol list: the return type is what i need, how do i return that function? http://pastebin.com/m7794b336
<olegfink>
apply it to some Ast.symbol list?
<Gionne>
it's recursive
<Gionne>
ups
<Gionne>
surely
<Gionne>
;)
<Gionne>
thanx
ikaros_ has quit [".quit"]
alexyk has quit []
Stefan_vK1 has joined #ocaml
apples` has joined #ocaml
alexyk has joined #ocaml
Stefan_vK has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
Camarade_Tux has joined #ocaml
asabil has joined #ocaml
sporkmonger has joined #ocaml
apples`` has joined #ocaml
apples` has quit [Nick collision from services.]
apples`` is now known as apples`
sporkmonger has quit []
rwmjones has quit [Read error: 60 (Operation timed out)]
alexyk has joined #ocaml
rwmjones has joined #ocaml
Yoric[DT] has joined #ocaml
Camarade_Tux has quit ["Leaving"]
jlouis has quit [Remote closed the connection]
<alexyk>
how do you pass a string list into C?
asabil has quit [Read error: 60 (Operation timed out)]
Snark has quit [Read error: 113 (No route to host)]
willb has quit [Read error: 110 (Connection timed out)]