Yurik changed the topic of #ocaml to: http://icfpcontest.cse.ogi.edu/ -- OCaml wins | http://www.ocaml.org/ | http://caml.inria.fr/oreilly-book/ | http://icfp2002.cs.brown.edu/ | SWIG now supports OCaml| Early releases of OCamlBDB and OCamlGettext are available
MadRat- has joined #ocaml
<MadRat-> Hi is this an english speaking channel?
<taw> mostly
<taw> but if you want to speak polish i can live with it
<taw> ;)
<MadRat-> Oh good (:
<MadRat-> I don't suppose there are very many Micro$oft Windows programmers who use OCAML
gehel has quit [Read error: 110 (Connection timed out)]
<lament> alas
<lament> although, there's F#.NET
<taw> hehe
<taw> Mi what ?
<MadRat-> To be honest I don't even know what .NET is
<taw> i think i heard that name ...
<whee> if you don't know what .NET is, you don't need to :)
<taw> i have to learn .NET for this silly course
<taw> on my uni
<taw> not sure why they put it there
<taw> it would be nice with java alone ;)
<taw> aa, i know
<taw> they put it so people know that java isn't that bad
<MadRat-> Is OCAML a hard language for beginners to learn?
<whee> I hate java :|
<whee> MadRat: not really
<whee> it helps to have some experience, but it's not that hard in any case
<taw> it is hard ;)
<MadRat-> I haven't written a program in the last 10 years
<taw> i wouldn't recomment starting with it
<taw> it's rather for experienced programmers
<whee> I would
<taw> whee: i thought that about java too
<taw> whee: but as the course includes DCOM and .NET
<whee> it's better to get in the habit of doing things right, and not introducing bad design choices while learning
<taw> whee: i started to think that java is quite sane
<whee> I don't think OO should be introduced early
<whee> it's a design thing, not programming in general
<MadRat-> I've tried to understand OO but it seems to be beyond me
<whee> you can do anything with ocaml and not even touch the OO support
<taw> nowadays oo is everywhere
<whee> it's nice to have, though. some problems do work well with OO
<whee> but a lot don't.
<MadRat-> I saw some benchmarks using 44 different languages and OCAML always came out in the top 5
<MadRat-> The only thing that really beat it was Visual C++
<whee> ocaml is one of the faster high-level languages
<MadRat-> (this is all under Windows, sorry)
* whee considers C/C++ low-level heh
<MadRat-> It also seems to use memory effeciently
<MadRat-> a lot of people do whee
<whee> maybe, but they're used for the wrong things
<whee> I see a lot (read: all) of applications using C or C++ when they do nothing that requires the low-level nature
<whee> just look at freshmeat sometime :)
<Kinners> would ocaml be ok for experimenting with compression algorithms, I would guess the only drawback would be having to use bigarray (for processing 16 bit data) ?
<taw> mmm
<taw> compression ?
<taw> i wouldn't really use ocaml for binary stuff
<whee> it's possible, but likely not in a functional style
<taw> or for memory-heavy stuff
<taw> that's where c++ clearly wins
<lament> or even C
<whee> yes
<taw> many important compression algorithms are not functional at all
<taw> they do lot of variable modifications etc.
<taw> now, why people don't do cgi in ocaml ?
<MadRat-> Could you explain imperative vs functional? I don't really understand it.
<lament> the better question would be, why do people do cgi?
<taw> generally, server-side web programming
<whee> taw: same reason they're using perl and friends. most people don't know any better :)
<taw> doesn't matter if by cgi or some other mechanism
<taw> perl is much better than c
<taw> they aren't that dumb after all if they use perl
<MadRat-> Isn't it better to use python than perl?
<whee> perl doesn't really encourage structured program design
<taw> as if that was big difference
<lament> taw: no, the point is, CGI is bad :)
<whee> it's hard to maintain at a point
<taw> lament: you mean CGI mechanism, or server-side www ?
<taw> perl/python/php aren't really much different
<lament> taw: uh, yes, they are
<whee> not really
<whee> well, php maybe
<whee> but python/perl/ruby are largely similar, with the main difference being syntax and library support
<whee> ignoring the OO nature of ruby and python
<taw> i have seen big fragments of code that worked exactly the same way in php and perl
<taw> and compiled in both to begin with
<lament> taw: CGI is bad because it doesn't separate logic and representation
<taw> lament: you can use CSS and stuff
<lament> that's not what I mean :)
<taw> and you can design scripts to separate them
lament is now known as lameAFK
<whee> heh, I can't find a nice definition of functional programming
<MadRat-> Thank you for trying whee.
<taw> foldoc:
<taw> functional programming
<taw> <programming> (FP) A program in a functional language consists
<taw> of a set of (possibly {recursive}) {function} definitions and
<taw> an expression whose value is output as the program's result.
<taw> Functional languages are one kind of {declarative language}.
<taw> They are based on the {typed lambda-calculus} with constants.
<taw> There are no {side-effect}s to expression evaluation so an
<taw> expression (e.g. a function applied to certain arguments) will
<taw> always evaluate to the same value (if its evaluation
<taw> terminates). Furthermore, an expression can always be
<taw> replaced by its value without changing the overall result
<taw> ({referential transparency}).
<taw> The order of evaluation of subexpressions is determined by the
<taw> language's {evaluation strategy}. In a {strict}
<taw> ({call-by-value}) language this will specify that arguments
<taw> are evaluated before applying a function whereas in a
<taw> non-strict ({call-by-name}) language arguments are passed
<taw> unevaluated.
<whee> that definition doesn't hold for ocaml, though
<taw> Programs written in a functional language are generally
<taw> compact and elegant, but have tended, until recently, to run
<taw> slowly and require a lot of memory.
<whee> (referential transparency doesn't, at least)
<taw> Examples of functional languages are {Clean}, {FP}, {Haskell},
<taw> {Hope}, {LML}, {Miranda} and {SML}. Many other languages such
<taw> as {Lisp} have a subset which is {purely functional} but also
<taw> contain non-functional constructs.
<taw> ocaml isn't purely-functional
<Kinners> what are a couple of projects that show off excellent ocaml programming and design?
<whee> the ocaml compiler :)
<Kinners> apart from that :)
<whee> perhaps camlp4 would be a good reference as well
<Kinners> ok
<MadRat-> thank you taw but I'm afraid most of that made no sense to me.
<whee> heh
<MadRat-> «Kinners»
<MadRat-> oops
lameAFK is now known as lament
<whee> what kind of experience do you have MadRat?
<taw> fftw !
<taw> that's very nice success of ocaml
<MadRat-> Mostly stuff from Ye Olde Days (6502 series ASM, BASIC, ANSI C...)
<taw> lambda is even older than that ;)
<lament> whee: I still think saying Python and Perl are largely similar is unfair :)
<MadRat-> All my programming knowege is in procedural, imperative languages
<lament> of course, #python would be the more appropriate language to debate that
<lament> s/language/channel
<whee> http://caml.inria.fr/tutorials-eng.html you might want to run through that
<MadRat-> «whee» me
<MadRat-> ?
<whee> yes, MadRat
<MadRat-> whee; oh yeah I found that.
<taw> ruby is even more different than perl
<taw> than python
<whee> the first intro (Hickey's) should be good
<taw> and i'd still call them similar
<whee> they're similar in that I see them used for mostly the same purposes
<lament> taw: different from what?
<taw> diff(ruby,perl) > diff(python,perl)
<lament> ah.
<taw> i know both ruby and perl well
<lament> I think you're wrong :)
<taw> and i think they are still similar in general design
<lament> Both Ruby and Perl have closures, while Python doesn't
<taw> python doesn't have closures ?
<lament> in Python everything is an object, while in both Ruby and Perl, it's not
<taw> i know both ruby and perl well but i'm no python expert ...
<whee> you're wrong already lament
<taw> realy ?
<MadRat-> hmmm...how does this sound?
<MadRat-> In functional languages, functions are treated as mathematical objects. If you define a function exactly the same as its definition in mathematic, the languages can guarantee that you will get nothing but the exact function you defined - nothing more or less.
<whee> everything is an object in ruby, no exceptions
<taw> in Ruby everything with exception of maybe methods is object
<lament> whee: no, you're wrong :)
<lament> whee: and taw is right
<lament> Ruby methods aren't even first-class
<whee> pfft :P
<taw> but that's pretty minor thing
<taw> you can put them into closures :)
<lament> taw: it's the language philosophy.
<taw> and closures are objects
<lament> taw: no, they're not
<whee> are if statements objects in python?
<whee> heh
<taw> hmm
<lament> the { ... } things are not objects
<lament> Blocks are objects
<taw> there was some talk about making methods objects too on ruby list
<lament> taw: that would be very good
<taw> so this isn't that much language design difference
<taw> lament: what would it help ?
<lament> taw: would make the language more consistent, for one. Would get rid of the stupid & prefix
<taw> hehe
<taw> "more consistent" isn't any goal
<taw> in what real things would it help ?
<lament> taw: It is a goal of Python
<lament> taw: which is one of the differences between it and Ruby/Perl :)
<taw> python has its own inconsistencies
<taw> like smallint/bigint
<taw> tuple/array
<taw> none of them in ruby
<lament> um, those aren't inconsistencies
<taw> but what could you do that you can't do now if methods were objects ?
<taw> or what would be much easier ?
<emu> who needs programming languages? just use turing machines/lambda calc
<whee> down with computing!
<whee> heh
<lament> taw: It hardly matters
<taw> emu: functional part of ocaml is very much typed lambda calc
<emu> indeed
<lament> taw: I'm not talking about usefulness
<lament> taw: I'm only saying that Python is not Ruby :)
<taw> lament: of course it matters
<emu> from my limited experience with Python, I would say that it is not a functional lang
<taw> well, and for more differences
<taw> Ruby is functional
<taw> Python is not
<emu> there is a distinct imperative flavour to it
<taw> Perl is not
<taw> so diff(ruby,perl) > diff(python,perl)
<lament> taw: um, you're mad
<emu> whereas Ruby seems to support fp more (as Smalltalk does)
<lament> taw: Ruby is not functional
<lament> and neither is smalltalk
<lament> both are very much non-functional
<taw> i had really cool example to prove you wrong ...
<emu> what do you think ``blocks'' are?
<taw> block is a closure
<lament> emu: closures. So?
<emu> tada
<lament> emu: and?
<taw> small function that takes any iterator
<taw> and turns it into folding function
<taw> you can't do something on such high level in ocaml even
<emu> [|a b| a + b]
<emu> (fn (a,b) => a + b)
<lament> taw: anyway, how can a language without first-class functions be considered functional? I'm at loss.
<lament> taw: In smalltalk, blocks ARE first-class objects
<taw> lament: closures are first class objects
<taw> that is blocks
<lament> taw: no, they are not
<lament> you have to convert them to objects
<taw> block is passed as last argument to iterating function
<lament> taw: yes. They're treated in a special way
<taw> iterator calls method on it
<emu> look, this usage of blocks as a special case for iterators is just dumb
<lament> taw: because, again, they're not first-class objects :)
<taw> the rest is syntactic sugar
<emu> I haven't followed that that much
<emu> but in Smalltalk, blocks are first-class functions/closures
<taw> ruby is full of syntactic sugar
<lament> taw: what if a function wants to access two blocks?
<lament> taw: instead of just one?
<taw> you have to use uglier way then
<emu> I do recall ways of creating function objects in ruby
<lament> taw: exactly
<emu> lament: so?
<lament> taw: because ruby blocks aren't first-class
<taw> but that's syntax issue
<lament> no, that's not a syntax issue
<emu> lament: I suggset you go read it
<taw> foo (1, 2, 3, lambda {one block}, lambda {another block})
<emu> lament: I distinctly recall seeing first-class functions in ruby
<lament> first-class versus non-first-class is a design issue
<taw> that's all
<lament> emu: well, you can convert blocks to objects with Block
<taw> lambda {foo} is first class
<emu> ruby even has call/cc
<taw> lament: you seem to care more about syntactic issues that practice
<lament> taw: _design_ issues, not syntactic issues
<taw> what's wrong with having to write lambda here and there ?
<taw> it's design of parser if any design at all
<lament> no, it is not.
<lament> In the same way you could say that you can have first-class functions in C by taking their pointers
<emu> no closures though
<taw> ruby -e 'print STDIN.map{|s| s.chomp.reverse}.sort.map{|s| s.reverse + "\n"}'
<taw> no closures in c
<taw> that's the problem
<taw> does this thing look functional ?
<taw> (copy&paste from my shell history)
<lament> taw: yes
<taw> i don't see any variables here
<taw> that's usual ruby one-liner
<emu> p1 = proc{|n| bar=n}
<emu> p1.call(5)
<lament> on the whole, i would not call ruby functional, though :)
<emu> we're only saying that it has functional elements
<lament> oh, sure. So do Python and Perl. And almost all other languages.
<taw> it has more functional elements that some "functional" languages
<emu> what a `functional programming language' is it not up for debate, and it's vague anyway
<lament> didn't C win in ICFP one year?
<taw> if something has closures and high level functions - it's functional
<emu> ICFP lets all in
<emu> but even C is considered `functional'
<emu> by some
<taw> as far as i'm concerned
<taw> emu: by who ;) ?
<lament> if C is functional, then Ruby, Perl and Python certainly are :)
<emu> i'm not sure. i've just heard someone say it.
<emu> presumably because it has functions =)
<taw> emu: how much did he drank before ;)
<emu> call-by-value and `referential transparency' (but in a stupid way)
<emu> and perhaps also because it allows recursion
<lament> taw: After all, closures are just a syntax issue
<emu> recall in 1972 that recursion was a new-fangled thing
<emu> lament: huh?
<taw> lament: huh ?
<lament> taw: you can emulate them with functions :)
<emu> lament: try and depend on closures in C, and it gets painful fast!
<taw> closures and high order functions are exactly the features that are not just syntactical
<emu> you need to write your own trampoline for funcptrs and establish the bindings
<emu> on the stack, or through some explicit mechanism
<lament> taw: um, you just said that high-order functions are a syntax issue
<taw> now, i'll have to chose language of the year 2003 to learn ;)
<lament> taw: you're contradicting yourself...
<taw> lament: where ?
<lament> <taw> what's wrong with having to write lambda here and there ?
<lament> <taw> it's design of parser if any design at all
<emu> lament: no he said that a few syntax issues does not unmake a functional language
<taw> lament: having to put lambda before block ?
<lament> taw: a syntax issue, that
<taw> in 2001 it was ruby, in 2002 ocaml
<emu> lament: and has nothing to do with actually having closurse
<taw> what language should i learn in 2003 ... ;)
<emu> what was it prior to ruby?
<taw> perl, but i didn't have such shedule then
<emu> I recommend Common Lisp, Smalltalk, and Haskell
<taw> i'm thinking about haskell mostly
<taw> common lisp also makes some sense
<taw> but why smalltalk ?
<emu> Squeak is fun
<lament> it's pretty :)
<lament> and it seems logical, after knowing ruby, to learn the language it tries to emulate :)
<emu> give you a glimpse of how computing should look
<emu> if not ideal
<taw> what does it have that ruby doesn't ?
<emu> (ie, why are we still hacking with such non-interative environments)
<taw> and are there any opes source programs in smalltalk i could learn from ?
<lament> taw: clarity.
<emu> taw: squeak
<emu> non-interactive
<emu> i meant to ay
<emu> I don't understand why Ruby doesn't even have a repl
<lament> repl?
<emu> really, a dynamic language without decent interactivity/runtime support is kinda silly
<emu> which is why perl, python, and ruby puzzle me a bit
<emu> lament: read-eval-print-loop
<taw> what is squeak ?
<lament> emu: uhh, ruby and python do
<taw> irb may not be perfect but ... ?
<emu> yeah, but it's still far inferior to CL or Smalltalk
<lament> emu: In Python, that's how the interpreter works
<lament> How's it inferiour to CL?
<taw> oh
<taw> but the question was
<emu> the error handling system is pathetic
<lament> and in any case, "inferior" is not the same as "not having any"
<taw> what real programs are written in smalltalk ?
<emu> taw: squeak.org !
<emu> who cares what real applications are written in it
<emu> you should see it anyway, it's a whole environment in itself
<taw> hmmm
<taw> i use emacs
<emu> note that I'm not a big Smalltalker, I just like Squeak
<taw> i know whole-environment thing already ;)
<lament> taw: emacs is nothing compared to squeak
<emu> now think ``nice programmable graphical system''
<lament> taw: emacs is ugly, with lots of horizontal complexity
<lament> squeak is structured
<lament> (by 'ugly' i mean 'overcomplicated')
<emu> oh and those 3 languages don't even have compilers
<emu> (not that squeak itself does, though smalltalk does. but squeak is still interesting)
<taw> CL has compilers iirc
<emu> yes, CL has compilers. I meant ruby, python, perl
<lament> emu: so?
<taw> aah yes
<emu> ruby still uses a mark-sweep GC
<taw> what's wrong with that ?
<taw> what else would you like to use ?
<emu> heh heh
<lament> having a compiler is hardly a major feat
<taw> certainly not reference counting
<taw> ruby has nice c interface
<taw> if program is too slow
<emu> mark-sweep is the lowest kind of GC
<emu> ref counting isn't GC
<taw> you can write offending 1% of code in c
<emu> taw: I don't want to program in C!
<taw> you can't get faster than that
<taw> in fact i got ruby+c program more efficient than comparable all-c program that way
<emu> C isn't very efficient anyway
<lament> together with GCC, it often is
<emu> if ocamlc.opt isn't faster already, I fully expect it will be in the future
<lament> s/gcc/sane compiler
<emu> GCC is crappy
<emu> on x86
<lament> use that magic intel compiler, then.
<emu> the reason is simple: more information means better optimization
<emu> high-level languages give more information about the program, therefore better optimize
<lament> emu: also a PITA :)
<emu> you need a ``sufficiently smart compiler'' however :)
<lament> high-level languages don't, as a rule, give more information about the program
<lament> they usually give less :)
<emu> are you kidding?
<emu> rather than fiddling with pointers, you can tell it what data structure you really want to use
<lament> depends on what you consider a high-level language
<lament> emu: only if you have static typing :)
<emu> C is weakly typed too
<lament> I'd say that Perl, Ruby, Python, Smalltalk are all high-level languages
<lament> neither is statically typed
<lament> all of them are usually less explicit than C
<emu> CL isn't statically typed either, but you can add annotations and there are compilers that do type-inference too
<lament> yes, but in Perl, Ruby, Python and Smalltalk you can't, and they're still high-level
<lament> Unless you consider CL "more" high-level
<taw> mmm
<taw> ocaml may use less cpu
<taw> but the way it uses memory
<taw> and also in case of other high level languages
<emu> lament: different goals
<taw> is often horrible
<lament> emu: certainly.
<lament> taw: that's a design issue
<lament> taw: there exists the developent resources/execution resources tradeoff
<taw> not really
<lament> ?
<lament> it doesn't?
<taw> it doesn't
<taw> some languages use more machine resources and more human resources
<lament> well, sure
<lament> like Brainfuck
<taw> like pascal ;)
<lament> but there's the minimal room
<emu> java
<emu> I think, is the stereotypical example
<lament> i.e. below some development resources threshold, the language cannot be fast
<taw> are you sure ?
<lament> below some execution resources threshold, the language can't be easy
<lament> Yes, i'm sure
<taw> where do you see this threshold ?
<lament> With languages like Python and Smalltalk.
<lament> I.e. languages with reflexivity, dynamic typing, late binding, object systems
<emu> hah. I have a language with two symbols: {0, 1}. 0 means output a high-performance 3d game. 1 means output a word-processor. fast, easy, and high-level!
<taw> if language is well-suited for usual stuff
<taw> it can be both easy and fast
<emu> there is definitely a trade-off between features and ease of compiler-creation
<lament> usual stuff?
<lament> taw: can you give an example of such a language?
<taw> php
<taw> it is optimized for one kind of work
* lament screams
<emu> yeah, creating simple home pages
<taw> and that makes it both easy and reasonably-well-performing in that case
<emu> anything beyond that and ... poop
<lament> As far as I know, php is not fast
<taw> oh it is
<emu> for its kind, i hear it is
<taw> naive c++ is slower than that
<lament> taw: for what?
<taw> it does database connection caching, and thing like that
<taw> for free
<emu> well, a cgi program will be slower than modphp anyway
<taw> it does lot of magic for you
<taw> modphp i mean
<taw> naive c++ prog would connect to db on every run
<taw> that would be slow as hell
<taw> oh, not to mention fork/exec
<lament> anyway, php is below my ease-of-use threshold
<lament> i don't know much about php, but i don't think it satisfies my "reflexivity, dynamic typing, late binding, object systems" criterion
<emu> taw: um, you're comparing apples and oranges
<taw> you mean is it too hard or too easy ?
<lament> too hard
<emu> php is not very powerful language anyway
<lament> oh, i should add strong typing to my criteria
<taw> lament: it's very easy for web pages that aren't too complex
<emu> ooh, strong typing and reflexivity
<emu> you don't mean static, right?
<taw> dynamic/static typing
<taw> etc.
<lament> emu: strong, dynamic
<taw> are features of language
<emu> oh ok
<taw> ease of use doesn't depend on them
<emu> i'm way too accustomed to ML people calling strong static
<emu> er, static strong
<lament> I think static typing is evil, but annotations are good
<emu> how about implicit static?
<lament> implicit static?
<taw> implicit static like ocaml ?
<taw> infered you mean ?
<emu> yep
<lament> that's still static :)
<emu> okay =)
<emu> I was curious whether you were bothered just by syntax
<lament> Don't get me wrong, I love the HM type system :)
<emu> explicit is just annoying
<lament> you mean annotations?
<lament> or really static static typing like in C?
<emu> required ones
<emu> explicit static typing means that you have to put the types everywhere you use them
<lament> well, yeah.
<taw> ocaml is very much like that ;)
<emu> syntactically
<emu> no
<lament> taw: no
<taw> you have to put them almost everywhere
<taw> costructors of type foo have to be FOO_*
<emu> ml has a implicit static type system
<taw> fields of record bar have to be bar_*
<emu> but of course, it's still static and it shos =)
<taw> or they will clash
<emu> also I think that the general case of type inference is undecidable
<emu> particularly with modules
<taw> hehe
<taw> ocaml screws it in a few points already
<emu> it's still a heck of a lot nicer than C
<emu> or Java
<lament> Haskell is supposed to be good at that, although I don't know the differences from ocaml
<lament> (that == type inference)
<whee> mmmm haskell
<lament> but then, haskell doesn't have objects
<emu> Haskell is subject to the same limitations
<emu> but it does have a more expressive typesystem afaik
<emu> huh?
<lament> objects as in class instances
<emu> they do better, with type classes
<lament> That's not quite the same. In any case, OO doesn't make much sense in a purely functional language
<lament> Certainly possible, but appaling
<taw> there are many mixed funcional/oo
<emu> blah, lets not get into OO
<taw> like ocaml and ruby
<emu> and CL
<taw> but none of them is fully functional
<taw> and cl right
<emu> because no one seems to be able to define it well
<whee> OO is pretty much useless in a purely functional language like haskell
<taw> the point of objects is that they are modificable
<lament> emu: "encapsulation, inheritance, polymorphism"
<lament> emu: a very simple yet effective definition
<emu> scratch encapsulation
<lament> encapsulation as ability to put objects inside objects, not data hiding
<whee> and that would be ad-hoc polymorphism with OO
<lament> no, that's object polymorphism
<emu> inheritance isn't mandatory either
<lament> (which, interestingly enough, C++ and Java don't have)
<emu> take a look at languages like Self
<lament> emu: well, inheritance/delegation
<lament> they clearly do the same thing
MadRat- has quit ["—I-n-v-i-s-i-o-n— 2.0 Build 2104"]
<emu> and even if you didn't have inheritance, you could still be ``object oriented''
<lament> a prototype-based language without delegation, now, wouldn't be very useful :)
<emu> personally, I think the defining characteristic of object oriented is object identity
<lament> that's a very lax definition
<lament> what's object identity?
<emu> OOP is a very vague term ;)
<lament> emu: not if you define it properly :)
<emu> how can you define it properly if it's used so many ways?
<emu> descriptive definition rather than prescriptive
<lament> ignore the infidels, and define it in the One True Way :)
<lament> so what's object identity?
<lament> An invariant property of every object?
<emu> the protocol by which each object is identical only to itself
<lament> oh, that's simple
<lament> then C is certainly object-oriented
<emu> try it with C structs
<emu> hehe
<lament> you just compare the pointers
<emu> values, my friend
<emu> C values
<lament> int i, j;
<emu> this is why people get so utterly confused when they look at the call-by-value semantics of Lisp, ML, etc
<lament> &i == &j;
<lament> Is false
<emu> struct foo a, b;
<emu> a = b;
<lament> &a == &b is still false :)
<emu> a.bar = 1; printf("%d\n",b.bar);
gehel has joined #ocaml
<lament> emu: so? Most language work that way
<emu> nope
<lament> smalltalk does, I think
<lament> Python certainly does
<lament> it will always work that way unless the '=' does implicit copying
<lament> which is stupid and bad
<emu> it does
<emu> in C, assigning values, passing by value, means copying
<emu> shallow-copy
<emu> effectively
<emu> remember, structs are just a series of bytes
<lament> they are? :)
<emu> whereas in almost all high level languages
<emu> all these operations would be done ``by pointer''
<lament> by reference
<emu> no, because on the language level it's not by reference
<lament> nor by pointer
<emu> pointers are an implementation detail
<emu> however
<emu> compare
<emu> (let* ((a (make-foo :bar 1)) (b a)) (setf (foo-bar a) 2) (print (foo-bar b)))
<emu> Torquemada: struct foo a, b; a.bar = 1; a = b; a.bar = 2; printf ("%d", b.bar);
<emu> arg
<emu> that's a to:
* lament tries to see the difference
<emu> both are call-by-value languages
<emu> however the Lisp will print 2 and the C will print 1
<emu> er
<emu> make that b = a;
<emu> but anyway
<lament> C will print 1?
<taw> no !
<lament> heh.
<taw> in c it won't compile
<taw> a = b
<lament> hm, true :)
<taw> memcpy or something
<lament> anyway, I'll sleep now. And I still don't see why you think copy-on-assignment is such an important OO feature.
<lament> Bye.
lament has quit ["It's not like I'm using."]
<emu> argh
<emu> it's NOT copy-on-assignment
<emu> that's a C ``feature''
<emu> http://mapcar.org/~mrd/compare/ is what i was gonna show him, but anyway
foxen5 has quit [Read error: 104 (Connection reset by peer)]
taw has quit [Read error: 60 (Operation timed out)]
Kinners has quit ["leaving"]
Begbie has quit ["Lost terminal"]
foxen5 has joined #ocaml
Kinners has joined #ocaml
lament has joined #ocaml
notkoza_ has quit [Read error: 60 (Operation timed out)]
notkoza_ has joined #ocaml
Kinners has quit ["zzz"]
stephane has quit [Read error: 54 (Connection reset by peer)]
mattam has quit [Read error: 110 (Connection timed out)]
asqui has quit [Read error: 104 (Connection reset by peer)]
asqui has joined #ocaml
lament has quit ["PROSECUTORS WILL BE TRANSGRESSICUTED."]
two-face has joined #ocaml
docelic has joined #ocaml
docelic has quit ["Client Exiting"]
docelic has joined #ocaml
docelic has quit ["later"]
Nshag has joined #ocaml
<Nshag> hi.
<async> yo
<two-face> hi
<Nshag> in :
<Nshag> # type my_first_rec_t = { field_x : int ; field_y : int };;
<Nshag> # type my_second_rec_t = { field_s : string; field_x : int; field_y : int };;
<Nshag> # let x = { field_x = 0; field_y = 0 };;
<Nshag> Some record field labels are undefined: field_s
<Nshag> how to create a my_first_rec_t ? i'm just starting to learn ocaml, sorry for the newbie question(s) and my english :).
<Nshag> got the answer.
whee has quit [Remote closed the connection]
docelic has joined #ocaml
docelic has quit ["biznis"]
docelic has joined #ocaml
whee has joined #ocaml
Nshag has quit [""grignotage.""]
two-face has quit ["Client Exiting"]
whee has quit ["No windows for this server"]
jao has joined #ocaml
YveDeLarc has joined #ocaml
<YveDeLarc> hi
jao has quit ["ERC vVersion 3.0 $Revision: 1.329 $ (IRC client for Emacs)"]
Kinners has joined #ocaml
docelic has quit [Remote closed the connection]
docelic has joined #ocaml
skylan has quit [Read error: 104 (Connection reset by peer)]
skylan has joined #ocaml
YveDeLarc has quit [Read error: 60 (Operation timed out)]
TimFreeman has joined #ocaml
TimFreeman has left #ocaml []