Abo-Marwan has quit [Read error: 104 (Connection reset by peer)]
screwt8 has quit [Read error: 104 (Connection reset by peer)]
chris2 has joined #ocaml
ita has quit [Remote closed the connection]
bluestorm_ has quit [Remote closed the connection]
oc13 has joined #ocaml
ttamttam has quit ["Leaving."]
bluestorm_ has joined #ocaml
tremuKas has joined #ocaml
tremuKas has left #ocaml []
d2bg has joined #ocaml
seafood_ has quit []
ikaros has joined #ocaml
ikaros has quit [Read error: 104 (Connection reset by peer)]
ikaros has joined #ocaml
screwt8 has joined #ocaml
Abo-Marwan has joined #ocaml
yminsky has joined #ocaml
yminsky has quit [Client Quit]
bluestorm_ has quit ["Konversation terminated!"]
yminsky has joined #ocaml
gene9 has joined #ocaml
gene9 has quit [Client Quit]
JohnnyL has joined #ocaml
Tetsuo has quit ["Leaving"]
munga has joined #ocaml
<munga>
I want to test a small cgi I wrote with ocamlnet from command line. what is the easiest way to interact with this cgi without passing from a web server ? I can write a small server with Nethttpd, but I've the impression that this is overkilling ... I've to say the the cgi speaks xmlrpc and writing requests by hand is a bit tedious ...
yminsky has quit []
<flux>
I suppose you can write a client that generates said format and pipe it to the binary?
gene9 has joined #ocaml
smimou has joined #ocaml
<chris2>
.oO(why does Hashtbl.find have a different argument order compared to Map.find)
<Smerdyakov>
Because you didn't eat your vegetables when you were a kid?
<chris2>
i still dont
ikaros has quit ["segfault"]
<Smerdyakov>
Mystery solved.
<flux>
chris2, I've wondered the same, the vague explanation has been that because it is side-effectful
ita has joined #ocaml
Yoric[DT] has joined #ocaml
ikaros has joined #ocaml
buluca has joined #ocaml
gene9 has quit ["Leaving"]
<Jeff_123>
module Hashtbl_hack = struct include Hashtbl let find x y = Hashtbl.find y x end
<JohnnyL>
are success 'let in's stack calls?
<JohnnyL>
successive
<JohnnyL>
rather
<Yoric[DT]>
JohnnyL: usually, no.
<Jeff_123>
you got me... :\
<Smerdyakov>
What is a "stack call"?
<JohnnyL>
Yoric[DT], so if it's just a scope, how is the scope carried over without being a stack call?
<JohnnyL>
Smerdyakov, in c or asm, a push or pop of the current state.
<Smerdyakov>
JohnnyL, don't think of 'let' any differently than variable assignment in C, in terms of how you expect it to be compiled.
<Smerdyakov>
Jeff_123, that's "call stack."
<Yoric[DT]>
JohnnyL: I'm not sure I understand the question. The scope is a compiler convention, it doesn't have to reach the asm level.
<Jeff_123>
I'm thinking they're related.
<Yoric[DT]>
It's just a matter of name resolution.
<Smerdyakov>
Jeff_123, I'm thinking JohnnyL used non-standard terminology.
<JohnnyL>
well let in appears to be a block. a scope. the only way that's achieved in by stack pushes. in c a block is just a sequence in which jmp is called in asm to go to the next 'block' of c code.
<Jeff_123>
I guess so
<Smerdyakov>
JohnnyL, your second sentence is wrong.
<JohnnyL>
Smerdyakov, no, a c block is an asm sequence of commands where the block changes due to stack calls or jmps.
<Smerdyakov>
JohnnyL, no.
<Jeff_123>
heh ok, you guys know way more about this tuff than me. I'm used to reading ocaml_beginners at yahoo
<Smerdyakov>
JohnnyL, you might be thinking of a particular C compiler, but that would make it a poor compiler.
<Smerdyakov>
JohnnyL, the definition of C has nothing to do with assembly.
<JohnnyL>
Smerdyakov, ok, great , now your saying i am right. make up your mind.
Tetsuo has joined #ocaml
<Smerdyakov>
JohnnyL, how did I say you're right?
<JohnnyL>
Smerdyakov, sorry, maybe we can talk about this l8r. i'm busy.
<Smerdyakov>
OK. In the mean time, everyone be aware that what JohnnyL is saying is wrong. ;)
bluestorm_ has joined #ocaml
<JohnnyL>
No.
<Smerdyakov>
If you don't have the time to figure out why we're disagreeing the Socratic way, then there's no choice but to appeal to our credentials for folks to guess whom to believe, and I probably win.
<Jeff_123>
could this question be answered by writing a minimal example and compiling it to assembly?
<Smerdyakov>
Jeff_123, which question?
<Jeff_123>
whatever you're debating. I don't exactly follow the conversation though.
<Smerdyakov>
Jeff_123, a main problem is JohnnyL talking about the C language like it has a fixed compilation strategy.
<Smerdyakov>
Jeff_123, another problem is mentioning a particular poor compilation strategy like it would be used in serious compilers.
<Smerdyakov>
'gcc -O3' had sure better not be doing what he's suggesting.
<Jeff_123>
ah right, I was just thinking about helping him discovere how "let...in" works. but maybe lookign at the corresponding assembly wouldnt' help answer that. I wouldn't know.
<JohnnyL>
jeff, it would.
<JohnnyL>
i'm looking at ocaml source now.
<JohnnyL>
it's an offset to an array structure.
<JohnnyL>
not bad. just an add.
<Smerdyakov>
I'll be really surprised if ocamlopt never allocates let-bound variables to registers....
<Yoric[DT]>
Well, knowing that let...in always allocates exactly one word on the stack, I'd be really surprised if ocaml didn't preallocate the whole stack at once.
<Yoric[DT]>
s/ocaml/ocamlopt/
<Yoric[DT]>
s/didn't/never/
<Smerdyakov>
I'm really surprised if it always allocates memory.
pango has quit [Remote closed the connection]
<Yoric[DT]>
etc. :)
<Smerdyakov>
I'd bet in favor of allocating as many locals as possible to registers.
<Smerdyakov>
Not to mention coalescing multiple stack-allocated locals to use the same stack slot, when they are never live simultaneously.
pango has joined #ocaml
<JohnnyL>
yeah well an operation that has two register vars and an address is as slow as accessing the address. Which is part of the 'let in' command in OCaml.
<Smerdyakov>
First, 'let..in' is an expression. OCaml has no commands.
<Smerdyakov>
Second, what is it that you are saying is part of 'let'?
<JohnnyL>
let in (imperatively speaking an expression is a command if it performs some operation y), is simply an array access of an address using two register vars for it's array offset. last of all.
mordaunt has joined #ocaml
<Smerdyakov>
JohnnyL, are you looking at ocamlc or ocamlopt?
<JohnnyL>
i am looking at ocamlc 3.10.0.
<JohnnyL>
not bad though.
<JohnnyL>
thought it may have been some stupid stack push.
<JohnnyL>
makes me want to use it more.
<Jeff_123>
ocaml or "let...in"?
<JohnnyL>
jeff ocaml, because of let in.
kelaouchi has quit ["leaving"]
<JohnnyL>
registers are way nice too.
<JohnnyL>
it means that it will use an open register if available at the time of the reference.
<Smerdyakov>
JohnnyL, do you use 'ocamlc' on .ml files whose performance you care about?
<JohnnyL>
i didn't know about ocaml until about an hour ago when my partner suggested we use it for opengl.
bluestorm_ has quit ["Konversation terminated!"]
<Jeff_123>
ah ya. there are some need examples of ocaml and opengl out there.
<JohnnyL>
opengl is very processor intensive. but i can see a good fit here.
<Smerdyakov>
JohnnyL, OK. 'ocamlc' is a bytecode compiler. 'ocamlopt' is the native code compiler. If you are trying to understand performance implications, 'ocamlc' is the wrong place to look for serious projects.
<Yoric[DT]>
I've tried OCaml with OpenGL.
<Yoric[DT]>
I found the match impressive.
<Yoric[DT]>
Much better than C + OpenGL.
<JohnnyL>
Smerdyakov,Ok, well, what is more faster than an address access with two register variable offsets?
<JohnnyL>
Yoric[DT], ok
<Smerdyakov>
JohnnyL, a single register access.
<JohnnyL>
Smerdyakov, that's not realistic.
<Smerdyakov>
JohnnyL, sorry, but you're wrong. This is the standard for how compilers work today.
<JohnnyL>
well, it's always a tradeoff.
<JohnnyL>
for example opengl has ARB extensions.
<JohnnyL>
you *can* use one register access, but you have to specify the whole structure beforehand.
<Smerdyakov>
That doesn't seem related to the question of if you can expect a compiler to allocate local variables to registers..
<Smerdyakov>
If you use ocamlopt on an amd64 platform, you can expect many locals to end up in registers.
<JohnnyL>
I doubt that a general purpose language has one register access. Why ? Because I looked at the source code for it, and it doesn't.
<Smerdyakov>
You looked at ocamlc. I already told you to look at ocamlopt for the version that tries to maximize performance.
<Smerdyakov>
And, you are just completely wrong in doubting that general purpose language compilers allocate temporaries to registers.
<Smerdyakov>
This has been the standard approach for decades.
<JohnnyL>
no
<Smerdyakov>
OK, I have a PhD in CS, working in compilers.
<Smerdyakov>
I challenge you to explain your "no."
<JohnnyL>
access usually have two accesses, one for the inner, one for the outter loop.
<Smerdyakov>
Where did loops come into this?
<Smerdyakov>
We're just talking about local variables in general.
<JohnnyL>
gesh. memory access.
<JohnnyL>
well, i'm talking about let in.
<Smerdyakov>
I'm using "local variables" as a more general term that encompasses them.
<JohnnyL>
And other general scope accesses.
<JohnnyL>
in functional land.
mulander has joined #ocaml
<JohnnyL>
anyway, all i need to see is that one implementation.
<Jeff_123>
Smerdy - JohnnL already seems to have answered his own question.
<Smerdyakov>
Why does what ocamlc does matter re: performance when you would never use ocamlc for programs with serious performance requirements?
<JohnnyL>
Jeff, thank goodness for the open-ness of opensource.
* JohnnyL
pets his GNUland.
<Smerdyakov>
Does anyone else think JohnnyL is making any sense? Why did he ask his question in the first place if he doesn't care about performance?
mordaunt has quit [Remote closed the connection]
yminsky has joined #ocaml
<Jeff_123>
Smerdy - I don't know why you're so hellbent on showing he's wrong. Are you saying that he *shouldn't* use ocaml?
<Yoric[DT]>
Maybe he's curious ?
<Smerdyakov>
Jeff_123, I'm saying that he's drawn an incorrect conclusion.
<Yoric[DT]>
Jeff_123: no, he meant using ocamlopt instead of ocamlc.
<Yoric[DT]>
s/using/use/
<Smerdyakov>
Jeff_123, on amd64, a good proportion of his 'let'-bound variables will end up in registers.
rayno has joined #ocaml
* JohnnyL
bows to the eternal within Smerdyakov
* Yoric[DT]
encourages JohnnyL's curiousness.
<Yoric[DT]>
Even if Smerdyakov's argument about ocamlopt is valid :)
<Smerdyakov>
Yoric[DT], you think I'm encouraging him not to be curious? I'm just baffled at how he's misunderstanding what I'm saying.
<Smerdyakov>
Yoric[DT], my "why did he ask" was more rhetorical. It's pretty clear that he cares about performance and his drawn the wrong conclusion.
<Jeff_123>
I don't properly understand assembly, but if JohnnyL is wrong then he'll find out while he plays with ocaml. Why not just let it go then?
yminsky has quit [Client Quit]
<Smerdyakov>
Jeff_123, maybe because I want to help people avoid wasting their time?
<Jeff_123>
let him
<Jeff_123>
who cares
<Smerdyakov>
Jeff_123, I'm telling you that I do.
<Jeff_123>
obviously whatever you're doing isn't helping him agree with you
<Jeff_123>
so let it go
<Jeff_123>
I was wasting time last night playign with tcl :)
<Jeff_123>
but then I missed ocaml's type system
mordaunt has joined #ocaml
ita has quit [Read error: 110 (Connection timed out)]
<JohnnyL>
where is the elusive source for ocamlopt?
<Smerdyakov>
JohnnyL, should be the same place you found ocamlc source.
<Yoric[DT]>
JohnnyL: iirc, the source for ocamlopt is in ocaml.
buluca has quit [Read error: 110 (Connection timed out)]
<JohnnyL>
What does the directory fall under as far as ocaml is concerned.
<Jeff_123>
right exactly. it's all in teh same source distribution
<JohnnyL>
Because to me, just glancing at it, looks like all ocaml.
<JohnnyL>
Because thats what I've been looking at.
<JohnnyL>
oh sorry.
<JohnnyL>
under yacc.
<Smerdyakov>
Probably not. That would just be the parser.
<Jeff_123>
well there's 2 versions of ocamlopt in a sense - one is written in c (ocamlopt) and the other in ocaml (ocamlopt.opt)
<JohnnyL>
yeah, but there are let in structure in there. Specifically the one i mentioned.
<JohnnyL>
Jeff, interesting.
<Smerdyakov>
Jeff_123, actually, I think they come from the same compiler source.
<Smerdyakov>
Jeff_123, you have ocamlopt built with ocamlc and ocamlopt built with ocamlopt.
buluca has joined #ocaml
<JohnnyL>
yeah, i have been looking at c source.
<Jeff_123>
oh ok right
<Smerdyakov>
Jeff_123, there might be a bootstrap compiler written in C, but the standard ocamlopt installed in your $PATH is build with ocamlopt.
<Jeff_123>
OK right I had it a bit mixed up. Iwas thinkign there was a c version of the ocamlopt compiler.
<Smerdyakov>
It's more likely that they would use ocamlc as the bootstrap compiler.
<Smerdyakov>
Since, working with bytecode, it's easier to do portably.
<Smerdyakov>
JohnnyL, did you find the ocamlopt source yet?
<JohnnyL>
Smerdyakov, i haven't been looking, sorry.
<Jeff_123>
Hm, it's in asmcomp/ isn't it? Not sure
<Smerdyakov>
Even if you find it, you can expect it to be much harder to understand than ocamlc.
<Jeff_123>
it is
<Jeff_123>
probably the best way to test compiled ocamlopt's performance is to build an example and time it
<Jeff_123>
easiest anyway
<Smerdyakov>
For questions like this, you don't even need to run the code. Disassemble it and see the registers used.
<Smerdyakov>
I've done that recently on amd64 and seen pleeeenty of locals in registers.
<Jeff_123>
right or that
<JohnnyL>
no.
<Jeff_123>
or I think you can have the compiler give you the assembly, though I forgot how
<JohnnyL>
well since yacc is used to define let in. let in is used in asmcomp thoroughly.
<JohnnyL>
looks interesting.
<JohnnyL>
well written.
<Jeff_123>
Er, are you interested in how fast ocamlopt compiles or the speed of the compiled cdoe?
<JohnnyL>
Jeff, well, if we are to use ocaml. people will want intepreter access most likely.
<Jeff_123>
mmmmmmm toplevel
<JohnnyL>
jeff, but is is very interesting.
<JohnnyL>
Jeff, yeah i mean why not.
<JohnnyL>
if you use c, it's compiled.
<JohnnyL>
if it's not, use those features.
<Jeff_123>
I think there was someone who created a toplevel out of ocamlopt, that is, the toplevel compiled to native code instead of bytecode.
<Jeff_123>
I can't remember what it was called though...
<Jeff_123>
or at least they tried to
<JohnnyL>
besides, one register access compared two register accesses with one memory address is nominal
<JohnnyL>
i was just worried that ocaml looked a bit foolish in composing a series of stacks.
<Jeff_123>
Hm, I think I kind of can think of what you're talking about now. Maybe
<Jeff_123>
The level I understand caml's stack is recusive functions, tail recursive functions and and exceptions.
<Jeff_123>
not so much the underlying code
<Smerdyakov>
JohnnyL, registers are always stored in quickly-accessible memory.
<Smerdyakov>
JohnnyL, add any RAM access and you have the possibility for long delays.
<Smerdyakov>
JohnnyL, at the least, you have non-trivial cache logic involved.
<JohnnyL>
Smerdyakov, well, back in 1991. registers were a hint to the compiler. Because any other program might conjest the register use if multitasking. but this is all rather academic.
<Jeff_123>
The only place in ocaml I haven't found its performance acceptable is when I tried to solve this problem https://www.spoj.pl/problems/MUL/
<Smerdyakov>
JohnnyL, in 1991, research compilers were allocating to registers automatically, and I bet some production compilers were, too.
<Smerdyakov>
JohnnyL, today, all serious compilers allocate to registers automatically.
<JohnnyL>
Smerdyakov, I disagree with you againm this time on the register keyword.
<JohnnyL>
nothing is automatic in c.
<JohnnyL>
everything is a value.
<Yoric[DT]>
Er....
<Smerdyakov>
JohnnyL, I'm not talking about C.
<Yoric[DT]>
gcc -O3 does a large number of optimizations (some of them breaking the semantics of the language)
<Smerdyakov>
JohnnyL, I'm using "automatic" in the standard English sense, and using "register" to mean the concept from computer architecture, not the C keyword.
<JohnnyL>
Yoric[DT], registers can be all used up by one program, leavning the next program to only choose local memory for allocation. but again, this is all very academic.
<Yoric[DT]>
I'm pretty sure that's handled by context-switching.
<Yoric[DT]>
Might depend on the OS.
<JohnnyL>
Yoric[DT], it's always the least common denominator when it comes to cross platform.
<Yoric[DT]>
Are you talking about desktop/server OSes or embedded stuff ?
<JohnnyL>
besides context switches cost too.
<Yoric[DT]>
Sure, they do.
<JohnnyL>
no generic opengl.
<Yoric[DT]>
But they do push all the registers to the stack, don't they ?
<JohnnyL>
platforms that is.
<JohnnyL>
Yoric[DT], At what time?
<Smerdyakov>
If you're on a desktop, multi-tasking OS, then it's very unlikely that one program's register allocation choices affect any other program's.
<Yoric[DT]>
JohnnyL: context-switching.
<Yoric[DT]>
Unless you're working in an embedded OS without context-switching, but that's a very specific case.
<JohnnyL>
Yoric[DT], well, on a c64 there is two asm calls (stack)and an interrupt call. prolly not much different than today's oses.
<JohnnyL>
stacks SUCK.
<JohnnyL>
no magic.
<JohnnyL>
nope
<Yoric[DT]>
Two asm calls and an interrrupt call for what ?
<JohnnyL>
Yoric[DT], two switch contexts.
* Yoric[DT]
starts to feel that there's a language barrier, here.
<JohnnyL>
so yes, stack calls.
<Yoric[DT]>
What's your native language, JohnnyL ?
<JohnnyL>
Yoric[DT], It's just a multlanguage barrier. Please forgive.
<JohnnyL>
Yoric, started with basic, then went to c, then c++, then vb, then a bunch of others.
<Yoric[DT]>
No, I mean your spoken language :)
<JohnnyL>
Oh, engrish.
<Jeff_123>
hehe
* JohnnyL
snickers.
<Jeff_123>
That's awesome. "My native language is c++."
<JohnnyL>
please excuse the brain farts as I have many.
<Smerdyakov>
I think the main problem is JohnnyL not being willing to accept that things change in 16 years. ;)
<JohnnyL>
I don't see any problems. only solutions.
<Jeff_123>
Soemtimes I have fun reminiscing about my first programming language - User RPL on the HP 48 calculator.
<JohnnyL>
life is too short to be religious.
* JohnnyL
throws a (+ 1 1) at jeff.
<Jeff_123>
oh no! taht's backwards!
<Yoric[DT]>
"Life's too religious to be short" ?
<chris2>
i have a datatype in my main file (Theme2.ml) and the interface (Theme2.mli), i want to create an instance of it with ocamlyacc, so i open it there but nevertheless need to say %type <Theme2.term> input; now, when i try to access the parsed structure, I get: File "Theme2.ml", line 85, characters 19-52: This expression has type Theme2.term but is here used with type term
<chris2>
how do i tell ocaml that these are the same?
* JohnnyL
smiles at Yoric[DT]
<Yoric[DT]>
JohnnyL: actually, what Smerdyakov and I are telling you is that there's no need for a solution, as there's no problem in the first place :)
<Smerdyakov>
chris2, please come up with a minimal example illustrating the same problem and post a URL to the code.
<JohnnyL>
Yoric[DT], tell that to the customer!
<JohnnyL>
:)
<Yoric[DT]>
But that sounds like the kind of discussion which can't be solved by IRC.
<Jeff_123>
grrr, they still haven't updated the ocaml tutorial for 3.10's camlp4
<JohnnyL>
Yoric[DT], I'm finding that languages are no very different from one another. You can only program a calculator so many different ways to do the same thing. The only promising thing i have found to be of general interest is lisp macros. Apart from that it's programming as usual.
<JohnnyL>
interesting to note that javascript before it was javascript almost become a scheme offshoot.
<Yoric[DT]>
I only half-agree with you.
<Smerdyakov>
JohnnyL, then you will be presently surprised with OCaml if you give it a chance.
<JohnnyL>
Smerdyakov, so far i have, thanks.
<JohnnyL>
:)
<Smerdyakov>
JohnnyL, every language you listed as knowing before falls into a single very narrow language family.
<Smerdyakov>
JohnnyL, OCaml is in a different family.
<Yoric[DT]>
But yeah, lisp macros are quite good.
<JohnnyL>
Yoric[DT], I see your better half agrees with me. :)
<Yoric[DT]>
(And they're called Camlp4 in the OCaml world :))
<Yoric[DT]>
:)
<JohnnyL>
ah ok
<JohnnyL>
thats new?
<Jeff_123>
camlp4 is powerful but i've found it hard to learn
* Yoric[DT]
agrees with Jeff_123.
<Yoric[DT]>
JohnnyL: no, it has existed for quite some time.
<Jeff_123>
and lisp and ocaml are in the same family of languages, no?
<Yoric[DT]>
There's a new version, though.
<Yoric[DT]>
Halfway :)
<Yoric[DT]>
Lisp is more dynamic, not quite as typed.
<Yoric[DT]>
OCaml has more structure.
<Jeff_123>
but it's functional nevertheless?
<Yoric[DT]>
Yup.
<JohnnyL>
Jeff_123, yes and imperative too.
<JohnnyL>
it's not truely functional, it has side affects.
<JohnnyL>
(regarding lisp)
<Jeff_123>
ocaml isn't pure either luckily
<Jeff_123>
I've written programs in ocaml taht would make a c programmer proud
<Yoric[DT]>
:)
<JohnnyL>
Jeff_123, whatever makes the customer happy (or you)!
<Jeff_123>
I like imperative code sometimes, but my professor can't stand it.
* Yoric[DT]
doesn't like these pesky customers.
<Jeff_123>
imperative? Impared code would be bad.
<JohnnyL>
Yoric[DT], most open source types despise any customer design, i 'd say go half way. meet in the middle. you them, together. peace and flowers in rifle barrels, Yeah baby! :)
<JohnnyL>
asm is imperative, yet beautiful in it's simplicity.
<JohnnyL>
it can write itself, just like lisp macros can.
<Yoric[DT]>
Brrrr.....
<Yoric[DT]>
Well, yes, but it's scary.
<Yoric[DT]>
(and it won't work on every OS anymore)
* Yoric[DT]
prefers LISP macros - at least, they can be debugged :)
<JohnnyL>
Yoric, no but all asm instructions in theory all derive from the same command. It's just syntax and mode in each processor is different. But it's all about the turing machine.
<Smerdyakov>
chris2, you're not allowed to have cyclic dependencies among modules like that.
<chris2>
i just want to share a parse tree between several modules... how would i do that then?
<Yoric[DT]>
JohnnyL: well, I do have slight difficulties coding a Turing machine to do anything as complicated as, say, a^b.
<Yoric[DT]>
("a" to the power of "b")
<Yoric[DT]>
It's easier in asm.
<Yoric[DT]>
And much easier in a high-level language.
<Yoric[DT]>
So, while everything is electrons ultimately (or quarks, or whatever subparticles), scale makes a difference.
<JohnnyL>
i am curious, what benefits do I have in OCAML in comparison with something like say lua? I ask because the game industry is already familiar with lua. the two look similiar at various focal points.
<Jeff_123>
Heh, i've had to write that a few times. Ocaml has no built-in ^ for integers. At least not that I know of.
<Yoric[DT]>
JohnnyL: I don't know the answer to your question.
<flux>
jeff_123, you mean power or bitwise xor?
<Yoric[DT]>
However, do you mean as a scripting language or as a main language ?
<Jeff_123>
me either. I don't know LUA.
<JohnnyL>
Yoric[DT], either, but ulimately scripting.
<JohnnyL>
i am open.
<flux>
oh, context, never mind
<Yoric[DT]>
JohnnyL: I don't know lua.
<Yoric[DT]>
But I'd say that "custom syntax" is a good start :)
<Jeff_123>
I'm guessing LUA is better as a scripting language simplyl because it's designed to be embedded in other programs.
<Smerdyakov>
chris2, define it in a new module to use in both.
<chris2>
okay
<pango>
lua is dynamically typed, with a very small set of types (much like too many languages out there)
<Jeff_123>
I love ocaml's type system.
<Jeff_123>
If I get the types right the rest of my code almost writes itself.
<Jeff_123>
If I'm writing something pure anyway
<JohnnyL>
yeah it looks similiar to haskell. am i correct?
<Jeff_123>
there are commonalities
<Jeff_123>
haskell doesn't allow imperative code though
<JohnnyL>
ah ok.
<Yoric[DT]>
Still, many things are common.
<Jeff_123>
haskell doesn't have variant types as far as I know.
<Yoric[DT]>
(it would actually be possible to rewrite OCaml's libraries to prevent side-effects)
<Yoric[DT]>
Haskell has a variant on imperative code, though.
<JohnnyL>
i only like some of haskell. the language should be easy as a commanlity. Haskell has different forms that differ greatly detracting from the experience unless you have a memory like spock. :)
<Yoric[DT]>
I mean, it's possible, after a fashion.
<Yoric[DT]>
:)
<Jeff_123>
right... it's so strange
<Jeff_123>
IMO ocaml is more terse and simple to learn, but I haven't played with haskell too much
<Jeff_123>
I practically think in ocaml now - it's too much effort to use anythign else.
<chris2>
Smerdyakov: thanks, that works
<Yoric[DT]>
I like some of Haskell's syntax.
<Yoric[DT]>
I mean, I can write
<Yoric[DT]>
let do_something (Some x) = ...
<Yoric[DT]>
let do_something None = ...
<Yoric[DT]>
And that actually makes a function
<Yoric[DT]>
let do_something = function
<Yoric[DT]>
| Some x -> ...
<Yoric[DT]>
| None -> ...
<Smerdyakov>
Funny. I much prefer the latter.
<Smerdyakov>
Who wants to be repeating function names?
<Yoric[DT]>
I like the ability to have both.
<Smerdyakov>
SML has both.
<Yoric[DT]>
yep
<Smerdyakov>
But the first form can't be spread out like in Haskell.
<Jeff_123>
eh, they both work, but it's nice to type less
<Yoric[DT]>
When you're implementing specifications, it sometimes allows keeping things closer to the documents, hence easier to check.
<Jeff_123>
Does haskell have an easy way to express "function 1 | 2 | 3 -> do_something 4 | 5 | 6 -> do_something_else"?
<Yoric[DT]>
IIRC, it's almost the same syntax as in OCaml for this kind of things.
* Yoric[DT]
hasn't coded in Haskell for some time.
<Jeff_123>
ah that's cool
<JohnnyL>
Yoric[DT], your thoughts of lisp macros within ocamls pretty printing is encouraging.
<Yoric[DT]>
I haven't fully mastered Camlp4 yet, but it's quite powerful.
kazzmir has left #ocaml []
<JohnnyL>
yes, why not have the benefits of all languages at your disposition. (enter asm)
<Yoric[DT]>
For scripting ?
<JohnnyL>
code resuse. :l
<JohnnyL>
such as all languages.
* Yoric[DT]
wonders if JohnnyL has been bitten by some strange exotic fly.
<JohnnyL>
reuse
<JohnnyL>
lol @ flyman.
<Jeff_123>
something I've been looking at is llvm. I know apple is probably going to replace gcc with their own c/objc/c++ frontend and llvm.
<Jeff_123>
if ocaml could target llvm it would be pretty cool
<Yoric[DT]>
Yeah, I've been thinking the same thing.
<Yoric[DT]>
I'm not sure it would change much (by opposition to targeting .Net, which would bring a whole load of libraries).
<Yoric[DT]>
But it would be pretty cool :)
<Jeff_123>
well you'd get maybe better optimization, but I was thiking specifically about ... well if there were an ocaml front end to llvm, could we perhaps have easier access to eg openstep or cocoa.
<Jeff_123>
or c functions
<Jeff_123>
or anythign compiled with llvm
<Jeff_123>
And yes I'm talking about things I don't konw much about :)
ygrek has quit [Remote closed the connection]
<Yoric[DT]>
Well, .Net has a number of conventions designed to make interoperability between languages easier.
mordaunt has quit [Read error: 104 (Connection reset by peer)]
<Yoric[DT]>
Afaik, there's no such thing for llvm [yet].
<Yoric[DT]>
Now, Apple may decide to change that.
buluca has quit [Read error: 113 (No route to host)]
<Jeff_123>
just as long as it isn't slow like .NET
malc_ has joined #ocaml
bluestorm_ has joined #ocaml
Mr_Awesome has joined #ocaml
Zola has joined #ocaml
pango has quit [Remote closed the connection]
Abo-Marwan has quit [Success]
screwt8 has quit [Remote closed the connection]
Jeff_123 has quit ["Quit"]
pango has joined #ocaml
malc_ has quit [Read error: 110 (Connection timed out)]
ttamttam has joined #ocaml
bluestorm_ has quit [Remote closed the connection]
buluca has joined #ocaml
ttamttam has left #ocaml []
screwt8 has joined #ocaml
Abo-Marwan has joined #ocaml
mulander has quit [Remote closed the connection]
nuncanada has joined #ocaml
buluca has quit [Read error: 113 (No route to host)]
d2bg has left #ocaml []
chris2 has quit ["Leaving"]
oc13 has left #ocaml []
seafood_ has joined #ocaml
Tetsuo has quit [Remote closed the connection]
oc13 has joined #ocaml
oc13 has left #ocaml []
ita has joined #ocaml
Beelsebob has joined #ocaml
<JohnnyL>
each library or vm has it's strengths, weaknesses, niches, it's all a matter of unique features and retaining them for a certain usage.
* JohnnyL
likes vice for the c64.
buluca has joined #ocaml
al___ has quit ["BitchX-1.1-final -- just do it."]
l_a_m has quit [Remote closed the connection]
yminsky has joined #ocaml
buluca has quit ["Leaving."]
yminsky has quit []
seafood_ has quit []
ita has quit ["Hasta luego!"]
opening`` has quit [Read error: 110 (Connection timed out)]