flux changed the topic of #ocaml to: Yes, inria.fr is back up! | Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.0beta1 available from http://caml.inria.fr/pub/distrib/ocaml-3.11/ | Or grab OCaml 3.10.2 from http://caml.inria.fr/ocaml/release.html
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
willb1 has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
sysfault has joined #ocaml
sysfault has left #ocaml []
sysfault has joined #ocaml
sysfault has left #ocaml []
thelema has quit [Read error: 110 (Connection timed out)]
sporkmonger_ has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has quit ["Leaving"]
hkBst has quit [Read error: 104 (Connection reset by peer)]
sporkmonger has joined #ocaml
<mbishop> Mmm
<mbishop> new batteries look nice
munga_ has quit [Read error: 113 (No route to host)]
<mbishop> Anyone got a list of the combinators in the new batteries?
marmotine has quit ["mv marmotine Laurie"]
ulfdoz has quit [Read error: 113 (No route to host)]
tvn1981_0 has joined #ocaml
thelema has joined #ocaml
psnively has quit []
dabd has quit ["Ex-Chat"]
<mbishop> mfp: thanks
<thelema> more people testing batteries?
<hcarty> thelema: This release is a bit more attractive than the last, with a selection of examples and better documentation to go along with it
<hcarty> And it /has/ to be good if it takes 15 minutes to build :-)
<hcarty> Batteries is looking very nice at this point and seems to have a promising roadmap. Thanks to those involved.
<thelema> heh. just the documentation takes 15 minutes.
<thelema> it's frickin' awesome.
<hcarty> The documentation is an impressive (ab)use of ocamldoc
<thelema> thank yoric for that. I'll admit its impressiveness.
<mbishop> I haven't even gotten it installed yet
<mbishop> installed godi, but it's erroring on the second bootstrap
<mbishop> Error: Package godi-ocamlnet replaces previous godi-equeue, but the latter is still installed. Remove godi-equeue first!
<mbishop> got a whole bunch of messages like that, but I have no idea how to remove them...running 'godi_console' tells me it's just a bootstrap version
<hcarty> mbishop: Did you set your $PATH appropriately?
<mbishop> yes
<mbishop> it tries to install godi-ocamlnet but complains about a whole bunch of other godi packages that it replaces
<mbishop> So...know any way for me to remove the ones it's asking to remove?
<mbishop> the readme says there should be godi_delete, but there isn't
<mbishop> I think I'll uninstall godi and wait for a debian/ubuntu package for batteries :)
<thelema> yes, we really do need that. I insisted on a one-command install of batteries, but was told that people'll just use package managers for dependencies.
* thelema doesn't use package managers for ocaml stuff.
<thelema> I install ocaml, then bin-prot, camlzip, camomile, findlib, lablgtk2, sexplib and type-conv (not in that order)
tvn1981_0 has quit ["Leaving"]
<mbishop> I use apt for ocaml and it's libraries, usually
<mbishop> and I agree it would be nice to have a single command to install what is needed (and in the right places)
<mbishop> I've never used godi before, and hope I don't have to again heh
<doy> so i'm trying to do stuff with lablgtk
<doy> and i have an event
<doy> it's a button_press event
<doy> and i want to only get `BUTTON_PRESS Gdk.event things, not `TWO_BUTTON_PRESS Gdk.event things
<doy> but i can't find any way to get that out of the event that i receive
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
<doy> aha, found it
jknick has joined #ocaml
Palace_Chan has joined #ocaml
Palace_Chan has quit [Client Quit]
threeve has quit []
Palace_Chan has joined #ocaml
Jedai has joined #ocaml
|Jedai| has quit [Read error: 110 (Connection timed out)]
bohanlon has quit [Remote closed the connection]
<det> Will installing godi-batteries give me alpha 2 ?
kg4qxk has joined #ocaml
<thelema> det: pretty likely yes, but I don't use godi
Palace_Chan has quit ["Palace goes to sleep"]
sporkmonger has quit []
apples` has quit ["Leaving"]
jeddhaberstro has quit []
jknick has quit [kornbluth.freenode.net irc.freenode.net]
mbishop has quit [kornbluth.freenode.net irc.freenode.net]
snhmib has quit [kornbluth.freenode.net irc.freenode.net]
BSWolf has quit [kornbluth.freenode.net irc.freenode.net]
lorph has quit [kornbluth.freenode.net irc.freenode.net]
ecc has quit [kornbluth.freenode.net irc.freenode.net]
authentic has quit [kornbluth.freenode.net irc.freenode.net]
jknick has joined #ocaml
authentic has joined #ocaml
lorph has joined #ocaml
Mr_Awesome has joined #ocaml
snhmib has joined #ocaml
BSWolf has joined #ocaml
ecc has joined #ocaml
mbishop has joined #ocaml
ecc has quit [Read error: 60 (Operation timed out)]
ecc has joined #ocaml
det has quit [Remote closed the connection]
Guest37031 is now known as tp76
det has joined #ocaml
ulfdoz has joined #ocaml
velco has joined #ocaml
filp has joined #ocaml
mishok13 has joined #ocaml
Camarade_Tux has joined #ocaml
Kerris0 has joined #ocaml
velco has quit ["Ex-Chat"]
rwmjones_ has joined #ocaml
_zack has joined #ocaml
seafood has joined #ocaml
munga_ has joined #ocaml
velco has joined #ocaml
seafood has quit [kornbluth.freenode.net irc.freenode.net]
Camarade_Tux has quit [kornbluth.freenode.net irc.freenode.net]
munga_ has quit ["Ex-Chat"]
seafood has joined #ocaml
Camarade_Tux has joined #ocaml
Kerris0 has quit [Read error: 113 (No route to host)]
jknick has quit ["leaving"]
code17 has joined #ocaml
Kerris0 has joined #ocaml
kattla has joined #ocaml
marmotine has joined #ocaml
Snark has joined #ocaml
rwmjones_ has quit ["Closed connection"]
Kerris0 has left #ocaml []
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
<Yoric[DT]> Gasp, my post on Batteries Included has disappeared and has been replaced by a political rant (of mine).
marmotine has quit [Read error: 113 (No route to host)]
<Yoric[DT]> Ok, rewritten.
marmotine has joined #ocaml
marmotine has quit [Read error: 104 (Connection reset by peer)]
marmotine has joined #ocaml
marmotine has quit [Read error: 54 (Connection reset by peer)]
marmotine has joined #ocaml
<flux> I take it val unique : unit -> int is thread-safe?
<flux> I would like to see companion unique' or unique64, it is not unforeseeable that unique will eventually end up either failing or returning duplicate identifiers. with Int64 that's much less likely :)
<mfp> it isn't
<mfp> just incr counter; !counter
<Yoric[DT]> flux: not thread-safe yet.
<flux> that should be mentioned in the interface then
<mfp> (<|) is left-associative, doesn't that make it essentially useless?
<mfp> f <| g <| x is not equivalent to the symmetric x |> f |> g
<Yoric[DT]> mfp: that's a problem, I grant you.
<mfp> *symmetric
<Yoric[DT]> If you have a better alternative, please submit it.
<Yoric[DT]> For the moment, I'm thinking about using Camlp4 to change the associativity of this operator.
<mfp> either using an operator starting with ^, @ or **, or camlp4, yep
Kerris0 has joined #ocaml
<Yoric[DT]> I guess we could use *>* and *<*
<mfp> ah regarding operators
<mfp> wouldn't pa_do be a nice addition?
<Yoric[DT]> Yes, at some point.
<Yoric[DT]> Not just quite yet, but that's bound to happen.
<mfp> batteries.syntax could use it to change the associativity of (<|), probably easier than special-casing it manually
<Camarade_Tux> *<* and *>* aren't so nice to type
<Yoric[DT]> That's the problem.
<mfp> *<*? where's that from, the parser combinator lib?
<mfp> s/lib/module/
<Yoric[DT]> Well, placed in the TODO list.
<mfp> ah, so the rule is *[whatever]* = right-assoc?
<Yoric[DT]> No, it's a suggestion for replacement.
<Yoric[DT]> Yeah.
<Yoric[DT]> iirc
<Yoric[DT]> Actually, iirc *[whatever] is right-assoc.
<Camarade_Tux> if only *[whatever] is needed, that's much easier to type for me
<Camarade_Tux> anyone on a qwerty ?
<_zack> Yoric[DT]: I think yesterday we have concluded that config.ml generation can be done via ./configure, right?
<Yoric[DT]> _zack: No.
<Yoric[DT]> Camarade_Tux: me
<Yoric[DT]> _zack: since, when installing as a GODI package, we detect GODI only in Makefile.
<mfp> the rule seems to be **…, not *…*
<_zack> ah, right
<Yoric[DT]> Gasp.
<Yoric[DT]> Well, the Camlp4 solution is probably better.
<_zack> it is really annoying that GODI does not easily permit to pass ./configure flags
<Yoric[DT]> _zack: well, technically, it's feasible.
<Yoric[DT]> It's just that to do that, we need to write the whole package manually, rather than using package assistant godiva.
<_zack> well, ok, then I think I've a feature request for godiva ;)
<Yoric[DT]> Yes.
<Yoric[DT]> mfp: so this could be **< and >**
<Yoric[DT]> Not very nice.
<Yoric[DT]> **- and -**
<mfp> yes, the only pb is that is so much uglier than |> <|, camlp4 is looking better...
<Yoric[DT]> Yeah, camlp4.
<Yoric[DT]> I'll try not to work on Batteries today.
<Yoric[DT]> Deadlines calling.
<flux> ahh.. the luring sound of a deadline..
<Camarade_Tux> hmmm too, stupid work for tomorrow... =/
vixey has joined #ocaml
bluestorm has joined #ocaml
<bluestorm> Yoric[DT]: in case you're interested, http://bluestorm.info/camlp4/dev/try/pa_tryfinally.ml.html
<bluestorm> that's a first draft, i'll add some documentation, tests, and it's not yet variable-capture-proof
<bluestorm> s/in let result/and result/
<flux> wouldn't using regular variants be slightly faster?
<bluestorm> flux: i should declare them, wich means local module and unknown performance costs
<flux> bluestorm, well, I'm thinking a global transformation would be ok too
<flux> or even requiring a library to be used
<bluestorm> isn't that overkill ?
<flux> batteries might actually have related types already?
<bluestorm> hm, i'll investigate
<bluestorm> i think the current solution is an acceptable compromise between performance and readability
<bluestorm> but you're right, i could use an Either-like type from battery
<bluestorm> hm
<bluestorm> but then i'd have to be careful not to introduce cycles in batteries compilation (some of the batteries modules may depend on this extension in the future)
<bluestorm> flux: do you see any isssue with variable capture ?
<bluestorm> the code i draw from is http://caml.inria.fr/pub/ml-archives/caml-list/2007/07/a61dd3d3d5414b06c5f084dc7fb2bbaa.en.html , wich does not bind anything (so no capture possible) but is quite unreadable
<bluestorm> i think users should be able to read the postprocessed code for simple extensions
<flux> surely it will fail if I use let after () = 42 in try let a = final () finally ..
<flux> should be simple enough to use generated ids?
<bluestorm> hm
<bluestorm> i don't think it will fail
<bluestorm> (i don't like generated ids)
<flux> how will it not fail?-o
<bluestorm> hm
<flux> if the example is correct
<flux> uh
<flux> I meant obviously try let a = after () finally ..
<flux> how would one call a user function called 'after' from within the try .. finally -block/
<bluestorm> well
<bluestorm> my first version used "let after ... in let result = ... in"
<flux> ah, I misparsed
<bluestorm> but i noticed the issue and changed (about 2 second after releasing on the chan) to an "and" wich i think should handle that
<flux> indeed, it doesn't cause a problem :)
<bluestorm> i should add a comment on the issue, though
<bluestorm> it tends to be error-prone and gives headaches to check
<bluestorm> hm, lunch time
<bluestorm> hopefully i'll bug you with the "let try ..." extension this afternoon :)
seafood has quit []
* _zack is preparing debian packages of batteries alpha 2
<_zack> but I'm still fighting with the docpath, even though config.ml is right, #help looks for them in the wrong place
Kerris0 has quit ["Leaving."]
willb1 has quit ["Leaving"]
munga has joined #ocaml
<_zack> Yoric[DT]: any reason why batteries top.ml is executable?
<_zack> it was just an heisenbug
vixey has quit [Remote closed the connection]
<det> I've noticed that debian packages for camlzip and lablgtk differ greatly in their META file than GODI's
munga has quit ["Coyote finally caught me"]
munga has joined #ocaml
<det> To the point that your build infrastructure must target one or the other
<det> for example, lablgtk2 in godi links in gtkInit.cmx and gtkThread.cmx by default, whereas the Debian packages dont link in anything other than the cmxa
<det> Also, the zip package is called camlzip in GODi and zip in Debian
<flux> I find it a bit redundant to call packages caml-foo or ocaml-bar ;)
<flux> but otoh, the package might be well known with its full name
gene9 has joined #ocaml
<det> # 50 -- 55 |> List.of_enum;;
<det> - : int list = [51; 52; 53; 54; 55; 56]
<det> off-by-1 bug ?
<flux> what does 55 -- 50 |> List.of_enum give?
<det> empty list
<flux> but in any case, looks like a bug
<flux> or atleast very unexpected behavior!
<det> I'm really impressed with the integration of Libraries in Batteries
<det> like using Generic IO and Enum types all over the place
<Camarade_Tux> I can't believe it either :)
<Yoric[DT]> _zack: no good reason, no.
<Yoric[DT]> det: yes, I've just fixed that bug.
itewsh has joined #ocaml
<Yoric[DT]> (if you wish to fix it for yourself, it's in [Enum.seq])
<det> Btw, was it a conscience decision to use raise and exception style instead of return an option style ?
<_zack> Yoric[DT]: other minor point, isn't documentation_root inconsistently used in batteries_help.ml? we look for docroot ^ toplevel.help and for docroot ^ doc/batteries/...
* Yoric[DT] returns to deadline mode and stops answering questions on Batteries :)
<det> conscious*
<_zack> Yoric[DT]: ah, oops, /me didn't know
<_zack> I'll post on the ML then
<det> Yoric[DT], I'll leave you alone then :-)
Axle has joined #ocaml
sporkmonger has joined #ocaml
<hcarty> bluestorm: Yoric[DT] said you are the one to talk to regarding camlp4 + Batteries. I have some patches for pa-do which add ocamlbuild support and expand the META file a bit if/when you integrate pa-do.
<hcarty> The patches also make the extension work properly with a (patched) 3.10.2 toplevel or a 3.11.0 toplevel which already has several camlp4 + toplevel bugs fixed
<hcarty> I'm planning on submitting the patches upstream some time in the next few days
<bluestorm> hcarty: hm, what's the link between batteries and pa-do ?
willb has joined #ocaml
purple has joined #ocaml
itewsh has quit [Read error: 60 (Operation timed out)]
vixey has joined #ocaml
tp76 has quit ["ERC Version 5.2 (IRC client for Emacs)"]
<det> Is it necessary to "Open Batteries" and "Open Batteries.Standard" in every source file of a batteries using project ?
<ertai> Yoric[DT]: hi
<Yoric[DT]> det: no, see examples/
<ertai> I'm looking at the new release of batteries and looked at combinators in Standard
<det> ahh, using the ocamlbuild tagging system
<ertai> currently first is: let first f x = fst (f x)
<Yoric[DT]> hi, talk to you later, deadline mode.
<ertai> I was expecting let first f (x, y) = (f x, y)
<ertai> Yoric[DT]: ok
<ertai> Although my message is there!
<Yoric[DT]> :)
<vixey> can you write it like first f = fst "compose" f
<vixey> ?
<vixey> let first f = fst o f
<kattla> yes
<kattla> is there a compose in Batteries?
<kattla> i think ertai's version of first seems more usefull
<det> there is compose in Batteries, see Standard module
<vixey> det, is it an infix operator?
<det> yes
<kattla> hm, (***) and (&&&) seems very nice ^^
<vixey> oh my god that is so ugly
<det> # let f = open_in |- System.IO.read_all;;
<det> val f : string -> string = <fun>
<vixey> why are you using |- ?
<det> what would you prefer ?
<vixey> o
<det> o can't be defined except using camlp4
<vixey> *** and &&& are actually useful ?
<det> and even then it will cause syntax errors when using "o" as an indentifier
<vixey> why is this batteries thing using haskell names for things
gene9 has quit ["Leaving"]
<det> What is wrong with the names it is using ?
<vixey> this is dumb
<_zack> vixey: also it is not using haskell names on purpose
<vixey> half this crap is in the ocaml std library
<_zack> the ones which were found useful have been reused, the others have not
<kattla> vixey: i think that is the point
<kattla> (to extend the std library)
<det> The point of it is the replace the standard library, so of course there will be some overlap
<vixey> I really think this is completely stupid
<vixey> I do not want to use any language that has |- as the compose operator
<_zack> vixey: you haven't provided much of arguments thus far ...
<vixey> and haskell names like &&& and *** are a terrible choice
<kattla> i think the only nice alternatives to |- are using unicode, which is not possible with ocaml
<vixey> is there any document from batteries describing what is wrong with the current std library?
<det> Suddenly I don't feel like responding to you any longer
* Camarade_Tux wonders why nobody wants Þ :'(
<vixey> det, then please don't. I don't care if you want to talk to me or not. I don't know why you are telling me that
<_zack> vixey: because you seemed a bit troll-ish
<vixey> _zack, if you missed my previous comment, I don't care
<_zack> vixey: anyhow, the problem with the stdlib is that it is terribly limited
<Camarade_Tux> vixey, there's nothing wrong with gallium's lib, it does what it does perfectly, batteries aims at being more complete
<_zack> that anybody reimplement (variations of) the very same basic functions missing in the stdlib
<_zack> indeed, complete, consisted, and documented
<vixey> I don't see why that can't be done by writing a new extension library instead of replacing what's already there
<Camarade_Tux> and with the common IO interface \o
<Camarade_Tux> /
<vixey> -- batteries project doesn't release a document describing motivations?
<Camarade_Tux> vixey, it's not replacing,
<_zack> vixey: by adding only you can address incompleteness, but not inconsistencies
<_zack> vixey: yes, RTFM
<Camarade_Tux> _zack, it doesn't replace *really stdlib right ?
<Camarade_Tux> s/replace *really/*really* replace/
<_zack> Camarade_Tux: it does not, everything legacy is still available under Legacy
<Camarade_Tux> _zack, ok, as I had understood, thanks :)
<_zack> moreover, most of the Ext* modules mirror "legacy" modules adding new functions
<vixey> Author(s): Xavier Leroy (Base module), Nicolas Cannasse, David Teller, Zheng Li
<vixey> ahaha
<_zack> though in some cases you have type changes, like in_channel vs input
<vixey> Xavier Leroy isn't writing this batteries thing
<_zack> ok, I'll stop feeding the troll
<_zack> vixey: *plonk*
<vixey> _zack, hint, complaining about trolls and all this whining is actually not improving the situation
<Camarade_Tux> vixey, batteries is not reimplementing *absolutely everything* from scratch, hence Xavier Leroy being named
<vixey> Camarade_Tux: yes, that, to me, looks like name dropping to try and steal some credibility
<Yoric[DT]> Well, we're reusing part of the .mli .
<Yoric[DT]> Sounds coherent to cite the author of the .mli .
<_zack> Yoric[DT]: more than coherent, it is mandatory for copyright reasons
<vixey> Yoric[DT]: this section 'Fundamental functions and operators' is really awful
<Camarade_Tux> vixey, I can assure you batteries doesn't need more credibility, there are really a lot of people interested in this project
<vixey> |> is some F# thing
<vixey> |- looks like a turnstile, makes no sense for function composition
<vixey> *** and &&& are silly names
<Smerdyakov> I have to agree that |- is a horrible composition operator choice, for a language that was invented to be used in a proof assistant.
<Smerdyakov> |- means something completely different in that proof assistant (Coq).
<vixey> huh ? I thought ocaml was for LCF not Coq
<_zack> Smerdyakov: that's true, the point of that (I guess) is to clear the long standing issue of "direction" of function composition
<_zack> hence batteries have both |- and -|
<_zack> Smerdyakov: do you have any better suggestion? (which is not a rhetoric question)
<Smerdyakov> vixey, well, then I guess you thought wrong!
<vixey> aw.....
<Smerdyakov> _zack, no.
<_zack> I mean, I've used happily <*> for function composition in some ocaml projects
<Smerdyakov> If I actually used OCaml anymore, I might make an effort to think of an alternative. :)
<_zack> but I acknowledge that I've fixed one of the two possible composition operators
<_zack> how to provide both of them with meaningful symbols is not evident at all
<_zack> Smerdyakov: pretty please :)
<det> Smerdyakov, What do you use in its place? SML? Your pet language ?
<flux> well, o wouldn't be that bad, except it requires camlp4
<Smerdyakov> det, both.
<flux> also it might break some code but batteries does that anyway, right?
<Yoric[DT]> Smerdyakov: vixey: feel free to suggest other operators, we have a Feature Request tracker for this purpose.
<vixey> flux, does ocaml have something against unicode syntax?
<flux> vixey, I don't know, but I like to be able to enter code without special magic
<det> o is a bad idea IMO
<vixey> Yoric[DT]: I have a whole set of tuple operations but they are all unicode
<flux> det, well, SML uses it ;)
<det> # let mod _ = ();;
<det> Syntax error
* Camarade_Tux thinks using o is asking for problems
<det> I don't want another anomaly like that
<vixey> Yoric[DT]: I'm curious how |> got in there though
<vixey> Yoric[DT]: is it some F# user that suggested it ?
<mfp> · (ISO 8859-1 0xB7 MIDDLE DOT) would be nice
<_zack> mfp: that does not solve the problem of the direction of composition
<vixey> mfp, I prefer a ring but yeah
<vixey> _zack, you probably have me on ignore but incase you don't, this is not a problem
<flux> yes, use something that's difficult to write, that must be popular ;)
<Camarade_Tux> ... how do I type a middle dot ?
<mfp> _zack: that would be for uh -| only
<flux> camarade_tux, simply press compose . .
<mfp> on my kb, it's shift + 3
<Camarade_Tux> nope, not available to me
<Camarade_Tux> and that will probably help a lot for ocaml on windows...
<mfp> there's also ° DEGREE SIGN 0xB0
<mfp> (azerty sucks)
<vixey> I use that for a different meaning
<_zack> mfp: and why not for |-
<Camarade_Tux> ° doesn't work in ocaml
<Camarade_Tux> Illegal character (°)
<_zack> I mean, maybe having just one is ok as long as it is documented, but I'm not really convinced ...
<flux> |> looks pretty decent to me, even if it did originate from F#
<Camarade_Tux> I agree with flux
<vixey> flux, what about a program written like x |> h |> g |> f ?
<Smerdyakov> I agree, too.
<flux> in my books it's better to use something someone else has used earlier, unless there is a real reason why it's worse
<flux> vixey, what about it?
<mfp> _zack: because o, which is sort of looks like, is -|, but with right-associativity
<_zack> flux: I like it, but you sure it originated from F#? doesn't haskell have the same?
<flux> _zack, it uses .
<vixey> flux, It's only me that doesn't think of functional programming like input |> ... |> output ??
<Camarade_Tux> and I think we got |> because of *our own* troll whose name I'll let you guess ;)
<mfp> |> is IMO the least objectionable of the ops (I use it myself sometimes)
<vixey> I don't have anything against other people using it .. but putting into a standard library? Very odd...
<mfp> there's the arity problem with the others, but |> works fine and doen't look bad
<mfp> *doesn't
<Camarade_Tux> vixey, but nothing forces, or even push you to use it
<vixey> mfp, what do you mean arity problem?
<mfp> oops, I meant associativity
<det> Haskell-esque functions as infix syntax might be kind of nice, too: let o f g x = g (f x) and then let f = open_in `o` System.IO.read_all
<vixey> mfp, I don't understand... (f compose g) compose h = f compose (g compose h)
<Camarade_Tux> det, the problem is ` can't be used
<mfp> vixey: x |> f |> g is g (f x), but g <| f <| x isn't --- it's (g f) x
<vixey> mfp, ah yes, .. this is one of the reasons that |> is a terrible idea
<mfp> same problem with |- and -|
<vixey> |- and -| are bad names
<vixey> they should not be replaced with something better.. they should be removed
<mfp> it's an argument against the current (<|), but not against a fixed one using camlp4
<vixey> I'm surprised you can't define right associative operators
<mfp> ^..., @... and **... are
<vixey> why can't <| be+
<vixey> ?
<bluestorm> mfp: i don't think we should change the associativity using pa-do or something
<bluestorm> that would confuse people
threeve has joined #ocaml
<_zack> bluestorm: ack
<bluestorm> for my own code i used >^ for application and >| for composition
<vixey> bluestorm, why did you choose >| ?
<bluestorm> because of >^
<mfp> >^ for application? don't you need a right-associative operator for it?
<Smerdyakov> Application is left-associative.
<vixey> so you write x >^ f rather than f x ?
<bluestorm> well x >^ f and f ^< x
<mfp> I use (@@) f x = f x sometimes
<vixey> why ?
Kerris4 has joined #ocaml
<bluestorm> vixey: the use of ^< is the same as Haskell's ($)
<bluestorm> you can remove parenthesis
<vixey> ok, I don't understand why anybody would want to take these haskell idioms (and silly names) into ocaml though
<mfp> Smerdyakov: that's the very point of having a right-associative operator for application, because it's left-associative by default
<vixey> but ($) is a valid operator in haskell too?
<olegfink> I'm used to left-associative (>>) x f = f x
<vixey> I mean why not use ($) in ocaml
<bluestorm> i guess so but ($) in ocaml is left-associative
<vixey> ohh
<bluestorm> and for application you want something right-associative
<vixey> the associativity of an operator is predetermined
<bluestorm> yes
<bluestorm> from the first character of the operator
<vixey> this is awful
<bluestorm> hence the "^" of ^<
<bluestorm> hm
<vixey> why not add fixity declarations to ocaml?
<bluestorm> you may find it awful but it's actually more meaningful than this "infixr 7 $" haskell thing
<bluestorm> imho
<bluestorm> vixey: pa-do is a syntax extension that essentially do that
<_zack> bluestorm: I disagree, I think it was just a hackish way of avoiding to implement something more expressive
<olegfink> why should application be right-associative?
<mfp> pa_do's concrete syntax is better IMO INFIX subset LEVEL ( && )
<_zack> still, right now people got used to that, that's why we can't change just a single op, IMO
<vixey> bluestorm, but people seem to be afraid of confusing others by using this tool 'pa_do' so is pa_do unsuitable?
<olegfink> composition has its reason, but application?
<vixey> I can't understand who would find x |> h |> g |> f more clear than f (g (h x))
<vixey> maybe if they were a BASIC programmer or something
<mfp> olegfink: fewer parentheses f (g (h x)) vs. f $ g $ h x in Haskell
<Kerris4> vixey: people used to UNIX pipes would find that intuitive
<vixey> mfp, only newbies write f $ g $ h x though
<bluestorm> Kerris4: and if you expand your expression on multiple lines, it's easier to indent coherently
<olegfink> mfp: vs. x >> h >> g >> f which is what I usually do. I'm used to left-to-right reading.
<mfp> vixey: well, because there's .
<vixey> Kerris4, I suppose I see what you mean, I think that UNIX pipes work so differently that it is harmful to use anything analoguous
<vixey> Kerris4, (this is why I did not like the thing |> in F#)
<vixey> Kerris4, (and it is a shame to see it be taken up by other languages)
<Kerris4> vixey: it's used in other languages too?
<vixey> Kerris4, ocaml
<Kerris4> oh. :x
<Yoric[DT]> Well, it's still time to drop it from Batteries if you a good alternative is suggested.
<vixey> yeah :/
<vixey> Yoric[DT]: I think removing it is a good idea but adding in an alternative would be bad again
<bluestorm> olegfink: f << g << h << x wouldn't work because of the associativity : ((f g) h) x isn't usually what you expect
<vixey> Yoric[DT]: Although my opinion shouldn't matter much since I don't start new programs in ocaml
<olegfink> why do you insist on right-to-left order?
<vixey> bluestorm, is that easier to read, reason about, anything? than f (g (h x)) ?
<Yoric[DT]> Noted.
<bluestorm> olegfink: in some occasion right-to-left is more natural than left-to-right
<olegfink> Yoric[DT]: I would *really* like to see 'a -> ('a -> 'b) -> 'b making it into Batteries.
<Yoric[DT]> Features request :)
<vixey> olegfink, isn't that the type of |> ?
<olegfink> er, it is.
<vixey> ok so that's already in batteries
<vixey> I'm suggesting it be removed
<bluestorm> :]
<olegfink> then just disregard everything I'm saying here. :-)
<vixey> as well as <| |- -| &&& and ***
<bluestorm> i think that
<bluestorm> we may choose meaningful prefix names
<vixey> maybe the whole section 'Fundamental functions and operators' should be taken out of batteries core and put into a new one called 'Trivial combinators'
<det> |> is very useful
<olegfink> what what harm does |> do? It doesn't have associativity problems and is quite useful.
<bluestorm> and then add an Infix module with cryptic operators for the enthusiats
<vixey> det, I am certain that there is absolutely no use for it
<bluestorm> hm
<bluestorm> i find the similarity in expression between vixey and Smerdyakov confusing
<vixey> <bluestorm> i find the similarity in expression between vixey and Smerdyakov confusing
<vixey> oops
* kattla has used |> a lot
<bluestorm> (are you from the same family or something ?)
<vixey> olegfink, compare x |> h |> g |> f with f (g (h x))
<olegfink> vixey: print me all the numbers plus two in a list which are greater than 7?
threeve_ has joined #ocaml
<olegfink> compare list >> List.filter (>7) >> List.map (+2) >> List.iter print_int with parans version
<bluestorm> Yoric[DT]: (<|) probably has an associativity problem, though
<olegfink> *parens
<vixey> olegfink, looks like Ruby
<olegfink> maybe, I don't do Ruby.
<vixey> olegfink, (btw, you might notice that you just wrote down your specification _in reverse_ to write that program)
<det> # (1 -- 1000) // (fun x -> x mod 30 = 0) |> take 10 |> List.of_enum;;
<det> - : int list = [30; 60; 90; 120; 150; 180; 210; 240; 270; 300; 330]
<vixey> olegfink, and I'm not sure that reversing specifications in ones head is sensible
<det> # List.of_enum (take 10 (filter (fun x -> x mod 30 = 0) (1 -- 1000)));;
<det> - : int list = [30; 60; 90; 120; 150; 180; 210; 240; 270; 300; 330]
<det> I prefer the first version
<vixey> det, I like that (--) thing though
<bluestorm> det: using pa_holes you could write (\ \1 mod 30 = 0) :-'
<det> bluestorm, in place of the anonymous function ?
<bluestorm> (and possibly (\ _ mod 30 = 0), though i'm not sure about enabling that one)
<bluestorm> yes
<vixey> It looks like an attempt to turn Ocaml into Perl 6 :)
<olegfink> vixey: in which direction would you read haskell's print $ map (+2) $ filter (>7) $ list?
<vixey> olegfink, I would not even finish reading that, I would just tell them not to use ($) in that way
<olegfink> I apparently don't have a stack in my head, so I have to read it right-to-left
pango has quit [Remote closed the connection]
<olegfink> okay, somefun = print . map . (+2) . filter (>7)
<vixey> olegfink, am I to ignore the type error?
glondu has joined #ocaml
<vixey> sorry I don't I'm going to grasp your point if you use haskell code to explain it
<olegfink> there shouldn't be dot after map, sorry.
<olegfink> I thought you were advocating haskell approach, but probably I just don't have any clue whatsoever.
<vixey> olegfink, I am mostly suggesting that ($) in haskell, (|>) in ocaml and f# are fundamentally bad things to program with because they are awkard and do not admit nice algebraic properties
<olegfink> so you suggest rewriting that with parens?
<vixey> olegfink, I'm not really saying there's a specific good way to do anything, just that this one thing is _bad_
<bluestorm> i don't really understand why you think that f $ g x is worse than f (g x)
<_zack> vixey: we kind of get it, but I'm entirely sure yet, can you repeat the concept? (SCNR)
<vixey> _zack, if you have had me on /ignore then you should read the channel logs
pango has joined #ocaml
<bluestorm> looks like the same to me, except parens put delimiters both before and after the latter part
<_zack> vixey: ok, I'll try again, can you please first of all explain why you do bother? if you don't like the operators, just don't use them
<olegfink> vixey | det, I am certain that there is absolutely no use for it
<_zack> second, the examples with just f/g/h are naive, when the code gets trickier, the parens version has not only the parens required for nested applications, but also all the other parens inside f/g/h
<_zack> in that case, the ability to write them in a non-nested way, makes the code more readable
<olegfink> I think that's the point, but I have provided sort of a counter-example
<_zack> and, as it has been already pointed out, indentable more clearly
<vixey> _zack, If you write code that complicated _You are doing something wrong_, if |> makes it easier to do the wrong thing this is not helpful
<_zack> that is, each successive step in a series of transformation can be indented on the same line
<_zack> it does not
<_zack> on the contrary, it encourages to write complex nested applications, which is the core of functional programming
<vixey> olegfink, the one where you had to reverse the problem specification in your head to write the code? that was not a good counter example
<_zack> if the current style forces people to do sequential let ... in, that is less of a functional style
<Smerdyakov> I'm all in favor of complex nested applications.
<vixey> olegfink, at least you did not convince me
<Smerdyakov> (That one was for people who claim vixey and I say things that are too similar. :P)
<_zack> Smerdyakov: :)
<olegfink> am I supposed to do the right thing with var:=... in a (...) block instead
<olegfink> ?
threeve_ has quit []
<_zack> moreover, a series of sequential transformation is really a functional way of seeing a program, a syntax that make the sequence explicit is just good(TM)
<olegfink> vixey: the problem specification in my head follows the process, which is the same order as my ocaml code. Natural language is more complicated.
<vixey> ok
<vixey> oh well I didn't convince anyone :p
<_zack> vixey: in spite of that, can you explain which danger do you see in having that operator? I didn't get that
<_zack> I mean, OK, you don't like it, but what harm it does?
<vixey> _zack, yes I already did that, like I said you should read the channel logs
<bluestorm> from what i find in the logs, you find the |- symbol confusing
<bluestorm> (you could also argue that if such operators become more-or-less "standard", then you'll have to read the code of others people using it)
<_zack> vixey: just reread, I've only found a "very odd choice", and a "a shame to take it over from other languages", which don't really answer my question
<vixey> bluestorm, I didn't argue that though
<bluestorm> yes
<bluestorm> from the analogy with Smerdyakov i'd guess that you don't read others people code anyway :-'
<bluestorm> i agree that |- is probably not an optimal choice
<bluestorm> and |> has the advantage of F#-compatibility, and the disadvantage of being associativity-flawed
mishok13 has quit [Read error: 60 (Operation timed out)]
* olegfink still can't understand what's wrong with |> associativity
<bluestorm> finding a consensus on intimate matters like infix operators naming is damn hard
<bluestorm> olegfink: |> is right but <| is not
<olegfink> there I agree.
<Yoric[DT]> Well, we'll just fix this with Camlp4 (and possibly using pa_do).
<vixey> F# compatability is not an advantage
<bluestorm> Yoric[DT]: i'm not sure it's a good idea, but why not
<Yoric[DT]> We're not aiming for F# compatibility. We're aiming for something nice.
<Yoric[DT]> bluestorm: well, still waiting for alternatives :)
<bluestorm> i've proposed >^ but seems nobody loves it
<bluestorm> (a possible critic is that on some keyboards, ^ is a dead key)
<vixey> Yoric[DT]: Do you use |> though?
<bluestorm> i've used >@ in the past but people tend to find it awful
<vixey> bluestorm, I actually don't see why anybody would use any operator for this
<bluestorm> vixey: to get rid of parenthesis
<Yoric[DT]> vixey: sometimes.
<vixey> why would you want to get rid of them?
<Yoric[DT]> Sometimes, they hamper reading.
<Yoric[DT]> Not always.
<vixey> if they are meant to be there, it seems right to have them
<Yoric[DT]> This is not an operator to be abused.
<Smerdyakov> Yoric[DT], which operators should I abuse?
<Yoric[DT]> +
<Yoric[DT]> :)
<vixey> Yoric[DT: what did you think of my earlier suggestion though?
<Yoric[DT]> Dropping it from the language?
<Yoric[DT]> s/language/library/
<vixey> move the section 'Fundamental functions and operators' out of batteries core and put into a new one called 'Trivial combinators'
<vixey> then people aren't forced with this
<Yoric[DT]> Well, they never are.
<_zack> vixey: they aren't force right now either
Axle has left #ocaml []
<_zack> vixey: and you still need to explain why you have a problem with the mere existence of |>
<vixey> Yoric[DT]: everything in batteries looks fine except this one awful thing
<bluestorm> i would find it nice to have them in an "Infix" submodule
<vixey> _zack, I'm sorry you are asking me the same question again and again, I have answered it already
<vixey> _zack, please do not keep doing tat
<mfp> Yoric[DT]: is there any reason for not submitting the ANN to reddit?
<_zack> vixey: no, you didn't, but I can assume that now you like &&& and *** ?
threeve_ has joined #ocaml
<_zack> Yoric[DT]: in debian we usually don't install 0-sized files, while some of the *.idex file are, so I'm changing batteries_help to avoid complaining if some .idex file do not exist, do you see any problem with that?
<_zack> Yoric[DT]: I don't, because anyhow they were empty files
<_zack> (JFTR: just 2 of them: class_types.idex and attributes.idex)
<Yoric[DT]> _zack: no, no problem.
<Yoric[DT]> They probably won't remain empty forever, though.
<Yoric[DT]> mfp: well, someone has done it, I think.
<_zack> yep, sure, the day they won't be empty they'll get installed, and everything will be fine as well
<Yoric[DT]> sure
<mfp> Yoric[DT]: really? must have been downvoted quickly (missed it)
* mfp checks
<bluestorm> does anybody read the "ocaml" subreddit ?
purple has quit [Read error: 110 (Connection timed out)]
<mfp> uh, I for one, rarely do
purple has joined #ocaml
<bluestorm> Yoric[DT]: btw, i have a question regarding the syntax extensions i'm gonna add for alpha 3
<bluestorm> should the development happen in the batteries tree ?
<_zack> bluestorm: I guess the answer depends on how generic they are
<bluestorm> hm
<_zack> if they are more general then batteries they should better be decoupled from batteries, so that other people can use them
<_zack> let's be good freesw players :)
<bluestorm> ok
<_zack> but I don't know which ext you are referring to, so the decision is still up to that
<bluestorm> the "try .. finally" and "let try ...", wich are "more general" as you said
<_zack> yup, definitely, still there is a third alternative
<_zack> keep them in the batteries tree, but in a subdir which is usable independently from the rest
<_zack> so that we can distribute easily small tarballs of the xt
<_zack> ext
<_zack> I'm not sure how a good idea that is
<kattla> Has anybody used symbiosis?
<bluestorm> (other question : do some of you have an idea of when batteries will be 3.11 ready ? i heard the problem are bin-prot related but i'm not very up-to-date on these things)
<_zack> bluestorm: no idea, but I know you will soon be able to try it out in debian :)
<Camarade_Tux> bluestorm, mfp tried very recently and has patches iirc
jeddhaberstro has joined #ocaml
<bluestorm> i guess they're waiting for the next Janestreet Core release wich was to happen "soonish"
<_zack> bluestorm: yeah, right :/
hkBst has joined #ocaml
velco has quit ["Went wasting time elsewhere ..."]
threeve_ has quit []
<bluestorm> i have a question regarding the "let .. try" construct
<bluestorm> should it be "let try a = b in c with ..." or "let try a = b with ... in c" ?
<bluestorm> i prefer the first solution actually
<Yoric[DT]> _zack: by the way, what about a Debian package?
<_zack> Yoric[DT]: working on it
* Yoric[DT] still needs to get rid of 3 pages from his paper, though.
<_zack> Yoric[DT]: once done, I'll blog about it, don't worry :)
<Yoric[DT]> :)
<_zack> Yoric[DT]: FWIW, the missing bit for debian package is graceful degradation for the top-level when doc is not installed. Doc is in a separate package in Debian, because it is quite big (13 Mb)
apples` has joined #ocaml
<_zack> I'm adding a Debian-specific patch for that (not to Batteries itself of course), which suggest to install the -doc pacakge
filp has quit ["Bye"]
jeddhaberstro has quit []
comglz has joined #ocaml
BSWolf has quit [Read error: 104 (Connection reset by peer)]
<Yoric[DT]> ok
comglz has quit ["AddToFunc ExitFunction I Exec exec sudo halt"]
itewsh has joined #ocaml
glondu has left #ocaml []
Smerdyakov has quit ["Leaving"]
zbrown has quit [Read error: 60 (Operation timed out)]
ygrek has joined #ocaml
<flux> bluestorm, why not .. | `Exn (End_of_file) -> .. | `Exn x -> raise x? too complicated?
<bluestorm> well
<bluestorm> that would complicate the code a bit
<bluestorm> but i could eventually do that
velco has joined #ocaml
<bluestorm> i think i will but i focused on getting the correct behaviour first
<bluestorm> (i agree in that case a bit of optimization will not hurt)
<flux> also.. polymorphic variants.. ;-)
<bluestorm> but you're right, i'm not so happy with the "try raise exn with ..."
<bluestorm> another possibility would be match (try `Result (read_line ()) with End_of_file -> `Exn (List.rev acc)) ...
<bluestorm> but that would break tail-recursion in the "with ..." position
<flux> `Exn (List.rev acc)?
<flux> looks strange :)
tomh-- has joined #ocaml
tomh-- is now known as tomh__
tomh__ is now known as tomh___
tomh___ is now known as tomh
jlouis has joined #ocaml
bluestorm has quit [Remote closed the connection]
vixey has quit ["Ex-Chat"]
vixey has joined #ocaml
seafood has joined #ocaml
Snark has quit ["Ex-Chat"]
itewsh has quit ["KTHXBYE"]
seafood_ has joined #ocaml
seafood has quit [Read error: 110 (Connection timed out)]
seafood_ has quit []
threeve_ has joined #ocaml
jeddhaberstro has joined #ocaml
<mbishop> Are "|" "&" and "^" used in standard OCaml?
<mbishop> well I know ^ is
<Camarade_Tux> # true & false;;
<Camarade_Tux> - : bool = false
<Camarade_Tux> but it's advised not to use it
<Camarade_Tux> (just like 'or')
<mbishop> what about "|"? I ask because I saw "&&&" "|||" etc are used in Batteries, but they are used the way they work in Haskell
<mbishop> and I generally used &&& etc for bitwise shorthand
<mbishop> so now I'll have to find new symbols, I guess :P
* Camarade_Tux fears the "heated discussion"
<Yoric[DT]> Let's just say that these symbol names are still up for debate :)
<Camarade_Tux> and I can't answer ;)
<mbishop> well
<mbishop> I don't particularly like tripling the symbol for bitwise shorthand anyway
<mbishop> just don't know of any better symbols
itewsh has joined #ocaml
<mbishop> F# uses &&&, ||| etc for bitwise stuff, which is why I used those in OCaml in the first place
threeve_ has quit []
<mbishop> Yoric[DT]: also, any news on a .deb package for alpha 2?
<Camarade_Tux> mbishop, there's been a 3-hours discussion about these operators, their use, their future, their origin (F#, haskell, ...), and anything you could imagine ;)
<mbishop> Camarade_Tux: well I missed it :P
<Camarade_Tux> you're lucky ;)
<Camarade_Tux> as for the debian package, zack is working on it, I don't know if he's done yet (must be close anyway)
<Yoric[DT]> mbishop: _zack promised me it was under way.
* Camarade_Tux goes into urgent deadline mode :)
<_zack> guys, calm down :) what's such a frenzy? :)
<_zack> anyhow I'm doing the final build right now
<_zack> (though of course, one know that it's final only after the final tests)
* Yoric[DT] is painfully aware of that.
<_zack> the fact that ocamldoc takes 25 minutes does not help either ;)
<mbishop> _zack: will there be an x86 version this time?
<_zack> well, there was also the other time, you just have to wait for the experimental autobuilders to catch up
<vixey> it seems to me that ASCII isn't big enough
<_zack> my upload will be amd64, as that is my devel machine
<Yoric[DT]> _zack: don't blame me :)
<_zack> Yoric[DT]: I wasn't :)
<Yoric[DT]> A new and improved ocamldoc would be nice.
<mbishop> Hmm, so I read the scrollback, and I would agree that |- isn't very nice, but I like |>
<mbishop> And as for the haskellish triple operators, they can stay as long as I can find a better replacement for bitwise operators :P
<_zack> mbishop: I've just checked, even the last time i386 packages were available, as you can check from http://ftp.debian.org/debian/dists/experimental/main/binary-i386/Packages.gz
<_zack> eventually, after my upload for amd64, the package gets rebuilt for all archs, it is just that being "experimental" there is some buildd sloppyness at a time
<mbishop> hmm k
<_zack> it did work, but due to some irony, I've some checksum mismatch, sounds familiar? :)
<_zack> they are totally different checksums, but it's still funny
<Yoric[DT]> Yep, familiar :)
rwmjones has quit ["Closed connection"]
Kerris4 has quit ["Leaving."]
Kerris0 has joined #ocaml
Kerris4 has joined #ocaml
Kerris0 has quit ["Leaving."]
<mbishop> I just installed the "old" Batteries for ubuntu (just downloaded the .deb myself)
itewsh has quit ["KTHXBYE"]
ygrek has quit [Remote closed the connection]
_zack has quit ["Leaving."]
marmotine has quit ["mv marmotine Laurie"]
willb has quit [Read error: 145 (Connection timed out)]
Yoric[DT] has quit [Read error: 104 (Connection reset by peer)]
snhmib has quit ["Good riddance!"]
hkBst has quit [Read error: 131 (Connection reset by peer)]
kattla has left #ocaml []
threeve has quit ["Leaving"]
code17 has quit ["Leaving."]
velco has quit ["Ex-Chat"]
ulfdoz has quit ["deprecated"]