huxley.openprojects.net changed the topic of #ocaml to: www.ocaml.org
<whee>
the Arg module handles command line arguments
<whee>
I think
<whee>
heh
<whee>
use Sys.argv
<whee>
val argv : string array
<whee>
The command line arguments given to the process. The first element is the command name used to invoke the program. The following elements are the command-line arguments given to the program.
<comatoast>
so I can get at them by doing Sys.argv.[1]?
<whee>
Sys.argv.(1)
<comatoast>
and they're strings, right?
<comatoast>
int_of_string exists, right?
* comatoast
tries stuff
<whee>
I believe that's it
<comatoast>
print_int gcd int_of_string Sys.argv.(1) int_of_string Sys.argv.(2) <-- I think I'm screwing up the order of things...do I do parentheses as in C++ to disambiguate what are arguments to what, or...?
<whee>
yes you should use parentheses
<whee>
print_int (gcd (int_of_string Sys.argv.(1)) (int_of_string Sys.argv.(2))) may work
<whee>
I usually overdo parentheses to be safe anyway heh
<comatoast>
looks strange without commas :)
<whee>
nah :D
<whee>
it'll grow on you
<comatoast>
to ME...
<comatoast>
(now)
<whee>
then you'll try programming in c and wonder why nothing works :)
<comatoast>
anyhow, it's not printing anything. compiles fine, though.
<whee>
try flushing the output stream?
<comatoast>
howzat work?
<whee>
flush Pervasives.stdout
<comatoast>
maybe I forgot a ;; at the end of the foo.ml file?
<whee>
or just call print_newline. that might also work
<whee>
you don't need ;;'s unless you're working with the toplevel
<comatoast>
I think I am
<comatoast>
here's the file, in a nutshell...
<whee>
by toplevel I mean the ocaml interactive read-eval-print loop thing
<comatoast>
oohhh
<comatoast>
let rec gcd a b = (* stuff *);; (* some newlines *) print_int(gcd(int_of_string Sys.argv.(1)) (int_of_string Sys.argv.(2)))
<comatoast>
do I need to separate the print_int call with the flush line with anything?
<whee>
I don't believe so
<whee>
basically just do let rec gcd a b = (* stuff *), then a newline, and let _ = print_int ( blah blah blah)
<whee>
I suggest using let _ = (* commands *) as a main function of sorts
<whee>
so you could do "let _ = print_int (gcd ( **** ) ) in print_newline" after you define the gcd function
<comatoast>
(* blah *) in print_newline?
<whee>
yes
<whee>
are you following a book or something?
<comatoast>
I have the ocaml caltech book here...
<whee>
when you do "let something = something else" you can follow that up with an "in more stuff" so that that something is used in something else
<whee>
ie. let a = 5 in 2 + a
<comatoast>
that makes sense.
<whee>
I forget what exactly "_" is, but it's basically a catch-all in pattern matching
<comatoast>
however, it doesn't make sense since I can't see how print_newline would be able to make use of the blah in "blah in print_newline"
<whee>
in this case, it can't
<whee>
it's just a way to continue processing without having to string together commands with ;
* Yurik
is drinking cola and thinking about some portion of wine
<comatoast>
I'd rather use ";"; it's clearer for me
<whee>
whatever floats your boat :D
<whee>
heh
<whee>
although I think there was a reason I used that style at the time
<whee>
I can't remember what it is
<comatoast>
let _ print_int((*blah*)); print_newline; print_newline;; (* warning: line 10 (the line containing the first print_newline): this function application is partial, or some arguments are missing. <--what's it expecting? ()? *)
<whee>
err, yes
<whee>
print_newline ()
<whee>
sorry D:
<whee>
you could alternatively print_endline (gcd (* rest *)) I think
<whee>
print_endline wants a string though
<whee>
nevermind
<whee>
heh
<comatoast>
string containing what?
<whee>
print_endline is for printing a string followed by a newline. print_endline "hello"
<whee>
I had a brain fart and forgot that gcd returns an int
<comatoast>
better question: where can I find out from some sort of reference doc?
<comatoast>
gives me an error that I'm passing print_newline a unit instead of a string
<comatoast>
but if I remove the parentheses around the argument to print_newline..
<comatoast>
then...File "foo.ml", line 10, characters 2-15:
<comatoast>
This function is applied to too many arguments
<whee>
hm
<JGibson>
i wish the error reporting system was nicer
<comatoast>
ditto
<JGibson>
i haven't tried programming in caml for a while since the last program i tried to write, the compiler said something like "error" and not much else
<whee>
heh
<comatoast>
ow ;)
<JGibson>
yea :)
<whee>
the toplevel has a nicer error thing
<whee>
but that doesn't help much with compiling :/
<JGibson>
ah, i haven't fooled with that a whole lot
<whee>
hold on comatoast, I'm going to see if I can reproduce that locally so I can figure it out :D
<whee>
I have problems matching parentheses by looking heh
<comatoast>
whee: want me to send you the file?
<whee>
nah, I figured it out
<whee>
you're using print_newline, which prints a newline and expects a unit
<whee>
use print_endline
<comatoast>
jeezis :P
<whee>
small error :D
<comatoast>
ok, I got it
<comatoast>
so, print_endline -> print a string and cap and endline..
<comatoast>
ok, next program...
<whee>
yes
<whee>
heh
<whee>
you're lucky you have something to program :)
<whee>
I've been sitting here for a week trying to think of something heh
<comatoast>
trust me, I know what a luxury it is to have a problem sometimes..
* comatoast
gets out his old CS120 sheets
<comatoast>
is there something special about functions with an uppercase character as their first letteR?
<comatoast>
s/R/r/
<comatoast>
and is there something special about the word "end"...?
<JGibson>
whee: come'on, there's tons of stuff to program :) we're in the stone ages of computers still, lots of work to bring them up to spec
<comatoast>
...yep.
<whee>
hehh
<whee>
what do you mean about "end" comatoast?
<comatoast>
whee: for what sorts of things does ocaml do better than most other languages?
<comatoast>
whee: I just found out it was a keyword, that's all
<whee>
oh
<whee>
well you use it in "begin ... end" blocks
<whee>
it's kindof like using parentheses
<whee>
also I prefer ocaml to just about everything somehow
<whee>
except for some massively text based applications, I'd rather use perl or something
<whee>
but that's just because I don't know what I'm doing with the parsers that ocaml has heh
<JGibson>
no way man, you should be using assembler!
<whee>
:D
<comatoast>
asm's too annoying and nonportable to be useful for much.
<JGibson>
nuh uh! asm 4 life
<whee>
I forgot how much I liked ocaml until I tried writing my own xml parser in c
<whee>
"free the mallocs$!@!"
<comatoast>
C sucks.
<comatoast>
C++ forever.
<whee>
I think c++ is a bad attempt at oo
<comatoast>
so?
<whee>
I'd rather use objective c if I had to
<whee>
basically c with some syntax for oo
<comatoast>
generics is where all the fun is, anyhow
* Yurik
is out to smoke
* Yurik
is back
gene9 is now known as gene9_afk
gene9_afk is now known as gene9
gene9 has quit []
whee has quit [carter.openprojects.net irc.openprojects.net]
hff has quit [carter.openprojects.net irc.openprojects.net]
JGibson has quit [carter.openprojects.net irc.openprojects.net]
jao has joined #ocaml
whee has joined #ocaml
JGibson has joined #ocaml
<comatoast>
hm, is there a "useless ocaml" page out there somewhere?
<whee>
eh?
<comatoast>
nevermind, these links pages should be good 'nuff
<comatoast>
type figure =
<comatoast>
| Triangle | Square | Circle | Parallelogram;;
<comatoast>
^---kinda like a strongly-typed enum?
<whee>
you could think of it that way
<comatoast>
is there another way to think of it that doesn't distort reality as much?
<whee>
I can't think of anything
<whee>
nuts
<whee>
heh
<whee>
you can do other things with type too, structlike things
<comatoast>
what's naturally recursive, and what isn't?
<whee>
well, parsing a tree structure would be naturally recursive
<whee>
there are things that are just easier to grasp when thought of recursively
<whee>
like if you took that gcd function and wanted to write a function that took the gcd of any amount of numbers, you could think of a recursive solution very easily
<whee>
ie. the gcd of a b c d ... x y z is the gcd of a and the rest of the list, which is the gcd of b and the rest of the list, which is the gcd of c and the rest of the list, and so on
<whee>
tree structures are usually what most people think of as a naturally recursive thing though
<comatoast>
and lists, iterative?
<whee>
it's hard to write an iterative approach to that
<whee>
for the example shown in the faq, recursive there makes sense
<whee>
it's a lot shorter and avoids having a side effect
<comatoast>
'a side effect'?
<whee>
notice how the iterative version has a reference "res" that gets incremented
<whee>
along with "l"
<comatoast>
where does l get incremented?
<whee>
the incr l; statement in the middle
<whee>
I can't even understand the iterative version :D
<comatoast>
let list_length l =
<comatoast>
let l = ref l in
<comatoast>
let res = ref 0 in
<comatoast>
while !l <> [] do
<comatoast>
incr res; l := List.tl !l
<comatoast>
done;
<comatoast>
!res;;
<comatoast>
^---what "incr l;"?
<whee>
errr oops
<whee>
the l := List.tl !l does that
<whee>
:= is the assignment operator for references
<whee>
List.tl returns the list minus the first element
<comatoast>
do references need to be explicitly dereferenced, like C pointers?
<whee>
yes
<whee>
you need to do !name in order to get the value
<comatoast>
why not !l = List.tl !l ?
<comatoast>
just because?
<whee>
probably because you aren't changing the value that l dereferences to, but l itself
<whee>
I'm not sure
<whee>
that and = is used for other things that it probably cause confusion
<comatoast>
I'm assuming that !foo is almost strictly equivalent to C's *foo
<whee>
probably
<comatoast>
well, I'm used to = meaning assignment (or in std::auto_ptr's case, ownership transfer)
<whee>
the thing with ocaml is that you aren't supposed to change the value of a something after it's been assigned one
<whee>
which is why it's := and <- (for mutable things)
<whee>
I think :D
<comatoast>
strange incongruity
<comatoast>
then again, ., ->, and :: have very little in common.
<whee>
I remember reading something about why they chose those somewhere
<comatoast>
how would I translate template<typename T, class UnaryFunction> void for_each(vector<T>& vec, UnaryFunction& uf); into ocaml?
<whee>
derr I have no idea
<whee>
it's been so long since I've looked at c++ :/
<comatoast>
basically, I want to do something to a list of T's
<comatoast>
where T is any arbitrary type
<comatoast>
urm, to each of a list of T's
<whee>
oh
<comatoast>
I've gotten to the let rec foreach part...
<whee>
apply a function to each element of a list?
<comatoast>
yeah
<whee>
try List.map
<comatoast>
I want to do it myself...I'm still getting the hang of the language (syntax, too...)
<whee>
hm
<comatoast>
isn't there something like "list of 'a"?
<comatoast>
I promise I won't use my way after I get any skill at using ocaml ;)
<whee>
the type doesn't matter in this case
<whee>
all you need to do is define a function that takes a function and a list as arguments
<whee>
and recursively call itself on each element on the list
<comatoast>
right...
<whee>
you know the "head :: tail" syntax of lists?
<comatoast>
ehh...I've seen it before..
<comatoast>
...sorta.
<whee>
you'll want to use that and pattern matching
<whee>
figure those out and you should see what you need to do
<whee>
you don't really need pattern matching but it helps make it look cleaner
<comatoast>
let rec foreach things func = (* if things == []: return (); *)
<whee>
that's the first part
<whee>
heh
<comatoast>
match things with [] -> (* we're done, bail *)
<comatoast>
what's the 'return' equivalent?
<whee>
simply what you want to return
<whee>
in this case, []
<whee>
an empty list
<comatoast>
what about ()?
<comatoast>
since we're doing everything by side effect (if that's the proper term)
<whee>
well
<whee>
it'd be without side effects, and the type checking would prevent you from using ()
<whee>
this function calls itself recursively and ends up returning a list
<whee>
so it has to return a list no matter what
<comatoast>
gotcha
<whee>
(I'm assuming you want to return a list that's the original list plus the modifications the function does
<whee>
unless you simply want to iterate over the list and do things with it
<comatoast>
what about inplace modification?
<comatoast>
that's what I'd rather do...
<comatoast>
since any shmuck can clone a list, I'd suspect...
<whee>
you could either construct a new list that's a result of the function to the initial list, or just use the function on each element and do something with that
<comatoast>
the latter is what I'd rather do
<whee>
then it doesn't really matter if the empty list case returns () I suppose
<whee>
as long as the recursive case returns nothing also
<whee>
hegh
<whee>
but I think you might want to return a new constructed list
<whee>
it's probably more useful
<comatoast>
still, if I want a fresh list, I'd make one myself...
<comatoast>
anyway, back to this implementation..
<whee>
it's probably more useful
<whee>
er
<whee>
oops
<whee>
wrong windows are fun :D
<JGibson>
and then i opened the door to the greenhouse to find not my grandparents sipping tea, but engaged in all manner of letcherous acts with a number of their mates from the cruise they had just returned from. imagine my shock. i didn't even get an invitation!
<JGibson>
doh! wrong window antics again
<whee>
heh
<whee>
still working on it comatoast? D:
<comatoast>
want to bug someone...
<comatoast>
(about something else)
<whee>
heg
<whee>
after watching tv for a few hours I actually wrote a simple irc bot in ocaml :P
<comatoast>
coo
<whee>
I think I confused myself with the way it works thought
<whee>
I do that with everything I write
<JGibson>
we need better visualization tools
<JGibson>
why don't you make some for us
<whee>
what now?
<whee>
heh
<JGibson>
programming is 'hard' now because we can't visualize everything that's going on. tools like debuggers are like trying to figure out why a chair broke by looking at a single joint, when it's obvious if you stand back at a distance that the chair broke because there was a 500 lb person sitting there
<whee>
I still don't see how that'd work
<JGibson>
we don't have tools that let us see a complex program very well. we start hitting walls, where the complexity is too great for a single person to manage. if we had better tools, programs that let the computer do more of the work, then the human programmer would be free to do the creative part of programming, making fewer errors and being more productive
<comatoast>
I want a language that slings kernel threads around with the greatest of ease
<comatoast>
that isn't a Java lookalike
<comatoast>
and I want a huge fucking library to come with it
<whee>
I don't think there's an easy way to debug a huge program that way D:
<JGibson>
an example of one possible visualization tool would be an interactive algorithm developer. you want to compute some function, so you define your data, and the computer represents that on the screen. you could set up your algorithm graphically, or with rules. and the simulator will go through it and show you exactly what's going on. boundary cases, etc.
<whee>
oh
<whee>
that takes all the fun out of programming though
<whee>
:D
<JGibson>
haha
* comatoast
slaps whee
<JGibson>
like, instead of getting some crappy text error message, you'd physically see your algorithm overshoot the bounds of an array
<whee>
basically you want a debugger that graphically represents everything
<comatoast>
I'd rather have nicely constrained iterators, thankyouverymuch.
<JGibson>
well, it's more of an ide\debugger combo, since it manages development and error corrections
<comatoast>
what I want for C++ are sane error messages.
<JGibson>
come'on, think to the future :)
<whee>
heh
<JGibson>
i want to be able to make 1mloc programs in my sleep
<comatoast>
JGibson: have you worked with STL code?
<comatoast>
1mloc?
<whee>
eeh
<whee>
I just don't think it's really necessary
<JGibson>
coma, i've never written anything with it, but i have read a few tutorials and am familiar with some of the concepts
<JGibson>
coma, mloc is millions of lines of code
<comatoast>
JGibson: let me write up a buggy bit of code and paste the error message...
<JGibson>
whee, so you'd rather continue the way we do now, where it's hard to make good software?
<whee>
how is it hard?
<JGibson>
oh, you don't have to show me bad error messages, i'm familiar with them :)
<whee>
I have no problem producing good software provided I have an idea of what I want to do
<comatoast>
JGibson: they're not so bad as they are long, and hence, obfuscated
<JGibson>
whee, because most software has bugs in it. most software that doesnt' have a lot of bugs is either old, or really expensive to make.
<comatoast>
whee: making it easier can only mean you get stuff done faster, and others that aren't as 31337 as you can also pitch into the pool
<JGibson>
take the space shuttle systems software. it's an extremely stable piece of software, and if you've looked at what goes into writing it, you'll appreciate why. but why not have that level of quality for everything we do?
<whee>
because that's impossible
<comatoast>
JGibson: the cost/benefit
<JGibson>
computers were invented to take the tedium out of common tasks. a lot of programming is just that, random stuff that a computer could do, given sophisticated enough algorithms
<JGibson>
whee: why is it impossible?
<whee>
because that requires not being human
<JGibson>
exactly my point. you let the computer do it
<comatoast>
why should Microsoft bother with making things flawless when people buy their stuff as it is, flaws, exploits, and all?
<whee>
but a human has to do something at some point, which is where it all breaks down
<whee>
just because joe sixpack can "program", doesn't mean he has the knowledge to actually do much
<JGibson>
why bother? because as we rely on computer systems more and more, the bugs will come back to haunt us. failures will start meaning lost lives
<JGibson>
whee, did i ever say to get rid of the programmer entirely? nope. i just suggested we raise the abstraction level.
<JGibson>
it's like the difference between writing your apps in assembler, vs ml
<whee>
I don't see the point in that
<whee>
any higher than what we have now isn't making it any better
<comatoast>
it's portable, silly
<whee>
it ends up turning into something like java, where you have tons of classes to handle high end tasks, but they aren't detailed enough to do a specific job you might have without massive workarounds
<JGibson>
if you had a do_stuff() routine, you'd use it, right?
<comatoast>
whee: that's because Java sucks.
<comatoast>
it's inflexible
<JGibson>
comatoast: that's not the point! the point is the level of detail you're working at. if you had a choice between writing a program in assembler, or writing it out in pseudocode, which would you chose?
<comatoast>
pseudocode
<whee>
asm and psuedocode is a huge jump
<comatoast>
agreed
<JGibson>
yes, so?
<whee>
I fail to see what could possibly be beyond actual code like ml
<whee>
it can't get much higher level
<JGibson>
ok, let's just take a gander and invent something higher level. if you could make the perfect programming language, what would you make it like?
<comatoast>
it'd smell like C++.
<whee>
mine would be a mix of ml and perl
<whee>
heh
<comatoast>
functions would be first class types
<comatoast>
gotta have that...
<comatoast>
classes would be first class types..
<comatoast>
dunno what that'd do to it, though...
<comatoast>
hm...
<comatoast>
static, or dynamic typing?
<comatoast>
...or a mix?
<comatoast>
or no typing at all?>
<whee>
static definately
<comatoast>
all the time?
<whee>
yes
<JGibson>
ok.. well what i'd do is make the language as close to natural language as possible. i'd make it so you can draw up some pictures on the screen showing a timeline of how the program should go logically, and then let the computer whiz away, calculating everything it needs to make that happen
<whee>
you can prove anything if it's static
<whee>
you're basically saying like applescript jgibson?
<JGibson>
and if you want to make progress in the computing world, we need to solve the problems that lead to such an ideal.
<whee>
heh
<JGibson>
i've never seen a.s.
<JGibson>
that's still too low level
<whee>
are you sure about that?
<whee>
applescript is basically english sentences
<JGibson>
yea. you have to remember names and so forth with apple script, right?
<whee>
it even allows you to just _do_ things and have it turned into a programing language
<comatoast>
I want fuckloads of syntactic sugar
<whee>
given asm and vb, I'll take asm.
<whee>
I'm imagining this higher language as a vb for the masses, which I don't like at all
<JGibson>
ok, say i want to make an image processing application. why not be able to say 'apply a fft to this, then lay it out in a 3d matrix, then invert it. if the result matches this general pattern, notify me of the interesting points, otherwise take another sample and continue"
<comatoast>
whee: what about VB is so repulsive?
<comatoast>
whee: I'm not done yet ;)
<whee>
I hate the syntax, and it's not crossplatform
<whee>
I haven't used it at all so I can't get into actual detail heh
<whee>
asm isnt crossplatform either, but at least it's not os specific
<JGibson>
any comments?
<whee>
I don't believe it's possible to go beyond merely scripting actions without requiring actual code
<JGibson>
we do it
<JGibson>
do you believe that the human brain is irreproducable?
<whee>
absolutely
<JGibson>
why
<comatoast>
JGibson: with what tools?
<JGibson>
comatoast: that is the tool. some ideal ide
<whee>
if you show me a computer that has the pattern matching skills, learning capabilities, and visual processing skills of a human, I'll believe it's possible
<comatoast>
JGibson: how good of an approximation do you need?
<whee>
even just one of those would satisfy me
<JGibson>
whee: do you know much about neuroscience?
<whee>
that depends on where this is going
<JGibson>
comatoast: well, that is the ideal to work towards. i'm saying that we should strive to meet that, rather than accept what we have
<JGibson>
whee: well, i just want to know what background you have
<whee>
not much in that area
<comatoast>
JGibson: I've dabbled a bit in there... (read a book or two)
<JGibson>
whee: ok, i do, so would you be interested in me telling you a bit about what i know?
<comatoast>
I think it's possible to model a human brain with software/hardware; current technology isn't anywhere near that
<whee>
fine by me :P
<JGibson>
yea, i totally agree that with the state of our technology today we don't have anything approaching it. but consider where the field is. neuroscience only really started 20 years ago. that's younger than computer science. the tools required to understand the components of the brain are still in their infancy
<JGibson>
there are around 10^12 neurons in the brain, with 10^15 connections between them. so it's an enormous machine to simulate. as of right now, we have a pretty good idea of how the basic components work. we can simulate individual neurons and make predictions about their behavior. we probably won't have any really big surprises computationally as far as they are concerned.
<comatoast>
I think we've got plenty of surprises in store
<whee>
even if it is possible, do we even want to do it?
<JGibson>
we can simulate lots more, depending on how detailed your simulation is(the jury is still out due to lack of information on what is exactly necessary), so some simulations are about 250k neurons for large ones. the systems level is not very clear, because we can only monitor about 200 neurons at once
<whee>
matching our capability wouldn't be enough, they'll want to go beyond
<whee>
(insert the matrix references here :D)
<JGibson>
but we do understand a lot of functionality of the various brain regions. we understand how signals are relayed, we understand how the processing works, and the information flow. we can take the data that the retina in your eye gets, and follow it along it's path, and at many of the steps, we can tell you what the brain is doing to it, and where that new information goes.
<JGibson>
for instance, one part of the brain processes edges in an image. whenever an edge passes by, that area lights up, passing the knowledge that an edge was detected, upstream to a higher level center.
<JGibson>
so, there isn't really anything magical about the brain. the reason we haven't reproduced much of it is because of the complexity, and the lack of processing power to do it. our current synthetic neural nets are spreading pretty fast as far as the applications that use them. we have a good understanding of their mathematical properties, so we can apply them to domains that we don't have the proper tools for.
<JGibson>
and as time goes on, we'll be able to learn how to build our own computational centers, mimicking the ones in the brain. by that time, we'll likely have a much better understanding of the principles behind it, and be able to make much more powerful systems. and with that, we'll be able to solve many more problems with computers. things like having a car drive us places, etc
<whee>
having a car drive us places is nothing
<whee>
we can do that now
<JGibson>
not really
<JGibson>
i'm not going to take an automated taxi cab anytime soon
<whee>
we have gps, we have the sensors to detect these things
<JGibson>
heh, but those are all so rudimentary compared to what would be necessary safety wise, and reliability
<comatoast>
let l = "hey" :: "world" :: [];; (* why is the trailing [] needed? *)
<whee>
I'm not sure it is D:
<comatoast>
# let l = "hey" :: "world";;
<comatoast>
This expression has type string but is here used with type string list
<whee>
I can't check because for whatever reason I can't access any sites heh
<whee>
probably just so the checker knows it's a list in that case
<whee>
you could use the other syntax
<whee>
["hey"; "world"]
<comatoast>
the fundamental question: what is this :: thing?
<whee>
it's for adding things to list
<comatoast>
insert the lhs into the list...aaah, ok
<whee>
like cons in lisp if you've used that
<comatoast>
nope
<comatoast>
what about pop_from_front, analogous to the push_onto_front that I've just learned?
<whee>
the what now?
<whee>
those sound like custom functions
<comatoast>
go beyond the names and to what they do
<whee>
oh
<whee>
you could use List.hd list
<whee>
or pattern match hd :: tl and do something with hd
<whee>
or something elsethat I'm missing for some reason
<comatoast>
so ::, when it's used in matching, pops hd off of tl?
<whee>
I'm pretty sure lists are immutable so you couldn't actually modify the original list
<whee>
yes
<whee>
if you match a list against a :: b, the head (first element) is a, while the rest of the list is b
<whee>
but the original list isn't changed
<comatoast>
wacky
<comatoast>
so back to that thingy I was writing earlier..
<comatoast>
let rec foreach things func = match things with [] -> [] | (* how can I capture my equivalents of a and b so I can do stuff with them later? *)
<whee>
match things with [] -> [] | a :: b -> (* do stuff with a/b *)
<whee>
| seperates cases
<comatoast>
-> does...?
<whee>
hm?
<comatoast>
well, the way I read it..
<whee>
in this case, -> is a seperator that specifies what should happen when something to the left occurs
<comatoast>
how would it match against a :: b?
<whee>
it knows things is a list, so it takes the list and applies it to a :: b, which specifies that it put the head in a, and the rest of the list in b
<whee>
if you have a list of [1; 2; 3; 4], a would be 1, and b would be [2; 3; 4]
<comatoast>
then how does it apply a list to another list?
<comatoast>
for the first case, it works like a comparison thing
<comatoast>
for the second, it's like an apply thing
<whee>
it's pattern matching, and a :: b is a pattern
<whee>
just like [] is
<whee>
you've seen tuples right?
<comatoast>
how's [] a pattern?
<comatoast>
in python, much less so in ocaml
<whee>
suppose you have a tuple and a match tuple with (3, x) -> 1 | (x, 2) -> 2 | (x, y) -> 3
<whee>
if this tuple were (3, 5), this would return 1
<comatoast>
right
<comatoast>
2, 2 -> 2
<whee>
and anything else is 3
<comatoast>
anything else , 3
<whee>
it's the same with this
<whee>
a list is a data type, and [] is specifying an empty list
<whee>
I dont think that cleared anything up
<whee>
it didn't for me anyway
<whee>
heh
<whee>
sounded like a good approach at the time :D
Yurik is now known as Yuri
Yuri is now known as Yuri\
<comatoast>
s'ok...I'm beginning to accept it
<whee>
match things with [] is basically saying "if things is of the form [], do this"
<whee>
think of it as the form, not the thing
<whee>
just like (3, 2) is of the form (3, x), where x is anything
<comatoast>
gotcha...
Yuri\ is now known as Yurik
jao has quit [Read error: 113 (No route to host)]
engstad has joined #ocaml
<engstad>
Greets.
<comatoast>
heya
<engstad>
I'm trying to simulate a processor. It has vector 32-bit floating point registers, but these can also be read as 32-bit integer register. How do I convert a float to an int32? In C: *(int *)®[N].x
<engstad>
Actually, a regular int31 is fine (I can get the sign from the float).
<whee>
you can use the Int32 module
<whee>
Int32.of_float takes a float and returns an int32
<engstad>
But it converts it..
<whee>
eh?
<engstad>
I need to get the actual bit pattern.
<whee>
oh
<whee>
I'm still an idiot and not following this so hold on :D
<engstad>
Hehe, I'm pretty new to OCaml myself (I know a lot of assembly, Lisp, C, C++ though).
<whee>
I'm just not understanding what you want to do, although I should
<engstad>
Ok. Here's an equivalent question. Given any floating point variable, print out its bit representation.
<whee>
hmf
<whee>
I'm not sure if there's a builtin way to do that
<engstad>
Darned. I'd hoped not to have to interface with C.
<whee>
geh it should be doable
<whee>
I just can't find any info on it
<whee>
heh
<comatoast>
yay, I did it
<comatoast>
how lame, and yet thrilling
<whee>
how many lines is it :)
<comatoast>
foreach? four
<whee>
that's probably right
<comatoast>
let rec foreach things func = match things with [] -> [] (* if there's nothing left, return nothing...*) | a :: b -> func a; foreach b func;; let _ = let stuff = [1; 2; 54; 75;] in foreach stuff print_int;;
<comatoast>
^--including test driver
<whee>
yes that's right
<whee>
heh
<whee>
it's basically the same one that's defined in ocaml itself (list.ml iter)
<comatoast>
I've seen a couple of definitions of a map function, too
<comatoast>
time to actually not move my eyes away...
<comatoast>
list.ml iter?
<comatoast>
howzat work
<comatoast>
?
<whee>
I mean in the source file list.ml of ocaml
<comatoast>
kinda like a standard header, but with the implementation right there?
<whee>
the List module implementation is there and it has a function called iter that does what you just wrote
<comatoast>
the $64,000 question: did I end up making another list, or not?
<comatoast>
...or does it not matter, because the compiler can optimize it to an iterative thing that's easier for the processor to choke down?
<whee>
well yes and no
<whee>
you did end up making smaller and smaller lists to parse, but it doesn't really matter
<whee>
ocaml handles these things well
<engstad>
usually you put the func before the list.
<engstad>
iter f [1;2;3]
<comatoast>
that makes sense
<comatoast>
if I get a chance in between homework, I'll drop back in and bug y'all for a third thing to do in ocaml...
whee has quit [Read error: 104 (Connection reset by peer)]
comatoast has quit ["Whoosh!"]
Yurik has quit [Read error: 113 (No route to host)]
mellum_ has joined #ocaml
mellum has quit [Read error: 110 (Connection timed out)]
JGibson has quit [carter.openprojects.net irc.openprojects.net]
engstad has quit ["using sirc version 2.211+KSIRC/1.1"]
JGibson has joined #ocaml
jao has joined #ocaml
JGibson has quit [carter.openprojects.net irc.openprojects.net]
JGibson has joined #ocaml
jao has quit [Read error: 104 (Connection reset by peer)]
whee has joined #ocaml
JGibson has quit [Read error: 104 (Connection reset by peer)]
whee has quit [Read error: 104 (Connection reset by peer)]
whee has joined #ocaml
JGibson has joined #ocaml
<whee>
geh
<whee>
has anyone worked with threads much?
<JGibson>
nope
<JGibson>
should we start calling you race-condition-whee?
<whee>
okay
<whee>
heh
<whee>
but I'm not using threads in a manner that would cause problems :D
<JGibson>
not using them at all then? ;)
<whee>
not quite
<whee>
heh
<JGibson>
what's the issue? (not that i can really offer any specific help)
<whee>
I'm just having problems getting these threads to run in parallel
<whee>
they always want to block and I have to yield all over the place
<JGibson>
ooh, got a nasty case of sequential threading eh
<JGibson>
it must be the lazy evaluation. none of them want to do the work