<hcarty>
Yoric[DT]: Thanks. Does not being currifiable matter for an identity function?
<hcarty>
Are there any pluses/minuses to using an identity function like (let id x = x) vs (external id : 'a -> 'a = "%identity")?
2008-06-04
<hcarty>
bluestorm: The last link looks like it is going in that direction, though I don't know how complicated it would be to make that happen
<hcarty>
I emailed the ocamlp3l folks to see if the project is still being maintained, and I received replies from several developers assuring me that it is
<Yoric[DT]>
hcarty: if you need a name, my project is ExtraPol.
<hcarty>
Are frama-c and your project (and/or the combined form of them) something that is or will be useful for simplifying C library binding generation for OCaml? I am not a CS person, and am unfamiliar with the details of what a project like this involves
<hcarty>
Very cool
<hcarty>
Yoric[DT]: Is this frama-c project related to your C analysis project?
2008-05-25
<hcarty>
tsuyoshi: I that what ulex is? (I don't know, it's not something I've used)
<struk_atwork>
hcarty, sigh guess I'll have to drop my mad scientist vision of autonomous ocaml agents taking over networks :(
<hcarty>
Definitely useful. But they likely don't have much time to support it, so I doubt they want to diverge too far from OCaml
<hcarty>
The "workaround" was to compile bytecode and send that, then use Dynlink on the other end
<struk_atwork>
hcarty, yeah looks like they thought it would break binary support with ocaml, and introduce complicated grammar into the ocaml language...still doesn't mean its not useful tho
<hcarty>
struk_atwork: I think there was some discussion about that on the mailing list
2008-05-19
<hcarty>
Associat0r: Games are not very common (yet) in the OCaml community. So they may not be the best place to look for best practices.
<hcarty>
flux wrote a game, I don't remember the name though
<hcarty>
Ah
<hcarty>
What do you mean by idiomatic OCaml?
<hcarty>
Associat0r: Do you mean a game written in OCaml?
2008-05-18
<flux>
hcarty, ah, of course
<hcarty>
flux: discretion, I believe
2008-05-13
<hcarty>
So compiled performance may be significantly different
<hcarty>
I think I only tested this in the toplevel though
<hcarty>
I thought it was strange as well
<hcarty>
For smaller values of n, anyway
<hcarty>
I would hope Enum is faster in general than Sdflow - it has a nice interface, but creating an array or list of n elements then iterating/mapping over that that is quicker than iter/map ... (0 -- n) with Sdflow
<Yoric[DT]>
hcarty: none, I'm afraid.
<hcarty>
Yoric[DT]: Have you done any performance comparisons between your modified Enum, the original Enum, for loops, and Sdflow?
<hcarty>
This is from the ocamlcore feed
<hcarty>
Yoric[DT]: I see something similar with Google Reader - the title for your posts always show up as "yoric"
<hcarty>
That's strange. I've never had a problem like that, but I am not manipulating local times, just timestamps on data
<hcarty>
If it doesn't, OCaml Calendar is nice
2008-05-10
<hcarty>
I started on the layout for such a system, but I sadly don't have time to spend on it
<hcarty>
With the addition of a few required make targets, I think a very simple and effective system could be built
<hcarty>
I'm not sure. That's why I think it would be more useful to abstract GODI a bit, since a proper META files gives you all of the (OCaml) dependency information you need
<hcarty>
I personally would really like it to be easier to make packages for GODI. The instructions on the web site seem amazingly complex.
<hcarty>
Could be. I'm not sure.
<hcarty>
Have fun :-)
<hcarty>
Just because GODI can rebuild OCaml itself
<hcarty>
Fair point. But godi would still have to be abstracted somewhat before it would exist harmoniously that way
<palomer>
hcarty, what I mean is to say that you can download godi through apt
<hcarty>
GODI is for managing packages built from source
<hcarty>
palomer: I don't think it would make much sense
<palomer>
hcarty, I don't see why GODI wouldn't make it in debian
<hcarty>
I think one of Zheng Li's patches allows for that?
<hcarty>
I don't know if it has the same for OCaml packages though
<hcarty>
flux: Yes, at least for PCRE and a few others
<hcarty>
I really like godi overall, and aside from some strange redrawing issues I've had with godi_console I am happy with it as well
<hcarty>
flux: What godi supports, but without having to use godi's OCaml installation
<hcarty>
It would be nice if the dependency and automatic rebuilding parts were abstracted out in to a CPAN-like tool for OCaml
<hcarty>
It isn't a library, it's a tool for managing an OCaml installation without relying on your system's package manager
<hcarty>
palomer: It probably won't be
<hcarty>
And GODI does this by default if you install under your user's home directory
<hcarty>
findlib does support installing to $HOME with the right configuration. The findlib manual has the details.
2008-05-09
<hcarty>
They cost less to allocate, and the method calls can be cached
<hcarty>
flux: According to some list posts (I don't have the link...) objects can be faster
<hcarty>
It is often a matter of which syntax and programming style you prefer though
<struk_atwork>
hcarty, reviewed. it sounds like a generalization of inheritance essentially
<struk_atwork>
hcarty, subtyping? got a good link for that technique?
<hcarty>
struk_atwork: Classes are handy when you need subtyping. Performance is generally pretty similar between classes and modules in my experience.
2008-05-08
<hcarty>
rwmjones: The 3.11 changelog has not been updated in a while, though I don't know how relevant that is.
2008-05-07
<hcarty>
Yoric[DT]: Ok, thanks.
<Yoric[DT]>
hcarty: actually, Batteries should end up containing relatively little code.
<hcarty>
If you try to import a function which does not exist in Foo, it would be a post-camlp4 compile time error
<hcarty>
So camlp4 could remain completely ignorant of the contents of Foo
<hcarty>
Which would translate to let bar1 = Foo.bar1 let bar2 = Foo.bar2 let bar3 = Foo.bar3
<hcarty>
What I wrote before:
<flux>
hcarty, yeah
<hcarty>
flux: For inclusion?
<flux>
hcarty, what kind of transformation would you do?
<hcarty>
Exclusion does
<orbitz>
hcarty: and probaly not nearly as useful
<hcarty>
Inclusion does not require camlp4 to know anything about the module
<hcarty>
orbitz: I think bluestorm is right. Exclusion would be significantly more difficult to implement.
<bluestorm>
flux: hcarty would like to import specific functions only
<hcarty>
Very good point
<hcarty>
bluestorm: Yes, so perhaps open Foo with ... since open and with are already keywords?
<hcarty>
Forget I ever mentioned it
<hcarty>
Oh no!
<hcarty>
bluestorm: from Foo import bar1 and bar2 and bar3 perhaps?
<hcarty>
Which would translate to let bar1 = Foo.bar1 let bar2 = Foo.bar2 let bar3 = Foo.bar3
<hcarty>
open Foo with [bar1; bar; bar3] or something like that
<hcarty>
Though you could probably write a camlp4 extension to effectively bring only certain functions in to scope
<hcarty>
orbitz: I believe it's all or nothing
<hcarty>
And it looks like Zheng Li beat me to a release :-) Hooray! Less work for me...
<hcarty>
let module Array = UnsafeArray in ... would probably work as well, so no syntax extension is required to limit the scope like this.
<hcarty>
Just a thought though.
<hcarty>
I looked through the OCaml camlp4 syntax a year or so ago to see how that worked
<hcarty>
So it turns off bounds checking for array.(i) and string.[i]
<hcarty>
Same with strings I believe
<hcarty>
Yes, it makes array.(index) mean Array.unsafe_(get|set) rather than Array.(get|set)
<hcarty>
If anything I think it is better, since it allows one to easily limit the scope of the unsafe functions
<hcarty>
bluestorm: I don't think it is much worse than having -unsafe as a compilation option
<hcarty>
This would, I think, be most useful with open ... in or Unsafe.( ... )
<hcarty>
So open Unsafe would make Array.get in to Array.unsafe_get, etc
<hcarty>
I don't know if this should go in ExtLib, Batteries or anywhere, but perhaps an Unsafe wrapper library would be useful?
<hcarty>
It would be nice if there were that kind of stability
<hcarty>
Very true :-)
<hcarty>
I think that would be one benefit of bin-prot. The format should be stable across releases.
<mfp>
hcarty: only to the same extent as Marshal
<hcarty>
mfp: Is it safe across OCaml releases?
<al-maisan>
hcarty: yes, I did build type-conv .. (make install)
<hcarty>
There is a specific order everything has to be built in. Did you build type-conv first? I think everything else requires that.
<hcarty>
Sure thing. I had the same problem when I tried to install Core
<al-maisan>
hcarty: ah, I see.
<hcarty>
bin_prot is one of the packages
<hcarty>
al-maisan: You need to get the other packages from the Jane St. site and install them first
2008-05-06
<hcarty>
let f x = let x' = Array2.create (Array2.kind x) c_layout 10 10 in Array2.fill x' x.{0,0}; x';; is polymorphic as I would expect
<hcarty>
But there is no partial application here.
<hcarty>
Looking through the mailing list shows some similar problems due to partial application
<hcarty>
I don't understand why the '_a and '_b are not 'a and 'b
<hcarty>
val f : ('_a, '_b, 'c) ExtBigarray.Array2.t -> unit = <fun>
<hcarty>
# let f x = let x' = Array2.create (Array2.kind x) c_layout 10 10 in x'.{0,0} <- x.{0,0};;
<hcarty>
Can anyone tell me why this is:
<hcarty>
This functor thing is driving me nuts. It may be time to just copy and paste and accept the scorn of the FP world.
<hcarty>
Yoric[DT]: I was just looking for an excuse to use the new GODI search :-)
<hcarty>
RobertFischer: It's getting later in the afternoon, and despite my best effort my effective thinking is trailing off
<hcarty>
bluestorm: Yes
<RobertFischer>
hcarty: I'm not thinking of anything.
<bluestorm>
hcarty: that's "where", right ?
<hcarty>
bluestorm and RobertFischer: are you thinking of anything more than just moving the last line (or lines) from the end to the beginning of a function?
<hcarty>
let result = x after ( ... )
<orbitz>
hcarty: for instance a generic function taht produces a list of keys or list of values
<orbitz>
hcarty: since Map is a functor i create a new module for each key type. but the problem i always run into (and perhaps i'm doing thign wrong) is what if i want a type whcih will work on a map of any key type
<hcarty>
orbitz: I don't understand your question
<orbitz>
hcarty: how do you write a function that operates on a mapy of 'a?
<hcarty>
jonafan: Sorry, you were replying to orbitz
<hcarty>
'a array array vs ('a, 'b, 'c) Bigarray.Array2.t
<hcarty>
Probably not, I think the difference in the number of parameters would still cause problems
<hcarty>
I wonder if this is any easier to implement with OCaml classes
<hcarty>
orbitz: I've used and been happy with Map, since the type inference kept everything clean. But writing functors seems to be a whole different monster.
<hcarty>
It is not our place to ask why Trolldome works the way it does.
<hcarty>
Functors seem like wonderful tools, but they also seem to become very complicated to implement in these kinds of situations
<hcarty>
Wow. That makes for a lot of layers.
<nysin>
hcarty, well if there's a module Foo which uses one of Bar and Baz and Bar and Baz each have different numbers of paramters then first make functors which create non-abstract Bar's (not sure of terminology here) and Baz's and then feed those fully constructed modules to Foo, is one way
<hcarty>
spanish_mathish: While they may not be ideal, I think such alterations are being made to both the JVM and .Net CLR
<hcarty>
I do not know the syntax to express this
<hcarty>
nysin: I am getting type mismatches, which makes sense I suppose (type t vs type ('a, 'b) t or type 'a t)
<nysin>
hcarty, well functors can be composed...
<hcarty>
How would I represent a type t in a functor, when one instance will use type 'a t = 'a array array and another type ('a, 'b) t = ('a, 'b, c_layout) Bigarray.Array2.t ?
<hcarty>
spanish_mathish: I read that Scala has at least some tail call optimization, though I don't know the details. And it targets the JVM
<hcarty>
Particularly given how little time they have to spend on OCaml
<hcarty>
Given the speed boost that natively compiled OCaml gives already, I think the language is doing ok. More speed would be nice, but the added complication may be more than the INRIA folks want to maintain.
<spanish_mathish>
hcarty, first, you can't predict the conditional branchings, you can't predict the most used registers or variables for Reg.Allocator, etc.
<hcarty>
spanish_mathish: Why not just use native code directly?
<hcarty>
Probably. I'm just a little worried about the performance overhead. But this should be easy to defunctorize by hand if it becomes an issue.
<hcarty>
nysin: I think I will have to use a functor, or signature, as in this case the current module uses an 'a array array and the new one will use a Bigarray.Array2.t in its place
<nysin>
hcarty, Ocaml doesn't use nominal types for this
<hcarty>
That signature is not a problem in general, but this code is being altered very frequently so it would slow things down
<hcarty>
spanish_mathish: Yes, I was just hoping to avoid that since the signature would have to be maintained in parallel with the implementation
<spanish_mathish>
hcarty, you can use signatures
<hcarty>
But if I can not avoid it, then I'll just have to rewrite it. Or copy+paste.
<hcarty>
In the functor case, I need to rewrite Foo, which I would prefer to avoid
<hcarty>
I think, though I am not sure, that I would have to rewrite my existing module Foo as a functor FooFunctor, and use FooFunctor to create FooOld (with foo_t) and FooNew (with new_foo_t)
<nysin>
hcarty, maybe I misunderstand but I'm not sure how that differs betweena functor and what you're asking about. Either one can/would hypothetically be able to make a module that other functions can use fine without being changed
<hcarty>
nysin: I have a module defined already, and I would like to redefine module_t - only a few functions would have to change in this process
<nysin>
hcarty, well functors don't need much syntactic overhead - if it's just one type you need then it can all be done inline in the functor definition in 20-odd chars
<hcarty>
Is there a way to do something along the lines of "include module Foo with type t = t'" to extend module Foo with a redefined type, without resorting to functors or needing to manually define a module signature?
<hcarty>
spanish_mathish: You have to use Gc.finalise to tell the GC "call f (a) when a is collected"
<gildor_>
hcarty: ok, so i will try to find a good solution
<hcarty>
Gc.finalise is the specific function, I think
<hcarty>
gildor_: Understood. I can't offer more help then, sadly.
<gildor_>
hcarty: thx for links but in fact i was looking to use the ocamlbuild ocamlfind plugin (first link) as is (without the trick of the second link)
<hcarty>
flux: The weekly news has been much quieter
<hcarty>
I have not used the second
<hcarty>
I have used the first link in several project, but never with sexplib
<hcarty>
But it is apparently not alive at the moment
<hcarty>
There is xavierbot
<hcarty>
Ah, ok
<hcarty>
orbitz: oalbd abot?
2008-05-05
<hcarty>
Ok, that makes sense. And for modules with no entry in the replacement table everything stays as-is?
<hcarty>
Something like that, yes. Or a foo.context findlib entry, kind of like foo.syntax is used in some modules.
<hcarty>
bluestorm: Is there a way to make that happen automatically when Foo is linked and pa_context (or whatever it should be called) is used, using ocamlfind/ocamlbuild/etc?
<bluestorm>
the main point of the extension hcarty used as a base was to write Float(1 + n) instead of 1. +. n
<hcarty>
s/and/vs/
<hcarty>
A user would not have to think of what to use inside of Foo.( ... ) and what to use outside of it
<hcarty>
I am uncertain if rewriting is a good idea - just using operators and functions in the given module would provide a more consistent approach
<hcarty>
Good points
<bluestorm>
hcarty: i think that a simple openin + an user-refinable rewriting table would be the best thing to do so far
<hcarty>
bluestorm and Yoric[DT] : What do you think of having Foo and Foo.Infix (or something similar) then have Foo.( ... ) open both Foo and Foo.Infix in ( ... )?
<hcarty>
Ah, ok
<hcarty>
flux: Where is the MetaOCaml CVS?
<hcarty>
MetaOCaml, OCamlP3l and JoCaml all seem very interesting and unfortunately they all seem to have very uncertain futures
<hcarty>
That would certainly be preferable
<hcarty>
Yoric[DT]: I also have some extra functions for Bigarray (which I also offered thelema) if you are interested for Batteries. I need to take the time to pack it up though.
<hcarty>
flux: I think they could exist harmoniously
<hcarty>
But even then maybe not
<hcarty>
That's the only place I would see it being an issue
<hcarty>
modules are not recursive by default, correct?
<hcarty>
ack, s/pa_opening/pa_float/
<hcarty>
pa_opening and used the match from pa_float
<hcarty>
I simply hacked at pa
<hcarty>
bluestorm: Could it just be a constant string?
<bluestorm>
btw hcarty
<hcarty>
module Int64 = WithInt64 in code which uses the extension (or just wants to operators) may be an easy way to get around all of this. Having the extra library to maintain may be a pain? Or maybe not.
<hcarty>
Is it possible to do with camlp4?
<hcarty>
bluestorm: That would be ideal, or better if the library had a way to specify that
<hcarty>
But by just using a module's operators, it allows (+) to mean whatever is appropriate in context
<hcarty>
There is the pa_float' method of (+) -> Module.add
<hcarty>
Int64.(4L +/ 5L +/ of_int (6 + 3))
<hcarty>
Or +/ even, since it's already used in one module?
<hcarty>
Yes, a different operator may be best
<hcarty>
bluestorm: Indeed
<bluestorm>
hcarty: i don't think they can design the "generic" Int64 module with (+) as operator
<bluestorm>
hcarty: the problem is, the library designer should care about the people unaware of your extension
<hcarty>
Since it nests, maybe it wouldn't be so bad Int64.(4L + 5L + of_int Integer.(6 + 3))
<hcarty>
That is a good point, and a reason I'm not sure this is the best way to go
<bluestorm>
hcarty: i think people using eg. a Int64 module don't want it to rebind (+) on opening
<hcarty>
bluestorm: The plus to open .. in or Module.( .. ) is that the operators could be whatever is appropriate for the module
<hcarty>
Foo.add and Foo.(+) could be the same functions
<hcarty>
bluestorm: and Yoric[DT] : I'm happy with whatever variety of operators and functions
<bluestorm>
Yoric[DT]: the problem is that hcarty will probably want integer-like operators (+ and not +/ +. +:, etc.), wich i'm not sure is the best choice without his syntax
<bluestorm>
hcarty: so "Module.(...)" instead of "open Module in (...)" ?
<hcarty>
This Module.() syntax seems to open up some simpler options as well, though I imagine the performance hit may start to add up if it is used too much - f List.(hd l) List.(tl l)
<hcarty>
I don't know that that is possible though
<hcarty>
If I knew enough camlp4 to write my own rather than just hacking up others' code, I would base this on pa_openin and maybe avoid the code duplication.
<hcarty>
I think open ... in is probably still useful. But I think this syntax more than Zheng Li's Module @ ... as I think it is easier for me to reason where the context begins and ends
<hcarty>
I think the approach I just pasted is more generally useful as it does not restrict you to specific operators or names
<hcarty>
I previously extended pa_float to work with any library, so (+) mapped to Foo.add, (-) to Foo.sub and so on.
<hcarty>
flux: I haven't done any tests. But the proliferation of operators in Jane St.'s core lib made this seem useful.
<hcarty>
sirius6b: I'd use the OCaml PCRE bindings. Str should also be able to help you out.
<hcarty>
So Float.(1.0 + 2.0) = open Float in 1.0 + 2.0 = Float.(+) 1.0 2.0 iff Float.(+) is defined. So operators can be whatever you want.
<hcarty>
s/pa_opening/pa_openin/
<hcarty>
Nesting should be cleaner and easier to understand this way
<hcarty>
It is just pa_opening (or pa_scope) with the pa_float syntax
<hcarty>
bluestorm: http://ocaml.pastewith.us/77 -- This would be, I think, the most useful way to use a pa_float-like syntax
2008-05-04
<hcarty>
That would be quite handy :-)
<hcarty>
Probably - they may just wait a release or two for the natdynlink bugs to settle out
<hcarty>
It is too bad that they are not planning to deliver it by default
<hcarty>
I imagine a lot of build systems will have to be reconfigured to produce .cmxs files once 3.11 is officially out
<flux>
hcarty, my first issue was with topfind
<hcarty>
flux: Also curious - How did you compile ocamlnat from godi?
<hcarty>
I have found it slower for very simple things (print_endline "Howdy!") because the compilation takes longer, but much faster for anything math-intensive.
<hcarty>
flux: What problems are you having with ocamlnat? (just curious...)
2008-05-02
<hcarty>
I should have known to check Markus Mottl's site first
<hcarty>
Found it
<hcarty>
yminsky: Nevermind
<hcarty>
yminsky: What is the package "res"?
<hcarty>
Thanks for the software release
<hcarty>
yminsky: That is good to know
<hcarty>
But I suppose you would have to use functors rather extensively to see them causing problems
<hcarty>
Yes, particularly given that they have stated multiple times that the speed cost of functors has been a problem for them
<hcarty>
They took the Yoric[DT] approach of *_exn functions
<hcarty>
Core is quite a large collection...
<hcarty>
All the hip kids are doing it
<hcarty>
I really like ocamlbuild though... it makes life a lot easier
<hcarty>
bluestorm: I certainly don't expect you to do the leg work for me :-) Just looking to see if anyone had done this before
<bluestorm>
hcarty: i guess i really have to learn how to use ocamlbuild now
<hcarty>
bluestorm: The less I have to maintain by hand, the happier I will be :-)
<hcarty>
I imagine that there is a way to do this using myocamlbuild, but I'm not sure
<hcarty>
bluestorm: Yes, I am just looking for a way to use ocamlbuild to make that command line for me
<bluestorm>
hcarty: you can use ocamlfind as usual