<dark>
i would like some features of it in the regular syntax, such as \+ instead of (+)
<dark>
list int instead of int list
<dark>
"There is a syntax difference between data constructors with several parameters and data constructors with one parameter of type tuple." <- this is likely to be the most valuable feature of this revised syntax
<dark>
i didn't liked do { } and the overuse of [], but the rest is fine. ;-;
<adrien>
mandatory 'else ()' branches
<dark>
i have mixed feelings
<dark>
while i like brevity, i dislike the ending problems
<adrien>
and a few others, like delimiting match clauses (or the whole thing, I can't remember)
<adrien>
but I don't like everything in the revised syntax
<dark>
i mean, it's annoying to have to write () sometimes..
<dark>
but it's even more annoying to write [ ] all the time o.O
<dark>
[] is ugly (well it doesn't need shift, but the whole idea of conciseness is to be beautiful for me, not to require less keystrokes)
<dark>
while writing ocaml i most likely spend time thinking and not typing
<dark>
but at least
<dark>
the [ fills the space of the extra | in the beginning
<dark>
it may work well..
<adrien>
mandatory I'd like a middle ground in the syntaxes: one that would help catch errors but not change everything
<dark>
i would like to change the type syntax
<dark>
also i liked the x.val better than !x
<dark>
in fact... it makes sense to write my own record with a val
<dark>
and start using this convention
<rwmjones>
yeah, !x seems to bother a lot of C programmers I know
<rwmjones>
if !debug then printf "a debug message";
<avsm>
once people get past the whole "let" hurdle, everything else seems minor :)
<adrien>
well, I sometimes read it as "if not debug"
<f[x]>
\+ is not in current camlp4r
<dark>
in that syntax chart, how one would define a top level function?
<dark>
value f x = .. ?
ygrek has quit [Ping timeout: 245 seconds]
<dark>
i enjoy the overuse of let .-.
<_mpu>
what is let _ = blah blah ?
<dark>
_mpu, execs blah blah, then binds the result to nothing
<dark>
_mpu, think about match blah blah with _ -> (), but without actually returning ()
<dark>
(it's a statement, not expression.. unless there is a "in" after it)
<_mpu>
I forgot the in
<_mpu>
oops
<dark>
_mpu, let can bind patterns like match
<_mpu>
no I did not forget it :)
<dark>
_mpu, like: let f (a, b as c) = a, b, c
_unK has joined #ocaml
<_mpu>
it as a 'a * 'b -> 'a * 'b * ('a * 'b) function .
<_mpu>
?
<dark>
_mpu, yes, what's the value of f (1, 2) :
<dark>
?
<_mpu>
(1,2,(1,2))
<dark>
a is 1, b is 2.. c is (a, b)
<dark>
think about match (1, 2) with a, b as c -> a, b, c
<dark>
returns the same thing, but binding with match, not let
<dark>
_mpu, in fact, let _ = .. is used in lieu of C's int main() { }
<dark>
because there are some syntatical problems into putting expressions straight at top level
<_mpu>
that's in this context I've seen it
<dark>
(the compiler needs some guessing sometimes, and it will not be available if you type print_int 9 in place of statements)
<dark>
you would sometimes need ;;
<dark>
or exemple, this will compile: let _ = print_int 9 let _ = print_int 9 (you could use ; but it's just an illustration)
<dark>
suppose you want to turn the first let _ = print_int 9 into print_int 9
<dark>
print_int 9 let _ = print_int 9 is a syntax error, you need ;;
<dark>
print_int 9;; let _ = print_int 9 works
<dark>
if all your top-level code is composed of statements, you can avoid this ugly ;;
<_mpu>
a statement only triggers side effects while an expression evaluates to something
<_mpu>
is that true ^
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<gildor>
are the some Lwt experts around?
<gildor>
in Lwt_unix, some functions are missing like Unix.mkdir
<gildor>
does it means I can use one directly from Unix.
<dark>
<_mpu> a statement only triggers side effects while an expression evaluates to something
<dark>
i don't quite understand this statement
<dark>
of course side effects are achieved by evaluating expressions..but defining new names or types seems like a side effect to me, too
jakedouglas has joined #ocaml
<dark>
anyway "side effect" is usually reserved for what expressions does besides returning a value
<hcarty>
dark, _mpu: let () = ... is often a bit safer
<hcarty>
than let _ = ... as that can accidentally hide mistakes
<dark>
hcarty, so that you can ensure the expression return unit?
<hcarty>
dark: Yes
<dark>
it makes sense
<avsm>
gildor: you have to be careful of exceptoins
<avsm>
even if the call doesnt block, raising a direct exception (Unix_error) will cause all hell to break loose
<avsm>
so it's best to bind it into Lwt_unix
<dark>
what's lwt?
<avsm>
light weight threading library
ttamttam has quit [Remote host closed the connection]
<hcarty>
Which happens to come with a pretty cool enhanced toplevel
Yoric has quit [Quit: Yoric]
<gildor>
avsm: ok for the exception, I already get this
<avsm>
that looks fine as long as mkdir doesnt block
<gildor>
(and mkdtemp is BSD, which is not a big deal but nevertheless)
<gildor>
If I want to prevent block, I can detach the computation ?
<avsm>
the problem is that mkdir can block if the underlying filesystem blocks (e.g. nfs)
<avsm>
but it doesnt really have a blocking/nonblocking option as it doesnt work on FDs
<avsm>
so detaching it to a thread is the only safe way probably,but its very heavyweight
<avsm>
i'm guessing this is why mkdir isnt already bound ;)
<gildor>
avsm: just have a look in the ocaml source
<gildor>
avsm: no use to detach
<gildor>
there is not non-blocking sections
<gildor>
so in this case, I must run an external process
<gildor>
so I suppose, the solution I pick is ok
<avsm>
thats horrible
<avsm>
just call the syscall...
<avsm>
a whole process just to mkdir is not great
<gildor>
indeed
<avsm>
traditionally, i guess disk-level blocking isnt considered blocking
<avsm>
i wonder what pthread does if a single mkdir blocks on a stale nfs mount. probably just hangs everything
<gildor>
I think that they consider FS metadata manipulation as non-blocking
<gildor>
(after all creating a directory should be mostly metadata manipulation wrt as creating a file and its content)
<gildor>
so the probability to block mkdir is << than to create a file
barismetin has quit [Remote host closed the connection]
travisbrady has joined #ocaml
avsm has quit [Quit: Leaving.]
qwr has joined #ocaml
barismetin has joined #ocaml
|marius| has joined #ocaml
barismetin has quit [Remote host closed the connection]
barismetin has joined #ocaml
ygrek has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
|marius| has quit [Remote host closed the connection]
nejimban has quit [Ping timeout: 240 seconds]
th5 has quit [Quit: th5]
nejimban has joined #ocaml
chee1 has joined #ocaml
chee1 has quit [Changing host]
chee1 has joined #ocaml
chee1 is now known as chee
joewilliams is now known as joewilliams_away
ygrek has quit [Ping timeout: 245 seconds]
Anarchos has joined #ocaml
ftrvxmtrx has joined #ocaml
barismetin has quit [Remote host closed the connection]
|marius| has joined #ocaml
|marius| has quit [Remote host closed the connection]
|marius| has joined #ocaml
|marius| has quit [Remote host closed the connection]
|marius| has joined #ocaml
philtor has joined #ocaml
sepp2k has joined #ocaml
philtor has quit [Ping timeout: 260 seconds]
joewilliams_away is now known as joewilliams
ygrek has joined #ocaml
<dark>
if inside an object i can mark a variable mutable and do x <- x + y., why can't i mark a variable mutable outside an object?
<dark>
and just do the same
<dark>
i suppose this has something to do with the type system, but i can see completely
<dark>
the thing is, if you return x, the caller can't do x <- y, because the caller does not know x is "mutable"
<dark>
mutability is a concept kept only inside a class. maybe it simplify some analysis?
<dark>
couldn't mutability be kept across the whole type system?
<dark>
it seems that a function or method can't accept a mutable parameter and handle with its mutability
<dark>
if they accepted, mutable int vs. int would be just like C++'s int vs. const int, and the compiler would need to do this analysis
<dark>
so a method can change a mutable member, but this doesn't mess with the type system
<dark>
because there is no "free" mutability created and returned, all mutability is "static"
<flux>
dark, what's wrong with ref?
<dark>
i think one could have the function let f x = x <- 1 with type mutable int -> void. and i could do print_int (let mutable x = 0 in f x; x + 2), it would print 3
<dark>
flux, nothing, but if ref has nothing wrong, why to have mutable values in objects?
<flux>
no idea
<dark>
... but if mutable values in objects are a win, why not to let you do high-order mutability with them?
<dark>
i mean, pass a mutable to a function and handle mutability there
<flux>
btw, also records allow for mutable fields
<dark>
yes, but i can't pass x.contents to a function and expect it to be able to change it
<dark>
i have to pass x
<flux>
it might be that if ocaml were to have plain mutable values, they would nede to be handled similarly to 'ref'
<dark>
btw bitC try to do this (having x itself mutable, and dealing with this with a more complex type system)
<flux>
in other words, maybe minor heap is assumed to be immutable?
<dark>
hmmm? this is a concept i don't understand
<dark>
minor heap/
<flux>
the things that make gc work
<dark>
hmm
<dark>
bitC is having problems with the type of functions like map, they explode in complexity for some tasks
<dark>
but i don't know if this is related to this kind of mutability
ygrek has quit [Ping timeout: 245 seconds]
Yoric has joined #ocaml
<qwr>
dark: i think that no mutable bindings is mostly for simplification of the language
<qwr>
dark: it is possible to have them in a language with ml-like typesystem
<qwr>
dark: although it makes the language "unclean" in some ways
<dark>
flux, a function that receives 'a can receive int; a function that receives int can receive mutable int
<qwr>
dark: but they don't have special types
<dark>
so int is kind like a quantification, that also matches the mutable version
<dark>
special types, qwr
<dark>
?
<flux>
dark, it's not really a coercion in my mind. the function has no idea what it has received.
<flux>
dark, how about: let f (a : int) (b : mutable int) = assert (b = a); b <- b + 1; assert (b = a + 1); in let a : mutable int = 5 in f a a ?
<qwr>
dark: variable mutability isn't directly visible in yeti type-system
<dark>
flux, interesting
<dark>
flux, i suppose the compiler has to copy the first a
<qwr>
dark: basically, it's property of the binding there, not property of the value
<dark>
because f doesn't expect a to be mutable
<dark>
qwr, hmm
<flux>
dark, how would it know to do that?
<flux>
dark, it might get both a and b from another, separately compiled, module
<dark>
flux, in the degenerate case where you don't know i think you must copy
<flux>
dark, or do you mean to do that always when coercing?
<qwr>
dark: automatic coercions interact really bad with type inference
<dark>
no, just when you can't prove it doesn't do anything wrong
<dark>
you need some theorems to do the easy checks..
<dark>
i saw some things on bitc mailing list about this: type inference + first class mutability
<dark>
and this was their biggest problem
<dark>
(something to do with "region analysis", but i haven't understood those things yet)
joewilliams is now known as joewilliams_away
<qwr>
dark: say you have expression (a x)
<qwr>
dark: where type of x may be coerced
<qwr>
dark: now you but into function f x = a x;
<qwr>
dark: what is the type of x and f ?
<qwr>
dark: especially f, as inside of it the type of x is obviously 'a
<qwr>
dark: and attempting to special-case it will end up in a gigantic hack, afaik
<qwr>
dark: but you can mutable bindings without coercing anything and keep some sanity
<qwr>
can have
dark has quit [Ping timeout: 265 seconds]
<qwr>
only thing is, that there isn't really a need for those in ocaml. ref works as well.
ulfdoz has joined #ocaml
joewilliams_away is now known as joewilliams
dark has joined #ocaml
ygrek has joined #ocaml
ftrvxmtrx has quit [Ping timeout: 264 seconds]
dskippy has joined #ocaml
<dskippy>
I am having a simple problem running an example from ocaml-shout. I installed ocaml-shout using apt get, and also got the source from savonet. Now I am trying to run the examples from the source and getting "Error: Unbound value Shout.init" This is my command line: ocaml /usr/lib/ocaml/shout/shout.cma examples/shoutfile.ml
<adrien>
dskippy: you should do something like: ocamlfind ocamlc -packages shout examples/shoutfile.ml
<adrien>
it'll create an executable (a.out)
ftrvxmtrx has joined #ocaml
<adrien>
ocamlfind makes it easier to run/compile things (I think you're missing an '-I' entry on your command-line) and it's always a good idea to use it
<adrien>
if absolutely need, you can use ocamlfind's "query" feature to get all the arguments if absolutely needed
<dskippy>
adrien: Thanks, I'm going to try that. I'm really new to OCaml, especially compiling stuff. I might have a really uninformed question in two seconds.
<adrien>
hmmm, must be a typo or a small error in what I gave you but I don't have shout (yet) so I can't tell you right now
ulfdoz has quit [Ping timeout: 276 seconds]
<dskippy>
But that's how you normally compile stuff that requires installed, compiled, shared libraries?
<dskippy>
Kind of like pkg-config for C compilation?
<adrien>
yup :-)
<adrien>
well, I can't tell you so try: ocamlfind list | grep -i shout
<adrien>
that'll give you the exact name of the package
dark has joined #ocaml
<adrien>
and are you sure you have the '-dev' package on your system,
<adrien>
?
<dskippy>
I have the dev package for sure.
<dskippy>
That command gives me back "shout (version: 0.2.6)"
<adrien>
no, stupid me: add '-linkpkg' when calling ocamlfind
<adrien>
it's simply compiling and linking in one call, so you need -linkpkg
pheredhel has joined #ocaml
<dskippy>
Oh that works, adrien, thank you!
<adrien>
^^
<adrien>
btw, for more complex builds, there are "quite" automated systems like omake, ocamlbuild, ocamlmakefile and probably one or two I've forgotten
philtor has quit [Ping timeout: 246 seconds]
<dskippy>
adrien: What are the majority of people using?
<dskippy>
Do you have a favorite?
<adrien>
(forgot to mention the regular configure+makefile+autotools)
<adrien>
ocamlbuild is used more and more, among others it comes with ocaml
<adrien>
omake is nice and works well but I haven't really used it
<adrien>
ocamlmakefile is a big makefile for which you set a few variables and does the rest "automatically"
<adrien>
(it's possible to easily figure out dependencies between files/modules when compiling ocaml, and these three take advantage of that)
<dskippy>
Awesome. Thanks so much. I'll look into using one of them.
<adrien>
:-)
<dskippy>
Do you, or anyone, have an recommendations for books or web sites on learning OCaml for someone who's programmed a long time, knows Scheme, Haskell, Lisp, Python, C, etc, and is about to write a large project in OCaml?
<dskippy>
(hypothetically speaking of course. :) )
Yoric has joined #ocaml
<dark>
there is some excellent book at caml.inria.fr
<dark>
there is a section on "resources
<dark>
there, there is the manual, the library reference, and books
<dark>
also tutorials
<dark>
dskippy, there are a tutorial aimed for java/c++/c programmers at ocaml-tutorial.org
<dskippy>
Cool. Thanks.
<dark>
but it's rather basic
dark has quit [Ping timeout: 265 seconds]
Yoric has quit [Quit: Yoric]
sepp2k has quit [Quit: Leaving.]
jakedouglas has quit [Quit: Leaving.]
ygrek has quit [Ping timeout: 245 seconds]
Anarchos has quit [Ping timeout: 252 seconds]
Yoric has joined #ocaml
valross has joined #ocaml
Yoric has quit [Client Quit]
dskippy has quit [Quit: Leaving.]
valross has quit [Remote host closed the connection]
dark has joined #ocaml
jakedouglas has joined #ocaml
philtor has joined #ocaml
philtor has quit [Ping timeout: 240 seconds]
valross has joined #ocaml
marteo has quit [Quit: Debian GNU/Hurd is Good.]
jakedouglas has quit [Quit: Leaving.]
jakedouglas has joined #ocaml
liftM has joined #ocaml
<liftM>
Am I right that physical equality (==) is always translated by the ocaml compiler into a single pointer comparison?
<dark>
# [1, 2] == [1, 2];;
<dark>
- : bool = false
<dark>
liftM, looks like
<qwr>
dark: its because you construct list here
<dark>
i mean, it looks like it's just a pointer comparison
<qwr>
dark: for primitive types it behavies the same as = afaik
<dark>
hmm
<qwr>
e1 == e2 tests for physical equality of e1 and e2. On integers and characters, physical equality is identical to structural equality. On mutable structures, e1 == e2 is true if and only if physical modification of e1 also affects e2. On non-mutable structures, the behavior of (==) is implementation-dependent; however, it is guaranteed that e1 == e2 implies compare e1 e2 = 0.
<qwr>
(from the doc)
<dark>
so he asked what the current implementation effectively does
<dark>
i think
<dark>
but the "always" maybe means "required by the specs" so i think it's no, it's implementation-dependent
<qwr>
i think the compiler probably implements it using pointer value comparision...