bobov has quit [Read error: 104 (Connection reset by peer)]
TimFreeman has left #ocaml []
gl has quit [Read error: 104 (Connection reset by peer)]
gl has joined #ocaml
gl has quit [No route to host]
malc has joined #ocaml
yangsx has joined #ocaml
Yurik has joined #ocaml
<Yurik>
re
yangsx has left #ocaml []
Yurik has quit [Read error: 104 (Connection reset by peer)]
malc has quit ["no reason"]
gl has joined #ocaml
gl has quit [bear.openprojects.net irc.openprojects.net]
Dybbuk has quit [bear.openprojects.net irc.openprojects.net]
exarkun has quit [bear.openprojects.net irc.openprojects.net]
smkl has quit [bear.openprojects.net irc.openprojects.net]
themus has quit [bear.openprojects.net irc.openprojects.net]
dmiles_afkish has quit [bear.openprojects.net irc.openprojects.net]
jaene has quit [bear.openprojects.net irc.openprojects.net]
Belgarion has quit [bear.openprojects.net irc.openprojects.net]
gl has joined #ocaml
Dybbuk has joined #ocaml
dmiles_afkish has joined #ocaml
exarkun has joined #ocaml
smkl has joined #ocaml
themus has joined #ocaml
jaene has joined #ocaml
Belgarion has joined #ocaml
Belgarion has quit [bear.openprojects.net irc.openprojects.net]
jaene has quit [bear.openprojects.net irc.openprojects.net]
gl has quit [bear.openprojects.net irc.openprojects.net]
exarkun has quit [bear.openprojects.net irc.openprojects.net]
themus has quit [bear.openprojects.net irc.openprojects.net]
Dybbuk has quit [bear.openprojects.net irc.openprojects.net]
smkl has quit [bear.openprojects.net irc.openprojects.net]
dmiles_afkish has quit [bear.openprojects.net irc.openprojects.net]
gl has joined #ocaml
Dybbuk has joined #ocaml
dmiles_afkish has joined #ocaml
exarkun has joined #ocaml
smkl has joined #ocaml
themus has joined #ocaml
jaene has joined #ocaml
Belgarion has joined #ocaml
Belgarion has quit [bear.openprojects.net irc.openprojects.net]
jaene has quit [bear.openprojects.net irc.openprojects.net]
gl has quit [bear.openprojects.net irc.openprojects.net]
exarkun has quit [bear.openprojects.net irc.openprojects.net]
themus has quit [bear.openprojects.net irc.openprojects.net]
Dybbuk has quit [bear.openprojects.net irc.openprojects.net]
smkl has quit [bear.openprojects.net irc.openprojects.net]
dmiles_afkish has quit [bear.openprojects.net irc.openprojects.net]
gl has joined #ocaml
Dybbuk has joined #ocaml
dmiles_afkish has joined #ocaml
exarkun has joined #ocaml
smkl has joined #ocaml
themus has joined #ocaml
jaene has joined #ocaml
Belgarion has joined #ocaml
Belgarion has quit [bear.openprojects.net irc.openprojects.net]
jaene has quit [bear.openprojects.net irc.openprojects.net]
gl has quit [bear.openprojects.net irc.openprojects.net]
exarkun has quit [bear.openprojects.net irc.openprojects.net]
themus has quit [bear.openprojects.net irc.openprojects.net]
Dybbuk has quit [bear.openprojects.net irc.openprojects.net]
smkl has quit [bear.openprojects.net irc.openprojects.net]
dmiles_afkish has quit [bear.openprojects.net irc.openprojects.net]
gl has joined #ocaml
Dybbuk has joined #ocaml
dmiles_afkish has joined #ocaml
exarkun has joined #ocaml
smkl has joined #ocaml
themus has joined #ocaml
jaene has joined #ocaml
Belgarion has joined #ocaml
taw has joined #ocaml
<taw>
if i write parser in ocamlyacc + ocamllex then in case of parse error it just throws Parsing.Parse_error exception
<taw>
how can i get information in which line is the error ?
exarkun has quit ["Reconnecting"]
exarkun has joined #ocaml
<smkl>
try something like Lexing.lexeme_start and Lexing.lexeme_end
<taw>
smkl: but where ?
<taw>
try X with Parsing.Parse_error -> Y
<taw>
how can i use it in Y ?
<smkl>
if you do not have the lexbuf, then you can't use it
<taw>
i already found out that
<taw>
there are special variables in c lex/yacc
<taw>
for that
<mr_bubbs>
smkl: that your page that is returned by a google search of smkl? hehe
<smkl>
probably, but it's at least 4 years old
<mr_bubbs>
hehe
taw has left #ocaml []
graydon has joined #ocaml
<Dybbuk>
Howdy guys.
<mr_bubbs>
yello
<Dybbuk>
Anything new?
<mr_bubbs>
nothing much
<mr_bubbs>
just working on my httpd
<Dybbuk>
In Ocaml?
<Dybbuk>
How's it coming?
<mr_bubbs>
yes
<mr_bubbs>
coming along nicely
<Dybbuk>
Cool, that's an awesome thing to have.
<mr_bubbs>
I'll say!
chandan has joined #ocaml
chandan has quit [Client Quit]
<mr_bubbs>
I think it's funny that OOP is not introduced until Chapter 15 in the O'Reilly OCaml book!!
<mr_bubbs>
needs to put more O in OCaml!
<Dybbuk>
mr_bubbs: I still haven't even explored the O in Ocaml much. :)
<mr_bubbs>
Dybbuk: I have! it's fun stuff
Dybbuk has quit ["Desk moving time!"]
two-face has joined #ocaml
<two-face>
hi
<graydon>
I think the thing is that Ocaml even *without* the O is quite powerful, and needs a fair amount of explaining
<two-face>
i fear the native compiler
<graydon>
what's to fear?
<two-face>
i don't know how they intend to make it evolve wrt upcoming architures
<two-face>
architectures
<graydon>
"upcoming" == IA64 or x86-64?
<two-face>
yes, and specifs stuff like sse
<two-face>
currently they are generating x86 code
<two-face>
nothing specific
<graydon>
so you fear that it is emitting microarchitecturally inefficient code?
<two-face>
i fear that it will be beaten some day at benchmarks
<graydon>
it is already beaten at benchmarks by C/C++ and asm.
<two-face>
even C++ ?
<graydon>
benchmarks are not the only story (indeed, they are relatively frivolous beyond a point)
<two-face>
i wonder why not mking it a GCC frontend
<graydon>
safety and productivity are also very important, and ocaml scores admirably well
<two-face>
of course
<graydon>
interfacing with GCC might be possible, but it's not always easy. I can understand their reluctance.
<two-face>
the advantage is that you rely on all available architectures and optimizations
<graydon>
I tend to think (perhaps naively) that the organization of the runtime and the representation of code and data, for such a high level language, plays a much more dramatic performance role than the instruction selection.
<graydon>
with gcc, you also get all the bugs for free :)
<two-face>
perhaps
<two-face>
:)
<graydon>
you see if you look into the ocaml / C interface that the runtime representation is quite sparse, and maps very close to what you would hand-write in C anyways. that decision seems most important to me.
<two-face>
what i don't like too is that the main type are standard types minus 1 bit
<two-face>
i know the OCaml/C interface, i'm writing one :)
<graydon>
what would you prefer?
<two-face>
graydon: ints as 32 bits rather that 31 :)
<graydon>
you need to know whether something is boxed or not, or else you leave the problem to the type system and make all your operations much more complex.
<two-face>
when you interface with C, you may need 32 bits sometimes, so you have to use int32 with is slower
gl has quit ["La foule est une somme d'erreurs qu'il faut corriger."]
<graydon>
you can get boxed 32-bit values, and arrays of unboxed 32-bit values, just not single unboxed 32-bit values. do you really need that case?
<mr_bubbs>
graydon: yes, the Caml bit needs explaining before the "O"
<mr_bubbs>
graydon: but the "O" is way too far down the line in that book, heh
<two-face>
graydon: yes
<graydon>
two-face: perhaps there are times when you need that case, but it is a trade-off when working with a language which has a complex storage manager
<two-face>
mr_bubbs: don't you like the O ?
<exarkun>
I dunno, I think the O is pretty well placed
<graydon>
two-face: and this is a normal, well practised solution to the problem, using a tag bit.
<exarkun>
It's hard to do anything with that part until you get the rest of the syntax and ideology down
<mr_bubbs>
two-face: I do
<mr_bubbs>
exarkun: then it's just an afterthought
<two-face>
graydon: i wonder if there was no other means of taging for the GC
<exarkun>
mr_bubbs: Well, yea. It is, isn't it? O'Caml is just Caml with some OOness tagged on, right? :)
<graydon>
two-face: there are other methods, but they have their own costs
<two-face>
graydon: sure
<mr_bubbs>
exarkun: bummer
<exarkun>
If OO is a prime concern, something like Smalltalk is the way to go :)
<graydon>
two-face: ocaml is the Nth generation in a line of compilers which explored many options, and its current choices are mostly guided by empirical cost analysis
* exarkun
runs away and hides.
<two-face>
exarkun: without efficency of course
<two-face>
graydon: yeah i jnow
<two-face>
know
<graydon>
two-face: for example you can type-specialize your code to different operand combinations, but you pay some icache and page table costs.
<two-face>
graydon: hmm, right
<two-face>
graydon: have you ever tried to interface with C++ ?
<graydon>
two-face: nope. only simple C wrappers.
<exarkun>
C++ doesn't offer much anyway ;)
<mr_bubbs>
a job, probably, hehe
<two-face>
exarkun: what si status of your Qt binding ?
<two-face>
graydon: which is quite straightforward
<graydon>
oh, I disagree. C++ is a widely deployed, portable term-rewriting engine glued onto the front of a C compiler. it's very useful.
<mr_bubbs>
graydon: you work for an advertising agency, by chance?
<exarkun>
Qt?
<graydon>
mr_bubbs: no, I work for red hat. but it's true. the template engine is very flexible and can catch lots of kooky errors at compile time if you're willing to throw arbitrary memory at it.
<exarkun>
graydon: The template engine is great except each implementation works differently, so your code has almost zero portability :)
<two-face>
exarkun: sorry, I thought you were Eray Oskural
<exarkun>
Heh :)
<two-face>
which nick is exa
<exarkun>
graydon: Anyway, doesn't O'Caml already catch a lot of kooky errors at compile time?
<graydon>
exarkun: certainly, and its compile time is usually fantastically faster.
<graydon>
but two points work in C++'s favour
<graydon>
it's widely deployed / well known so you have fewer hoops to jump through to get people to let you work in it
<exarkun>
true
<graydon>
and its template language is actually a bit more powerful than ocaml's type language, though more awkward for doing complex expressions.
<two-face>
graydon: hint: eiffel
<exarkun>
hmm, that may be so. I'm still working out ocaml's typing system
<graydon>
tho when I get the choice of course I take ocaml
<exarkun>
Both languages chafe a lot since my prefered language is python ;)
<graydon>
two-face: hint: unresolvable link-time errors when trying to agree on the type of "self".
<two-face>
exarkun: not the same family
<two-face>
graydon: could you explain a bit more ?
<exarkun>
Nope, not the same family at all.
<graydon>
I'll find a reference, hang on
<exarkun>
Not that C++ and O'Caml are in the same family, either.
<two-face>
exarkun: yes
<mr_bubbs>
doesn't RedHat use an awful lot of Python?
<exarkun>
Apparently their installer is in python
<mr_bubbs>
I see
<exarkun>
But I've no first-hand experience with it
<exarkun>
gentoo is all pythony, too, though the code is kind of scary.
<graydon>
non-working copy & paste on this terminal
<graydon>
yeah, red hat uses a lot of python. and a lot of tcl left over from cygnus days.
<two-face>
what can i find in that page ?
<mr_bubbs>
wish Python was faster
<graydon>
and a lot of m4 and sh from GNU. the horrors never stop.
<exarkun>
ick
<graydon>
two-face: a summary of some of the typing problems in eiffel
<two-face>
graydon: do they intend to fix this? what is the ultimate language you recommend ?
<exarkun>
Languages have strengths and weaknesses. Use a language which has strengths to match your problem domain. :) There are no magic bullets.
<two-face>
you replied well
<two-face>
I also use Ada95
<graydon>
ultimate? there is no ultimate language, just an endless progression of better or worse ones with respect to given tasks. for my tastes, probably the front runners these days are Cyclone, Cayenne, Generic Haskell, and DeCaml.
<two-face>
C# ? :)
* exarkun
snickers.
<graydon>
But plain C++ and Ocaml are OK by me.
<graydon>
it's the regressive trend of using dynamic languages (python, perl, ruby) in infrastructure code that bugs me. stuff that *ought* to be statically analyzed isn't getting even a passing typecheck glance.
<two-face>
they are scrpting languages, they have to be use for that purpose, nothing more
<exarkun>
Types are irrelevant :) Only interfaces matter.
<two-face>
wrong. it is a matter of safety
<graydon>
um
<exarkun>
This is a holy war for another day ;)
<graydon>
the difference being?
<exarkun>
graydon: A good point. At a certain level, I wouldn't say there is one.
<graydon>
at what level would you say there is one? I'm not being difficult -- I just use the words pretty much synonymously and honestly don't know what you're saying.
<exarkun>
In a statically typed language, like O'Caml, two different types can share part or all of their interfaces, but still be considered distinct types. floats and integers, for example.
<exarkun>
Or two different classes that implement many of the same methods
<graydon>
so, you mean subtyping?
<exarkun>
Hmm, somewhat. But more than just that. Objects that can receive the same messages but may be unrelated otherwise.
gl has joined #ocaml
<exarkun>
If I create two classes, foo and bar, and give them each a method, foobar, they are still distinct types, but, depending on your design, they might (conceptually) be usable interchangably
<exarkun>
Because anything you can do to a foo you could also do to a bar.
<graydon>
depends on the type system.
<exarkun>
hence "conceptually"
<exarkun>
in O'Caml it isn't true, nor C++, but in python you could
<graydon>
in a static system with name equivalence, they might not be usable interchangeably, unless they are subtypes of a common ancestor (say a pure virtual C++ class or a java interface)
<graydon>
in a dynamic language there's no static check to talk about, and the dynamic metaprogramming makes object types pretty meaningless anyways.
<exarkun>
But the "interface" remains important. So, yea, this is just my preference for dynamic typing showing through.
<graydon>
in most languages like python (ruby, clos, perl), you can cook up new "classes" on the fly, since their names are just advice to the dynamic method resolver.
<two-face>
this is eveil
<two-face>
evil
<graydon>
there's a good survey book by adabi and cardelli called "a theory of objects" which puts interfaces and type systems in OO languages on a good theoretical grounding.
<exarkun>
I need to read more theory books
<exarkun>
But most of the time I'd rather be programming ;)
<graydon>
they make a very good case for prototype languages, actually, by implementing class languages on top of them.
<exarkun>
nod
<exarkun>
time to catch my bus. later :)
<graydon>
cya
two-face has quit ["Client Exiting"]
cymonts has joined #ocaml
malc has joined #ocaml
Dybbuk has joined #ocaml
graydon has quit []
Belgarion has quit ["Client Exiting"]
Belgarion has joined #ocaml
taw has joined #ocaml
<taw>
if i have "foo list"
<taw>
and want to process it
<taw>
to get "bar list"
<taw>
and 1 foo generates 1 bar usually, but sometimes more
<taw>
how can i do that ?
<taw>
let foolist_to_barlist = function [] -> [] | h :: t -> (foo_to_bar h) :: (foo_to_bar_list t);;
<taw>
allows only 1 foo -> 1 bar conversions
<smkl>
List.flatten (List.map f lst)
taw has quit [Read error: 104 (Connection reset by peer)]
taw has joined #ocaml
<taw>
if i have "foo list" and want to process it to get "bar list" and 1 foo generates 1 bar usually, but sometimes more how can i do that ?
<taw>
let foolist_to_barlist = function [] -> [] | h :: t -> (foo_to_bar h) :: (foo_to_bar_list t);;
<taw>
allows only 1 foo -> 1 bar conversions
<smkl>
List.flatten (List.map f lst)
<taw>
oh
<taw>
thanks
taw has left #ocaml []
malc has quit ["no reason"]
cymonts has quit [Read error: 104 (Connection reset by peer)]