m[kel[ has quit [Read error: 110 (Connection timed out)]
Deknos has quit ["Leaving"]
Dybbuk has quit [Remote closed the connection]
Dybbuk has joined #ocaml
Nutssh has quit ["Client exiting"]
cjohnson has joined #ocaml
mfurr has joined #ocaml
cjohnson has quit ["Drawn beyond the lines of reason"]
drWorm has quit [Read error: 54 (Connection reset by peer)]
Defcon7 has quit [Client Quit]
Kinners has joined #ocaml
drWorm has joined #ocaml
Defcon7 has joined #ocaml
tautologico has joined #ocaml
Defcon7 has quit [Client Quit]
Defcon7 has joined #ocaml
async has joined #ocaml
drWorm has quit [Read error: 54 (Connection reset by peer)]
tautologico has quit ["Leaving"]
Herrchen has quit [Read error: 60 (Operation timed out)]
JPL-Justin has joined #ocaml
<bk_>
i still hate emacs w/ a passion, but tuareg mode is the bomb
phj has joined #ocaml
Kinners has quit ["leaving"]
<JPL-Justin>
don't hate emacs :(
<JPL-Justin>
wow taureg mode, never heard of that
<JPL-Justin>
used ordinary caml-mode
<bk_>
its key-shortcuts were made by a madman or an alien with 3 hands and 18 fingers
<Riastradh>
What do you prefer, bk_?
<bk_>
usually vim, but tuareg mode beats vim's ocaml editing hands down
<Riastradh>
You can use the same arguments about obfuscated commands in vi.
<Riastradh>
'dd' to delete a line? 'o' to insert a line after the current one and 'O' to insert one before?
<bk_>
so ? :>
<bk_>
you have two modes, that i see as a great advantage on vims side
<JPL-Justin>
emacs vs vi... it's not really that either is better
<JPL-Justin>
it's just like... it matches your personality
<Riastradh>
How is it an advantage, and how is it different from Emacs?
<JPL-Justin>
personally I *HATE* the idea of multimode editing
<JPL-Justin>
but... I think for some people i'ts awesome
<JPL-Justin>
so vim is therefore awesome
<JPL-Justin>
for them
<Riastradh>
(Hint: if you type C-c before something, the next thing you type will have a _very_ different meaning.)
<JPL-Justin>
emacs multimode is... not as periminent
<JPL-Justin>
that's the difference
<bk_>
ok ofc, i'm biased because i have used vim for such a long time and never bothered w/ emacs
<JPL-Justin>
in vim you can go into a sorta command/edit mode and just flip out a ton of commands
<JPL-Justin>
whereas emacs isn't meant to do that, but... I got used to the keybindings, they are quite simple
<bk_>
yes
<JPL-Justin>
vim just feels too old school for me :)
<JPL-Justin>
yeah
<JPL-Justin>
emacs has a weird learning curve
<JPL-Justin>
I need to learn elisp
<JPL-Justin>
I have this feeling that if I learn elisp, I"ll totally love emacs
<Riastradh>
Bill Joy once tried Emacs and really liked it.
<Riastradh>
JPL-Justin, no, you'll just hate elisp.
<bk_>
well nm, all i was going to say is that i find tuareg mode extremly supportive, makes many things alot easier
<JPL-Justin>
hahaha well.. I won't do anything hard
<JPL-Justin>
besides I'll probably write ELISP as ML
<Riastradh>
Elisp is like modern Lisps, except not modern.
<JPL-Justin>
I'm working on an ML->lisp syntax converter, because I can't stand lisp parse trees
<JPL-Justin>
by ML, I mean simplified ML-like language
<JPL-Justin>
I'm working on it for an imaging system I work with at Maas Digital... the guy who wrote the system is a lisp fanatic and I can't stand lisp
<JPL-Justin>
not that I don't think it's good and all, it's just not my type of thing
<Riastradh>
How much have you used Lisp?
<JPL-Justin>
I prefer to write code that looks like mathematics/pseudocode, not parse trees :)
<JPL-Justin>
not a lot... I mean I can write simple LISP stuff just fine, but I'm not expert
<bk_>
oh and another thing i learned tonight : ocamlmake is great
<JPL-Justin>
I need ot learn ocamlmake
<JPL-Justin>
I've been using makefiles
<Riastradh>
JPL-Justin, have you really put any effort into learning Lisp well?
<JPL-Justin>
of course not
<JPL-Justin>
I can't get paid to write it
<JPL-Justin>
and I love ocaml
<JPL-Justin>
it's something I hope to slowly learn over the next few years
<JPL-Justin>
just for the heck of it
<JPL-Justin>
but... I don't care if I"m ever great at it, it's probably something I"ll never use too much... I want to do computational physics
<JPL-Justin>
and LISP isn't exactly the language of choice for that :) they tend to use things like FORTRAN
<JPL-Justin>
I just don't know of anything that LISP can do for me that all the other languages I know can't, other than emacs modes, and that damn image thing that isn't even true LISP, but just a simplified lisp interpreter
<Riastradh>
What can OCaml do for you that Fortran can't? They're both Turing-complete.
<JPL-Justin>
hahahaha
<JPL-Justin>
You are a pure CS guy?
<Riastradh>
Lisp has, in my opinion, _MUCH_ better development environments; it also has macros.
<Riastradh>
No. I avoid pure CS or pure engineering; one without the other is useless.
<JPL-Justin>
well... you can do pure engineering and use concepts developed by, say, physicists, without understanding them
<Riastradh>
Now, those two advantages of Lisp may not seem like much, and it's hard to explain why they're great advantages...
<JPL-Justin>
I mean, you don't have to understand stress tensors in General Relativity to calculate GPS orbits
<JPL-Justin>
well better development environment doesn't impact me much, because ocaml represents like 10% or less of my total development time
<JPL-Justin>
and... most of what I'm doing doesn't really benefit from self-modifying code or macros... it's a play language for me
<JPL-Justin>
ocaml is what I do for pleasure. I have never, and probably will never done anything serious in it
<Riastradh>
Why?
<JPL-Justin>
fortran however, well, I'm paid to write in that, because even though shell script is "turing complete" it doesn't really get the MHD equations solved very nicely
<JPL-Justin>
I have two types of employment
<JPL-Justin>
that which uses high level languages
<Riastradh>
Saying 'because we use Fortran here' only hurts yourself. The more you say it the more true it becomes and the less likely it is _anyone_ will use OCaml there.
<JPL-Justin>
and that which uses low-level
<JPL-Justin>
well dude
<JPL-Justin>
I"m just the student
<JPL-Justin>
and lets face it, ocaml is not and cannot be as fast as fortran
<JPL-Justin>
fortran is designed to do only one thing: math, really fast
<JPL-Justin>
and that's why it's almost unbeatable. I don't like it much
<Riastradh>
Actually, I'd like to see you pit Stalin, a _wicked_ optimizing Scheme compiler, against Fortran.
<JPL-Justin>
I hate the syntax etc
<JPL-Justin>
dude
<JPL-Justin>
our fortran code is most likely IO bound
<JPL-Justin>
that is, it's using the processor at highest possible speed
<JPL-Justin>
I do'nt believe it's possible to make it faster by any significant amount
<JPL-Justin>
unless you did some rediculously wicked cache improvmenets
<Riastradh>
Maybe not _performance_-wise, but development-wise?
<JPL-Justin>
development wise fortran is much faster
<JPL-Justin>
because the developers are like 50 year old russian physicistcs
<JPL-Justin>
they don't know anything about computers
<Riastradh>
(Unfortunately, that's one area in which Stalin won't do well: it uses Boehm, which sucks for locality...)
<JPL-Justin>
they just know how to type formulas into fortran
<JPL-Justin>
and read to/from files
<JPL-Justin>
that's all the program does
<JPL-Justin>
it's just a bunch of loops, formulas etc
<JPL-Justin>
I had to do all the "heavy" programming, the MPI stuff
<JPL-Justin>
does scheme have MPI bindings?
<Riastradh>
No, but you could probably write one easily enough.
<JPL-Justin>
of course
<JPL-Justin>
and then I could debug them
<JPL-Justin>
it's hard enoguh to debug programs on a parellel machine that's working flawlessly
<JPL-Justin>
this stuff is being run on a parallel supercomputing cluster etc
<JPL-Justin>
and I"m the most junior person on the project, so I don't really make decisions, except limited implementation details that only concern me
<JPL-Justin>
the biggest prolbme with scheme is that
<Riastradh>
Yes, yes, I see your point. Still, I'd like to see how well Stalin compares with some of your numerical Fortran code.
<JPL-Justin>
it's absolutely rediculously terrible for writing formulas in
<JPL-Justin>
physicists want to see code tha tlooks like math
<Riastradh>
How so?
<JPL-Justin>
that's hwy they like things like maple/fortran
<JPL-Justin>
they want it to look like what thye'd write on a piec eof paper
<Riastradh>
Fortran uses an infix syntax, not algebraic. Infix is just as different from truly algebraic as prefix is.
<JPL-Justin>
I"m not saying you can't write it in it, but these are old people stuck in their ways, and uncomfortable with programming even when it's simple stuff
<JPL-Justin>
Riastradh: I"ve heard that argument before, and that's not true at all
<JPL-Justin>
I don't buy that for a second
<Riastradh>
Beyond the basic arithmetic routines, it's definitely true.
<JPL-Justin>
pure algebraic has almost purely infix operators, almost no prefix operators
<Smerdyakov>
Riastradh, look at the "real math" way of writing 1 + 1 and say that again to my face. :P
<JPL-Justin>
oh no is Smerdyakov agreeing with me? I must be dreaming :)
<Riastradh>
Smerdyakov, so, write an example of using sigma in infix.
<Smerdyakov>
sigma + sigma = 2sigma
<JPL-Justin>
hahahaha
<Riastradh>
Or how about an integration?
* Riastradh
bahs at Smerdyakov.
<JPL-Justin>
Integral(3*x,dx)
<JPL-Justin>
which is almost exactly yhow it's written on paper
<Riastradh>
Well, you're using prefix right there!
<JPL-Justin>
that's how you'd write it in fortran
<Riastradh>
The only difference is where you put the parentheses and how you delimit arguments.
<JPL-Justin>
and it's not strictly prefix
<JPL-Justin>
because, dx is part of the operator
<JPL-Justin>
dude
<JPL-Justin>
it's more like parenthesis and you know it
<Riastradh>
(integral (* 3 x) (d x)) -- is that really that different from Integral(3*x, dx)?
<JPL-Justin>
I do not think infix is superior to prefix or any such nonsense
<JPL-Justin>
I just know for a FACT that the astrophysicists I work with are more comfortable with writing programs in it
<JPL-Justin>
however I bet many of them would like postfix, because some of them still use RPN calculators
<JPL-Justin>
I'll grant that's almost equivilent
<JPL-Justin>
however the vast majority of our code is completely arithmetic
<JPL-Justin>
because it's a low level encoding of a high level algorithm
<JPL-Justin>
in the code, you don't do Integral( thing x, dx)
<JPL-Justin>
you do
<JPL-Justin>
a descritized loop
<Riastradh>
Compare with Scheme, where you have a macro for INTEGRAL.
<JPL-Justin>
which sux dude
<JPL-Justin>
you don't write code like that in computational physics
<JPL-Justin>
you do NOT write high level code for your innermost loops
<Riastradh>
The INTEGRAL macro expands to the equivalent loop.
<JPL-Justin>
90% of your processor time is spent in a few loops. you write those out by hand and hope the compiler is smart enough to make them even better
<JPL-Justin>
remember, these guys care about 10% performance increase
<JPL-Justin>
Riastradh: no it doesn't dude, there's a lot of different ways to write those loops
<JPL-Justin>
Riastradh: loop structuring is very important
<JPL-Justin>
Because often you combine multiple things into loops
<JPL-Justin>
or factor things out of loops by hand etc
<JPL-Justin>
almost all of the integrals are multidimensional and require a lot of balancing etc
<JPL-Justin>
it's not a simple or trivial thing, ti's as much of an art as a science
<JPL-Justin>
I don't like it and I can't wait to get to write only high level code
<Riastradh>
I am _sure_ you can factor out much of the code into macros.
<JPL-Justin>
Mathematica type syntax is much better
<JPL-Justin>
Riastradh: you need to understand, they are not doing something high level
<JPL-Justin>
Riastradh: most physicists do NOT care about abstraction
<JPL-Justin>
most physicists are writing a program to be used for one specific thing, and they want to know the details of exactly what's going on, and don't care about eleganc eor symplicity
<Riastradh>
They rather care about mangling their equations into low-level code, two forms that resemble neither of each other whatsoever?
<JPL-Justin>
the people I work with don't even use subroutines where they could
<JPL-Justin>
Riastradh: It runs blindingly fast, and it's very very very very easy to reason about
<JPL-Justin>
I *PERSONALLY* prefer high level stuff
<JPL-Justin>
etc
<JPL-Justin>
But... that's not the work environment I'm in
<JPL-Justin>
and... the other job I have where I use high level languages is Java, there's nothing I can do to change it, and no other language does what we need
<JPL-Justin>
I don't think scheme is bad or anything... it just doesn't serve any purpose to me other than a curiosity
<JPL-Justin>
at some point, I want to use something like ocaml in 10 years for computational physics, until I can finally just do almost everything in mathematica
<JPL-Justin>
if I could do all my physics in mathematica, that'd be perfect... to have programs that look like scientific papers, that -ARE- the paper, written out like you'd do by hand
<JPL-Justin>
abstract, just like the math, with perhaps a few hints for performance at most
<JPL-Justin>
eh... I'm way beyond "this language is better than that language". There's a right language (or set of languages) for any given job, I use whatever's best for a job, given the overall problems that need to be solved, some of which, like it or not, are social.
<JPL-Justin>
and solutions like "write your own naive binding to some library you're just learning how to use that has to work well on a highly complex, high performance system without failure in batch mode with no human to oversee it and no easy way to debug it" is never an option :(
<Riastradh>
Of course. That's why I mentioned Stalin, and not some slower Scheme implementation.
<Riastradh>
JPL-Justin, I wasn't suggesting that you rewrite all of your code in Scheme.
<JPL-Justin>
well Scheme is great and all etc... but, once again, not something that's right for any job that I do
<Riastradh>
I was merely curious about how Stalin would perform compared with the kind of work you do in Fortran.
<JPL-Justin>
because the msot important thing about my computational physics work is that osmoene else can understand it after I"m done
<JPL-Justin>
and I guarantee you the people I work iwth couldn't read a single line of that, and worse DO NOT EVER WANT TO LEARN HOW TO
<JPL-Justin>
yes
<JPL-Justin>
I'd love to pit it against it
<JPL-Justin>
tell you what
<JPL-Justin>
if you're really curious
<JPL-Justin>
I'll dig up some fortran code we can test against
<JPL-Justin>
I'd be quite happy to see if it's really fast
<JPL-Justin>
If Stalin is faster than OCAML, then I'll finish up my ML->Lisp converter so I can write Scheme :)
<Riastradh>
I have to leave shortly, but I'd be glad to try this out when I have a little more time.
<JPL-Justin>
sure
<JPL-Justin>
me too
<JPL-Justin>
I'd say... sometime in the next 3 months
<JPL-Justin>
I'll be around, I'm very interested in learning about Stalin
<Riastradh>
(Start compiling it on a Saturday. If all goes well, you'll be done by the following Monday.)
<Riastradh>
(Well, the pregenerated C doesn't take long to compile, but Stalin compiling itself to C does.)
<Riastradh>
(C is used only as a portable assembly language, by the way; there are no 'high-level' features of C, higher-level than assembly, used by Stalin.)
<Riastradh>
(There's a funny comment in the documentation stating that you can't compile the pregenerated C on some machine with gcc because there are too many global variables.)
smklsmkl has quit [Read error: 110 (Connection timed out)]
<JPL-Justin>
hehehe
smklsmkl has joined #ocaml
<JPL-Justin>
oh is that how this is fast?
<JPL-Justin>
it compiles scheme to C?
<Riastradh>
(Only on that machine, of course; you can compile it on most machines just fine.)
<Riastradh>
No, that's not why it's fast.
* JPL-Justin
listens
<Riastradh>
C is merely a convenience so it doesn't have to have several back ends.
<JPL-Justin>
well it could compile to java bytecode ;)
<Riastradh>
Look at source/stalin5e.sc and look at how many passes it invokes.
<JPL-Justin>
I'll look at it sometime
<JPL-Justin>
I do question anyone who names their compiler after a genocidal dictator though :(
<Riastradh>
JMS is a queer fellow.
<JPL-Justin>
Although I admit Stalin does seem like a cooler name than Hitler
<JPL-Justin>
I can just see Stalin trying to beat up my java compiler
<Riastradh>
It would knock that Java compiler over, kick it unconscious, stomp it into the ground, stomp it again into the ground, continue stomping it into the ground for about ten hours, beat it to a bloody pulp, incinerate parts of it, rearrange it, incinerate a little more of it, kick it around some more, bury it, and then incinerate some more of it.
<JPL-Justin>
right
<JPL-Justin>
but only out of sheer coolness
<JPL-Justin>
if it came to Usefulness to Majority of the World, it'd have to go run back and hide
<Riastradh>
It's mainly designed for the use of JMS.
<JPL-Justin>
Two of the people I work with at JPL used Scheme a lot back when they got their masters at MIT, however unfortunately it doesn't do what we need here :(
<Riastradh>
He's a bit of a megalomaniac.
<JPL-Justin>
yeah that's good though :)
<JPL-Justin>
ti's great to have niche languages :)
<JPL-Justin>
I love that kind of stuff
<Riastradh>
You should read some of his writings.
<JPL-Justin>
when you say JMS
<Riastradh>
(E.g., fdlcc.pdf from that FTP directory.)
<Riastradh>
(He submitted the companion papers and later complained that they were rejected due to jealous compiler authors whose compilers were slower than Stalin.)
<JPL-Justin>
I think J. Michael Straczynski
<Riastradh>
No...I'm talking about Jeffrey Mark Siskind.
<JPL-Justin>
yeah sorry
<JPL-Justin>
I just think about *THE* JMS when you say it
<Riastradh>
If you read stalin.el, too, it's amusing the way he says stuff like 'This is exactly how an Emacs interface to a compiler should be.'
<JPL-Justin>
hehehe :)
<JPL-Justin>
He sounds like RMS, only not actually insane
<JPL-Justin>
It's part of being an ubergenius, being convinced your way is THE way
<JPL-Justin>
that's why I'm always right :)
<Riastradh>
In a thread on TCO on c.l.scheme, it was mentioned that Stalin now supported full TCO; JMS responded claiming that he added it only because of insistent people who had misunderstood his research.
<JPL-Justin>
TCO???
<Riastradh>
Tail call optimization.
<JPL-Justin>
oh
<JPL-Justin>
I call that tail recursion :)
<JPL-Justin>
why woulnd't you want that???
<Riastradh>
It's more accurately called TCO, especially in this context.
<JPL-Justin>
It's especially easy to do if you do CPS
<Riastradh>
I am certain JMS has a reason.
mfurr has quit ["zzZZzz"]
<JPL-Justin>
I think for everything there is a reason
<JPL-Justin>
however rarely does it make sense :)
<Riastradh>
One problem with Stalin is that you have to have about the same brain as JMS to use it. I don't know what half of the compiler options do.
<JPL-Justin>
I will say that I"m sure that Stalin cannot touch Intel/Compaq/Digital's Fortran compiler... it agressively optimizes so much, and fortran is so rediculously optimized for heavy scientiifc math that I'd be surprised if stalin did much better than java for it
<JPL-Justin>
Java compilers are now rediculously fast
<JPL-Justin>
well, if you use a decent one like IBM's JIT
<JPL-Justin>
of course you still have to write good code
<Riastradh>
The _compiler_ may be fast, but I doubt it can generate as fast code as Stalin can.
<JPL-Justin>
no
<JPL-Justin>
what I mean is
<JPL-Justin>
the JIT
<JPL-Justin>
JIT compilers can often be much faster than static compilers
<JPL-Justin>
as far as the code generation
<JPL-Justin>
static compilers suck because they don't know things about runtime that JITs do
<JPL-Justin>
that's why things like .NET aren't really so god-awful as you'd think
<JPL-Justin>
JIT compilation allows the compiler to take advantage of precise features of the specific cache setup of the processor that you're on
<JPL-Justin>
and the overhead is minimal over a long runtime
<JPL-Justin>
the big thing is this... a lot of stuff like heavy numerical computation, and image processing is an exercise in cache locality
<Riastradh>
You need both. An aggressive JIT can do great, but if the static compiler performed no static analysis & optimization, well, the JIT just isn't going to manage that.
<JPL-Justin>
and JITs can produce code that uses the cache much better through use of profiling etc
<JPL-Justin>
well... compiling to an intermediate representation is rarely the hardest part of making code go fast
<JPL-Justin>
JITs are great because they can inline code where it makes things faster... often times inlining causes code to be SLOWER
<JPL-Justin>
because bigger binaries tend to be slower, due to instruction cache sizes etc
<JPL-Justin>
Inlining is bad in general, but in some cases results in rediculous gains in speed, but you CANNOT KNOW that statically
<Riastradh>
Stalin isn't the kind of compiler that would blindly perform integration.
<JPL-Justin>
I'm sure Stalin is very advanced etc
<JPL-Justin>
but this like made by... some guy right?
<Riastradh>
Some ubermegalomaniac who decided he wanted to use Scheme for his numeric code.
<JPL-Justin>
it's like how gcc sucks incredibly because it doesn't have the same market pressure other compilers have
<JPL-Justin>
gcc is slow because thye aren't willing to sacrifice design modularity to get better optimizations etc
<JPL-Justin>
that's why they don't use apple's stuff for powerpc, because it breaks modularity
<JPL-Justin>
but gives code that's considerably faster
<JPL-Justin>
modern CPUs require specific compilers to really do a good job of optimizing things
<Riastradh>
So use xlc.
<JPL-Justin>
gcc is a great compiler and all etc
<JPL-Justin>
I'm just saying that
<JPL-Justin>
xlc == ibm
<JPL-Justin>
not some guy
<JPL-Justin>
gcc = some guys
<JPL-Justin>
stalin == some guy
<Riastradh>
xlc & Stalin are at _wildly_ different levels.
<JPL-Justin>
right
<JPL-Justin>
but more importantly
<JPL-Justin>
they have different goals and most importantly they are supported differently
<JPL-Justin>
and like it or not, money is a powerful motivator, and in things like numerical computing, it's not a question of marketing but actual results
<JPL-Justin>
so the $$$ goes to engineers who kick ass
<JPL-Justin>
not saying Stalin is bad
<JPL-Justin>
or isn't revolutionary or anything
<Riastradh>
Somehow I get the idea that JMS didn't just do it for the fun of it.
<JPL-Justin>
I don't care if it's Gosling or some other crazy expert guy
<JPL-Justin>
it's *A GUY*
<JPL-Justin>
he could be the most brilliant guy in the world
<JPL-Justin>
it's some guy
<JPL-Justin>
it's not a team, it's not supported by 20 dedicated Q/A guys that test the hell out of it
<JPL-Justin>
the biggest problem with things in numerical computing is that oftne it's really really hard to catch bugs etc
<Riastradh>
Do you suppose we could wait until we see the results of pitting Stalin against your Fortran compiler before continuing this?
m[kel[ has joined #ocaml
<Riastradh>
I have to leave, anyways.
<JPL-Justin>
of course
<JPL-Justin>
enjoy
<JPL-Justin>
it's possible however if you use a good enough C compiler with stalin
<JPL-Justin>
there might not be a huge difference
smklsmkl has quit [Connection timed out]
Herrchen has joined #ocaml
smklsmkl has joined #ocaml
smklsmkl is now known as smkl
m[kel[ has quit [Read error: 110 (Connection timed out)]
fab has joined #ocaml
fab has quit [Remote closed the connection]
karryall has quit ["."]
smklsmkl has joined #ocaml
smkl has quit [Read error: 110 (Connection timed out)]
bk_ has quit ["I'll be back"]
karryall has joined #ocaml
kosmikus|away is now known as kosmikus
kinners has joined #ocaml
m[kel[ has joined #ocaml
smklsmkl has quit [Read error: 110 (Connection timed out)]
vezenchio has joined #ocaml
smklsmkl has joined #ocaml
m[kel[ has quit [Read error: 110 (Connection timed out)]
Dybbuk has quit [Remote closed the connection]
Dybbuk has joined #ocaml
kinners has quit ["leaving"]
phj has quit [Read error: 104 (Connection reset by peer)]
gim has joined #ocaml
smimou has joined #ocaml
SpookRijder has joined #ocaml
mattam_ has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
Shammah has joined #ocaml
_Defcon7 has joined #ocaml
Defcon7 has quit [Client Quit]
noss has joined #ocaml
Shammah has quit ["Leaving"]
SpookRijder has quit ["ni!"]
lodewijk has joined #ocaml
<lodewijk>
anyone up for a hopefully simple question?
<karryall>
sure, go ahead
<Banana>
yop.
<lodewijk>
type foo = { name: string; a: int }
<lodewijk>
type bar = { name: string; b: int }
<lodewijk>
let florp = { name= "florp"; a = 1 }
<Banana>
non.
<Banana>
beeeep
<karryall>
don't do that
<Banana>
error.
<lodewijk>
yup, error. how do I do that? do I have to have unique names for every field in my system?
<Banana>
you cannot use the same name for fields in different type.