<palomer>
if you annotate your references with grounded types, then you don't need the value restriction
goalieca has joined #ocaml
<tsuyoshi>
oh.. well it depends
<tsuyoshi>
you have some example code where you're running into the problem?
<palomer>
I'm evaluating ocaml as a candidate language to compile into; the value restriction makes it an impossible choice
<tsuyoshi>
oh, in that case I don't know what to tell you
<tsuyoshi>
but if you have specific type annotations with no polymorphism, then there shouldn't be any problems
<palomer>
hmm
<tsuyoshi>
if you want something to be polymorphic, then you can often work around it by putting the problem function into a record
<tsuyoshi>
(or into an object, but most ocaml coders find objects to be annoying)
<palomer>
objects aren't popular?
<tsuyoshi>
no... I think because with a functional language, they're only really useful with inheritance, but inheritance tends to confuse the type inference
<palomer>
hrmph
<palomer>
I'll have to think about that
<tsuyoshi>
you have to explicitly coerce objects to a specific type sometimes
<palomer>
that must be annoying
<palomer>
getting back to my polymorphism problem
<palomer>
some of my terms will be polymorphic
<palomer>
but all variables inside my reference types will be monomorphic
<palomer>
(ie, grounded)
<palomer>
that's how they used to do it before the value restriction
* palomer
goes and grabs a snack
pattern has joined #ocaml
evn has joined #ocaml
evn has quit [Client Quit]
dynamix has joined #ocaml
AxleLonghorn has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
jlouis_ has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
postalchris has joined #ocaml
jderque has joined #ocaml
postalchris has quit [Client Quit]
jderque has quit ["leaving"]
ttamttam has joined #ocaml
dynamix has quit [Remote closed the connection]
AxleLonghorn has left #ocaml []
szell` has joined #ocaml
middayc has joined #ocaml
pango has quit ["I shouldn't really be here - dircproxy 1.0.5"]
pango has joined #ocaml
szell has quit [Read error: 110 (Connection timed out)]
middayc_ has joined #ocaml
l_a_m has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
middayc_ has quit [Read error: 110 (Connection timed out)]
thermoplyae has quit ["daddy's in space"]
filp has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
mwc has joined #ocaml
Yoric[DT] has joined #ocaml
middayc has joined #ocaml
olleolleolle has joined #ocaml
mwc has quit [Remote closed the connection]
goalieca has quit [Remote closed the connection]
Yoric[DT] has quit ["Ex-Chat"]
coucou747 has joined #ocaml
OChameau has joined #ocaml
lidi20 has joined #ocaml
lidi20 has quit [Client Quit]
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
coucou747 has quit [Remote closed the connection]
OChameau has quit [Read error: 104 (Connection reset by peer)]
Linktim has joined #ocaml
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
coucou747 has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
OChameau has joined #ocaml
hkBst has joined #ocaml
OChameau has quit [Read error: 104 (Connection reset by peer)]
middayc has left #ocaml []
evn has joined #ocaml
evn has quit []
Yoric[DT] has joined #ocaml
Tetsuo has joined #ocaml
mattam has joined #ocaml
OChameau has joined #ocaml
julm has quit [Read error: 104 (Connection reset by peer)]
julm has joined #ocaml
middayc has joined #ocaml
jlouis_ has quit ["brb"]
linktim_ has joined #ocaml
linktim__ has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
delamarche has joined #ocaml
olleolleolle has left #ocaml []
linktim_ has quit [Read error: 110 (Connection timed out)]
det_ is now known as det
linktim_ has joined #ocaml
linktim__ has quit [Read error: 110 (Connection timed out)]
middayc has left #ocaml []
acatout has quit [Read error: 104 (Connection reset by peer)]
bluestorm has joined #ocaml
acatout has joined #ocaml
romanoffi has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
Snrrrub has joined #ocaml
Snrrrub__ has joined #ocaml
Poulet has joined #ocaml
AxleLonghorn has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
linktim__ has joined #ocaml
Snrrrub__ is now known as Snrrrub
Poulet has quit []
linktim_ has quit [Read error: 110 (Connection timed out)]
LordMetroid has joined #ocaml
jlouis has joined #ocaml
linktim__ has quit [Read error: 110 (Connection timed out)]
delamarche has quit []
delamarche has joined #ocaml
pango has quit [Remote closed the connection]
mbishop_ has joined #ocaml
delamarche has quit [Client Quit]
AxleLonghorn has left #ocaml []
julm has quit [Read error: 104 (Connection reset by peer)]
julm has joined #ocaml
pango has joined #ocaml
madroach has joined #ocaml
kig has left #ocaml []
mbishop has quit [Read error: 110 (Connection timed out)]
Snrrrub__ has joined #ocaml
ttamttam has left #ocaml []
filp has quit ["Bye"]
marmottine has joined #ocaml
ygrek has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
bongy has joined #ocaml
thelema has quit [Read error: 110 (Connection timed out)]
OChameau has quit ["Leaving"]
petchema has joined #ocaml
<jonafan>
so
jderque has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
jstanley has joined #ocaml
<jstanley>
Does anyone have some general purpose C array -> OCaml list marshalling code lying around? The CAMLlocalN macro is not working for a variable-length array for me (obviously).
<flux>
I don't, but could you make use of Bigarray-module to do it for you?
<flux>
that is, make the ocaml code see the array, which would then proceed converting it to a list
<flux>
shouldn't be that difficult to convert it into a list in C either, though..
<jstanley>
flux: hmm, that's not a bad idea, i spose.
<rwmjones>
jstanley, yes probably let me take a look
<rwmjones>
that's C array of strings -> string list in ocaml
<rwmjones>
on the return path
<rwmjones>
r is length of the C array
Yoric[DT] has joined #ocaml
<rwmjones>
actually, no sorry I'm wrong
<rwmjones>
that converts to an OCaml array
Yoric[DT] has quit [Read error: 104 (Connection reset by peer)]
<flux>
I've used a utility function static value CAMLprim cons_list(value a_value, value a_list) { CAMLparam2 (a_value, a_list); CAMLlocal1 (result); result = caml_alloc_small(2, 0); Field(result, 0) = a_value; Field(result, 1) = a_list; CAMLreturn (result); }
<jstanley>
rwmjones: yeah, i'd expect to see explicit car/cdr sets for a list
<flux>
and a piece of code using it: rservers = empty_list(); { GSList* it; for (it = servers; it != NULL; it = it->next) { SERVER_REC* server = it->data; rserver = wrap_server(server); rservers = cons_list(rserver, rservers); } }
<flux>
oh, right, and this: static value CAMLprim empty_list(void) { CAMLparam0(); CAMLlocal1 (result); result = Val_int(0); CAMLreturn (result); }
<jstanley>
flux: ah, that would work for me. i was hoping to not have to repeatedly call cons though
<rwmjones>
lots of functions generate lists
<jstanley>
rwmjones: looking
<rwmjones>
eg perl4caml_call_array
<rwmjones>
/* Pop all the return values off the stack into a list. Values on the
<rwmjones>
* stack are mortal, so we must copy them.
<rwmjones>
*/
<rwmjones>
list = Val_int (0);
<rwmjones>
for (i = 0; i < count; ++i) {
<rwmjones>
SV *sv;
<rwmjones>
cons = caml_alloc (2, 0);
<flux>
jstanley, well, it's a list..
<rwmjones>
Field (cons, 1) = list;
<rwmjones>
list = cons;
<rwmjones>
sv = newSVsv (POPs);
<rwmjones>
Field (cons, 0) = Val_sv (sv);
<rwmjones>
}
<jstanley>
rwmjones: cool
<jstanley>
flux: no, i gotcha -- i just mean to marshall and entire array over, i wouldn't want to cons up the list one element at a time
<jstanley>
flux: wanted to be able to prealloc all of the cons cells and just rip down the array etc.
<jstanley>
thanks rwmjones and flux, this should give me a good start.
<rwmjones>
you might want to consider leaving it as an array on the OCaml side, since that will be more efficient (although less convenient usually)
<jstanley>
rwmjones: yeah, i don't have that option easily, as the api i'm binding to is pretty fixed.
<rwmjones>
right
<rwmjones>
camlidl is a possibility also, although I find it fairly frustrating to use in real-world cases
<jstanley>
rwmjones: yeah, already investigated. i'm having to write a custom binding generator.
<jstanley>
rwmjones: right now it's just a simple generator, but i'll likely extend it to .mli parsing and module awareness relatively soon
<jstanley>
rwmjones: we have a frankenstein memory management model that camlidl, etc., aren't going to give us. we have to promote a lot of ocaml heap objects to global roots so that we can pass them over to *another* FFI (in this case, Poly/ML).
<rwmjones>
jstanley, yes been there too. I wrote a custom generator for libvirt
<rwmjones>
in our case camlidl fell down because it doesn't know how to generate weak symbol bindings
<jstanley>
rwmjones: ahh.
<jonafan>
asdf
<rwmjones>
oh yeah, and the other problem is that camlidl doesn't understand that C objects can be "related" to each other
<rwmjones>
eg. in libvirt there's some half-assed refcounting scheme
<rwmjones>
so a "connection" creates "domain" objects
<rwmjones>
but you can't close the connection until all the domain objects are freed (first)
<rwmjones>
because if you do that it kills all your domain objects which migth still be live in ocaml code
<rwmjones>
it's a nightmare
<rwmjones>
bloody C programmers ...
<rwmjones>
ODE has the same problem when I was writing ocamlode .. there's implicit dependencies between all the objects, the forces between them and the "world" object
<jonafan>
so who's sold on unit testing
<jstanley>
rwmjones: hehe
<jstanley>
rwmjones: that sounds really painful.
<hcarty>
jstanley: I don't know if it will help, but I saw a few recent posts on one of the OCaml feed aggregators on inline-C in OCaml
<hcarty>
They seem to be very simple, but may be helpful for your binding generation
<jonafan>
it seems like i'm only going to think to write tests for things that are super easy to catch in the first place
<rwmjones>
the thing that would help is for people to stop writing stuff in C ...
<jstanley>
hcarty: i'd be interested in taking a look, anything that might clean up this mess would be a good thing.
<jstanley>
rwmjones: well in my case, C is only present because it's the only seemingly easily accessible interop mechanism short of some RPC solution.
<jstanley>
rwmjones: the api i want to use externally *is* in ocaml, but i want to use it from inside a Poly/ML runtime.
<jstanley>
hcarty: thanks.
ita has joined #ocaml
<hcarty>
rwmjones: Working with legacy code/data libraries/gui seems to be sadly C-entrenched
<jstanley>
yeah, in my case i've *introduced* the C layer, sadly, but only because it's the only way for Poly/ML and OCaml code to talk together. My fear was that RPC mechanisms would have been too slow, although I'm not convinced that the FFI gymnastics through all 3 layers won't be the same way ;P
<hcarty>
rwmjones: And I will be testing several of those Fedora/RHEL OCaml packages in the next 7-10 days. Thank you for putting them together
<rwmjones>
oh yes, no problem, thanks
<rwmjones>
you'll need rawhide, else adjust the "BuildRequires: ocaml >= 3.10.1" dependency suitably
<flux>
ciml looks interesting
<hcarty>
jstanley: You are welcome - it looks like a nice wrapper, but I have not used it beyond compiling the example
<jstanley>
hcarty: yeah, def. looks interesting.
<hcarty>
rwmjones: Ok. I think I am going to put the latest Fedora 9 pre-release on a test partition to do so
<flux>
nice, change log mostly in french..
<flux>
(version history that is)
<hcarty>
flux: That link is the only English-language description I've seen, though there was at least one other post on it in French
<rwmjones>
hcarty, I don't think F9 installs at the moment, at least people on fedora-devel-list were talking about that. You can always install F8 and upgrade through enabling the development repo though.
Morphous has quit [Connection timed out]
<hcarty>
rwmjones: Thanks for the tip. I am at a conference now, hence the lack of testing so far. I'll see what the state of F9 is when I get home and pick an install method from there.
<hcarty>
F8 may be safer regardless
Amorphous has joined #ocaml
<rwmjones>
hcarty, yes I think just install F8 and them use the SRPMs directly. They may just need to have the BuildRequires adjusting
* rwmjones
checks
det has quit [Read error: 104 (Connection reset by peer)]
<rwmjones>
actually I don't think you'll need to adjust anything
<rwmjones>
be sure to update the BZs though ...
<hcarty>
BZs?
<rwmjones>
bugzilla.redhat.com
<hcarty>
Oh yes, will do
<rwmjones>
any comments useful, even "it worked"
thelema has joined #ocaml
Tetsuo has quit [Remote closed the connection]
middayc_ has joined #ocaml
mwc has joined #ocaml
Ugarte has joined #ocaml
julm has quit [Read error: 104 (Connection reset by peer)]
Tetsuo has joined #ocaml
jderque has quit ["leaving"]
julm has joined #ocaml
jlouis_ has joined #ocaml
goalieca has joined #ocaml
romanoffi has left #ocaml []
thelema has quit [Read error: 110 (Connection timed out)]
jlouis has quit [Read error: 110 (Connection timed out)]
middayc_ has quit []
julm has quit [Read error: 110 (Connection timed out)]
madroach has quit [Read error: 113 (No route to host)]
Morphous has joined #ocaml
postalchris has joined #ocaml
|Catch22| has joined #ocaml
bongy has quit ["Leaving"]
Amorphous has quit [Connection timed out]
Demitar has joined #ocaml
l_a_m has quit [Remote closed the connection]
* Yoric[DT]
needs to find a name for his monad.
<flux>
YoricMonad?
<flux>
TheMonadOfYoric
<Yoric[DT]>
:)
<Yoric[DT]>
It's for my exception-monad.
Morphous has quit [Connection timed out]
<Yoric[DT]>
And, somehow, ExceptionMonad doesn't quite catch the feeling.
rogo has joined #ocaml
<Yoric[DT]>
mmmmhhh... CatchMonad ?
<Yoric[DT]>
CatchMeIfYouCanMonad ?
<bluestorm>
wich kind of exception monad is that ?
<Yoric[DT]>
Always the same one :)
<mwc>
I've never tried monadic programming in a strict language
<mwc>
seems like so many things wouldn't be possible
<mwc>
like unless, when
<bluestorm>
hm
<bluestorm>
you can still add lazy annotations when needed
<mwc>
true
<mwc>
just seems like more trouble than it's worth
<bluestorm>
actually mwc it's interesting to make the effect of lazyness explicit
<bluestorm>
often you end up understanding thing better
<mwc>
bluestorm, very true
<mwc>
that's the route Okasaki takes in PFDF
<bluestorm>
actually that's exactly what Haskell people say about side effect :p
<mwc>
*PFDS
<mwc>
maybe for maximal pedantry we should create a strict, pure language
<bluestorm>
:p
<bluestorm>
there was a question on the mailing list
<bluestorm>
about that one time
<mwc>
with optional lazy primitives, à la Caml
mbishop_ is now known as mbishop
<bluestorm>
mwc: wouldn't a reasonable subset of caml do the job ?
<mwc>
true
<bluestorm>
moreover, there are "function" functions (in the sense of mathematical functions) that you can't express in a pure language
<mwc>
you'd have to abandon a ton of the standard libraries
<bluestorm>
i've read a very short paper about that yersteday
<bluestorm>
hm
<bluestorm>
s/"function"/"functional"/
<mwc>
bluestorm, true, but I found that when I had to do that, the ST monad worked nicely
<bluestorm>
hm
<bluestorm>
i'm not sure the ST monad would do the job
<mwc>
why, you get imperative, in place-update reference cells and mutable arrays
<Yoric[DT]>
Can anyone tell me if Haskell actually has exceptions ?
<jstanley>
Yoric[DT]: Haskell has about 8 different ways of *doing* exceptions :P
<Yoric[DT]>
I mean not a monad which behaves like exceptions but built-in exceptions.
<jstanley>
Yoric[DT]: and there is of course an exception monad
<mwc>
Yoric[DT], not in the language
<Yoric[DT]>
Yeah, but to the best of my knowledge, they're all monads :)
<jstanley>
Yoric[DT]: *nod*
<mwc>
exceptions play very poorly with laziness
<Yoric[DT]>
That was my suspicion.
<bluestorm>
Yoric[DT]: difficult to differentiate built-ins and monads
<Yoric[DT]>
But Haskellers are sometimes a treacherous bunch. They've managed to sneak states inside a purely functional language, after all :)
<jstanley>
Yoric[DT]: lol
<mwc>
consider something like foo (try bar handle Baz -> quo)
<bluestorm>
i suppose for example you'd consider ST a "built-in" thing, although it could be implemented as a library, couldn't it ?
<mwc>
suppose bar throws an exception, but it doesn't occur until foo forces evulation of it
<mwc>
or not until something else forces foo
<mwc>
maybe you could tag each thunk with an exception handler to push?
<mwc>
but I'm not surethat's sufficiently rigourous
<mwc>
anyhoo, I should go purchase foodstuffs
<Yoric[DT]>
have a nice purchasing foodstuffs
* Yoric[DT]
actually doesn't really see the problem.
<palomer>
erm, doesn't haskell have exceptions in IO?
<jstanley>
palomer: yeah, Control.Exception in base
<jstanley>
try/catch/etc are all in the io monad
<jstanley>
palomer: could still be argued that they're not "in" the language itself.
<Yoric[DT]>
Well, iirc, a big difference between these exceptions and ML exceptions is that propagation has to be performed manually.
<Yoric[DT]>
Am I wrong ?
<Yoric[DT]>
That is, propagation of uncaught exceptions when some exceptions are caught.
<jlouis_>
Yoric[DT]: partly. In the IO monad, you only need to propagate the IO-type
<jlouis_>
If you use the Either monad (A treacherous name for a sum type A + B in a monad), then you have to propagate knowledge about it in the types and lift everything
<Yoric[DT]>
What's the nature of "Non-exhaustive patterns in function foo" ?
<Yoric[DT]>
jlouis_: don't you need to perform "ioError stuff" ?
<Yoric[DT]>
In your `catch` ?
<jlouis_>
Yoric[DT]: Its been too long for me to keep the language specifics in my head :/
<Yoric[DT]>
ok
<jlouis_>
ie, I can't remember
<Yoric[DT]>
Thanks for the input, though.
<jstanley>
newbie ocaml question -- can i bind a name to a pattern match? e.g., in haskell i can do mytup@(a,b) in a pattern match context for a tuple.
<bluestorm>
"as"
<bluestorm>
match foo with _ as bar -> ...
<jlouis_>
In general, whenever you have a monadic effect, the type of the function encodes the effect(s). Consequence: Your program must reflect the type. Corollary: Changing effects may alter large call paths
<jstanley>
ah, cool. thanks bluestorm
<Yoric[DT]>
jlouis_: yeah, for some definition of effect :)
<jlouis_>
Yoric[DT]: indeed, it needs to be monadic, as I said :)
<bluestorm>
jlouis_:
<bluestorm>
the IO being a trade-off between "the type of the effect is informative" and "i don't bother with ugly combinators"
thelema has joined #ocaml
ygrek has quit [Remote closed the connection]
linktim_ has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
thelema: unless I'm mistaken, you just answered a different question on the mailing-list.
<Yoric[DT]>
s/different/wrong/
<thelema>
really?
* thelema
double checks what he wrote
<thelema>
oops, match case unused != match failure
julm has joined #ocaml
* thelema
should have read the post more accurately
<julm>
hi all
<Yoric[DT]>
hi
<Yoric[DT]>
julm: btw, I've fixed my Obj.magic bug.
middayc has joined #ocaml
<julm>
nice :) how did you do?
<Yoric[DT]>
It was actually a copy-and-paste-and-mix error due to too many open .ml files and too little sleep :)
<julm>
tout est bien qui fini bien alors =)
marmottine has quit [Remote closed the connection]
<Yoric[DT]>
:)
<julm>
2008 fév 22 22:08:23 <flux> if you know a function you call can use such exceptions, you could just pass the thing to do on exception as an argument <-- yep, but passing it with an exception removes the need to convey an argument on all intermediate functions which do not care at all of `the thing to do'.
<julm>
that was about Common Lisp exception handler
<julm>
thelema: about the community's stdlib, shall it only handle UTF-8 and a few algorithms working on unicodes, or is there a will to make it handle other encodings too?
<thelema>
If I were building it (.. well, come to think of it, I probably am building it), it'll have two levels of character support.
<thelema>
I'm keeping 100% backwards compitibility (modulo new functions/modules in the stdlib)
<thelema>
so all the existing string functions/infrastructure will stay
<thelema>
but I plan a second "string" type that's more high-level : UTF-8, ropes (thus immutable and resizable), ...
<julm>
no Unicode algorithm? like the normalization forms?
<thelema>
I plan to handle other representations as old-style strings, with functions to convert from those to UTF8 rope-strings
<thelema>
I'll have to survey what everyone else does, but IIRC, linux filesystems use NFC, and if it's good enough for the filesystem, it's good enough for me.
<julm>
so UTF-8 will *only* be usable through a rope-like structure?
<julm>
no abstraction?
<julm>
I mean ropes are not good for everything isn't it, so why enforcing their use?
<jlouis_>
ropes or finger trees mayhaps
<julm>
[23:59:43] thelema | I'll have to survey what everyone else does, but IIRC, linux filesystems use NFC <- a wait a minute, it is the user who choses what form to use, normally
thelema has quit [Read error: 104 (Connection reset by peer)]
<thelema_>
<thelema> I plan on providing utf-8 ropes. I don't plan on anything else.
<thelema_>
Should I?
<flux>
thelema_, wouldn't ropes be nice for plain binary data too? (which would cover all non-utf8-encodings also..)
<julm>
well thanks jlouis_, and so are you arguing like me? that we shouldn't enfore the underlying data structure for the UTF-8 algorithm?
<jlouis_>
Functor.
<flux>
if functors were to be used, the granularity should be need to be something higher than the finest possible, due to efficiency concernrs..
<jlouis_>
But choosing a sensible default is not necessarily a bad idea. If for most uses it tends to be good enough, then it is better saving complexity in the interface in the common case
<jlouis_>
In my opinion, striking a balance between implementation complexity, performance and API simplicity is important.
<thelema_>
flux: plain binary data can go in the current mutable strings. Ropes' overhead is best when you're doing insertions/deletions - it seems reasonable to ask the user to convert to UTF-8 (and I approve of encouraging UTF-8)
<thelema_>
jlouis_: at the moment, the ropes implementation has a functorized version that can plug in any array-like data structure
<thelema_>
but the set of functions defined over those sturctures won't be as rich as I plan for UTF-8 ropes
<flux>
thelema_, file and descriptor io interfaces, would they be utf8-rope-capable or plain strings? or would they be duplicated?
<Yoric[DT]>
Why UTF-8 rather than UTF-16 ?
<flux>
not even utf-16 covers the whole unicode space, so why that?
<Yoric[DT]>
But yeah, I agree that a second layer with Unicode would be important.
<Yoric[DT]>
Because UTF-8 algorithms tend to be linear when they're constant time with UTF-16, iirc.
<Yoric[DT]>
Am I wrong ?
<flux>
you are
<Yoric[DT]>
(I mean things like "get")
<julm>
UTF-8 is smaller, and widely used
<flux>
and if you don't have constant time random access anyway (utf-32 can be wasteful), utf-8 is a good compromise
<thelema_>
IO seems reasonable to lock to binary, and force the user to say what encoding the input its.
<Yoric[DT]>
ok
<flux>
unicode space is much larger than 16 bits
<Yoric[DT]>
My bad.
<julm>
in UTF-8 differents char size is not a constant
<julm>
-differents
<julm>
to reach char n you need to process 1, 2, ..., n-2, n-1
<thelema_>
julm: correct, you lose O(1) access to characters. But with ropes, you don't have that anyway.
<Yoric[DT]>
The question being: when do we need O(1) access to characters ?
<thelema_>
and I imagine it not too difficult to construct partial lookups for easy-enough lookups
<jlouis_>
Actually, when I am manipulating strings in SML (where strings are immutable), you often have something rope-like for fast concatenation anyway
<Yoric[DT]>
I can think of a few cases (Knuth Morris Pratt, etc.), but most users would probably be fine with folds/iters/maps.
Amorphous has joined #ocaml
<jlouis_>
I don't think O(1) access is that important. Make it. Make it correct. Make it fast.
<Yoric[DT]>
Well, we still want "make it fast" :)
<ita>
"code first, think later" is back
Amorphous has quit [SendQ exceeded]
<jlouis_>
ita: You have a type system. It is impossible to "think later"
<Yoric[DT]>
Anyway, I'm going to call it a night.
<thelema_>
ita: you mean "release early, release often"
<Yoric[DT]>
jlouis_: well, Java has a type system, too and look where that got them :)
<Yoric[DT]>
Anyway, good night everyone.
Amorphous has joined #ocaml
<jlouis_>
Yoric[DT]: Yeah, a puny excuse for one, hehe
<julm>
'nuit Yoric[DT]
<ita>
thelema_: actually, release early, release often is not incompatible with "design on paper first, code later"
Yoric[DT] has quit ["Ex-Chat"]
<thelema_>
ita: I like "learn from your mistakes and keep going"
<ita>
thelema_: i do too
<thelema_>
I'm not opposed to thinking, I just find coding to work very well at finding problems that need solving.
<thelema_>
whereas working on paper can stay divorced from "reality" for a long time.
<ita>
from what i have seen on my previous jobs, the work on paper was divorced for a long time because people always made the diagrams once the code was written and that they could not understand anymore how the system worked
<jstanley>
ita: or made the diagrams only for the initial design, which quickly diverged from what the code represented.
Amorphous has quit [SendQ exceeded]
<thelema_>
if the language is high-level enough (and programs get written in high-level style), code == design
<ita>
thelema_: self-documenting code, that's what they all say
Amorphous has joined #ocaml
Amorphous has quit [SendQ exceeded]
<bluestorm>
hm
<bluestorm>
in practice
<bluestorm>
however high may you langage be
Amorphous has joined #ocaml
<bluestorm>
red-black trees are still a pain
<bluestorm>
hm
<thelema_>
I've not written a r-b tree, but I've heard that ocaml's matching makes them much less a pain.
<bluestorm>
of course it doesn't negate what you say
<bluestorm>
but "algorithmic design" is a pain
<bluestorm>
that is, "pure design" isn't necessarily an easy thing
<ita>
especially when there is a bug, and the guy who made it is not available for comments
<thelema_>
Writing software requires a lot of learning to figure out the "real" requirements. I like performing this learning through the process of coding
<ita>
thelema_: i am pretty certain you enjoy this a lot with your colleagues @work
* thelema_
works for self
<ita>
thelema_: that's a very different situation then
<julm>
thelema_: btw, tell me when you've got the UTF-8 decoder working, I'll be glad to test it
<thelema_>
For the projects I've worked on, the hard part was coming up with the "real requirements" - a characterization of the plain English requirements (like "must be secure") into ... precise requirements that can be turned into code.
<thelema_>
julm: thanks. Any chance this testing'll include unit tests?
<julm>
why not =)
<julm>
I've already written a few unit test for my own UTF-8 decoder, so I'll just adapt them
<thelema_>
I'm not a huge fan of unit testing, but I'll give it a try to see how well it works.
<julm>
just take care of incomplete sequences, of overlong forms and of prohibited code points; and it should be fine
jlouis has joined #ocaml
<julm>
And as skaller advised me a few months ago, it's better to use continuations than exceptions when you either encounter a bad sequence or run out of data
ita has quit ["Hasta luego!"]
* thelema_
plans to leave the hard work to the nice people developing the netstrings library. My work will involve taking their code and using it on ropes.
<julm>
well you also have camomile
middayc_ has joined #ocaml
<julm>
also will you handle orfail on UTF-8 chars longer than 4 bytes?
<thelema_>
julm: any preferences between the two?
middayc_ has left #ocaml []
<thelema_>
julm: I plan on the conversion failing when given invalid input.
middayc has quit [Read error: 110 (Connection timed out)]
<julm>
thelema_ | julm: I plan on the conversion failing when given invalid input. <<-- yes, but this kind of validity depends on the standard you're using; I mean for instance Camomile allows UTF-8 chars greater than 4 bytes but nowadays those are prohibited
<julm>
thelema_ | julm: any preferences between the two? <- I've never read a line of netstring, I can't tell =( However, IMHO, Camomille is quite comprehensive but a little hard to decipher :/