__DL__ changed the topic of #ocaml to: OCaml 3.09.0 available! Archive of Caml Weekly News: http://sardes.inrialpes.fr/~aschmitt/cwn/ | A free book: http://cristal.inria.fr/~remy/cours/appsem/ | Mailing List: http://caml.inria.fr/bin/wilma/caml-list/ | Cookbook: http://pleac.sourceforge.net/
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
malc_ has quit ["leaving"]
MisterC has quit ["Client exiting"]
smimou has quit ["bli"]
__DL__ has quit ["Bye Bye"]
<jeremy_c> How do I document parameters on class methods in a .mli ? @param does not seem to be showing up in the docs.
mkhl has quit [Connection reset by peer]
<Smerdyakov> Booo for OO!
* jeremy_c comes from a OO background, should he be doing something diff?
<jeremy_c> http://pastebin.com/483397 ... is an example of what I am using it for.
<jeremy_c> hm, that's an old copy.
<Smerdyakov> Yes. Most OCamlers don't use the OO stuff.
<jeremy_c> If I were to write the person.ml as a module, I would then have to pass around a type structure to each of the functions, correct?
<jeremy_c> I would then also loose out on inheritence and virtual methods?
<Smerdyakov> More or less.
<jeremy_c> Why do most OCamlers not like OO ?
<jeremy_c> I'm open to new ways of thinking if it's better.
<Smerdyakov> Functional programming is just more effective in the average case.
<jeremy_c> Smerdyakov: that's probably where we differ. I'm coming from OO background learning OCaml as my first functional language. I understand some of the syntax but I am not thinking in a functional pattern but an OO pattern.
Smerdyakov has quit ["Leaving"]
Bigbang is now known as Bigb[a]ng
gim has joined #ocaml
bzzbzz has joined #ocaml
<lispy> jeremy_c: what i like about ocaml is that it lets you do OOP and FP, you don't have to choose and stick to just one
<jeremy_c> lispy: I can tell that my challenge will be to determine which one is better suited for the task.
<lispy> yeah
<lispy> i find that when i have a lot of behavior for some data, and for that data alone that OO is good
<lispy> but FP is great for hammering out transformations
<lispy> political movements are like farts. Some you hear about, some really stink, some are painful (like gas pains), but in the end they all pass...
<lispy> er
<lispy> hehe
<lispy> wrong channel
<jeremy_c> lispy: you hope they pass.
<jeremy_c> lispy: some times they stick around for generations to come.
<lispy> jeremy_c: yeah, sometimes you just need a really big timeline
shirogane has joined #ocaml
ski_ has quit ["Leaving"]
<jeremy_c> How do I include a type from a different .ml file? Simply appending it to the ocamlc line before the source it is used in and in the code specifying the filename . typename does not work like it does for functions.
pango_ has joined #ocaml
pango has quit [Read error: 104 (Connection reset by peer)]
<jeremy_c> lispy: would you look at: http://pastebin.com/483704 and tell me if you would use a class or a module here? Where I am going with this is to provide a base data object class that has a few functions build into it, like the add_change, get_changes, clear_changes ... The file over all would be like a data access object, handling the get/save/remove/find of the class object.
ski__ has quit [Read error: 110 (Connection timed out)]
ski__ has joined #ocaml
jeremy_c has left #ocaml []
dvekravy has quit [kornbluth.freenode.net irc.freenode.net]
joshcryer has quit [kornbluth.freenode.net irc.freenode.net]
dvekravy has joined #ocaml
joshcryer has joined #ocaml
jeremy_c has joined #ocaml
shirogane has quit [Remote closed the connection]
asymptote has joined #ocaml
asymptote has quit ["Leaving"]
<jeremy_c> how do I declare a record type in a .mli ?
<jeremy_c> type dbo_change = { field_name : string; old_value : string; new_value : string } is what it looks like in my .ml file
<jeremy_c> I am now trying to create a .mli
<dylan> ocamlc -i foo.ml
<dylan> the answer is, of course, it looks the same. types in .mli are the same as in .ml
<jeremy_c> dylan: hm. So I've been making these by hand for nothing :-) Oh well, good practice I guess :-/
<dylan> although, most of the time you make the type abstract.
<dylan> jeremy_c: ocamlc -i is only good for a start. Surely you'll want to hide some functions from the outside world.
<jeremy_c> dylan: yeah. And commenting should go into the .mli as well, right?
<dylan> the documentation strings, yes.
<dylan> one thing I like about ocaml is it's impossible to have an entirely undocumented function; at the least you have the function signature. :)
<jeremy_c> dylan: I am beginning to understand function signatures, but they are still sometimes very confusing to me, esp on complex ones.
<dylan> Do you understand currying?
<jeremy_c> dylan: no. this is my first real venture into a functional language.
<dylan> Are you familiar with perl or ruby? It's really easy to explain currying if you know a modern scripting language. :)
<jeremy_c> Ruby, somewhat. I use Python and Java the most.
<dylan> well, then, staying purely in ocaml;
<dylan> let succ x = x + 1 has type int -> int
<dylan> right?
<jeremy_c> yes.
<dylan> it takes an int, and returns an int.
<jeremy_c> right.
<dylan> let add a b = a + b is int -> int -> int. The reason for this is it is the same as let add = fun a -> fun b -> a + b
<jeremy_c> dylan: I understand the simple ones.
<dylan> okay
<dylan> so, parens confuse you?
<jeremy_c> val remove_assq : 'a -> ('a * 'b) list -> ('a * 'b) list
<dylan> okie, 'a * 'b is a tuple. like, (1, "foo")
<jeremy_c> type a, type b
<jeremy_c> hm, so List.remove_assq 1 [(1,"foo"); (2,"foo")] would return [(2,"foo")]; ?
<dylan> Yes.
<jeremy_c> Hm. I think I understand that.
<dylan> and List.remove_assq "bob" [(1,"foo"); (2,"foo")] is a type error.
<jeremy_c> right 'a 'b ...
<jeremy_c> cool. Something just snapped for some reason in my brain.
<dylan> type signatures are one of the most confusing bits of ocaml.
<dylan> they were to me, anyway.
<jeremy_c> In a .mli does it have to contain the functions of base classes?
<jeremy_c> ocamlc -i seems to output it that way.
<dylan> I think so.
<dylan> if by functions you mean methods.
<jeremy_c> hm. I can see where this could turn into a real pain in upkeep.
<dylan> basically anything not in the .mli is hidden from the rest of the world.
<dylan> I find it's best to write an .mli once a module is mostly set in stone.
<jeremy_c> Yeah, it sure seems like that would be the case.
<jeremy_c> well, it's 1am here. Thanks for the help tonight dylan, I'm going to go to bed.
<dylan> Heh, another East-coast US person.
<jeremy_c> yeah, there are quite a few of us.
asymptote has joined #ocaml
sebell has joined #ocaml
sebell has quit ["leaving"]
ski__ is now known as ski
asymptote has quit ["Leaving"]
ramkrsna has left #ocaml []
pango_ has quit [Remote closed the connection]
Bigb[a]ng has quit [Read error: 110 (Connection timed out)]
m3ga has joined #ocaml
chs_ has joined #ocaml
pango has joined #ocaml
Skal has joined #ocaml
joshcryer has quit [Connection timed out]
m3ga has quit [Remote closed the connection]
malc_ has joined #ocaml
vodka-goo has joined #ocaml
smimou has joined #ocaml
malc_ has quit ["leaving"]
__DL__ has joined #ocaml
kryptt has joined #ocaml
Raziel has quit ["Yo soy goma. Tú eres cola."]
jeremy_c has left #ocaml []
jeremy_c has joined #ocaml
jeremy_c has left #ocaml []
jeremy_c has joined #ocaml
jeremy_c has left #ocaml []
malc_ has joined #ocaml
descender has joined #ocaml
Raziel has joined #ocaml
Skal has quit [Remote closed the connection]
mfurr has joined #ocaml
jeremy_c has joined #ocaml
<jeremy_c> Is there naming schemes for files? for instance, I have a module to record changes to items. Should I name the file ChangeLog.ml Change_log.ml change_log.ml changeLog.ml, etc ? It will then obviously change how I access it in source
<malc_> jeremy_c: the only thing that is certain is that capitalization of the first letter is irrelevant
ski_ has joined #ocaml
ski has quit [Read error: 110 (Connection timed out)]
<samx> ..any here I was thinking I was the only ocaml user in the east coast :-)
<jeremy_c> Ohio here.
<samx> <- new york
ski_ is now known as ski
<jeremy_c> Not really east coast, but EST at least :-)
Smerdyakov has joined #ocaml
pango has quit ["Leaving"]
pango has joined #ocaml
<jeremy_c> classes should be all lower case?
<Smerdyakov> Classes should be all Don't Use Them Case!
<jeremy_c> Smerdyakov: you really don't like classes, do you?
<Smerdyakov> I don't like using high-conceptual-overhead structures in contexts where most of that overhead is wasted.
<malc_> jeremy_c: defined should be... their names can not begin with uppercase that's all
<mfurr> Hey Smerdyakov
<malc_> Smerdyakov: so inria's people are highly misguided in putting classes/objects in the compiler itself, eh?
<Smerdyakov> malc_, it's a research project. It doesn't necessarily need to be widely useful to be valuable to them.
<Smerdyakov> mfurr, hey hey hey, going to POPL?
<mfurr> yup :) 'was just about to ask you the same q
<Smerdyakov> mfurr, I am.
<mfurr> excellent
<malc_> Smerdyakov: huh? what is the question you were trying to answer there?
<samx> in general, i think objects in ocaml (using the <...> notation) are quite more useful than using objects with classes
<Smerdyakov> malc_, they're not misguided, because they are investigating new programming language constructs.
<Smerdyakov> malc_, that doesn't mean that these constructs are widely applicable.
<jeremy_c> Smerdyakov: http://pastebin.com/484387 is what I am using them for right now. Base_do is a base data object. More functionality will be placed there as time goes on. I have a module called SqlHelper that does all sorts of Inserting, Querying, Updating, Removing... All based on the fact that my Data Object inherit from base_do ... Can you look at the code and tell me if you would do it with classes or Modules ?
<malc_> Smerdyakov: the optimizing compiler (ocamlopt) uses objects/classes internally, you are arguing here that those are heavy-weight concepts that have no place on the face of the planet, so are they misguided?
<Smerdyakov> malc_, ah, I see I read what you said too quickly.
<Smerdyakov> malc_, I don't know how they use them, but language designers are always under pressure to implement their language tools in their languages. It's not necessarily the case that they judged them the best tools for the job.
<malc_> Smerdyakov: okay.. lablgl and lablgtk along with most of Stolpmans work is equally misjudged too.. or are we in a bit of over-genrelisation mood tonight?
<Smerdyakov> malc_, jeremy_c wants to use it for everything. I think it's a bad match for _most_ things. That's it.
<jeremy_c> I have 2 classes and about 6 modules.
<malc_> Smerdyakov: aha see your point
<jeremy_c> I am asking if my use of classes is bad. nobody has answered me yet :-/
<Smerdyakov> jeremy_c, you haven't presented a full program, so how could we say?
<jeremy_c> If it is, I am more than willing to learn.
<jeremy_c> I thought I gave enough information to make that decision.
<jeremy_c> I have other modules that work with this class structure and depend on the data object classes being inherited from base_do.
<Smerdyakov> jeremy_c, it's not enough information for me.
<jeremy_c> Smerdyakov: I figured if I gave too much, then people would not want to answer because they would be wading through a few hundred lines of code.
<jeremy_c> I will provide more if you would be willing to look at it.
<Smerdyakov> jeremy_c, it's a tricky business.
<Smerdyakov> jeremy_c, I'm willing to load the page and decide what is worth reading. :)
<jeremy_c> k
<malc_> jeremy_c: objects come with a penalty both space and time (much more so than in say C++), also there are potential pitfalls, they can make the code clearer though
<malc_> #
<malc_> _changes <- List.append _changes
<malc_> #
<malc_> [{field_name=fn; old_value=ov; new_value=nv;}]
<malc_> wow
<jeremy_c> I did not check my sample program for syntax, but it should be a full copy. base_do.ml, sql_helper.ml, person.ml, test.ml ... A dumb example, but...
<jeremy_c> malc_: bad?
<malc_> jeremy_c: very
<malc_> irrelevant if changes are known to be small though
<Smerdyakov> jeremy_c, why do you want to use this imperative "changes" interface instead of using SQL directly?
<jeremy_c> Some of the tables I have contain 300 fields, I just thought the interfaces was an easy method of doing it.
<jeremy_c> Smerdyakov: the actual person.ml or whatever, would be generated from the sql table, so no real coding on my part.
<Smerdyakov> jeremy_c, but I find SQL nicer to use than ML for such things.
<Smerdyakov> jeremy_c, why do you prefer to use ML?
<malc_> the imperativeness can be easily avoided with {< >} notation
<flux__> atleast ML can be statically checked, and that interface can guarantee you won't have runtime errors due to weird sql ;)
<Smerdyakov> SQL is easy to check statically.
<Smerdyakov> Much easier than ML.
<flux__> hmm, I can imagine it is, but I don't know of any tools. I suppose they exist.
<Smerdyakov> And you can embed SQL in OCaml with campl4.
<flux__> does that do such static checking?
<jeremy_c> Sorry guys, boss called I am talking to him on the phone to him now trying to talk here too :-/
<flux__> or were you just talking theoretically
<Smerdyakov> I think it's not so hard to do it. I've not tried it yet, though.
<flux__> how about if you need to dynamically construct the sql queries? such things could be hidden away to some module.
<Smerdyakov> flux__, what do you mean precisely by "dynamically construct"?
<flux__> well let's say the user interface has buttons that allows you to choose which fields the user can view
* ski wonders if one could make some similar checking as with MetaOCaml ..
<flux__> so sometimes you ask only for one field and sometimes it may involve a join
<jeremy_c> which we do here in my main app
<Smerdyakov> flux__, it's easy to type queries so that you can operate on them as first-class entities.
<flux__> I should maybe take a look into that, as I'm somewhat interested in SQL queries (well, writing software that does those)
<flux__> I've mostly solved that problem with application specific functions, that input the desired fields and additional conditions and output the query
<Smerdyakov> Yeah, so have I, though I also wrote a generic tool that I stopped using.
<Smerdyakov> In the long term, I'm convinced that the right solution is to use an environment where all data is persistent and SQL-style querying is possible for all of it.
<flux__> some things are just difficult to express in sql, a richer type system could sometimes be helpful
<jeremy_c> Ok, done on phone, sorry.
<Smerdyakov> And some things are just right for SQL.
<jeremy_c> Smerdyakov: why do I prefer ML? I don't prefer it right now, I am learning it with a small project. I am told functional languages provide cleaner and more maintainable code. Plus, I'm always up for learning a new language.
<jeremy_c> Smerdyakov: the "changes" interface has come about for two reasons. 1. It's the way I have always done it, so it seems natural to continue doing it that way. I still am not thinking in a "functional" mindset, although I know I need to make that change. 2. I have many operations to perform on a given table. Some require updating 2 of the 300 fields, others require updating 300 of the 300 fields. A canned SQL update updating 300 all the ti
<jeremy_c> (that was 3 reasons)
<Smerdyakov> jeremy_c, SQL _is_ a functional language.
<Smerdyakov> jeremy_c, (in the sense of no side effects in the query portion)
<jeremy_c> Smerdyakov: my primary languages are: Python, Java, C++ ... SQL may be functional, but I have never treated it so. I'm learning.
<samx> C is a functional language, if you only consider the '+' expression ;-)
<Smerdyakov> SQL has a notion of transactions built into it. It seems that you are duplicating that in your code.
<jeremy_c> Smerdyakov: I don't think I am even worrying about transactions right now. What do you mean?
kryptt has left #ocaml []
<flux__> jeremy_c, why do you bother making a list of things to add when you could just add them immediately?
<jeremy_c> flux__: with each setting of a set? like set_first_name = UPDATE people SET first_name=xxx" ?
* jeremy_c thought he was doing good w/his first project :-/
<Smerdyakov> jeremy_c, that's the question, yes. Why don't you just do that?
<Smerdyakov> jeremy_c, even beter, why not just use the UPDATE inline instead of the method? It's much clearer to me
<jeremy_c> Well, for instance, one table (claim) has over 20 relational links, SQL will err out if all 20 of those are not set during an INSERT.
<Smerdyakov> So set them all....
cascey has joined #ocaml
<jeremy_c> What about INSERTING vs. UPDATING ?
<flux__> I think that's a good reason
<Smerdyakov> flux__, why?
<flux__> he wants to create an object, manipulate unknown number of fields, finally guarantee every field has a value, and then commit the object
<Smerdyakov> jeremy_c, I like to always add/modify rows in single units.
<jeremy_c> First_name cannot be NULL. Last_name cannot be NULL, TPA must be 3 characters long, etc...
<Smerdyakov> flux__, he wants to do that, but why is that a good thing to want to do?
<flux__> maybe it's convenient, I don't know
<jeremy_c> you guys are really challenging my programming thinking.
<flux__> the database might require that firstname is atleast one character long, so he can't just put some default values in insert and then update the fields later
<jeremy_c> methodologies I should say.
<Smerdyakov> flux__, why would he want to put default values?
<Smerdyakov> flux__, why is it not _better_ to provide all columns at once?
<jeremy_c> Smerdyakov: what else am I going to put in it if on each set an UPDATE/INSERT is issued?
<Smerdyakov> jeremy_c, I don't understand "put in it.:
<jeremy_c> place into the field
<Smerdyakov> What field?
<jeremy_c> the fields that require default values
<jeremy_c> or correct values I should say
<flux__> smerdyakov, say the program interactively wants to ask the user for all that information, line by line
<Smerdyakov> flux__, I don't see the problem. You add the row after all data is entered.
<Smerdyakov> jeremy_c, put correct values!
<flux__> smerdyakov, should the programmer provide 20 variables with proper types to do that task, for the parameters to be finally passed to the INSERT, or would it be nicer to call set value immediately after retrieving the value and just finally say 'commit'?
<Smerdyakov> flux__, "proper types" are a non-issue, since we have type inference.
<Smerdyakov> flux__, and I think the first alternative is nicer.
cascey has left #ocaml []
<flux__> it is easier to separate querying for a set of values to a separate function, as you don't need to pass those fields back
<flux__> basically the first method requires the developer to mention variable names more times, which may be a place for error :)
<flux__> hmm, or is that so..
<flux__> well, atleast the variables have longer scopes, hence requires to invent names
<flux__> (longer, overlapping scopes)
<Smerdyakov> You should be able to automate input via meta-programming, anyway.
<flux__> while with setter-interface you can do a set of foo#set (read_input ())-lines
<flux__> well yes, each field type could be associated to a function that reads such input from user
<jeremy_c> Smerdyakov: this may be too much, but I'd love to see my sample program written by you w/your thoughts.
<Smerdyakov> jeremy_c, I think I'd want to implement SQL-in-OCaml first, and that's not feasible for a quick demonstration.
<jeremy_c> Smerdyakov: understood.
<jeremy_c> Basically my idea was to make person.ml work, then move it to a template, generate the other 50 classes from the SQL database itself, so I would not have to do any of the programming.
<flux__> I've been really considering rewriting a perl-written bug tracking system in ocaml
<flux__> mainly to make maintaining it more feasible, and secondly to see how much different it would become
<jeremy_c> Ok. Since I am not going to create SQL in Ocaml due to lack of skill. My example provided, was it a good use of classes or should it have been developed using modules ?
<jeremy_c> skip the bad programming with the List.append ...
<flux__> I was _just_ going to mention that :)
<jeremy_c> flux__: I'd love for you too actually. It was a source of "hm. Now what do I do?" on my part.
<jeremy_c> CamlTemplate was what I was going to use as the template library to generate all the Data Object .ml files.
<ski> don't repeatedly append to end of list ..
<flux__> :-)
<ski> one thing one can do instead is to cons/append to front .. and finally reverse, if needed
<jeremy_c> ski: the order is not really important to me.
<ski> ok, so skip the reverse
<jeremy_c> so just flip the params to List.append ?
<ski> think that'd work fine, yes
<jeremy_c> That's the only thing? I thought I had done a serious programming flaw.
<jeremy_c> ski: however, now that you mention that, I remember reading about appending to lists.
<ski> it's not that append is bad .. it's that using it in that way needless makes for O(n^2), when only O(n) is expected/needed
<jeremy_c> ski: I vaugely understand O(n ^ 2) but I don't know as if I have it solidified in my mind.
<jeremy_c> er, what I should say, is a real understanding of what's happening behind the scenes with the list.
<ski> append traverses the first list (also copying it, unless compiler can figure out that old list isn't being used afterwards)
<ski> '((a @ b) @ c) @ d' first traverses 'a', then 'a' (again) plus also 'b', then 'a' and 'b' (again), and 'c'
<ski> so, number of traversals is triangular number of number of left-nested appends .. and that's proportional to quadratic
<ski> otoh 'a @ (b @ (c @ d))' traverses 'a','b','c' each once .. so linear
<jeremy_c> So the rule is to always append to the front of a list.
<jeremy_c> prepend
<ski> yes, if you're doing it repeatedly
kryptt has joined #ocaml
kryptt has left #ocaml []
humasect has quit ["Leaving.."]
kryptt has joined #ocaml
kryptt has left #ocaml []
Smerdyakov has quit ["Leaving"]
shirogane has joined #ocaml
mfurr has quit ["Client exiting"]
vodka-goo has quit ["Connection reset by by pear"]
clog_ has joined #ocaml
clog has quit [Connection timed out]
clog_ is now known as clog
Smerdyakov has joined #ocaml
clog has joined #ocaml
shirogane has quit [Remote closed the connection]