<pattern_>
but the argument is academic, unless you have access to said esoteric hardeware
<emu>
it would be nice if vendors would adopt the lessons of the past
<emu>
god forbid we might see decent operating systems
<pattern_>
unfortunately, operating systems seem pretty entrenched right now
<whee>
it'd be nice, but it's not going to happen
<emu>
i don't expect things to change fast
<systems>
netbsd looks promising
<emu>
but I'm not gonna just sit there and say forget abnout it either
<jameson>
It would certainly be preferrable to see an OS kernel, liniker, loader etc. being written in a solid, pure, statically typechecked language. The problem is that existing tools and programs (written mostly in C and C++, for historical reasons) would suffer badly from this.
<jameson>
And if EMACS, bash and ssh (and xterm and whatever other programs people use these days) start running at half speed, that's a practical problem.
<emu>
you can probably throw out a great deal of existing tools =)
<emu>
but yes, the effort would be still tremendous
<jameson>
Of course, spinning this further, a good compiler or cross-language translator could fix that... but it takes more than one Ph.D. thesis to get that done ;-)
<emu>
and supporting general purpose hardware is difficult
<emu>
interestingly enough, Genera was ported off the lisp machines, to alpha... (another dying arch :()
<emu>
so it is still being used
<emu>
but mostly legacy now
systems has quit ["Client Exiting"]
<phubuh>
hrm, I don't think this is possible in the pattern side
<phubuh>
why aren't strings just char list =(
<jameson>
Has anyone here ever used 'Clean'? It sounds rather interesting... can't get it to run here, though :-/
<whee>
that'd be a bit slower
<whee>
phubuh: you could go and use a list in your pattern matching
<whee>
convert the string to a list, apply the pattern, convert to substrings
<whee>
but that'd be rather slow
Riastradh has joined #ocaml
<whee>
oh, duh
<whee>
phubuh: use regular expressions or something :)
<phubuh>
how would I do that?
<whee>
say you want to match "pie" with "pi" ^ x
<whee>
use a regexp like "pi(.*)" (which you derived from "pi" ^ x), and then return a list of what matched
<whee>
then uh, hrmf :)
<whee>
oh, okay
<whee>
basically you'd want to compare what matched against the pattern and verify it fits
<jameson>
BTW, is there a regex package for ocaml that does negated character classes?
<whee>
so the pattern would get you ["pi"; (something here)], and the regexp would return ["pi", "e"]
<whee>
probably would use the 'a option type and assume None is equal to anything when comparing these two lists, or something. I don't know :\
<whee>
jameson: you can use pcre
<mrvn>
A kernel in ocaml would have a big problem with the Garbage Collertor.
<karryall>
"I'm a bit annoyed with the fact the OCaml is in fact so good the it steals ground from Ruby."
<karryall>
arf
<pattern_>
"The slightly disappointing side of this is, from a Ruby perspective, is that OCaml seems to be strong also in those areas where Ruby were supposed to be uniquely strong"
<karryall>
:)
<pattern_>
but it's not all praise for ocaml... there's some criticism also
<pattern_>
"I can positively say that for certain types of applications OCaml is 5 to 10 times faster to implement than C++ (for an experienced C++ developer and inexperienced OCaml developer) because I did prototype in OCaml and subsequently implemented in C++."
mellum has quit [Read error: 60 (Operation timed out)]
<mrvn>
What realy sucks in C++ are all those segfaults and memory leaks you get sometimes.
<pattern_>
well, c++ isn't the only language guilty of that
<pattern_>
and you can use a garbage collection library with c++
<pattern_>
of course, you could just use ocaml :)
<mrvn>
pattern_: you could but not realy. Too much work to tag and box all types to make it realy work.
karryall has quit ["bye"]
<mrvn>
Is there a way to tell the GC that I have a big chunk of memory here where it should move all objects to and only allocate from there?
phubuh has quit [Remote closed the connection]
<mrvn>
Or a call that dumps the current memory and stops the programm in a way that it resumes when its started again?
<pattern_>
sure
<pattern_>
it's possible
<pattern_>
i don't know of any gc that does it, though
<pattern_>
and i don't even know c++
<pattern_>
but it's possible in c... should be possible in c++
<mrvn>
I meant for ocaml.
<pattern_>
oh
<mrvn>
In C++ you just overload operator new.
<pattern_>
i have even less clue about ocaml
<pattern_>
as you well know :)
<mrvn>
If you want to learn some more ocam you culd join the Programming for Fun Contest
<pattern_>
before i join any contest i think i have to finish learning the syntax
<pattern_>
but i'd love to, once i have half a clue
<pattern_>
i haven't even started writing a meager test program, because i don't know enough to make it do anything useful
<pattern_>
i think i'd like to start by parsing through a file and creating a multi-field data structure
<pattern_>
but i'm not even there yet
systems has joined #ocaml
<pattern_>
there's no way i'd be able to compete in a contest... unless it's against people who are also completely incompetent :)
<pattern_>
maybe in a couple of weeks, though... if i manage to keep up my concentration on ocaml
<pattern_>
of course, i could just compete using a language i already know... but i think i'd rather use the time to learn ocaml
mellum has joined #ocaml
mellum is now known as anyone
anyone is now known as mellum
pedroxxx has joined #ocaml
systems has quit [Read error: 60 (Operation timed out)]
mattam has quit [Read error: 54 (Connection reset by peer)]
TachYon has joined #ocaml
AJC has joined #ocaml
<AJC>
hello... i'm a C++ user (ducks the tomatoes) and wondering what benefit ocaml would be to me. any tips?
<mellum>
No crashes. More fun to code.
<AJC>
crashes == bad programming
<mellum>
No manual memory management.
<AJC>
i'm confortable enough with C++, and have a MMGR class
<mellum>
A what?
<AJC>
"fun" in what way?
<AJC>
memory manager
<mellum>
If you try it, you'll understand :)
<AJC>
heh, how well does it integrate with existing code (any language?)
<mellum>
AJC: And it's impossible with that class to free memory twice or have a memory leak?
<mellum>
AJC: It integrates quite well with C.
<AJC>
mellum: no, that just optimises the hell out of the memory allocation... smart pointers take care of the leaks and "freeing twice"
<mellum>
AJC: well, actually, they can't. They cannot detect cyclic memory structures.
<mellum>
And they waste memory and make allocation slower.
<AJC>
that's where good design comes in...
<mellum>
AJC: Well, that's exactly the point of "fun". I don't think it's fun to have to bother with such issues.
<AJC>
hehe, allocation slower than "very fast"
<AJC>
yes, true
<AJC>
the donkey work
<mellum>
It's much more fun to design clever algorithms.
<AJC>
but you only have to do than once
<AJC>
so if i had an existing class with a lot of good code (C++), could i wrap that in ocaml and do all the high-level stuff with it?
<mellum>
Hm, you would probably have to write a C wrapper around it first. Or use some tool like SWIG.
<AJC>
hmmm... bummer
<AJC>
are there any plans to support this?
<mellum>
Not sure. Maybe SWIG already does it.
<AJC>
heh, any other reasons why C++ is evil? (more so than ocaml)
<mellum>
Lots of undefined behavior which leads to impossible to trace bugs.
<mellum>
No closures.
<AJC>
"undefined behaviour" but if you're coding low-level, it's your fault
<mellum>
AJC: So that never happened to you?
<mellum>
Never ever stepped over an array bound?
<AJC>
i've always managed to find bugs so far
<AJC>
assert( i < max );
<mellum>
AJC: then you probably have only written small programs
<gl>
we speak about the languages, not programmers
<AJC>
mellum: heh, good coding practice
<gl>
C++ allows you to do UBs
<gl>
that's the point
<AJC>
i guess you don't have to worry about practice as much in ocaml
<AJC>
UB?
<gl>
undefineds behavioues
<mellum>
AJC: It will still happen. I know what I'm talking abouyt, I have written lots of C++.
<gl>
-e+r
<AJC>
well, if you want strong semantics, use ADA
<AJC>
it'll run if it compiles
<gl>
with ocaml too
<mellum>
While we're at it, the strict type checking in Ocaml prevents more bugs
<AJC>
is there much additional complexity to defining such strictness?
<AJC>
s/to/in
<mellum>
Especially if you compare it to, say, scheme, where pretty much every bug only occurs at runtime
<gl>
what kind of complexity ?
<AJC>
in ADA for example (i know it enough to say) you have to define the size of your arrays explicitly
<mellum>
AJC: No, of course not. Stricter type systems make code more efficient, since the compiler can make more assumptions.
<AJC>
everything has to be explicit
<AJC>
mellum: not compiling, writing code
<mellum>
Well, the size of an array is not part of its type in OCaml
<mellum>
(that would be silly, IMHO)
<AJC>
then is ocaml actually compiled?
<mellum>
AJC: yes
<AJC>
static?
<gl>
yes
<mellum>
AJC: huh?
<gl>
static typing, i guess
<mellum>
You can link statically or dynamically, if that is what you mean
<AJC>
well, it's not interpreted, so i can't "add code" at runtime
<AJC>
(like python / perl)
<mellum>
AJC: well, you can probably do something like dlopen. But there's no "eval" or something
<pattern_>
ocaml has an interpreter too
<AJC>
k... so static language
<AJC>
ah... you can embed it in a C app?
<mellum>
Yes, you can also get a prompt where you type code, which then gets evaluated
TachYon has quit [Remote closed the connection]
<AJC>
right, so not fully static ;)
<steele>
what do you mean by static?
<AJC>
source -> binary
<gl>
(i thougth he spoke about static typing, but this is not the case)
<AJC>
can't change the binary at runtime
<mrvn>
AJC: whats binary?
<AJC>
mrvn: you being pedantic?
<pattern_>
executable?
<AJC>
yes
<mrvn>
AJC: You can't change java bytecode at runtime. So java bytecode is binary.
<mrvn>
Same with perl, python, bash
<AJC>
mrvn: heh, python can be interpreted
<Smerdyakov>
AJC, regardless of if you have some useful idea of "staticness" in your head, it's not one that is in common use, so you probably shouldn't use it.
<AJC>
you can create new functions within a program
<mrvn>
AJC: And bash scripts even
<mrvn>
AJC: mutability is not a criterium for binary.
<Smerdyakov>
(use the word "static" to mean what you mean, that is)
<mellum>
There's a compiler for sh, BTW :)
mattam has joined #ocaml
<mrvn>
mellum: There is a compiler for makefiles using ocamlp4, ocamlc and gcc
<mrvn>
mellum: Its like 400 lines of code.
<mellum>
It only compiles to C though, which is boring
<Smerdyakov>
AJC, have you ever used a functional language?
<AJC>
haskell
<pattern_>
i'm not sure i follow you still, ajc... you can compile ocaml programs in to executables, as you can c and c++... and, you can run ocaml programs through an interpreter, as you can with perl/python
<AJC>
Smerdyakov: do you call prolog functional?
<Smerdyakov>
No
<Smerdyakov>
It's funny that you talk of "<AJC> you can create new functions within a program"
<mrvn>
AJC: In ocaml you can just do #load "unix.cmo" to load it the unix library at runtime.
<Smerdyakov>
Since you can mix and match functions at runtime with a statically typed language and create all sorts of fun stuff.
<mrvn>
AJC: But then you need dynamic linking compiled in
<mrvn>
AJC: prolog is a logical language.
<AJC>
pattern_: in a C++ executable, you can only perform the computation that was programmed in and compiled. with python & co, you can create code at runtime, and have that merge within the program (dynamic program)
<mrvn>
AJC: Not true.
<AJC>
?
<mrvn>
AJC: C/C++ has dlopen
<AJC>
heh, little difference
<AJC>
that DLL is statically compiled too
<Smerdyakov>
AJC, did you understand what I just said to you?
<AJC>
so unless you have your compiler and linker within your C++ program, you can't mrvn
<mrvn>
AJC: Why? You write a small programm that downloads a *.so from the internet and dlopens that.
<AJC>
Smerdyakov: trying to follow multiple conversations
<mrvn>
Works just as well as downloading a java applet or a python class.
<mellum>
AJC: That's just a difference in easiness, no fundamental difference
<Smerdyakov>
AJC, OK. You might want to understand mine now, since it has to do with questioning why you are engaged in the others. =)
<mrvn>
Only difference is that you need to save the object to a file first for dlopen.
<mrvn>
But that libdl's shortcoming.
<AJC>
mrvn: you need an interpreter, it's a big difference
<AJC>
Smerdyakov: despite mixing and matching, it's still static
<mrvn>
AJC: An interpreteris just an emulator for a different cpu, broadly speaking.
<mrvn>
AJC: I need an interpreter if I want to run i386 code on my alpha too.
<AJC>
mrvn: yes, but it allows you to go from source to execution dynamically
<AJC>
compilers don't, and that's a bottlneck of static code
<mrvn>
AJC: For every langugae you can think of I'm sure there is an interpreter and a compiler for it somewhere.
<mrvn>
AJC: Interpreter and compiler are theoretically the same thing.
<Smerdyakov>
AJC, the challenge to you is to explain what you mean by "static" that has negative consequences.
<AJC>
mrvn: probably, but the functionallity to use it is not always as convenient from language to language. C++ sucks at it, python is great, perl ok...
<mrvn>
AJC: Whatever you say without giving strict definition can be turned against you.
<Smerdyakov>
I can make up a new word, "blimbaz," and define it so that it only applies to C++.
<AJC>
heh, by fair enough
<Smerdyakov>
So what? That doesn't make it a useful characertization.
<Smerdyakov>
I think your "static" is on the same footing so far.
<mrvn>
AJC: As you said above about your Memory Manager: You only write it once. Same for dynamic code loading :)
<AJC>
the code itself is on disk
<AJC>
compiled
<AJC>
doens't change at runtime
<mrvn>
AJC: Whats compiled?
<mrvn>
bash scripts don't (and can't) change at runtime.
<AJC>
a native format for a computer... fukin' hell
<Smerdyakov>
AJC, can you explain to me why closures being dynamically created at runtime is fundamentally different from whatever "eval" you want?
<AJC>
Smerdyakov: eval?
<mrvn>
AJC: java is compiled but still not native code for a computer (yet).
<mrvn>
AJC: but could be
<AJC>
mrvn: there's only so many pedantic comments i can take in a day
<Smerdyakov>
AJC, replace "eval" with whatever feature you want
emu_ is now known as emu
<AJC>
Smerdyakov: eval would allow a program to change itself at runtime
<mrvn>
AJC: What you probably mean is that in C++ you can't just type in some more c++ code into the running programm and it executes it.
<mrvn>
In bash or scheme you can do that.
<Smerdyakov>
AJC, can you define what that means rigorously so that creating closures doesn't fit in it?
<mrvn>
(via eval)
<AJC>
creating closures? you mean new functions?
<AJC>
yeah, eval is fine
<pattern_>
let me take a stab at what ajc may be getting at... let's say that a user types: "int c = 1;"... an "eval" using an interpreted language like perl/python could execute this statement provided by the user at runtime... ajc is concerned that this is not possible in ocaml
<pattern_>
is that right, ajc?
<mrvn>
AJC: Ocam doesn't have an eval natively but its easies to implement one.
<AJC>
pattern_: part of my point, yes
<Smerdyakov>
AJC, I mean closure. Code along with values for free variables in it. That's what a first class function is in OCaml, Haskell, Lisp, whatever.
<emu>
you don't need an interpreter to implement eval
<AJC>
emu: a compiler and loader then
<AJC>
some dynamic capabilities
<emu>
there are several compiler-only Lisp implementations
<emu>
however
<mrvn>
AJC: You can implement eval in any language but some have it natively. ocaml doesn't.
<emu>
I wouldn't call eval exactly a straightforward way of programming
<Smerdyakov>
This is going in circles now.
pedroxxx has quit ["|®NinJa 4.5®| --> Feito para você. Disponível em www.ninjascript.com.br"]
<Smerdyakov>
AJC, explain one _concrete_ thing you want to do (on the level of a whole project), and explain why what you know of OCaml makes you doubt its suitability.
<mrvn>
AJC: So ocaml would fall into the c/c++ corner and not python/bash corner
<AJC>
i have a function (with a few parameters) which returns a nice hard-coded behaviour...
<AJC>
(functional programming)
<AJC>
i want to execute that with the same language, at runtime
<pattern_>
smerdyakov, i think the eval point that ajc is making is more academical than practical
<AJC>
mrvn: in that it requires a few hacks to get working
<steele>
for bytecode, ocaml has eval
<pattern_>
i don't see that much use for eval
<AJC>
pattern_: no, quite practical
<emu>
eval has uses, it's just not what people think
<steele>
in the Toploop module, but you can't use it in native code
<emu>
and there's a tendency to overuse it by newbies
<mrvn>
steele: it has?
<pattern_>
ajc, how so? i think smerdyakov is very interested in a practical example of what you would use eval for
<AJC>
pattern_: say i want to do some genetic programming
<AJC>
pattern_: i've just told him
<mrvn>
pattern_: Write a function plotter, i.e. a programm where the user inputs a function and you plot it.
<Smerdyakov>
AJC, did you give an example of a concrete concern yet?
<AJC>
Smerdyakov: yes ;)
<Smerdyakov>
AJC, no
<Smerdyakov>
AJC, you talked about a language feature, not a software development goal.
<mrvn>
steele: wow. didn't know that.
<mellum>
mrvn: come on, that was obvious ;)
<AJC>
Smerdyakov: i have a function (with a few parameters) which returns a nice hard-coded behaviour (obstacle avoidance, wall following) in terms of sensors...
<AJC>
Smerdyakov: i want to execute that with the same language, at runtime, so i can get my bot to avoid or follow walls
<pattern_>
mrvn, point well taken :)
<Smerdyakov>
AJC, you mean you want to "change the function" over time?
<AJC>
yes, learning in some way
<mrvn>
mellum: a function plotter was my first need for an eval.
<mrvn>
seteel: Where is Toploop described in the ocaml docs?
<Smerdyakov>
AJC, and... you don't realize that this is generally done by modifying data structures used by a common algorithm?
<AJC>
Smerdyakov: AI is and will be pushing programming langages to their limit, I want to know these limits
<AJC>
Smerdyakov: not in genetic programming... it's often easier to eval
<steele>
it seems there isn't anything about it in the manual
<steele>
the mli files are in toplevel/
<AJC>
Smerdyakov: you're doing redundant work that the compiler interpreter is already doing
<mrvn>
Probably some internal hack and thats why its interpreter only.
<Smerdyakov>
AJC, yet you will not use the full expressive power of the language
<AJC>
Smerdyakov: this is an adaptive / dynamic program
<Smerdyakov>
AJC, you'd be better off creating a set of functional combinators and building new functions from those, if that's the only way you're able to think.
<AJC>
Smerdyakov: but ocaml cannot do it?
<AJC>
Smerdyakov: it's not a way of thinking, it's a way of implementing existing AI techniques
<Smerdyakov>
If OCaml "cannot do it," I see that as an advantage that forces you to think about _exactly_ what you want before you start.
<mrvn>
AJC: If you allow all dynamic programming the gene will most likely mutato into crashing your programm (in C++). In ocaml its much easier to build a block of combinators and dynamically builöd new functions out of those without the risk of crashes.
<Smerdyakov>
It's quite simple to create functional combinators that will accomplish whatever goal you have.
<AJC>
mrvn: but i'd have to code an eval myself?
<Smerdyakov>
No
<mrvn>
s/mutato/mutate/
<Smerdyakov>
Functional combinators give you functions equal to all others
<Smerdyakov>
You just call them like usual.
<mrvn>
AJC: No, the combinators eval themself.
<AJC>
Smerdyakov: functional combinators? custom data structures?
<pattern_>
smerdyakov and ajc, i've evolved novel genetic programming functions by way of combining function primatives... no eval was necessary
<Smerdyakov>
No.
<mrvn>
AJC: You just pass them as arguments to each other.
<Smerdyakov>
Functions that take functions as arguments and return new functions.
<AJC>
there we go
<Smerdyakov>
I am truly getting the feeling that AJC has never seriously used a functional language if we need to explain this much.
<Smerdyakov>
pattern_, why do you address that to me? =)
<pattern_>
smerdyakov, because you said: <Smerdyakov> AJC, you'd be better off creating a set of functional combinators and building new functions from those, if that's the only way you're able to think.
<AJC>
Smerdyakov: no, i've played with haskell but not voluntarily ;)
<mrvn>
AJC: You can build a primitive that adds X and one that multiplies by Y and give eigther one as argumentto another combinator.
systems has joined #ocaml
<pattern_>
ajc, and mrvn has an excellent point about crashing programs as a result of allowing arbitrary instructions to get executed... it's much more efficient for genetic programs to always be runnable
<AJC>
Smerdyakov: "combinators" can do anything, but you need to code them that way?
<Smerdyakov>
AJC, yes
<Smerdyakov>
AJC, the point is that you don't _want_ to do anything
<mrvn>
The combinator could then output a multiply or an exponentiation depending on its input without any change in the code being executed.
<Smerdyakov>
AJC, you only want a small set of possible code structures
<AJC>
Smerdyakov: i want to test anything that will run
<emu>
pattern_: it's generally possible to prevent problems from that though
<mrvn>
AJC: you never can
<AJC>
Smerdyakov: but i wouldn't have to code simple function combinators if i had some form of eval, right?
<emu>
pattern_: also, if you evaluate a structured data representation, it is easier to simply not construct bad programs in the first place
<mrvn>
AJC: But you can prove that anything that runs will do what its suposed to.
<emu>
AJC: why would you want to use eval instead of some simple function combinators?
<pattern_>
emu, it's not the problems (as in safety of your data, crashing main executable worries).. but efficiency: you don't want to waste time on evaluating incorrect programs... because evolutionary algorithms do billions of program evaluations... it's very inefficient if you allow any of those programs to be invalid
<AJC>
mrvn: with "function combinators", and not eval...
<Smerdyakov>
AJC, that's true. You wouldn't have to write a Java virtual machine if you wanted applets to erase your hard drive, also.
<mrvn>
AJC: you can't prove eval since it can do anything.
<mrvn>
AJC: Thats why you should prefer combinators anyway.
<emu>
pattern_: heh, and among those billions, many will be invalid even if oyu don't use eval =)
<AJC>
emu: because i have to write the "simple" function combinators, and this would already be done for the language
<emu>
inefficiency is another reason not to use eval
<pattern_>
ajc, you'll find that you will want higher primitives beyond the simple primitives a language provides... so you'll wind up writing them anyway
<emu>
AJC: so you're basically saying that you need the full expressivity of the language, every time
<mrvn>
AJC: How many combinator do you need? Those would usually be your genes.
<emu>
pattern_: well; a real language would let you extend those primitives =)
<mrvn>
AJC: And you would needsomething similar as building blocks for eval.
<AJC>
mrvn: i guess that's the issue.. few simple ones at first, more later
<pattern_>
ajc, 90% of your useful code with genetic programming will be more complex than simple addition, say... and the few basic, language-level primitives you'll allow you can code in no time... though i guess eval would save you that bit
<AJC>
emu: if i want fully adaptive software, yes
<mrvn>
AJC: You would hardcode some small combinators and then encode complexer ones in the genes as combinations of them.
<AJC>
so would the combinators be less intuitive to code than normal ocaml?
<pattern_>
emu, true, many programs evolved by gp will be useless, even if you don't use eval... but you cut down significantly if you use safe, working primitives instead of allowing arbitrary code evals
<AJC>
(i guess there is overhead in declaring the combinator as a function)
<pattern_>
and that's "significantly", as it a ton of time
<mellum>
Eventually, your programs will evolve to show pr0n movies, since that will ensure they run most often
<AJC>
lol
<mrvn>
AJC: everything is a function in ocaml.
<emu>
pattern_: depends what you want to do
<AJC>
one other thing. can i load and execute an ocaml source file at runtime with another ocaml program? i can't without eval right?
<mrvn>
AJC: or rather there are only values. No functions, no variables.
<emu>
pattern_: if your evolved programs aren't going to be doing very much, sure. if they are going to be doing everything that a normal program could, then implementing that could take a long time.
<mrvn>
AJC: you can. ocaml does it itself
<pattern_>
emu, extending those primitives is possible by combining them with simple genetic programming... unfortunately, that eats up a ton of time too... so really, you wind up writing your own high-level primitives rather than evolving them
<Smerdyakov>
AJC, you had best learn functional programming before proceeding further.
<emu>
pattern_: it's possible to generate programs in such a way that they are valid
<AJC>
Smerdyakov: thanks oh wise one ;)
<Smerdyakov>
AJC, it sounds like you don't really have a grasp of what higher order functions are and how to use them.
<AJC>
mrvn: i can? how come?
<Smerdyakov>
"oh wise one".... the problem is that you are now grilling us like you are looking for details of arcane features of OCaml, when in fact the things we suggest are the main features behind all functional languages
<AJC>
Smerdyakov: if i did have a problem with that in general, i probably wouldn't have come here, right?
<mrvn>
AJC: because ocaml can dynamically load code.
<Smerdyakov>
I don't know. You've said the only functional language you "know," you were forced to learn.
<Smerdyakov>
So I don't think it would be too unexpected if you didn't really try to understand it.
<AJC>
mrvn: so why did i need eval? i could have saved code to file, and loaded it?
<mrvn>
AJC: You can't load source and to save code you would need to generate it.
<AJC>
Smerdyakov: i have a degree in this, and the only thing i can't follow is multiple opinions and overlapping conversations
<mrvn>
AJC: Unless your running in the interpreter which can load source too.
<AJC>
mrvn: right. we've got somewhere
<pattern_>
emu, yo udon't want to evolve programs that can do _everyting_ that a normal program can... you'll naturally want to limit your primitives to your problem domain, which will greatly restrict what your program can do using those primitives alone... however, combination of primitives in to novel functions will still be very fruitful
<AJC>
mrvn: the interpreter can, but i cannot within a compiled program (as with C++), but i cannot within an interpreted program
<emu>
pattern_: and I'm saying ``what if your problem domain does require the full language?''
<mrvn>
emu: Then your screwed
<emu>
to the point where you would end up reimplementing a great deal of it
<Smerdyakov>
AJC, you have a degree in functional programming?
<emu>
mrvn: I wouldn't say so
<AJC>
Smerdyakov: no, both CS and AI
<mrvn>
AJC: You would have to link in the eval module from the interpreter. But you would interprete the source and not run it natievly.
* Riastradh
wakes up to find a delightful argument going on.
<AJC>
mrvn: right, thanks
<Smerdyakov>
AJC, that doesn't mean you've ever learned the ways of functional programming.
<Smerdyakov>
AJC, if you learned it all from a class you didn't want to take, then that's great. =)
<mrvn>
AJC: If you want to run source in code form you allways need to translate (compile) it into it some way or another.
<AJC>
Smerdyakov: well i have... and the GP stuff is only an example. it's your vocabulary that is different (learning doesn't teach you that)
<gl>
what does "CS" mean ?
<AJC>
mrvn: so i would put ocaml in the same category as C++
<emu>
gl: counterstrike, duh
<gl>
:)
<mrvn>
AJC: Thats what I said before.
<emu>
no I wouldn't put ocaml in the C++ category
<emu>
c++ is just evil
<AJC>
yes, i agreed then too... and confirmed
<emu>
ocaml seems to have some merit to it
<mrvn>
AJC: But in any other aspect those are 2 completly different worlds.
<pattern_>
emu, i have to agree with mrvn here... if you need the full expressiveness of a full-featured computer language as primitives in evolutionary computation you are screwed... because at current state of hardware you will never create anything useful that is not extremely basic
<AJC>
heh. enough emu
<AJC>
mrvn: of course
<emu>
pattern_: I wouldn't tell someone not to try
<pattern_>
emu, i would
<emu>
lack of imagination :-P
<mrvn>
Just try to evolve a ocaml programm that replicates itself.
<pattern_>
emu, koza recommends just the basic mathematical operators and a few other basic functions as primitives
<mrvn>
Or design one and try for it not to mutate into non replicating anymore.
<emu>
I really don't see why we are saying "you are screwed"
<emu>
people have done what AJC does for many years
<pattern_>
emu, at most people use hundreds of primitives (many of them of higher complexity than most language features).. and that's for large scale genetic programming
<emu>
whether or not it's a good idea in all situations is orthogonal
<mrvn>
emu: You are screwed not because it can't be done. Doing it is trivial. Your screwed because you won#t get anything usefull out of it anytime soon.
<emu>
pattern_: see, I don't see language features as being disjoitn from programmer-created features
<AJC>
emu: it was a practical example, not my life long goal or anything
<pattern_>
emu, a compiler is technically not disjoined from language features.. however, you are never going to evolve a compiler... thus, if you need a compiler (substitute other complex function here) you generally don't want to start evolving one (at least not to be used as a primitive... to be the end result of your evolution, maybe.. but again, you'll still be evolving relatively simple things)
<pattern_>
hell, evolving code that contains even basic loops or recursive functions can eat up infinate ammounts of time
* emu
is still trying to puzzle out what you said
<emu>
pattern_: that can be dealt with
<pattern_>
so you have to bound your loops and recursion depth
<pattern_>
and that limits you severely as to the data you can process
<pattern_>
so there go two incredibly useful features right off the bat
<pattern_>
and that's not even anything complex
<emu>
if you have turing-complete language, even a mini-one for your combinators, you cannot avoid the halting problem
<emu>
er, genetic programs
<pattern_>
yes, of course
<pattern_>
but it's not just about halting
<Smerdyakov>
But I don't think anyone does that, so why bother discussing it? =)
<mrvn>
I think that programming languages are just not made out for genetic programming. Its usually one step after another and each depends on the one before. In real life genetics I guess thats not the case.
<emu>
if you don't have one, then you have to accept some loss
<pattern_>
it's about how deep in a loop/recursion do you want your programs to look?
<emu>
it's just a matter of what you ened
<pattern_>
you will find you are _severely_ limited in depth due to the sheer numbers of programs you'll be evaluating
<pattern_>
the vast majority of the loops/recursions you will be evalutating will be completely worthless
<pattern_>
so you have to limit them, or get rid of them completely (prefereably the latter, gaining an incredible speed increase)
<emu>
but if you don't allow loops, then what?
<pattern_>
you can do it
<pattern_>
you just have to be realistic as to what you can expect to evolve
<emu>
you're basically saying "you have to limit waht you can expect to be evolved"
<pattern_>
that's why it's often better to write functions yourself that use a loop you know is useful
<emu>
which is fine
<pattern_>
so you wind up writing higher level primitives
<emu>
but not everyone may want to accept that
<mrvn>
Do you know what a "busy beaver" is?
<emu>
damn
<pattern_>
you don't have to accept the limits of evolutionary computation, but they're there
<Smerdyakov>
Not everyone wants to try genetic programming.... :P
<pattern_>
unless you have infinate hardware capacity, those limits are going to hit you like a brick wall if you try to allow arbitrary computation
<emu>
my uses of eval have not tended towards the genetic programming area
<AJC>
Smerdyakov: you got up on the wrong side of bed...
<pattern_>
smerdyakov, they're fools! ;)
<Smerdyakov>
emu said everyone!! :P
<emu>
I said not everyone
<AJC>
pattern_: the fundamental flaw with GP is the bottom up nature... there is no higher-level design, so the search space is huge
<emu>
get your quantifiers right :-P
<Smerdyakov>
That contains "everyone"!
<emu>
hahaha
<emu>
flaw.. bottom-up!
<emu>
lol
<emu>
I do believe that's one of the reasons to use GP =)
<pattern_>
ajc, not true.. you can add arbitrary high level domain knowledge to gp
<emu>
top-down is not necessarily wonderful
<AJC>
pattern_: example?
<pattern_>
however, it's often found that gp can be more creative with low level primitives
<pattern_>
it's a matter of getting a balance between high level and low level primitives, seasoned with some domain knowledge
<AJC>
emu: "flaw" with regards to it's limitations and scalability issues
<pattern_>
then you might have a successful gp
<emu>
you should build up further primitives from what is available
<emu>
until you can talk about your problem in your programming language
<AJC>
pattern_: give me an example of high-level "primitives" in GP?
<AJC>
pattern_: and while you're at it, "domain knowledge"...
<pattern_>
ajc, for example... i have a good deal of experience creating (unsuccessful) market timing gp's... i can incorporate various technical indicators as high level primitives... evolving those primitives would take forever.. but once i write them myself (not a hard task) they are useful in gp
<AJC>
arent' the technical indicators low-level?
<pattern_>
they're not as low level as: "+" "-" etc
<pattern_>
they're higher level than sin, cos, etc
<AJC>
still made bottom up from those
<pattern_>
they're actually relatively high level primitives
<pattern_>
yes, they're bottom up from there
<pattern_>
but it's up to you how low/high that bottom is
<AJC>
it's not: "you need a function to do this, and one to do this"
<pattern_>
also, you can influence search space traversal in many other ways
<Smerdyakov>
pattern_, "market timing"? Do you do economics research?
<pattern_>
no, i'm just stupid
<pattern_>
really... it's a stupid pursuit
<AJC>
pattern_: with domain specific knowledge? GP only takes a fitness functon with a scalar reward... all you have to work with is the crossover / mutation
<Smerdyakov>
Hm, I think I agree. ;-)
<pattern_>
i'm thinking of doing something more tractable, like detecting breast cancer, or analyzing astronomical data, or drug research via gp
<pattern_>
using gp for market timing is about as hard a problem as you can set for yourself... it's very frustrating
<pattern_>
and anyway, i don't even like finance... it's the gp aspects that i love
<AJC>
hehe, always on the brink of being a milionaire!
<pattern_>
domain specific knowledge (bias) can be used for any aspect of gp
<pattern_>
you bias gp by using certain primitives over others, you bias it via the fitness function (which is a huge source of bias)... and, of course, via the genetic selection and breeding operators
systems has quit [Read error: 110 (Connection timed out)]
<pattern_>
to give some other examples, outside the finance field:
<AJC>
no need
<pattern_>
you can write a primitive that moves the leg of your robot
<AJC>
seen that done before
<pattern_>
that's domain knowledge right there
<AJC>
very low-level knowledge ;)
<pattern_>
what high level knowledge do you require?
<AJC>
for NN topology creation, they use a RET operator to terminate the recursion
<pattern_>
i think you can incorporate arbitrarily high level knowledge in gp
<AJC>
erm, high-level example:
<AJC>
for navigation
<pattern_>
i have a great nn architecture evolution via gp paper for you, ajc
<AJC>
you need a function to avoid obstacles, a way to remember the terrain
<pattern_>
hussain and browse did a very detailed analysis of gurau and generalized and improved on his methods
<AJC>
but back to high-level knowledge, it's like OO concepts... when you have smaller components to implement, it's easier
<pattern_>
gruau is actually quite inconsistent and illogical in much of his scheme for gp nn architecture evolution
<AJC>
#ai ?
<pattern_>
check out the hussain/browse paper i just sent you a link for
<pattern_>
this is what i want to implement in ocaml
<pattern_>
i was going to do it in c, originally
<AJC>
hehe
<pattern_>
yes, we can switch to #ai
<pattern_>
sorry, ocaml folk
TachYon has joined #ocaml
<mrvn>
AJC: The grammar network would be your basic combinators.
<AJC>
mrvn: yes, though this was only an example of problem... there's other stuff where eval would have been nice
<AJC>
but thanks
<mrvn>
No, eval is too uncontrolled. Too much cance of introducing bugs.
<mrvn>
Imagine you have your genes running for a week and then it crasheswith an error in one of the evals. Thats fun.
<AJC>
heh, it's not only GP... crashing / bugs are not as much of an issue
<mrvn>
They cost millions.
<mrvn>
So any not to bothersome way of avoiding or detecting them is worth it.
<mrvn>
Thats where strict typechecking can save your neck.
<AJC>
yes, i see... as i said, it's not an issue for this
<pattern_>
it won't be weeks before your eval crashes but probably less than a second
<pattern_>
the vast majority of code evolved by the gp will simply not be valid
<pattern_>
"let ; = <= ; in" is a simple example
<Smerdyakov>
I like this one better: let
<pattern_>
you can, of course, make sure that the expressions that are generated are valid, at least syntactically
<AJC>
pattern_: yes, i was going to say. you're wasting your time doing that sort of thing
<pattern_>
in c you'd still have problems, because of invalid pointer references and the like
<pattern_>
i guess this wouldn't be a problem with ocaml
<pattern_>
something else you'd have to do is make sure variables that are referenced later in the program really exist
<pattern_>
and probably a host of other problems
<Smerdyakov>
*chuckle*
<AJC>
GP is strongly based on syntax anyway (tree) so you might as well use it
<Smerdyakov>
It's not actually terribly difficult, pattern_.
<Smerdyakov>
But I still don't see any utility in it.
<pattern_>
and that's beside the point that you're going to be wasing an enormous ammount of resources searching vast fruitless areas because you have too many low level primitives
<Smerdyakov>
AJC, so then.... why was it you wanted "eval"?
<AJC>
the only thing that really mattered was being able to load and run source files
<AJC>
(user created)
<pattern_>
i found a few relevant posts on the ocaml list, in regards to this
<AJC>
GP was another practical example, as you asked
<Smerdyakov>
Hm, I guess you'll make me say "evaluate/compile the full language" each time instead of just "eval", eh?
<pattern_>
that was just searching for "eval"... there may be more threads on this issue under different keywords
<AJC>
heh, nice find!
<pattern_>
i don't know if those are the "final word" on the matter, either
<smkl>
it's possible to do "eval" like stuff in bytecode, but not in native code because ocaml doesn't support dlls
<AJC>
heh, nothing as complex... just eval source code please ;)
<smkl>
in my post i show how to 'implement' eval in the toplevel. binding values does not work in real code, though
<pattern_>
the toplevel is the interpreter... and that's equivalent to python, since it's interpreted... no?
<smkl>
toplevel is bytecode compiler and interpreter
<pattern_>
ajc, this seems to provide equivalence to python, perl, etc, as far the eval goes, does it not? since smkl is saying you can do eval with ocaml on the interpreter level
<pattern_>
actually, i have to run... i'll bbl... if there's anything more on this, could someone log it for me? i'm interested to see where this leads.. thanks
<AJC>
so it seems... though data binding is an issue
pattern_ has quit ["..."]
mrvn_ has joined #ocaml
<mrvn_>
smkl: You can use the libdl for compiled code.
<smkl>
doesn't libdl only work for shared objects? or is there an ocaml version now?
<mrvn_>
shared objects
<smkl>
standard ocaml doesn't generate pic, so i don't think that will work
<mrvn_>
isn't there an ocaml -> C compiler (translator)?
<smkl>
perhaps. but i haven't heard of that
<mrvn_>
You can allways load in c libs.
<mrvn_>
Like dynamically load libgif if present and wanted.
<mrvn_>
That way you don't have to pay for the gif patent because your program has no gif code in it.
mrvn has quit [Read error: 60 (Operation timed out)]
<mrvn_>
Another method would be to compile all modules to reside at differend addresses or to use threads and IPC.
<mrvn_>
Not sure if ocaml can do the first but the later isn't hard to do.
<Smerdyakov>
Recompiling each time works fine if you have incremental recompilation.
<mrvn_>
I'm thinking of implementing a type save Marschal module. With that you would have static runtime type information to the extend the compiler has during compile.
<smkl>
do you mean like: pre-compiled application library, configuration files, initialization module ?
<Smerdyakov>
smkl, to whom do you address that?
<smkl>
you
<Smerdyakov>
I mean, when you want to "eval" some code, add it to your project and recompile the program.
<mrvn_>
Or just run bytecode. Still fast enough usually.
<smkl>
Smerdyakov: yes, "configuration files" is supposed to be that
<smkl>
evalled part
systems has joined #ocaml
<mrvn_>
smkl: Do you know whats all in a cmi file?
<smkl>
probably it's just the types and the names marshalled
<smkl>
and some dependency stuff
<mrvn_>
From the Dynlink module: The digests can be extracted from .cmi files using the extract_crc program installed in the Objective Caml standard library directory.
<mrvn_>
% /usr/lib/ocaml/3.06/extract_crc gui.cmi
<mrvn_>
Error while reading the interface for gui.cmi
<mrvn_>
Ill formed .cmi file
<mrvn_>
let crc_unit_list = [
systems has left #ocaml []
asqui has joined #ocaml
docelic has quit ["brb"]
docelic has joined #ocaml
docelic has quit [Client Quit]
docelic has joined #ocaml
<smkl>
use: /usr/lib/ocaml/3.06/extract_crc gui ... extract_crc should have better error messages
docelic has left #ocaml []
<mrvn_>
Ah, that works.
<mrvn_>
Bad, that only gives me one checksum for the file. I was hoping to get a cecksum on every type and function.
asqui has quit ["Now I am gone..."]
asqui has joined #ocaml
skylan has quit [Read error: 104 (Connection reset by peer)]
skylan has joined #ocaml
TachYon has quit ["Client Exiting"]
coolduck has joined #ocaml
coolduck has quit ["Client Exiting"]
coolduck has joined #ocaml
pattern has joined #ocaml
lament has joined #ocaml
TachYon has joined #ocaml
docelic has joined #ocaml
sproctor has joined #ocaml
<sproctor>
hello
<Riastradh>
Hi.
<sproctor>
in the client-server section of the ocaml book, there's a reference to a domain_of function.
<sproctor>
I haven't been able to find anything else about this. have any ideas?
<whee>
I suppose you could write that, it doesnt seem to e provided
<whee>
all it would do is, given a sockaddr, would return the corresponding socket_domain
<sproctor>
that's what I was thinking. would be cool if the example were complete though.
<whee>
it'd be a quick two-three liner using either fun or match
<whee>
let domain_of = function
<whee>
Unix.ADDR_UNIX _ -> Unix.PF_UNIX
<whee>
| Unix.ADDR_INET (_, _) -> Unix.PF_INET
<whee>
I believe that's what you would want
merriam has left #ocaml []
<sproctor>
thank you.
<Smerdyakov>
Any UK'ers here?
* Riastradh
is often thought to live in the UK.
<Smerdyakov>
Riastradh, is that "yes"? =)
<Riastradh>
No, I actually live somewhere in the north eastern U.S.
<sproctor>
why do people think you live in the UK?
<Riastradh>
I'm too English.
<mellum>
Riastradh: Too few spelling errors?
<Riastradh>
Not only that but I also spell things 'Britishly,' and if that isn't a word it ought to be one.
<Smerdyakov>
I have to find some Brits!
<Riastradh>
What are you looking for specifically?
<sproctor>
I have to find the reason I'm an idiot...
<Riastradh>
sproctor - You're human, that's why.
<Smerdyakov>
Verifying that the Computer Science A level is insultingly easy and should be avoided by competent people
<Riastradh>
It's too easy.
<Riastradh>
Is that good?
<Smerdyakov>
I'm trying to convince a younger acquaintance not to waste his time taking the classes for them.
<Smerdyakov>
But I'm not British, so for all I know it could be very fulfilling =)
<Riastradh>
What does this class consist of?
<Smerdyakov>
I don't know.
<Riastradh>
Then why are you trying to ocnvince a younger acquaintence (hrm, ought there be an 'a' or an 'e' there?) not to waste his time with it?
<Riastradh>
To practise arguing?
<Smerdyakov>
Because they're taught in high school
<Smerdyakov>
Or the British equivalent
<Smerdyakov>
In a school without special entrance exams
<Riastradh>
...and...?
<Smerdyakov>
So my prior experience suggests they're worthless =)
<Riastradh>
Well, then tell him to read SICP.
<Riastradh>
If the course is less advanced than SICP it's worthless; if it's more advanced than SICP it's too advanced.
<Smerdyakov>
I'd be bowled over were it not less advanced.
<Riastradh>
Well, maybe if it's more advanced it's not too advanced.
<Riastradh>
Structure and Interpretation of Computer Programs.
<Riastradh>
It's the textbook used at the introductory computer science course at MIT.
<sproctor>
thanks.
<Smerdyakov>
Phsaw. MIT. :P
<Riastradh>
It's an incredibly good computer science textbook.
<Smerdyakov>
Too bad it uses Scheme =)
<Riastradh>
ML has too complicated a syntax.
<Riastradh>
For an introductory computer science course, it's much better to use a language with a very simple syntax; then the semantics can be concentrated on much more.
* emu
agrees with Riastradh
* sproctor
does as well.
<emu>
though I don't care for scheme presonally
<emu>
personally too
<Smerdyakov>
Riastradh, I'd go for Haskell myself
<Riastradh>
Still, it's got a much more complicated syntax than Scheme.
<emu>
haskell is no better in the syntax dept
<Smerdyakov>
Not more complicated than the syntax first year students learn for math, anyway
<emu>
but it's in ASCII, which is butt ugly
<emu>
=)
<emu>
I can barely stand mathematical syntax as it is
<mrvn_>
scheme is very unintuitive to the beginner and the simplicity of the syntax or the lack of it doesn't realy help I think.
<mrvn_>
Also the missing infix operators are hard for some people
<sproctor>
I think it helps people think in new ways without having to memorize a bunch of stuff.
<whee>
I hope it wouldn't be hard for an MIT student :P
<mrvn_>
Its very easy to learn scheme but to grasph the concecpt of functional programming with it and find bugs is very hard.
<mrvn_>
I mean all you have to learn is to balance ( and )
<mrvn_>
Then define, lambda and if and your all set
<sproctor>
how does that make understanding functional programming hard?
<mrvn_>
It doesn't make it easier by introducing structure
TachYon has quit [Remote closed the connection]
<mrvn_>
Everything in scheme is new, nothing common knowledge
<sproctor>
things may be new, but there's so few new things in the syntax, it shouldn't be hard to internalize them.
<mrvn_>
I hope everyone understand 1+1, but how many students will be puzzeled by (+ 1 1)
<sproctor>
don't you need to be able to understand (+ 1 1) to get functional programming?
<mrvn_>
A beginer might not know infix, prefix, postfix notation.
<mrvn_>
sproctor: you need for scheme
<sproctor>
I know even in my programming class in highschool, we did postfix processing.
<mrvn_>
Those little things throw people off track
<mrvn_>
sproctor: Your lucky you had a programming class.
<async>
why you can't have multiple let declarations in a function?
<mrvn_>
async: let foo x = let a = 1 in let b = 2 in .... ?
<async>
well i want local scopes
<async>
er
<async>
dont want local scopes
<mrvn_>
thats local
<sproctor>
async: why not?
<mrvn_>
let foo x = let rec a = b and b = a in, something like that?
<mrvn_>
or let foo x = bar x and bar x = foo x?
<mrvn_>
+rec
<async>
hmm i forgout about the and..
<async>
i was doing: let foo = let a = 10; let b = 20;;
<mrvn_>
Do you start off with functional programming in the first semester in us?
foxster has quit [Connection timed out]
<sproctor>
mrvn_: I didn't. the freshman this year are (in college).
<mrvn_>
Here too. On monday they have the first math session and tuesday they learn scheme. Two big shokers in the first two days.
<sproctor>
they're doing scheme, java, java as the 3 introductory classes. when I was a freshman they were all c++
<mrvn_>
I don't think thats the best think to start of with.
<sproctor>
what would you start with?
<mrvn_>
Dunno. Its all somewhat bad to start with.
<sproctor>
I started in the third class. a lot of people didn't understand very basic things of c++ even then.
<mrvn_>
If you start with C some people will be way ahead. C++, Java and Pascal need a lot of structure first, so thats bad too.
<sproctor>
I like scheme because there's very little to teach before you can start using it, and you get to concept earlier, rather than syntax and structure.
<sproctor>
I've only had one class in scheme, and we didn't spend any time on the language, only on concepts.
<mrvn_>
I would love some ocaml variant where you get good hints as to what you did wrong if it doesn't compile.
<mrvn_>
Also a lot less () there.
<sproctor>
oh yeah, I like ocaml a lot better, but I think for learning scheme is a better choice.
<mrvn_>
I heard a lecture on systems to aid pupils in learning how to programm using scheme.
<mrvn_>
The start of with a limited version that doesn't allow higher level functions and such.
<mrvn_>
You start of with simple ints as arguments and simple recursion. Later than they allo simple higher level functions and so on.-
<emu>
scheme doesn't use prefix notation
<emu>
and why do people have so much trouble with parenthesis?
<mrvn_>
Someone doing the first exercises for a course certainly doesn't want to mess with higher level functions so better ctach them early.
<Riastradh>
If people have so much trouble with parentheses, why don't they have trouble with curly braces in C?
<mrvn_>
emu: so whats (+ 1 1) then?
<emu>
mrvn_: a function call
<emu>
actually, a list =)
<mrvn_>
Riastradh: ever seen a halfway complex scheme programm _without_ at least 10 closing ) in a row?
<emu>
though scheme doesn't really take advantage of that fact
<emu>
mrvn_: who CARES
<Riastradh>
mrvn - Ever seen a halfway complex C program _without_ a bunch of closing curly braces in a row?
<emu>
mrvn_: that's a consequence of nested structure
AJC has quit [Read error: 54 (Connection reset by peer)]
<mrvn_>
Riastradh: 10 } in a row a very uncommon
<emu>
mrvn_: use a fucking code editor for crying out loud
<Riastradh>
Ever seen a halfway complex Objective-C message _without_ a bunch of closing square brackets in a row?
<mrvn_>
never seen a Objective-C programm
<Riastradh>
It's essentially C + Smalltalk.
<mrvn_>
emu: Those guys show up with notepad.
<emu>
one of the reasons why C doesn't stack up so many }'s generally is because C programmesr don't generally program in a functional style
<emu>
if you start programming functionally in C, it piles up
<emu>
nesting nesting nesting
<Riastradh>
Message passes in Objective-C are surrounded with square brackets.
<emu>
now, I know that some people have difficulty with nesting
<emu>
but that's something to overcome, not cater to
<mrvn_>
but who would do that? If you programm a functional style why go through all the pain of C?
<emu>
argh!!
<emu>
I did not say "programs in a strictly functional sense"
<sproctor>
this rules... I've never heard an argument between different functional languages before. ;)
<emu>
but even simple things like nesting function calls instead of using local vars