<polux>
i've heard of continuations in ruby and python 2.5 is ot the same thing ?
<pango>
probably
<polux>
functions that stop at a point and come back to this point at the next call ?
<zmdkrbou>
nope
zigong has joined #ocaml
<polux>
looking ocaml doc
<zmdkrbou>
i don't think it's explained in the doc
<polux>
where is it documented ?
<polux>
oh ok it's a programming pattern ?
<zmdkrbou>
neither :)
<zmdkrbou>
it's when you give to a function the next function in the flow, as an argument
<polux>
ok
<pango>
in this context, when you select a value to try for the next column, and call the function the function that will test if it results in a valid pyramid (and try further on next columns...), you also give it the function to call in case of failure
<polux>
ok
<pango>
(in this context again, the function that will try the next possible value)
<polux>
but why isn't backtraking ok ?
<pango>
that's backtracking
<pango>
a way to implement it
<pango>
of course it will only work ok if all your data structures are immutable, because you won't have to revert back any "changes" made while evaluating your previous solution
<zmdkrbou>
you can avoid using continuations here
<pango>
if you use mutable structures, you'll have to be much more careful
<polux>
pango: yes but backtrackiing is simpler with a let rec function isn't it ?
<pango>
polux: continuations isn't an alternative to recursive functions
<pango>
polux: you'll use recursive functions too
<zmdkrbou>
you juste have to write a function that takes a list of n numbers, and build a list of n+1 numbers ... when it fails you raise an exception, and this exception is treated just by trying other n numbers
<pango>
exceptions are an imperative construct
<polux>
exception doesn't sound like pure functional programming
<polux>
maybe i'm wrong
<malc_>
polux: you are not
<zmdkrbou>
pfff, pango you're worst than me ! ;p
<zmdkrbou>
exceptions are functionnals
<pango>
zmdkrbou: they're not
<zmdkrbou>
they have an interpretation in a lambda-like calculus :)
<pango>
probably continuations ;)
<zmdkrbou>
i think so, yes :)
<polux>
zmdkrbou: yes in rho calculus :)
<polux>
that's what i'm going to work on with ocaml
<polux>
not exceptions
<polux>
but rho calculus
<polux>
at least i saw they had an interpretation in rho calculus but maybe there are simpler calculus that handle exceptions
<polux>
zmdkrbou: ho you're from ens lyon :)
<zmdkrbou>
yep
<polux>
i'm going to work with benjamin wack
<polux>
maybe you know him
<zmdkrbou>
nope, and i never heard of rho-calculus i think .... that's why i'm looking at the rho-calculus homepage right now :)
<polux>
ok we're 3 french people trying to speak english :)
<zmdkrbou>
pango is french too ?
<polux>
seems like he is
<polux>
bordeau
<zmdkrbou>
maybe we can get this to another chan, in french :)
<polux>
ok
<polux>
let's say #ocaml-fr
Skal has joined #ocaml
malc__ has joined #ocaml
malc_ has quit [Read error: 110 (Connection timed out)]
Smerdyakov has joined #ocaml
goomba has joined #ocaml
zigong has quit [Remote closed the connection]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
malc__ has quit ["leaving"]
rillig has quit ["exit(EXIT_SUCCESS)"]
goomba has left #ocaml []
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
jackhong has joined #ocaml
jackhong has left #ocaml []
pango_ has joined #ocaml
polux has quit [Remote closed the connection]
pango has quit [Read error: 110 (Connection timed out)]
bzzbzz has quit ["leaving"]
tristram has quit [Read error: 110 (Connection timed out)]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
Herrchen_ has joined #ocaml
Herrchen has quit [Read error: 110 (Connection timed out)]
MisterC has joined #ocaml
MisterC has quit [Read error: 104 (Connection reset by peer)]
__DL__ has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
Skal has quit [Read error: 110 (Connection timed out)]
Skal has joined #ocaml
Revision17 has quit ["Leaving"]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
pango_ has quit ["Client exiting"]
ramki is now known as ramkrsna
pango has joined #ocaml
<vincenz>
Hello
tristram has joined #ocaml
ppsmimou has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
Snark has joined #ocaml
Raziel has quit ["Yo soy goma. Tú eres cola."]
systems has joined #ocaml
systems has quit [Remote closed the connection]
Smerdyakov has quit ["Leaving"]
Raziel has joined #ocaml
ivans has joined #ocaml
pango has quit [Remote closed the connection]
Snark has quit ["Leaving"]
Smerdyakov has joined #ocaml
vodka-goo has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
gim has joined #ocaml
zmdkrbou has quit [Read error: 110 (Connection timed out)]
zmdkrbou has joined #ocaml
zmdkrbou is now known as uobrkdmz
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
zmdkrbou has joined #ocaml
uobrkdmz has quit ["pouet"]
zmdkrbou has quit ["encore un demenagement"]
zmdkrbou has joined #ocaml
knobo has quit [Read error: 113 (No route to host)]
ivans has quit ["bye"]
Revision17 has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
ski has quit [Read error: 110 (Connection timed out)]
ski has joined #ocaml
Schmurtz has joined #ocaml
knobo has joined #ocaml
ramkrsna is now known as rK|
pango has joined #ocaml
<flux__>
it appears I'm awake at all the wrong times, judging from the channel activity ;)
<Smerdyakov>
Oh, CRY me a river!
<flux__>
;(
<zmdkrbou>
because we're hiding from you flux__ :p
<vodka-goo>
OCaml programmers never have a single problem since OCaml is the perfect language :p
<Schmurtz>
flux__, ask questions ;)
<zmdkrbou>
(or because there's no activity here even when you're not here)
<zmdkrbou>
vodka-goo: ...
<Schmurtz>
so you'll have more chance to be here when there're discussions
<zmdkrbou>
vodka-goo: some people also talk about omlet problems here :p
<flux__>
well, I actually have one, but it's considered redundant to ask if there's anyone around, before asking it ;)
<vodka-goo>
zmdkrbou: can I make you the official maintainer of omlet ?
<zmdkrbou>
nope :p
<vodka-goo>
smart answer :)
* zmdkrbou
's not crazy
<flux__>
let's say I have modules Type, A and B, where A and B are functors taking module type Type, and B in addition takes module of type A
<dylan>
vodka-goo: by the way, if you attempt to backspace over a bunch of code that has a un-opened *) near the end, with no (* preceeding it, vim seems to go into an infinite loop.
<flux__>
and in A I want to write a function Type.t -> Type.t, and in B I want to write a Type.t -> Type.t too, but so that it basically uses A's definition
smimou has joined #ocaml
<flux__>
how should I go around expressing that? with my approaches I'm getting two instances of Type.t, which are incompatible
<dylan>
vodka-goo: This could construed as a feature, and not a bug. If you have badly formatted code vim dies! :)
<vodka-goo>
dylan: there may be some infinite loops
<vodka-goo>
but it's also possible that I take a very long time parsing ocaml code
<flux__>
actually A should be a module type, not an actual functor, I imagine that's where my problem is
<dylan>
vodka-goo: Perhaps. But after a day and a half...
<vodka-goo>
viml is slow and I do quite an important computation with parsing (didn't try/find a way to cache parsing results)
<dylan>
*nods*
<dylan>
I try to keep .ml files under 100 lines anyway, and it doesn't seem to be too slow.
<vodka-goo>
dylan: can you please describe the problem again ?
<vodka-goo>
maybe paste some code
<dylan>
vodka-goo: I'll try to reproduce it.
<vodka-goo>
I didn't manage to reproduce that loop
<vodka-goo>
k
<dylan>
both times, the circumstances were very abnormal...
<vodka-goo>
backspacing while in insert mode should not trigger indentation
<gim>
flux__: if X:Type and M:A, then you have two distinct types X.Type.t and M.Type.t (provided you aliased the module type Type from the functor argument to Type itself in A)
<gim>
i can't see where's the issue
<dylan>
it's more like: backspace over identation and newline, and then hit enter.
<dylan>
it seems to lock up on trying to indent long lines that have *) on the end.
Revision17 has quit ["Leaving"]
<dylan>
but it won't reproduce now. :(
<flux__>
hm, infact, I may have solved the issue, by giving one more stab to it :)
<flux__>
I wonder if I can actually apply that to my real problem
<gim>
ok good luck then
<vodka-goo>
btw I have a stupid announce about omlet ... I won't be able to post new versions since I lost my vim.org password and they don't provide the password recovery anymore :)
<flux__>
so at the moment I have: module type A = sig type t end module type b = functor (A : A) -> sig val foo : A.t -> A.t end module C (B:B) (A:A) = struct module B = B(A) let foo : A't -> A.t = fun a -> B.foo a end
<zmdkrbou>
:s
<gim>
vodka-goo: did you mailed them ?
<flux__>
(sorry for reusing identifiers ;))
<Smerdyakov>
vodka-goo, what is omelt?
<gim>
a vim ocaml mode
<flux__>
so module type B is parametrized by A and while module C is parametrized by both A and B
<flux__>
and they need to be compatible
<Smerdyakov>
Tehe. Someone trying to use vim for non-standard development tools.
<vodka-goo>
gim: that what I should do when I'll really have an update, but I'm reluctant to send that email begging for my password :)
<gim>
flux__: functor ... with type A.t = B.A.t -> ... ?
<flux__>
pango, hey, that seems to be relevant, thanks
<Smerdyakov>
vodka-goo, anything outside the GNU toolchain.
<gim>
maybe B.A is not exported, but you can deal with it
<zmdkrbou>
Smerdyakov ...
<Smerdyakov>
zmdkrbou, yes?
<zmdkrbou>
that makes a lot of things non standard
<Smerdyakov>
zmdkrbou, right, and vim doesn't work well for them.
<zmdkrbou>
vim works well.
_fab has joined #ocaml
<Smerdyakov>
I have a somewhat unusual viewpoint, since I work at the far end of the spectrum in formal methods research.
<Smerdyakov>
In this area, there's really no comparison between emacs and vi.
<Smerdyakov>
No one implements anything for vi.
<dylan>
Heh. I must be really non-standard.
<dylan>
as I use, for instance, zsh over bash.
<dylan>
mostly for mutlicompletion and the fact that zsh has a builtin FTP client.
<gim>
mmm what's the point for a builtin ftp client ?
<dylan>
it has the same tab completion as my shell
<Smerdyakov>
dylan, do you ever construct machine-checkable proofs?
<gim>
vodka-goo: do you plan to do a coq-mode for vim?
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
<dylan>
Smerdyakov: Not really, but I'd wager I do things in vim that you wouldn't in emacs, either. it's purely a matter of choice and what's practical for a job-domain.
<Smerdyakov>
gim, do you mean just the syntax, or an interactive mode?
<gim>
syntax would be enough for my needs
<Smerdyakov>
gim, you must not do much if you don't want to build proofs interactivey!
ski has quit [Read error: 104 (Connection reset by peer)]
<dylan>
Plus, if popularity and standards were my highest virture, one would have to assume I'd use windows...
<dylan>
well, not the standards bit, but anywho. :)
<Smerdyakov>
dylan, so far as emacs vs. vi goes, there really is no choice. There is nothing implemented for vi in the class of tools I've named.
<dylan>
Smerdyakov: In your case, yes.
* zmdkrbou
needs an editor, not a multi-usage tool for doing anything one can imagine
<Smerdyakov>
zmdkrbou, I need to get work done, and emacs helps me do it better than vi.
<dylan>
The only reason I use vim is it's the first text editor I learned, and I'm far too lazy to want to learn emacs commands.
<zmdkrbou>
if you use coq then why not using coqide ?
tristram has quit [Remote closed the connection]
<Smerdyakov>
zmdkrbou, I believe Proof General is superior in every way I've been able to determine is meaningful.
<gim>
zmdkrbou: coqide has a terrible built-in editor
<dylan>
coqide also requires a GUI, doesn't it?
tristram has joined #ocaml
<Smerdyakov>
zmdkrbou, I'm surprised that they even created coqide.
<gim>
or at least i don't know how to use it
<Smerdyakov>
zmdkrbou, I certainly don't recommend that anyone ever use it.
<zmdkrbou>
some people seem to have no problem working a lot with coq within coqide
roral has joined #ocaml
bd_ has joined #ocaml
<dylan>
Smerdyakov: What does vim not having nifty plugins for coq have to do with vim being a non-standard development tool for ocaml? I'm not trying to be troublesome, I'm just confused...
<dylan>
and I can certainly understand using emacs as a coq IDE. heck, I've used emacs a little to place with Oz/Mozart.
<dylan>
*play with.
gim has quit ["let's go home"]
<Smerdyakov>
dylan, no, I'm saying that _OCaml_ is non-standard, not vim.
<dylan>
Now that's quite confusing...
<Smerdyakov>
I will rephrase everything.
<Smerdyakov>
vim is maintained by a community of old-school crufty UNIX hackers who tend to care only or mostly about C development.
<Smerdyakov>
"Non-standard" includes anything not part of the standard, GCC-centric toolchain.
<dylan>
Why does vim come with syntax highlighting and plugins for most scripting languages?
<Smerdyakov>
The vim community just has little to no interest in anything else.
<Smerdyakov>
That fits into the same hypothesis: since they use C as the default, they need separate "scripting languages" to do many things tractably.
<dylan>
vim's support for C is mostly contained in $VIMRUNTIME/*/c.vim files, though?
<Smerdyakov>
The development models that more enlightened folks use are fundamentally different.
<dylan>
Oh. I see.
<Smerdyakov>
A dumb editor is just not that useful.
<Smerdyakov>
You need other tool support.
<dylan>
well, I see vim as an editor component of my IDE.
<Smerdyakov>
No reason to separate things when they can be combined so nicely as in emacs.
<dylan>
But I already have these other tools I use, that arn't emacs.
<Smerdyakov>
And you work harder to make them interoperate than you would with emacs.
<dylan>
Not really.
demitar_ has joined #ocaml
<dylan>
they get along like close brothers, that are within a few years of age.
<Smerdyakov>
I doubt you don't spend any additional time dealing with the fact that they live in separate process address spaces.
<dylan>
I wrote my own replacement for make, which I feel is better, and it's a simple "set makeprg=bake -f" in a file to have vim use it?
<Smerdyakov>
Why the question mark?
<dylan>
To express confusion in my reply.
<Smerdyakov>
Command-line invocation is a very simple interaction.
<dylan>
I have nothing against emacs, but I prefer having lots of independent processes communicating than having everything in the same address space.
<dylan>
I also love learning different languages, and finding ways of having them communicate together.
<dylan>
so the unix paradign of seperate programs for seperate tasks appeals to me.
<Smerdyakov>
Do you have some engineering reason for wanting to make different languages communicate? It's certainly more efficient to avoid the need.
<dylan>
Do I need one? It makes development more enjoyable. I assume the pleasure I get from this is some signal that I have made it easier and requiring less work...
<Smerdyakov>
I doubt it.
<Smerdyakov>
I think you just like solving puzzles.
<dylan>
The thing is I get a development environemnt that is exactly tailored to how I work.
<dylan>
This is possible in emacs as well, of course. But I didn't learn emacs, I learned vim. And I have more interesting things to learn besides another text editor.
<dylan>
Perhaps I'm just a young crufty-UNIX-monster-in-training (and I do have the beard for this), but I like my IDE to be a rag-tag band of programs that allow to be maximally lazy...
<Smerdyakov>
I don't understand your use of "lazy." You work harder to get them interoperating.
Demitar has quit [Read error: 110 (Connection timed out)]
<dylan>
I don't.
<dylan>
To start a new ocaml project, I go "new ocaml" in my shell. It starts me out with a template to work from.
<dylan>
My text editor lets me jump around between ocaml modules (using a ctags-like program).
<dylan>
Most of this functionality I didn't write, and that which I did write only had to be done once.
<Smerdyakov>
You still need to switch between shell and editor.
<dylan>
I use gnu screen.
<dylan>
I keep a text editor open in window 1.
<dylan>
and running "vim" in the shell is quite easy.
<dylan>
The biggest rock in my ear right now is having to use this accursed laptop keyboard... But that isn't a software problem.
<dylan>
and I think my environment is very efficent, human-wise. I was able to write a perl script the other day to parse the local bus schedules and build a directed graph of the cheapest route from my city to a nearby one, and display it using graphviz. It took about an hour..
<dylan>
I don't think I'm all that blessed with speed at programming, so it must be the environment I use. :)
gim has joined #ocaml
<dylan>
and I think I'm talking too much now. :(
<dylan>
Smerdyakov: In summary, my IDE is like my shoe-shine kit. It's constructed with care to just what I want/need. And it makes my shoes look nice. But I'm sure your shoe shine kit (or equivelant) is just as nice. But mine makes my shoes plenty shiney.
<Smerdyakov>
In general, I don't believe that there are such large differences between how good programmers work effectively.
<dylan>
Than I am not a good programmer. Simple. :)
<dylan>
But I have a nice gloss on my shoes.
<dylan>
(literally)
<Smerdyakov>
I'm not ncecessarily asserting that I'm right and you're wrong, but just that I don't accept excuses of the "different strokes for different folks" form.
Snark has joined #ocaml
<Smerdyakov>
And, BTW, don't you think it's pathetic that it would take an hour to code your conceptually simple bus schedule program?
<dylan>
Smerdyakov: I had to parse two different bus schedules.
<dylan>
by parse I mean screen scrape.
<dylan>
The rest was a piece of cheese.
<dylan>
The buses for each county here are different companies...
<Smerdyakov>
So it would have been trivial if the schedules were in XML?
<dylan>
I also had to normalize the bus station names. :(
<dylan>
Yes!
<dylan>
I also had to read the docs for graphviz .dot file formats. I never remember the syntax for attributes and so on.
<dylan>
btw.. "pathetic" is a pretty negative word. I hope I haven't rifled any feathers... I was just confused at your opinion, but do not want to come accross as rude.
<Smerdyakov>
Well, the state of software development today is pretty negative!
<dylan>
As someone that is rewriting most of the tools he uses, I'd say so.
<dylan>
The few things I'm happy with is vim, mutt, and zsh.
<Smerdyakov>
Are you rewriting any language tools?
<dylan>
If you count make as a language, then yes.
<Smerdyakov>
Which alternatives did you look at before deciding to make your own?
<dylan>
ant, jam, cons, scons, rake, and some that I forgot.
<Smerdyakov>
What's the secret weapon of your approach?
<dylan>
It's a turing complete language? :)
<Smerdyakov>
So is scons.
<dylan>
as is cons and rake.
<dylan>
But they seem focused on building software.
<dylan>
mine I use to build webpages from templates.
<Smerdyakov>
What are the main differences?
<dylan>
I didn't look deeply enough at scons.
<dylan>
But it seemed to more stuff under the hood then I liked.
<dylan>
*to do
<Smerdyakov>
I mean the differences from software to web pages that cause software-inspired approaches to fail.
<dylan>
ah
<dylan>
in scons, the tutorials say:
<dylan>
CProgram('main.c') (or some such, I forget)
<dylan>
unlike in make, where you just say "this file is made from this other file"
<dylan>
my replacement retains that.
<Smerdyakov>
I'm sure you'd find support for that elsewhere in the documentation.
<dylan>
Yes, but there's also the bit about scons requiring python.
<Smerdyakov>
Python is approximately universal now.
<dylan>
True.
<dylan>
Also, it's more work to call shell commands.
<dylan>
bake has syntax sugar for this, as a DSL should. :)
<dylan>
I highly doubt anyone but me will use bake, by the way.
<flux__>
is it available?-)
<dylan>
Well, not outside of a public SVN repository.
<Smerdyakov>
dylan, you made up a new language instead of using an existing one?
<Smerdyakov>
OK. Then I guess we don't really have any common ground for discussing its merits.
<dylan>
I'm not a language designer, and I suspect it has one of the slowest implementations of lexical variables ever.
<dylan>
it
<Smerdyakov>
You could probably have implemented this as a library for OCaml and gotten much better results.
<dylan>
Well, the code to build stuff is in a seperate module.
<dylan>
it could in theory be used as a library. Or as a camlp4 syntax extension even.
<Smerdyakov>
The problem with inventing your own language is that you will probably end up providing poor support for abstraction/modularity/extensibility.
<Smerdyakov>
You don't have that problem if the thing is nothing besides an OCaml library.
<dylan>
Nope!
<dylan>
I refuse to support people using bake for anything but building software!
<dylan>
Especially my crazy friend that wants to write a text-based adventure in it...
<Smerdyakov>
You're out of touch with reality if you think you'll think of every task that could be involved in building software.
<dylan>
I'm out of touch with reality anyway, but this only has to support my needs. :)
<dylan>
I'd have to be very egotistical if I thought anyone would use this to build important bits of software. :P
<Smerdyakov>
dylan, where is your web site hosted?