Functional - Re: how I find OCaml (was: intelligence is a search for satisfaction)

Author

Re: how I find OCaml (was: intelligence is a search for satisfaction)

Brandon J. Van Every

2004-08-09, 3:57 pm

Peter Ashford wrote:
> <snip>
>
> Sorry to ignore the point of most of your post, but how are you
> finding OCaml? I had a brief look at it recently, but not enough to
> judge it.

Rigorously applying my infamous top-down managerial style, I still haven't
written a line of code in it. :-) I have made plenty of progress with it,
however. Lotsa reading of the manuals and orchestrating tools and
libraries. It should be realized that I didn't just have to swallow OCaml,
I also had to swallow the Functional Programming paradigm. I think I sorta
get it; I won't strongly get it until I'm actually coding. Also I detoured
through SML for a time, but OCaml has got the viable community so I switched
back. For instance it has an OpenGL binding called LablGL which looks
reasonable, although I haven't delved deeply into it yet. In SML/NJ land I
would have had to create the binding using experimental tools. Maybe that
would work; possibly it wouldn't, and probably it would take a lot of time.

I get closer to understanding the performance implications of OCaml and how
to tie it to low level C code. The C FFI is not so great, it's kinda
clunky. Basically one needs to go through this thingy called Bigarray to
get the performance. Bigarray understands simple native C types, unlike the
rest of OCaml. However, you must use them in simple arrays of all ints or
all floats. To process game maps this is still viable, however. The
"flexible stuff" I'll do in OCaml proper, but map crunching probably needs
to be in some kind of low level, high performance C code. I want a map
crunching architecture that's very simple so that I don't have to write a
lot of that C code. I'm still working on the design. Coding happens when I
finally understand how the problem must be solved.

ML Seattle continues to meet on a 3 w

basis. Tentatively we'll be
meeting again on Tuesday, August 17th.
http://groups.yahoo.com/group/mlseattle/

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

Taking risk where others will not.

Siegfried Gonzi

2004-08-10, 8:56 am

"Brandon J. Van Every" wrote:

> I get closer to understanding the performance implications of OCaml and how
> to tie it to low level C code. The C FFI is not so great, it's kinda
> clunky.

Can you elaborate a bit on that. What do you miss from the FFI?

Is the OCaml FFI itself flawed or is it cumbersome to take workarounds?

I have never used the OCaml FFI. I use sometimes Bigloo its one.

What is your subjective feeling of the readability of OCaml code? I gather from
your posts that you eagerly are reading and studying OCaml code. When I was
reading other's OCaml code I always felt that there is something wrong with
their attitude: I mean what is bad concerning giving type annotations. Cleaners
do it all the time. The other day I started to type even my Bigloo code; the
latter tremendously improves managing the code but I have got always the
freedom of Scheme programming if I like.

Do you feel that the code in the OCaml distributuion is worth the reading. If
one believes in the following link then one of the important things when using
alternative languages is their quality of code of the distribution itself.
However, I am not a professional programmer (you know: I am an academic ass in
a physics departement) but I imagine that professional programmers learn from
code which comes with the distribution:

http://groups.google.com/groups?dq=...me%26start%3D25

Fensterbrett

Brandon J. Van Every

2004-08-10, 8:56 am

Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>
>
> Can you elaborate a bit on that. What do you miss from the FFI?

Ocaml does not natively understand 32-bit integers! It only uses 31-bit
integers, keeping 1 bit for garbage collection purposes. Personally I'm not
at all pleased with this language design choice. It's one of the things I
wish I didn't have to explain about OCaml when promoting it.

OCaml, like many other Higher Level Languages, also doesn't support 32-bit
floats. It thinks 64-bit doubles are good enough for anything. This is
annoying and shows that a language isn't mature in the realm of 3D graphics.

These warts can be worked around. There's a module called Bigarray that
will allow you to have unboxed arrays of native 32-bit integer types, or
32-bit floats. The purpose is to make it easier to pass data back and forth
to C or Fortran programs. The problem is you can only have an array of the
simple type. You can't have C structures, which is often what you really
want an array of. These limitations aren't insurmountable to the game
designer, if you're creating your own design. They'd be a XXXXX for
interfacing to someone else's code though.

The OCaml C FFI also gets hairy when you want to pass more than 5
parameters. You end up having to do it in 2 steps! Also you have to do the
OCaml 31-bit type to C 32-bit type translation. That's a PITA. I don't
really want to deal with any of this. So, I'm mainly focusing on how to use
Bigarray to avoid the work.

> What is your subjective feeling of the readability of OCaml code?

I don't have trouble so much with OCaml as with Functional Programming
styles. I'm still not to the point of being able to read other people's
OCaml code and know what's going on. Then again, often I don't know what's
going on with other people's C++ code either!

Or more accurately, I don't wish to know. Whenever someone shows me a code
snippet, my eyes glaze over. I don't like anyone's code, I only like what I
built myself. This is because if I went through the mental steps to build
the code, then I know what it does. Even if I come back to it months later,
my style + my comments makes it quite accessible to me. Of course, I
tolerate other people's code as a matter of industrial necessity. But, I
minimize my interaction with other people's code as much as possible. My
ideal universe would have only my code 97% of the time. I think the real
power of programming is building *your own* semantic system. Using other
people's semantic systems frequently is no more than slavery, i.e. corporate
bumbleXXXX APIs to sell someone's godawful OS.

I think Python code is easy to read. It should be, because that was a core
of its design. Most languages haven't had that as a core design priority.
I'd say readability and ease of use are Python's major contributions to
languagedom.

OCaml is difficult to read, at least at first. To a complete newbie, it's a
tossup between OCaml and C++ as to which is more difficult. I think
advanced guys are going to have an easier time in OCaml though. It's
baroque, but not as bad as C++. For instance it has type inference, so you
don't have to type 'int' all the friggin' time. Also I just don't see the
potential for the "son of a virtual son of a multiply inherited base class
constructor with member function pointer" problems as I did in C++. My
impression is that the organizational paradigms of OCaml are simpler than
that, once you've swallowed Functional Programming.

> I gather from
> your posts that you eagerly are reading and studying OCaml code.

No, I hate studying OCaml *code*. My attention is upon OCaml
*documentation*. Like, how does Bigarray work so I can get around C FFI
problems. And designing my AI algorithms. What components of the language
will allow me to do that more effectively? That's what I'm currently
working on. I don't care about other people's code, they're not solving my
problems.

> When I was
> reading other's OCaml code I always felt that there is something
> wrong with
> their attitude: I mean what is bad concerning giving type
> annotations.

Because most of the time you shouldn't need to type extra words. Compilers
can usually figure this stuff out. Why should we do lotsa extra boring
manual labor for the compiler's benefit? It's a machine, it doesn't get
bored, it should make our coding job easier.

OCaml isn't anal about this issue: type annotations are used when needed.
So I don't see that OCaml has "the wrong attitude" in any way here.

> Cleaners
> do it all the time. The other day I started to type even my Bigloo
> code; the
> latter tremendously improves managing the code but I have got always
> the freedom of Scheme programming if I like.

The ML camp does not believe in freedom of type. They believe in strongly,
rigorously knowing all types. They don't belive in having to type lotsa
extra verbiage about it, they think the compiler should infer the type as
often as possible. I do not yet know how much industrial advantage this
exceedingly strong, anal notion of typing yields. It could yield a lot, but
on the other hand, I've been through what RISC actually yields in industrial
practice. Many claims are often made for things that just don't pan out to
be so relevant or achievable in the real world.

> Do you feel that the code in the OCaml distributuion is worth the
> reading.

Well, in the sense that I looked at the C module of Bigarray to understand
what it does, I guess I'd answer "yes." But I'd answer "no" in general,
because I do not like reading code. :-) I will probably answer "yes"
when/if I want to fix some of OCaml's warts someday.

> If
> one believes in the following link then one of the important things
> when using
> alternative languages is their quality of code of the distribution
> itself.

Bigarray was reasonable. But, it was also pretty trivial. I have no idea
how complicated the core of the language is.

I will say, if you think your first problem is mucking around with the
internals of a language implementation, trying to change it, submitting
those changes to the administrative body, and getting them approved, is how
you should be using your time, then you've got totally screwed up
priorities. First see if you can get something done with the language,
regardless of what it looks like under the hood.

> However, I am not a professional programmer (you know: I am an
> academic ass in
> a physics departement) but I imagine that professional programmers
> learn from code which comes with the distribution:

Some do, others don't. I far prefer to bang things out with people in
newsgroups and mailing lists. Also to read a lot of documentation, so that
I'm not saying completely stupid things on the mailing lists. Eventually I
make enough passes through documentation that I understand what a language
can and can't do. I will say that OCaml documentation is fine.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Siegfried Gonzi

2004-08-10, 8:56 am

"Brandon J. Van Every" wrote:

>
> These warts can be worked around. There's a module called Bigarray that
> will allow you to have unboxed arrays of native 32-bit integer types, or
> 32-bit floats. The purpose is to make it easier to pass data back and forth
> to C or Fortran programs. The problem is you can only have an array of the
> simple type. You can't have C structures, which is often what you really
> want an array of. These limitations aren't insurmountable to the game
> designer, if you're creating your own design. They'd be a XXXXX for
> interfacing to someone else's code though.
>

As far as I can remember that also plagues Bigloo. Some do not consider Bigloo
a legal Scheme programming language out of that reason.

But Tim jr. (the man behind the PHP/Bigloo compiler and the link was given in
my last post) once posted a workaround on the Bigloo mailing list. He used some
external C types. Surely, the situation still remains "wacky" especially for
people who come from another Scheme camp. But one must honestly say, that the
Bigloo manual never hides that shortcomming of 31-bit integers.

I once tried to make a binding between OCaml and the plotting library DISLIN.
But as you wrote, I was a bit irritated by the passing scheme when there were
more than 5 variables in an external C function. I never grasped that scheme;
surely OCaml by nature is much more complex than Bigloo I assume and
communicating with external C code is not that easy.

In the meantime I have completed the binding to DISLIN but for Bigloo.
Integrating C code in Bigloo was easy. The binding now is as comfortable to use
as the one for Python/DISLIN.

>
>
> Because most of the time you shouldn't need to type extra words. Compilers
> can usually figure this stuff out. Why should we do lotsa extra boring
> manual labor for the compiler's benefit? It's a machine, it doesn't get
> bored, it should make our coding job easier.

It is not so much the typing issue itself rather it is something like
"documenting my own code".

I much prefer something like the following:

==
(define (do-this var::double s::bstring saro::vector bul::pair)
)
==

over:

==
(define (do-this var s saro bul)
)
==

The OCaml lacks such an "educational" style. This was in stark contrast to the
Clean manuals.

Out of curiosity: how many people attended your first ML meeting?

Fensterbrett

Vincenzo aka Nick Name

2004-08-10, 3:58 pm

Siegfried Gonzi wrote:

>
> Is the OCaml FFI itself flawed or is it cumbersome to take workarounds?
>

The OCaml FFI requires that you understand well C argument passing, memory
management and memory layout of datastructures, things which you don't need
to know when you use the same libraries from C. There is CamlIDL but it's
not as complete as one might want, mainly binding callbacks is not easy.
Haskell suffers of the same problem, and this is the reason why, even if I
am very productive when I code in OCaml (as I suspect everyone is), I am
constrained to C/C++ or java if I want to be sure that I will be able to
interoperate with other languages.

The problem is even more irritating when you want to write a general purpose
library, and you know that if you write it in C, you will be able to call
it from haskell and ocaml, even if it will be difficult, while if you write
that in OCaml or Haskell you won't be able to call it from respectively
Haskell or OCaml. And there are no serious efforts (where serious means:
paid by someone, since an high-level FFI needs expert people which are
already well-paid for their jobs and won't waste their little free time) to
solve this issue.

When I try to ask about cross-language interoperability solutions for
haskell and ocaml on their mailing lists or here what I get is an
embarassing silence. This might be because I don't know obvious solutions
(in this case please someone tell me) or just because no one is going to
solve the problem, which means that in any serious software project I will
never take the risk of choosing ocaml or haskell, even if they are my
favourite languages, because I will not be able to reuse components written
in these languages if I need to write some part of the software say in
java, or C++, or some .net language.

V.

Marcin 'Qrczak' Kowalczyk

2004-08-10, 3:58 pm

On Tue, 10 Aug 2004 17:01:01 +0000, Vincenzo aka Nick Name wrote:

> The OCaml FFI requires that you understand well C argument passing, memory
> management and memory layout of datastructures, things which you don't need
> to know when you use the same libraries from C. There is CamlIDL but it's
> not as complete as one might want, mainly binding callbacks is not easy.
> Haskell suffers of the same problem,

Haskell has a more convenient FFI than OCaml. In most cases you can avoid
writing a single line of C to access a C library. You need to write manual
wrappers for passing structs by value, and for wrapping function-like macros,
and you can't wrap vararg functions at all due to inherent C limitations.

You don't have to know the layout of C structures nor Haskell objects.
You must know only about the same amount of information as you need to
know anyway to access the library from C, except that you need to know
which functions are in fact macros.

You can wrap Haskell values in opaque C objects. You can allocate raw C
memory from Haskell and put C objects there. You can access C numbers,
enums, strings, structs etc.

You can even convert Haskell function closures to C function pointers
which store the closure inside them, which needs constructing machine code
on the fly, stored in the heap. They should be explicitly freed when no
longer needed.

> The problem is even more irritating when you want to write a general purpose
> library, and you know that if you write it in C, you will be able to call
> it from haskell and ocaml, even if it will be difficult, while if you write
> that in OCaml or Haskell you won't be able to call it from respectively
> Haskell or OCaml.

Indeed.

I'm experimenting with bindings between my pet language Kogut and other
languages.

Python bridge is mostly ready, you can access Python libraries without
wrapping each library separately, and it's quite convenient - values are
converted, wrapped or unwrapped automatically as needed. If someone has
done the trouble of wrapping some C library for Python (e.g. gtk), you can
easily access the library from Kogut. I haven't thought about building
Python modules though.

Perl bridge is being made; most of it is ready. It can't be as convenient
as the Python bridge because of fundamental language differences. For
example you can't reliably find out whether a Perl scalar was meant to be
interpreted as a string or as a number. Another problem is that everything
in Perl is mutable, so automatic conversion of objects from Perl to
another language would lose object identity when it might be important.
So data is not automatically converted from Perl.

I will see what can be done with Haskell and OCaml later. They are a
harder case because they are statically typed, so there must be some glue
code written in them for each library separately.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

Brandon J. Van Every

2004-08-10, 9:01 pm

Vincenzo aka Nick Name wrote:
>
> When I try to ask about cross-language interoperability solutions for
> haskell and ocaml on their mailing lists or here what I get is an
> embarassing silence.

Jeff Henrikson has made a stab at the problem with his Forklift project.
http://www.jhenrikson.org/forklift/ I'm in regular contact with him here in
Seattle. He's still interested in the problem, but as you said he's only
one guy. Maybe you could pool resources with him. I'm somewhat interested
in the problem myself, but still far from having the OCaml skills needed to
pull such a thing off.

Designing in terms of Bigarray is more practical for me at the moment. I'm
hoping to create a layer of syntactic sugar that would allow for C
structures composed of uniformly sized and typed elements, and treated as
structures from OCaml. For instance, all 32-bit ints for some low level
game map primitive, or all 32-bit floats for 3D graphics vertices.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie

Vincenzo aka Nick Name

2004-08-10, 9:01 pm

Brandon J. Van Every wrote:

> I'm_in_regular_contact_with_him_here_in
> Seattle. __He's_still_interested_in_the_problem,_
but_as_you_said_he's_only
> one guy. __Maybe_you_could_pool_resources_with_hi
m

As I said, the main problem is that no one is being paid for this, while
there are infinitely many paid research projects on high level languages,
and infinitely many researchers that worked on interoperability at least
when microsoft was desigining .net. I code 8 hours per day, and by night
guess what... I code for my own free software project. Even if I were paid
to work on forklift I wouldn't do such a good job because you need a real
expert in programming languages semantics to design a similar thing.

It's crazy and I am not sure how to justify this :) My project is in C++
(and sometimes segfaults) for the exact reasons I mentioned earlier.

I am pretty sure that, if I will become a computer science researcher again
after the short and wonderful parenthesis of my master thesis I will do
everything in my possibilities to work on cross-language interoperability.
But I don't expect a single man, in his free time, to be able to do this
thing, not better than .net at least. My hope is that with .net evolution,
generics and so on, someone will manage to create a true backend for
haskell, ocaml and other functional languages, where "true" means that you
can pass an ocaml function where C# expects a delegate and the converse.

Bye

Vincenzo

Vincenzo aka Nick Name

2004-08-10, 9:01 pm

Marcin 'Qrczak' Kowalczyk wrote:

>
> I'm experimenting with bindings between my pet language Kogut and other
> languages.

But what is this language designed for? Have you got documentation?

bye

Vincenzo

Siegfried Gonzi

2004-08-11, 4:00 am

Vincenzo aka Nick Name wrote:

> I am pretty sure that, if I will become a computer science researcher again
> after the short and wonderful parenthesis of my master thesis I will do
> everything in my possibilities to work on cross-language interoperability.
> But I don't expect a single man, in his free time, to be able to do this
> thing, not better than .net at least. My hope is that with .net evolution,
> generics and so on, someone will manage to create a true backend for
> haskell, ocaml and other functional languages, where "true" means that you
> can pass an ocaml function where C# expects a delegate and the converse.

Wouldn't such a project be a good topic for your PhD? You shouldn't stop after
you Master thesis.

I am not convinced that a paid software engineer will be better at doing and
accomplishing what you describe. Surely a PhD position is poorly paid. I
have a paid PhD position in physics but I can survive and it is better than to
have to apply for a loan and paying it back after the PhD term.

A lot of good things exclusively first happen in the computer science
departements.

Fensterbrett

Marcin 'Qrczak' Kowalczyk

2004-08-11, 9:05 am

On Tue, 10 Aug 2004 22:14:39 +0000, Vincenzo aka Nick Name wrote:

>
> But what is this language designed for?

To program in the dynamically typed functional style, without sexpr-based
syntax. There are only a few existing languages with this paradigm (Dylan,
Erlang).

More specifically, I want to experiment with language and environment
introperability, such that a program in my language can use existing
libraries written for other languages. Wrapped foreign objects are
integrated quite seamlessly, and thanks to generic functions they offer
the same interfaces as native objects. I'm quite happy with the Python
integration.

Besides that, it's for me to practice implementing compilers and for fun.

> Have you got documentation?

It's started but not finished yet.
http://kokogut.sourceforge.net/kogut.html

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

Vincenzo aka Nick Name

2004-08-11, 3:59 pm

Siegfried Gonzi wrote:

>
> Wouldn't such a project be a good topic for your PhD? You shouldn't stop
> after you Master thesis.

Of course it would, but you have to see what your supervisor wants you to
do :) I still don't know if I will be admitted to PhD, exams are in
november, but I am working at the moment and just discovered that I am
better paid to write foreach than to prove theorems.

>
> I am not convinced that a paid software engineer will be better at doing
> and accomplishing what you describe.___

Yes, I meant "a paid research group" :)

> paid._I have a paid PhD position in physics but I can survive and it is
> better than to have to apply for a loan and paying it back after the PhD
> term.
>
> A lot of good things exclusively first happen in the computer science
> departements.

I still believe in computer science research but am unsure of how much of
this research, that could be applied if projects were not closed every 3
years, will ever be used for some purpose when it's buried a dead project's
archive. Or patented by microsoft, of course :)

V.

Brandon J. Van Every

2004-08-12, 3:59 am

Siegfried Gonzi wrote:
>
> I am not convinced that a paid software engineer will be better at
> doing and accomplishing what you describe. Surely a PhD position is
> poorly paid. I have a paid PhD position in physics but I can survive
> and it is better than to have to apply for a loan and paying it back
> after the PhD term.

Currently I register voters at $8/hour to support myself. Starving artists
all over the world do what they gotta do to fulfil their visions. All the
money in computers makes people soft, or "golden handcuffed." But if you
end up on the wrong side of a dot.com bust, your perspective can change as
to what's the most important thing to pursue. Most important to me right
now is advancing my OCaml 3D graphics and AI projects. I will admit, I
think the investments will pay off with millions of dollars someday. Just
not now. I wouldn't do this if I thought I was going to be poor forever at
it. It's too much work; I would just paint.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

When no one else sells courage, supply and demand take hold.

Basile Starynkevitch [news]

2004-08-21, 4:01 pm

[En-tête "Followup-To:" positionné à comp.lang.functional.]
Le 10-08-2004, Brandon J. Van Every <try_vanevery_at_mycompanyname@yahoo.com> a écrit_:
> Siegfried Gonzi wrote:
>
> Ocaml does not natively understand 32-bit integers! It only uses 31-bit
> integers, keeping 1 bit for garbage collection purposes. Personally I'm not
> at all pleased with this language design choice.

This is not exactly accurate. Ocaml does provide the Int32 (and also
Int64 & NativeInt) module, which gives *boxed* 32 bits integers (boxed
means that you pass a pointer to a box containing the 32 integer).

Of course, you pay for the 32nd bit thru the boxing. The 31bit
integers are unboxed (because they are tagged).

So the choice between 31 and 32 bits integers is (as usual) a
price/performance tradeoff.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Sponsored Links