<Smerdyakov>
Payo543, looks like it might just be the project web sites that are down.
<Payo543>
i c
pango has quit [Remote closed the connection]
<dbueno_>
I'd like to write a function to create a collection type 'a t from an array of elements.
<dbueno_>
Currently my of_array is: val of_array: ?getter : ('b -> 'a) -> 'b array -> 'a t
<dbueno_>
My implementation uses the identity function as the default value for getter, but I get a type error at compile time.
<dbueno_>
(The implementation: let of_array ?(getter = (fun x -> x)) xs = ...)
<dbueno_>
Is there a way to write what I want to write?
<dbueno_>
In other words, I'd like the user to be able to supply a getter if he wants to extract a field from an array of objects, before putting those fields into a set.
<dbueno_>
Otherwise, just use the objects in the array and put them directly into the set.
<Mr_Awesome>
what is the type error you get?
<dbueno_>
Values do not match:
<dbueno_>
val of_array : ?getter:('a -> 'a) -> 'a array -> 'a list
<dbueno_>
is not included in
<dbueno_>
val of_array : ?getter:('a -> 'b) -> 'a array -> 'b t
<dbueno_>
(I can paste the rest of the implementation --- 1 line --- if relevant.)
<Ugarte>
Hmm. I can't seem to get fsharp to work on Mono with the latest version.
<Ugarte>
Irritating.
<Mr_Awesome>
dbueno: i think it has to do with the fact that the implementation constrains getter to having type 'a -> 'a
<Ugarte>
Er, at least fsc works, but not fsi.
<Ugarte>
Very very irritating.
<dbueno_>
Mr_Awesome, are you saying there's no way to fix it?
<Mr_Awesome>
im not quite sure how to resolve that however
<Mr_Awesome>
im sure theres a way
<Smerdyakov>
dbueno, your implementation only works when 'a = 'b.
<Smerdyakov>
dbueno, but you are asking the function to be treated as if it had the more general type.
<dbueno_>
I'd like it only to work at the call site, if when you haven't specified a getter, you expect the set to have the elements in the array.
<dbueno_>
... and to work when you specify a getter that returns elements of the type you expect in the set.
<Smerdyakov>
No way to do it without defining a separate function
<dbueno_>
If that makes sense.
<Mr_Awesome>
it seems like there should be a way to do it
<dbueno_>
Smerdyakov: You sure?
<Smerdyakov>
Mr_Awesome, doesn't seem that way to me. The type system would have to be waaay too complicated to allow that.
ziggurat has joined #ocaml
<Smerdyakov>
Mr_Awesome, think about it; the type of the function would need to express that you must have 'a = 'b if you don't give the optional argument.
<Mr_Awesome>
does removing the initialization alleviate the error?
<Smerdyakov>
dbueno, pretty sure. It would be ridiculous for OCaml to allow that.
<Mr_Awesome>
well, if you just had a function of type ('a -> 'b) -> 'a list -> 'b list, would identity not be an allowable function to be passed as the first argument?
<Payo543>
i kinda want to finish my jabber client in LUA
<Payo543>
but something inside of me says use ocaml
<Smerdyakov>
Mr_Awesome, yes. Just stop and think about what type you would give the function dbueno asked about. You won't be able to come up with one.
<Payo543>
but lua + that luaJIT speeds are crazy fast
<Ugarte>
Heh.
<Ugarte>
I'm trying to use F# on Mono right now.
<Ugarte>
Talk about slow, Payo543.
<Ugarte>
You can't do Ahead Of Time compiling with Mono on OSX for some reason or it doesn't work.
<Ugarte>
Fucking brutal.
<Payo543>
Ugarte, F# slow ?
<Ugarte>
F# is not slow.
<Payo543>
then?
<Ugarte>
The F# compiler (interpreter won't even WORK) on OSX without AOT is slow.
<Ugarte>
I'm going to try the MS SSCLI now instead of mono.
<Ugarte>
See if that's any better .
<Payo543>
so AOT is the slow part?
<Mr_Awesome>
what im saying is that i dont see why the type system should restrict the predicate to ('a -> 'a) just because the function might be (fun x -> x)
<Payo543>
lua HIT is faster then C# / mono
<Payo543>
JIT
<Ugarte>
AOT makes it run fast. You can't do AOT on OSX for some reason.
dbueno_ has quit ["Leaving"]
<Mr_Awesome>
why does an optional arg's initializer narrow its type?
<Ugarte>
What are you asking?
<Ugarte>
I wasn't following along.
<Mr_Awesome>
then read the previous conversation
<Ugarte>
Ah.
<Ugarte>
Sorry.
<Payo543>
Ugarte, hmmmm
<Payo543>
AOT is possible with luaJIT also but i dont do it
<Ugarte>
Payo543: It's just annoying, especially to not be able to use the toplevel interpreter.
<Payo543>
dont use F# :P
<Mr_Awesome>
Smerdyakov: do you see what im saying?
<Ugarte>
I could use OCaml, but at work at use C# and F#, and so I'mm more familiar with the .NET libraries at the moment.
<Ugarte>
If I were to use F#, I'd have to brush up on it.
<Ugarte>
Er, OCaml.
<Ugarte>
Not F#.
<Payo543>
i have a little of my jabber client written in ocaml .....i might just goto lua and finish it since it has speeds way up there
<Ugarte>
And anyway, the project I'm working at at home is a bit for work, so it should run on .NET.
<Payo543>
hmmmmmmm
<Payo543>
i dont liek any of that .net crap :)
<Ugarte>
It's a decent platform.
<Ugarte>
I'm starting out on a possible deobfuscator for it now. :)
<Smerdyakov>
Mr_Awesome, stop thinking about some imaginary world and THINK about what the OCaml type could be. ;)
<Mr_Awesome>
Smerdyakov: i just dont understand how a default value is different from a value bound at application time
<Payo543>
Ugarte, they need t omake it faster :)
<Payo543>
Ugarte, above Java :)
<Ugarte>
But that's on Mono.
<Mr_Awesome>
Smerdyakov: couldnt you just leave getter without an initializer and set it to id when is None?
<Ugarte>
I wonder what the results would be on the .NET framework.
<Ugarte>
Although Mono does compare favorably with .NET Framework.
<Smerdyakov>
Mr_Awesome, think about what the type means. It says that the function is safe to call, for any 'a and 'b, with an array of 'a to get a container of 'b.
<Smerdyakov>
Mr_Awesome, if the default converter forces 'a = 'b, then clearly the function can't satisfy its contract, right?
<Mr_Awesome>
the default function doesnt force 'a = 'b for every case though
<Smerdyakov>
It forces it for the case with no optional argument.
<Mr_Awesome>
yeah, and calling it with int_of_float forces 'a = float and 'b = int for that particular case
<Smerdyakov>
THINK about what type you could write that would work properly for the case with no optional argument.
<Mr_Awesome>
well if you didnt give the opt arg then passing a float array would give you a float container
<Smerdyakov>
I will not respond to you again unless you write out a precise OCaml type that you think could describe such a function.
<Mr_Awesome>
you mean the function that takes a function and an array and returns a container?
<Smerdyakov>
Yes.
<Mr_Awesome>
('a -> 'b) -> 'a array -> 'b t
<Smerdyakov>
No, it must have an optional argument, or you have missed the whole point.
<Mr_Awesome>
?p:('a -> 'b) -> 'a array -> 'b t
<Smerdyakov>
OK, now check for yourself that the suggested implementation can't have that type.
<Smerdyakov>
Similarly, any implementation with a default argument that forces 'a = 'b can't have that type.
yondalf has joined #ocaml
<Mr_Awesome>
i understand that ?(p = (fun x -> x)) narrows the type to ?p:('a -> 'a), i just dont understand why
<Smerdyakov>
Imagine that that implementation could have the type you wrote.
<Mr_Awesome>
ok
<Smerdyakov>
What would happen when you called it with 'a = int and 'b = bool?
<Smerdyakov>
(And no optional argument)
<Mr_Awesome>
it would raise an error saying bool used when int was expected
<Smerdyakov>
What would raise an error?
<Mr_Awesome>
because calling it with no optional argument constrains that particular call to having type ('a -> 'a) -> 'a -> 'a
<Mr_Awesome>
the compiler
<Mr_Awesome>
just like calling it with int_of_float constrains that particular call to having type (float -> int) -> float -> int
<Smerdyakov>
No.
<Smerdyakov>
The type ?p:('a -> 'b) -> 'a array -> 'b t GUARANTEES that ANY instantiations of 'a and 'b is allowed.
<Smerdyakov>
In particular, the no-optional-argument version must have the type 'a array -> 'b t.
<Mr_Awesome>
im just not seeing why that last statement is true
<Mr_Awesome>
when the no opt arg is called, how is that different than just calling it with (fun x -> x)?
<Smerdyakov>
Because that doesn't cover all the cases.
<Smerdyakov>
The no-optional-argument version MUST stand by itself with the type 'a array -> 'b t.
<Mr_Awesome>
does what im saying make sense in theory, or no?
<Smerdyakov>
I don't know what "in theory" means.
<Smerdyakov>
It makes no sense in the context of usable programming languages.
<Smerdyakov>
(With strong static type systems and type inference)
<Mr_Awesome>
so there is no way that the compiler could figure out that calling the function with no opt arg and an int array must return an int t?
<Smerdyakov>
Do you understand that, once a top-level function is defined, for type checking purposes the compiler NEVER AGAIN LOOKS AT ITS IMPLEMENTATION?
<Smerdyakov>
Only the TYPE is used afterward, and the type here conveys no information that would allow what you say to be deduced!
<Mr_Awesome>
so the reason is that the compiler doesnt know the type of the initializer after compiling the function, and therefore must narrow the type of the whole function in order to guarantee that it will work when the initializer is used
<Mr_Awesome>
and the difference between using the initial arg and one that you supply is that the compiler can know the type of an arg you supply, but not the initial arg
<Smerdyakov>
I don't know what that means. The type speaks for itself.
<Mr_Awesome>
since the initial arg was long since compiled
<Smerdyakov>
It sounds like you may finally have got it....
<Mr_Awesome>
my misconception stemmed from the fact that i didnt realize the compiler wouldnt be able to remember the initializer's type
<Smerdyakov>
OK. That's a fundamental conception about the way ML works, not this particular feature, so it's good that you've gotten it straight.
<Smerdyakov>
s/conception/misconception
<Mr_Awesome>
indeed, thanks for explaining it to me
chessguy has quit [Connection timed out]
<levi_home>
There doesn't happen to be anyone here that's used the C interface extensively, is there? I'm having strange problems.
delamarche has joined #ocaml
ziggurat has left #ocaml []
yondalf_ has joined #ocaml
yondalf has quit [Read error: 145 (Connection timed out)]
<ozzloy>
howdy
<ozzloy>
i'm new to list manipulations
<ozzloy>
can someone tell me how fold works?
<ozzloy>
let me rephrase "how does fold work?"
<levi_home>
It takes a function of two args, an initial value, and a list. It applies the function to the initial value and the first element of the list, then applies the function to that result and the next element, etc.
<levi_home>
That's a left fold.
<levi_home>
A right fold applies the function to the first element and the result of applying it to the second element and ... etc.
<levi_home>
So a left fold expresses an iterative process, while a right fold expresses a recursive one.
<ozzloy>
ok, then i think i get that
<ozzloy>
and that there is something else about this problem that is confusing me
<ozzloy>
this is for my hw btw
duncanm has quit [Read error: 110 (Connection timed out)]
<ozzloy>
thanks levi_home
<levi_home>
Hmm, apparently I have freaked out the garbage collector.
yondalf_ has quit ["leaving"]
<Payo543>
what all is there to take into consideration when making a web serveR?
<Payo543>
i need a very light one ......that can just work with lua code
<Payo543>
i was thinking of using the ocaml-HTTP lib and making my own
duncanm has joined #ocaml
<Payo543>
i really wish i had experince in making a wrapper for a c lib
smimou has joined #ocaml
bluestorm has joined #ocaml
dibblego has joined #ocaml
danly has joined #ocaml
slipstream-- has joined #ocaml
slipstream has quit [Read error: 145 (Connection timed out)]
Mr_Awesome has quit ["...and the Awesome level drops"]
dibblego has quit ["Leaving"]
danly has quit [Read error: 110 (Connection timed out)]
Snark has joined #ocaml
duncanm has quit [Read error: 110 (Connection timed out)]
<delamarche>
Let's say I have some mli file called "blah.mli"
<delamarche>
and within blah.mli I define a type "type foo = { x: int; y : int }" for example
<delamarche>
now say I'm writing some implementation bar.ml
<delamarche>
how can I access type foo from within bar.ml?
<delamarche>
when I "open Blah" it doesn't work
duncanm has joined #ocaml
<delamarche>
Hmmn I wonder if Blah.foo will work
<bluestorm>
hum
<bluestorm>
delamarche:
<bluestorm>
blah.mli is not real code
<bluestorm>
you have to redefine foo in blah.ml, i think
<delamarche>
That's what I've done
<delamarche>
that seems backwards though
<bluestorm>
hum
<bluestorm>
you may juste declare foo in the .mli, without describing type
<delamarche>
I mean, what do you do if you want to use that type across 20 different source files
<bluestorm>
type foo
<bluestorm>
ah
<bluestorm>
then you use Blah.foo
<bluestorm>
from another file you should you Blah.foo
<delamarche>
Ok one last thing though.
<bluestorm>
but in both blah.ml and blah.mli, foo is enough
<delamarche>
If I define a type like "foo" above
<delamarche>
and then do something like "let x = { x = 2; y = 4}"
<delamarche>
the compiler will figure out that x is type 'foo'
setog3 has joined #ocaml
<delamarche>
however, if I just define foo in the mli as 'type foo'
<delamarche>
won't I have to restate the type declaration in every file that uses the type?
<delamarche>
to get that behavior, I mean
<delamarche>
i think i'm too dense to figure out this interface/implementation seperation thing
<delamarche>
i run into even more trouble when I try to seperate class interfaces and implementations
shawn has quit ["This computer has gone to sleep"]
<delamarche>
oh nevermind
<delamarche>
guh... unbound constructor
<delamarche>
le sigh
<bluestorm>
hum
<bluestorm>
i think the easiest to do
<bluestorm>
is to code the beginning without .mli
<bluestorm>
and add them after
<bluestorm>
you'll be able to see what differ
<bluestorm>
(and the ocamlc -i option is really cool)
<delamarche>
That's what I did :)
<delamarche>
i started without them, now I'm teasing the interfaces away from the implementation
<delamarche>
i'll try -i, never used that before
<delamarche>
thanks bluestorm!
setog3 has quit [Client Quit]
setog3 has joined #ocaml
<pango_>
delamarche: .mli contain a module type (aka module signature), that constrains what's visible to the outside (and as you've found out, not only make things visible/invisible, but also make some types abstract...)
<pango_>
delamarche: if you use module and module types explicitly (not thru .ml/.mli) you can also constrain the same module with different module types to give the same code different visibilities at the same time
<pango_>
so it's more powerful than "attributes" way (public/private/friends/...) but incur some redundancy
Skal has joined #ocaml
<ikaros>
i wrote a program that reads sudokus from a file, prints them solves them and prints the solution.. what i dont understand is that it doesnt evaluate in this order: print solve print
<ikaros>
its more like it solves and prints unsolved and solved after that
<bluestorm>
i think you should get rid of global variables
<bluestorm>
global references seems like a bad idea
<ikaros>
hm why that?
<bluestorm>
as an example
<pango_>
ikaros: but it seems they're nicer solutions in functional paradigm
<bluestorm>
you may have solve returning backwards and mutations
<bluestorm>
hum ikaros
<pango_>
that contradicts "need some imperative code"
<ikaros>
yea but i doubt the are more efficient
<bluestorm>
global mutable variables generally are a bad idea, i think
<ikaros>
hm well that is no argument..
<bluestorm>
because every single function you have may change the program global state
<bluestorm>
and thus cause bugs very hard to find
<bluestorm>
hum
<ikaros>
its not that it is a large code.. this wont be enhanced or something..
<pango_>
actually the ffconsultancy very not purely functional either, mutating a string array
<ikaros>
there are sure some flaws ;)
<bluestorm>
hum, good practices still are good ones on a little code i think
<ikaros>
it was more a fun project to get a little into ocaml syntax
<ikaros>
problem is if i dont use global mutable structure for the sudoku
<ikaros>
it will eat lots of memory
<ikaros>
at least if i understood you right
<bluestorm>
hum
<bluestorm>
i don't see why hm
<ikaros>
where should i store the sudoku then?
<bluestorm>
hum
<ikaros>
local in the function? and mutate it there?
<bluestorm>
yes
<ikaros>
ah ok
<bluestorm>
hum
<ikaros>
ok if this was a real project i would probably change this ;)
<ikaros>
i see your point there
<bluestorm>
actually, there are some things
<bluestorm>
that may be globals
<bluestorm>
like '80'
love-pingoo has joined #ocaml
<bluestorm>
you sudoku's size is hard encoded each time
shawn has joined #ocaml
<bluestorm>
if it was a global, would you be able to use the same algorithme for other-size sudoku's ?
<ikaros>
well
<ikaros>
i wouldnt because i use this large table
<pango_>
ikaros: however you shouldn't assume functional = slow
<pango_>
not if the immutable datastructure allows for sharing
<pango_>
see lists, for example
<ikaros>
i would then have to write a function to create that table every start
<pango_>
(not that I mean that lists are the correct datastructure for this problem!)
<ikaros>
pango_, i know that
<ikaros>
i just said that the "sudoku problem" is more an imperative program.. depending on a matrix structure
<ikaros>
and mutable fields
<pango_>
in purely functional style, you'd need an immutable datastructure for cells, then build new board from previous one each time you set one cell
<pango_>
benefit would be that backtracking is trivial, you just go on from old board
<ikaros>
yea but i had to rebuild the whole sudoku every step
jajs has joined #ocaml
<ikaros>
i had one sudoku solved with 120mio backtracks
<ikaros>
in fact my solution isnt that fast
<ikaros>
because it uses only backtracking
<ikaros>
but its not that slow too
<ikaros>
well... i changed all those pring_strings to Printf.printfs now
<ikaros>
but..
<pango_>
google for "functional arrays"
<ikaros>
later ;) i first wanna fix that printing stuff
<bluestorm>
hum
<bluestorm>
i think arrays are right
<bluestorm>
but a lot of reference could be avoided, or made less global
<bluestorm>
(startTime and globalTime don't need to be references, for example)
<bluestorm>
hum
<bluestorm>
and lot of "for i = 0 to 80 do" could be turned into Array.iter or Array.iteri
<bluestorm>
(may be more efficient, and you don't have to hard_code the size)
<ikaros>
ok
<ikaros>
ill look into Array.iter soon too
<ikaros>
thx so far
<pango_>
<ikaros> yea but i had to rebuild the whole sudoku every step <- syntaxically, yes
<bluestorm>
hum, and ((int_of_char line.[j]) - 48) could be rewritten (int_of_char line.[j] - int_of_char '0')
<ikaros>
hm
<ikaros>
bluestorm, that would be another calculation right?
<bluestorm>
haha
<ikaros>
why would this be good? =)
<bluestorm>
doesn't cost anything
<bluestorm>
hum
<bluestorm>
int_of_char '0' is much more readable than '48'
<ikaros>
hm well yes
<ikaros>
thats right
<pango_>
see constants propagation
<pango_>
int_of_char '0' is probably computed at compile time
<ikaros>
ok
<pango_>
specially since int_of_char must be a noop
<pango_>
pervasives.ml:external int_of_char : char -> int = "%identity"
<bluestorm>
:D
<ikaros>
ok wait.. i just repaired all that printing stuff
<ikaros>
gotta test it
<ikaros>
ok. any one of you got an idea why the program calculates the solution BEFORE printing the initial sudoku?
<pango_>
probably missing some flush () before solve ()
<pango_>
input and output are buffered
<ikaros>
ok
<pango_>
and neither Printf.printf nor print_string call flush ()
<pango_>
print_newline, print_endline, etc. or Printf.printf "%!" do
<dark_light>
pango_, let f = String.sub str adds an overload? i though it would increase performance for saying a tip to the compiler..
<pango_>
you were using lots of partially applied functions in your ifs too... if your code is really time critical, creating lots of closures is said to be expensive
<pango_>
nope
<pango_>
the other obvious cost is the creation of temporary strings f (i+1) n
<dark_light>
i will use index_from for it like abez said
<pango_>
that said, will that code be really that time critical ?
<dark_light>
i don't know, but i don't want a slow code either..
<dark_light>
pango_, but i am prefering a readable code (partially applied functions helps me on this..)
<pango_>
yes, I'm like that too ;) However I suspect it won't matter for a function not called thousands of times/s
<pango_>
dark_light: actually I think let before s i = String.sub s 0 i and after s i = String.sub s i (String.length s - i) would probably make your code even more readable
<pango_>
(or something like that; seems you're getting rid of the separator too)
<pango_>
passing string length around along with the string is also an optimization that obscures the function (since one has to verify that it's really an invariant)
<pango_>
(and that you didn't mean something more complex)
<pango_>
and since String.length complexity is O(1), it's not really required
<dark_light>
pango_, but if i don't create new substrings, i will not able to use String.length ..
<pango_>
correct, just telling that if the point was readability, you could have gone one step further ;)
<dark_light>
i see :)
<bluestorm_aw>
btw pango_, are you related to PPS ?
<bluestorm_aw>
(as it seems a lot of wise french ocamlist are)
<pango_>
dark_light: you can move let len ... outside of loop since it's a constant now
<pango_>
(let's say a loop invariant)
<dark_light>
pango_, i writed it outside and seemed ugly.. there are some benefits to do it?
<pango_>
will be evaluated once instead of once per word
<dark_light>
pango_, no it will not evaluated every loop call (at least it was my desire, my assumption, and my, well.. my i-think-the-things-would-be-nicer-that-way..)
<pango_>
actually you'll be using it only once: for the last word...
<dark_light>
Hmmm well..
<pango_>
you could move it to the Not_found handler
<dark_light>
pango_, why you didn't used String.index_from ? it would saves a lot of work..
<dark_light>
and, btw, your version is tail-recursive and mine isn't?
<pango_>
yes... Somehow I switch to human-assembler for that kind of string parsing... But that's my own prejudice :)
<pango_>
it should be tailrec, yes... parsing from the end so I don't have to reverse the list, either
<dark_light>
there are any special reason for my version do not be tail rec? loop is the last call in the recursion.. is the :: the problem?
<pango_>
they're two :: and try ... with
<dark_light>
Hmmm.. well, it makes some doubt to my parser.. but i have never seen an irc message with more than, let's say, 10 parameters..
<dark_light>
and i have no idea if tail recursive functions are really faster than other recursive functions..
<pango_>
the point of tailrec is rather stack usage rather than speed
<abez>
a tail recursive function can be faster due to more cache hits
<abez>
also by avoiding doing real function calls it can be faster too. Anytime you can reduce memory access you can improve speed.
<abez>
But pango_ is right.
<dark_light>
what is the typical size of the stack?
<dark_light>
(well, i think i can verify this..)
<abez>
the size arguments and locals that are not on the heap
<dark_light>
Hmm?
<pango_>
let's say few tens of thousands recursive calls... maybe in the hundreds of thousands for native compiled code... around those values anyway
bluestorm_aw has quit ["Konversation terminated!"]
Leonidas has quit ["An ideal world is left as an exercise to the reader"]
bluestorm has joined #ocaml
<dark_light>
hmm.. here for the function let rec fat n = if n <= 0 then 1 else n * (fat (n-1)) seems to be 65460..
<bluestorm>
hum
<bluestorm>
when looking for some ocaml stuff
<dark_light>
hi bluestorm :)
<bluestorm>
i found a old ocaml package
<bluestorm>
ledit
<dark_light>
ledit is nice
<bluestorm>
hum
<bluestorm>
it don't work for me
<dark_light>
i didn't know that it was meant for ocaml
<bluestorm>
do you think it's a ledit problem, or a problem with my config specifically ?
<bluestorm>
(i thougt it may be based on a too old ocaml version)
<dark_light>
i dunno.. here i type ledit ocaml and everything runs fine
<bluestorm>
ok
<bluestorm>
so i'll explore the problem
<dark_light>
bluestorm, you can even execute ledit ocaml? there are any error message?
<bluestorm>
hum
<bluestorm>
compilation of ledit fails
<dark_light>
bluestorm, oh, i didn't compiled.. i installed from a ubuntu package
<pango_>
exceptions handling makes writing tailrec functions awkward... that's a shame
<abez>
can't ocaml detection than an exception is not caught in the method tho?
_velco has joined #ocaml
<pango_>
I suppose there's no way around this... it's just that, since the standard lib uses exceptions a lot, you run into this very often when writing tailrec functions :/
<bluestorm>
thanks pango_, make worked flawlessly
<bluestorm>
hum
<bluestorm>
i have now to figure how to say portage to use the good makefile ^^
<pango_>
ledit itself would probably benefit from some adjustments... upstream code is over 4 years old... (ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de_Rauglaudre/Tools/)
<abez>
pango_: if you don't catch exceptions in your recursive function doesn't it mean that tail recursion can still happen just fine
<abez>
side note: I've had to use exceptions as a substitute for gotos while porting some godawful algorithm
<abez>
>:(
<pango_>
but if you don't catch exceptions, and your function is functional (!), you lose the result of computation :)
<pango_>
actually I've never seen v2 suggested anywhere... it must be terribly wicked :)
<pango_>
bluestorm: I like it too :)
<bluestorm>
« i don't understang why everything is messed up when i just enter "anything will do". »
<bluestorm>
:D
<pango_>
of course, it's only correct because of physical equality
<bluestorm>
aha
<bluestorm>
hum
<bluestorm>
:D
<pango_>
it won't
<bluestorm>
yeah
<bluestorm>
i have just seen the ==
<bluestorm>
^^
<bluestorm>
but pango_, why would "creating 'a option values" be bad ?
<pango_>
btw I wonder how == is guaranteed to work with current Gc
<bluestorm>
i mean, you could just redefine read_line to send an option type and the replace "== magic_eof" with a nice pattern matching
<pango_>
correct, and it would be more sml-like, which would be a good thing in this context
<pango_>
well, I suppose the allocation cost wouldn't be that high, because all those wouldn't survive past the next minor gc
<pango_>
it just feels weird that syscalls return code is returned by libc (possibly translated), the OCaml runtime turns it into a raised exception, that you catch to convert result in 'a option... :)
<bluestorm>
hm
<bluestorm>
i don't think read_line() is often used in performance-strategical parts of programs ^^
<pango_>
yet such read_all_input () function comes very often of mailing lists, because it's more difficult than necessary to make it tailrec
<pango_>
so people write programs that mysteriously fail on large inputs
<pango_>
of course, for large inputs, it's better if you can avoid building that whole string list in the first place...
<bluestorm>
hm, i see
<pango_>
but it's so convenient :)
ziggurat has joined #ocaml
<dark_light>
the suggestions here not only made the code faster and easier to read (?) but also with less lines of code ^^ http://nopaste.tshw.de/1160937029833e0/ .. i am very happy with it (but maybe it would be better if outputs an array instead of a list..)
<pango_>
dark_light: I suspect it raises an exception if given an empty string
<dark_light>
! the old one raises it too
<dark_light>
... but why? the access to str.[0]? hmm..
<dark_light>
well i could make another if.. :-(
<bluestorm>
hum
<bluestorm>
would there be an easy way to have the test "str.[...] = ':'" done once only ?
<dark_light>
bluestorm, but how? i have to test it every new word
<bluestorm>
as it seems an important part of this function's logic, it would be more elegant not to have it repeated several times, i think
<bluestorm>
hum
Payo543 has joined #ocaml
<dark_light>
because the message ab a :test and ab :a test are valid in irc protocol syntax
<dark_light>
bluestorm, i really think i have to test it every word (and, worse, i have to treat it very specially if it's on the first word)
<bluestorm>
ok :p
<ayrnieu>
: will appear either at the beginning of an IRC message to mark the source of that message, or otherwise before 'the rest of the message, up to the newline' to mark an extended final argument.
<dark_light>
ayrnieu, exactly :) and worse: the source is optional
<dark_light>
i think i could not design a more confuse protocol
setog3 has quit [Client Quit]
<pango_>
raises an exception with strings made of spaces only, too
<pango_>
in fact strings ending with separator(s) will do
<dark_light>
:o
<pango_>
if str.[i] = ':' then [sub 1 len] <- are you sure it's not sub i len here ?
<pango_>
(beginning of loop)
falconair has quit []
<dark_light>
you are right. i corrected this early (actually it's sub (i+1) len, because i don't want the :)
shans_home_ has joined #ocaml
shans_home has quit [Read error: 110 (Connection timed out)]
<pango_>
the contrary of = is <> (but again, for chars, it's ok)
<dark_light>
hmm eh
<dark_light>
!= is for <> ?
<dark_light>
ops
<dark_light>
!= is for == ?
<pango_>
= and <> are structural operators, == and != are physical
<dark_light>
hmmm ok
<pango_>
is the second of : guaranteed to appear at the beginning of a word (= be preceded by a separator) ?
<pango_>
s/second/second kind/
_velco has quit ["I'm outta here ..."]
<dark_light>
pango_, yes :) i didn't know, but the rfc says this
<dark_light>
anyone here uses micmatch extension? the reference says that "beginning of line" and "end of line" matchs are specific to micmatch_str, i am using micmatch_pcre.. i am looking for a way to workaround this
<dark_light>
ps: no, i am wrong, micmatch_pcre suppors ^ and $
<dark_light>
passing objects by parameter is expensive? it passes a copy or just a pointer?
<pango_>
objects are boxed, like about anything but small enumerable types (ints, chars,...)
<pango_>
silently copying objects would be evil anyway
<pango_>
only C++ can do that ;)
<dark_light>
what you mean, there are no way to know unless looking at the code?
<pango_>
no, they're boxed, so what's copied is object references ("pointers")
<dark_light>
pango_, i am asking because i have a method that call a external function passing "self" to it.. and then that external function calls another function, and that another function calls one more another function.. all that time, passing the object as parameter..
<dark_light>
pango_, hmmm
<pango_>
so copying would not only expensive, but could also be the source of strange bugs... side effects suddently being reverted...
<pango_>
I remember staying puzzled for 3 days on such bug with Borland Pascal (ah, memories ;) )
<dark_light>
pango_, i think i have no choice.. i decided do not do any parsing using the object itself; all parsing is done will use external functions. but that parsing can execute tasks that requires access to connection methods..
<pango_>
mikeX: write more functional code, so you don't need to "do something after ifs" ;)
<pango_>
dark_light: or to enclose the then action with begin/end, or parenthesis
<mikeX>
hmm, we had an earthquake here too earlier
<mikeX>
well more functional code is not always easier or more elegant : P
<mikeX>
at least not to me
<dark_light>
mikeX, i always prefer to avoid ;, but in some cases is difficult or leads to complicated things
<mikeX>
yeap, that was the point I was trying to make
<pango_>
mikeX: but that in those small details that you see that syntax is optimized for functional use
<pango_>
another way to get around it, add "else ();" (but I'm not sure it's better than begin/end or parenthesis :)
<mikeX>
already used begin end, I was just wondering why it was so : )
<pango_>
let ... in ... has no closing keyword, so it expands has much as possible
<mikeX>
i see
<abez>
I used to really worry about writing functionally in ocaml but I think you get better at picking your battles
<abez>
often a for loop is just fine
<abez>
especially if you working with matrices and arrays
<abez>
Although I've made for_xy functions etc.
<dark_light>
Hmmm.. someone here made this function for me: let rec loop f = f(); loop f, for now on i am using it instead of while true do f () done (i think it was you abez)
<abez>
yah
<pango_>
abez: yes... that's specially true for numerical code, because the compiler doesn't know how to keep floats unboxed over function calls
<pango_>
(that's why OCaml gets so low score at the "recursivity test" in the language shootout)
<dark_light>
Even when i encapsule a ill-formed match with an try, as in try match 2 with 1 -> true with Match_failure _ -> false;;, the compiler says that match isn't exhaustive.. is there any problem to ignore it? (actually using | _ -> would be better..)
<pango_>
I think | _ -> assert false is the best solution
<Payo543>
pango_, huh ?
<pango_>
it's probably possible to tell the compiler to shut up, but then you could be unaware of cases you really forgot about ;)
<dark_light>
how tell this to it?
<dark_light>
ah, probably
<pango_>
Payo543: for your future packages repository :)
<pango_>
dark_light: ocaml{opt,c} -w e or -w p, not sure
<dark_light>
Hmmmm..
<Payo543>
pango_, yea i worked on it a little yesterday :P
falconair has joined #ocaml
<pango_>
dark_light: -w p
<dark_light>
pango_, i remembered why i asked this: i really wanted to abort when the match fails.. i was first trying with try, but to avoid the compiler message i created an exception and did | _ -> raise Malformed_msg
<dark_light>
(ps: maybe it should be named Illformed_msg ..)
<pango_>
depends whether this case should really not happen (bug) or is just a bad (but possible) runtime condition
<pango_>
if it's a bug, then that's what asserts are for
<pango_>
(however ocaml asserts are implemented using exceptions, so it's not that different)
jajs has quit [Remote closed the connection]
<Payo543>
i think i am going to write a jabber client in Lua and Ocaml
<dark_light>
pango_, it's a bad but possible runtime condition, but i want to know if *any* network would cause problem so i will raise an exception..
<dark_light>
Payo543, what lua will handle, and what ocaml will handle?
<Payo543>
dark_light, making 2 jabber clients one in ocaml and one in lua :P
<dark_light>
Payo543, ahahahaha :P
<Payo543>
dark_light, have you saw how fast lua is ?
<dark_light>
no, but i think it's a lot fast
<Payo543>
its the fastest scritping language and it gets even faster with a JIT thingy
<Payo543>
faster then fortran / forth
<Payo543>
right below java but it beats java memory wise
<dark_light>
actually i know lua as "the programming language developed on brazil that is known more outside the brazil than here" :P but i will use lua someday
<Payo543>
lua is my favorite language
<dark_light>
unhapply there are more urgent things to learn (like lisp)
<Payo543>
lua / ocaml are my picks
<Payo543>
i never got into lisp
<Payo543>
to many implmentations
<abez>
Payo543: why do you like lua? easy to throw functions around?
<Payo543>
simple fast :P
<Payo543>
and i can modify lua itself any way i like
<dark_light>
C is simple and fast :P
<dark_light>
Hmm
<Payo543>
dark_light, true
<Payo543>
but i can make a lua interpreter as small as 20 kb
<Payo543>
take out the parser and stuff i dont use
<dark_light>
Payo543, the fact lisp has many implementations i see as very good.. maybe many flavors (maclisp, common lisp, scheme) isn't a good thing, but at least it seems that the language isn't going to die
<Payo543>
its good :)
<Payo543>
i just never could decide which one to use
<Payo543>
als o i would like to distribute my program and thats hard to do with lisp
<dark_light>
the worse thing that can happen with a language is to have only one closed implementation.. (but it's very good to see that VB is going to die :)
<Payo543>
lol
<dark_light>
Payo543, hmmm.. hard to distribute, why?
<Payo543>
you have to distribute run time
<dark_light>
ahh you mean, hard to do concurrent processing?
Payo543 has quit [Remote closed the connection]
mikeX_ has joined #ocaml
mikeX has quit [Read error: 110 (Connection timed out)]
<pango_>
dark_light: no I think he meant to make self contained packages
love-pingoo has quit ["Connection reset by pear"]
<dark_light>
well there are no machine code compiler for any flavor of lisp? seems strange
<Smerdyakov>
Not true.
<ayrnieu>
absurdly untrue.
<dark_light>
good to know :)
<pango_>
I fail to see anything really exciting in lua's definition... it may be ok for an extension language, but still...
<bluestorm>
hum
<bluestorm>
"it's very exciting because JIT is soooo fast", would say Payo
Payo543 has joined #ocaml
<Payo543>
back
<Payo543>
i wish i could make some bindings to some c libs
<Payo543>
but whomever made that sqlite 3 binding why did they make it soo somplicated grrr
<pango_>
Payo543: I'm relatively unimpressed by lua syntax
<pango_>
or datastructures for that matter
<Payo543>
lua' syntax is pretty free
<Payo543>
they have libs for every data stucture you can think of
<Payo543>
be impressed with its msall size
<Payo543>
and speed
<Payo543>
and it rivals compiled languages being a dynamic language
<pango_>
well, almost ;)
<Payo543>
almost is good enough :P
<Payo543>
ruby cant even compete :P
<Payo543>
pango_, im going ot be donating to the Lua JIT ......development will be getting alot better for that and will be getting faster more parts being written in asm
<pango_>
mmmh
<Payo543>
i think its one of the best langs around performance wise
<Payo543>
and super fast development
<Payo543>
ocaml would be faster if people updated the libraries grrrrr
<ayrnieu>
#LUA I AM SURE WILL BE MOST FASCINATED
<Payo543>
lua is faster then Erlang
<bluestorm>
hmm
<Payo543>
and erlang has one of the best web servers out
<Payo543>
can handle 80,000 connections
<bluestorm>
Payo543:
<Payo543>
apache can handle around 4.500
<bluestorm>
you're writing a jabber client
<pango_>
Payo543: found the answer in the mailing list already... They want to keep the standard library as a reference of good practice for teaching and beginners
<Payo543>
bluestorm, yes ?
<bluestorm>
do you need a lightning-fast language ?
<ayrnieu>
I don't care about your program model of 'is faster than', or of programming speed, or of benchmarks. Go wax on about this in #la: you really said all there was to be said quite a while ago.
<pango_>
Payo543: so anything remotely "hackish" simply doesn't get in the standard library :/
<Payo543>
bluestorm, nope
<bluestorm>
i really think python is enough for a jabber client
<ayrnieu>
your broken model, ratther.
<Payo543>
pango_, heh hmmmmmmmm
<Payo543>
bluestorm, gajim ?????
<bluestorm>
possible
<Payo543>
gajim is a ver popular jabber client written in python
<Payo543>
bluestorm, but why not use the best technologies you can use
<Payo543>
with a practical mind
<pango_>
well, with a practical mind I would avoid dynamic typed languages... oops, doing that already ;)
<Payo543>
pango_, you mean static ones like c ocaml etc ?
<Payo543>
pango_, i so also but lua is an exception
<bluestorm>
[23:39:12] <Payo543> bluestorm, but why not use the best technologies you can use
<bluestorm>
i'm not sure "the best" is "the quickest"
<Smerdyakov>
Payo543, is there good tool support for proving correctness of Lua programs formally?
<Payo543>
bluestorm, its also just a matter of chouce .....lua intrest me :P
<Payo543>
Smerdyakov, i havent used it long enough
<Payo543>
pango_, a netwroking library would be great for ocaml
<ayrnieu>
sure, you start with coq and then export to Scheme and then translate to Lua and then you can't really be sure.
<Payo543>
pango_, theres a few http client here and there but a solid netwroking lib included with ocaml would be good
<dark_light>
there are some for ocaml, but i am writing my own lib (that unhapply is a module named Net, that conflicts with an popular existing library)
<ayrnieu>
payo - it has one. In core, even.
<Payo543>
well
<Payo543>
Unix.Connect
<Payo543>
but thats not a very good library :P
<dark_light>
ayrnieu, the sockets support in Unix is very low level
<Payo543>
i mean yea it good
<Payo543>
yea
<Payo543>
a little more higher level wouldnt hurt
<pango_>
Payo543: I doubt non will ever be "included" with it, however there's stuff like ocamlnet
<Payo543>
i think thats just for http
<Payo543>
<< doesnt really care now hes written his own small lib for himself
<ayrnieu>
dark - which is better than a broken abstraction: you have BSD sockets and a nice language to work with. It is, IAC, a networking library.
<Payo543>
whats better to use read . write or sock_recv / sock_send ?
<dark_light>
Smerdyakov, ah, after a while my irc bot object oriented worked :) i had to coerce the object passed to the function as the self class.. i will try abstracting network with modules later, in other projects, but now i will stay with classes..
<ayrnieu>
payo - if you mean to ask, 'is it better to use socket operations on sockets, or can I treat them like any other stream?', the answer is: yes, and no, you can't. Sockets are not files, and pretending otherwise prevents from writing even very trivial things like *echo servers*, correctly. It's very easy to provide a broken abstraction over BSD sockets.
<dark_light>
ayrnieu, hmmmm
<Payo543>
well
<Payo543>
i saw some examples of server some people use read and write
<Payo543>
and some use socket rec and send
<Payo543>
recv
<dark_light>
ayrnieu, so i can't really treat sockets like ocaml streams?
<dark_light>
ops, ocaml channels
<dark_light>
ayrnieu, i am using ocaml channels just because i don't want to reimplement read_line
batdog is now known as batdog|gone
<Payo543>
i think both languages deserve jabber clients
<Payo543>
but i do *NOT* like lablgtk
<Payo543>
GRRRRR
<Payo543>
and the way some people write bindings
<Payo543>
some people write them so complicated it would be easier to do it yourself in asm
<Payo543>
and people dont update those libraries
<ayrnieu>
dark - yes, you should implement your own read_line.
<dark_light>
Payo543, i think brainfuck deserves a jabber client, but i do not know how create a socket with brainfuck.. :)
<dark_light>
ayrnieu, well :(
<Payo543>
lol
<dark_light>
ayrnieu, so Unix.establish_server is, well, buggy? (it returns in/out channels)
<ayrnieu>
dark - sorry, I can't explain this right now. Some things are painfully obvious with experience, but difficult to briefly advocate. Take gets() and scanf() in C, for instance. Both of them completely horrible and broken by design, but you can't explain the first without communicating concern for buffer overflows and basic security, and you can't explain the second without communicating concern for sane unix interfaces, and timely respo
<dark_light>
Hmmm..
<Payo543>
i just wish compiled programs in ocaml were not so large
<Payo543>
i wish there was a better way of optmizing for size
<ayrnieu>
dark - as long as you've a proper recv, you can sanely deal with networking. FILE*s and their HLL analogues usually don't have this operaion. Otherwise, you can still get along in limited ways.
<ayrnieu>
payo - write more interesting programs, or compile to bytecode.
<dark_light>
ayrnieu, a socket isn't a file descriptor?
<pango_>
it's not like 80kB of disk space matters those days
<pango_>
ayrnieu: well, once you compile with -custom, bytecode lose its advantage (at least for small apps)
<pango_>
ayrnieu: (IIRC Payo543 was concerned about standalone executables)
smimou has quit ["bli"]
<Payo543>
pango_, well + libs and stuff it grows
<pango_>
TANSTAAFL
<ayrnieu>
if we tend to it, it will grow.
<pango_>
(not yelling, just acronym ;) )
<pango_>
dynamic binding of native libs would be great, however
<pango_>
specially close to world domination, when most apps will be written in OCaml ;)
<abez>
It is totally possible
<abez>
Write a general C wrapper
<abez>
Then make an interface
<abez>
sure it'll be relatively ineffecient
<abez>
but it'll be general
<abez>
You have to make a bunch of assumptions tho