I'm interested in learning OCaml.
Phoenix Magus
anything FREE on the internet costs more in time than it would in money), I
have a question.
Are there any kinds of programs that OCaml is NOT suited for?
Thanks In Advance
Bryce Byrd
Henning Makholm
> Are there any kinds of programs that OCaml is NOT suited for?
Yes, of course. No language is suited for everything. (For example,
I wouldn't dream of using any ML dialect for writing process-switching
code for an OS, or a garbage collector, or little automation tasks
for which shell scripts are adequate, or programs whose main task
is to provide a command-line interface to a system call).
--
Henning Makholm "You are in a little twisting
maze of passages, all different"
Matthias Blume
>
> Scripsit "Phoenix Magus" <phoe...@akrobiz.com>
>
> > Are there any kinds of programs that OCaml is NOT suited for?
>
> Yes, of course. No language is suited for everything. (For example,
> I wouldn't dream of using any ML dialect for writing process-switching
> code for an OS, or a garbage collector, or little automation tasks
> for which shell scripts are adequate, or programs whose main task
> is to provide a command-line interface to a system call).
While I agree that (probably) no language is good for everything, I
actually disagree with every single one of the above examples. Of course,
existing implementations might not be up to these tasks, but that's a
whole different story.
Matthias
PS: Every time I have to hack shell scripts, I wish they would be somehow
statically typed. In fact, run-once shell scripts are the one that would
most benefit from static typing because for run-once tasks you don't want
to go through the thorough testing cycle that dynamically typed programs
usually need in order to weed out all (most) of those stupid brainos that a
static checker finds right away (and before anything can go seriously wrong).
If the script messes with files, a dumb mistake can cost you a lot of precious
data...
(For command-line use, OTOH, the ML syntax might, indeed, be a bit on the
heavy side.)
PPS: Sorry about letting the PS get longer than the regular message body. :)
Ken Friis Larsen
Henning> (For example, I wouldn't dream of using any ML dialect for
Henning> writing process-switching code for an OS,
I know that you write that *you* wouldn't dream of using ML for this
task. Can you explain why? The only reason I can come up with is the
lack suitable ML implementation. I my memory serves me correct was
SML found to be a suitable language for implementing large parts
of an OS:
http://www.cs.utah.edu/flux/papers/oskit-sosp97.html#SECTION00061000000000000000
http://www.ai.mit.edu/projects/express/
Henning> or a garbage collector,
Again, why? For speed reasons?
--Ken
Julian Assange
> Before I go through the trouble of trying to get it (for it seems like
> anything FREE on the internet costs more in time than it would in money), I
> have a question.
>
> Are there any kinds of programs that OCaml is NOT suited for?
Device drivers, hard real-time code.
--
Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood or assign them tasks and
pr...@iq.org |work, but rather teach them to long for the endless
pr...@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
Phoenix Magus
is much left above me. To get a better answer I should be more direct.
Please forgive any ignorance I show, but one only learns by asking
questions. I have had ideas of programs that I would like try to make for
myself, however I do not know what language would be best suited for them.
I do know I want all three to be Object Oriented.
One would be a MUD (Multi-User Dungeon). From what I hear C++ would be good
for that but I wonder if OCaml (or another language with parametric
polymorphism) would in any way be beneficial.
Two would be a simple game 2D graphics 640x480 @ 256 colors, much like
Gauntlet. (Run around, swing your sword, kill monsters, take the loot)
However I would like to have advanced features like scriptable AI, possibly
even having players script groups of units into coordinated battles vs other
players. Again the question arises, is there anything in OCaml I'd find
useful for that, or should I stick to C++.
Three would be an electronic assistant of sorts. One part of it's duties
would be used to create, modify, delete, fill, and empty tables and objects
with a command-line like interface and with no recompiling or anything like
that needed. I remember I was able to do such a thing with a program at
school when we were learning Oracle. In addition I'd like to be able to
make "functions" or "scripts" to produce specific reports (queries I should
say) which use advanced mathmatics, this too I would like to be able to do
without recompiling. One quirk I should mention is it should be able to
resolve dice rolls in the formulas and from commands prompt. I.E. if I type
"2d6 + 1d4" it should recognize that I want to roll 2 six sided dice and sum
their results, then roll a four sided die, then add the results together.
Also, as far as I can tell, speed is not an issue.
If you can give me any advice, I would greatly appreciate it!
Thanks in Advance
Bryce Byrd
Henning Makholm
> Henning> (For example, I wouldn't dream of using any ML dialect for
> Henning> writing process-switching code for an OS,
> I know that you write that *you* wouldn't dream of using ML for this
> task. Can you explain why?
Because it necessarily involves instructions (or instruction
sequences) that no respectable compiler for any high-level
language would ever emit.
> Henning> or a garbage collector,
> Again, why? For speed reasons?
No, because in the situations where you *can* run ML code at all,
there'll already be a garbage-collector (or something more or less
functionally equivalent, regions or whatnot) present. So why would
you want to write one in ML, if you've already got one?
--
Henning Makholm "It's kind of scary. Win a revolution and
a bunch of lawyers pop out of the woodwork."
Henning Makholm
> One would be a MUD (Multi-User Dungeon). From what I hear C++ would be good
> for that but I wonder if OCaml (or another language with parametric
> polymorphism) would in any way be beneficial.
You will have lots of high-level gameplay rules to write here. Any
programming that does not force you to clutter your code with explicit
memory management (such as C++ does) will be a win. The alternative
would probably be Java, but high-level decision making is usually
easier to read and write in ML-style languages.
Alternatively, you might want to implement your own tailor-made
language for specifying the gameplay decisions. The ML family of
languages is exellently suited for implementing such a special-purpose
language.
> Two would be a simple game 2D graphics 640x480 @ 256 colors, much like
> Gauntlet. (Run around, swing your sword, kill monsters, take the loot)
> However I would like to have advanced features like scriptable AI, possibly
> even having players script groups of units into coordinated battles vs other
> players.
Again, implementation of script languages is one of the areas where an
ML language is really nice. You *don't* want to do that in C++, but
you may want to do some of the graphics with suitably interfaced C
functions. Start by doing most of it in ML, though, and then profile
to find out if performance absolutely requires you to redo it as C.
> Three would be an electronic assistant of sorts.
...
> In addition I'd like to be able to make "functions" or "scripts" to
> produce specific reports (queries I should say) which use advanced
> mathmatics, this too I would like to be able to do without
> recompiling.
Yet another variation of the same theme of symbolic computation. Go
for ML here, too.
--
Henning Makholm "I Gudfaders navn og snnens og den hellige
nds! Bevar os for djvelens vrk og for Muhammeds, den
forbandedes, underfundigheder! Med dig str det vrre til end
med nogen anden, thi at lytte til Muhammed er det vrste af alt."
Benjamin Ylvisaker
> > Henning> or a garbage collector,
>
> > Again, why? For speed reasons?
>
> No, because in the situations where you *can* run ML code at all,
> there'll already be a garbage-collector (or something more or less
> functionally equivalent, regions or whatnot) present. So why would
> you want to write one in ML, if you've already got one?
I have absolutely no experience writing garbage collectors, but let me
re-write your post replacing garbage collector with compiler and see
what we get:
> No, because in the situations where you *can* run ML code at all,
> there'll already be a compiler (or something more or less
> functionally equivalent, interpreter or whatnot) present. So why
> would you want to write one in ML, if you've already got one?
Sort of makes sense, right? If you already have an ML compiler, why
write one in ML? Except most ML compilers are written in ML and in
general I would guess that a large percentage of production level
compilers are written in the language that they are compiling. So your
argument that you wouldn't want to write X in language Y because
something like X is needed to get started with language Y goes out the
window. Let me reiterate that I have no experience with writing garbage
collectors, so there may be other good reasons why one would not want to
write a garbage collector in ML.
Benjamin
Mark Wotton
>> No, because in the situations where you *can* run ML code at all,
>> there'll already be a compiler (or something more or less
>> functionally equivalent, interpreter or whatnot) present. So why
>> would you want to write one in ML, if you've already got one?
>
>Sort of makes sense, right? If you already have an ML compiler, why
>write one in ML? Except most ML compilers are written in ML and in
>general I would guess that a large percentage of production level
>compilers are written in the language that they are compiling. So your
>argument that you wouldn't want to write X in language Y because
>something like X is needed to get started with language Y goes out the
>window.
But you don't need the compiler to be present to run the code. I think the
point he was making was that by writing a garbage collector in ML, you're
putting yourself in the position that you either have 2 GC in the program,
or you adapt whatever version of ML you're running to use the new garbage
collector you're writing...
mrak
Daniel C. Wang
mwo...@hons.cs.usyd.edu.au (Mark Wotton) writes:
{stuff deleted}
> But you don't need the compiler to be present to run the code. I think the
> point he was making was that by writing a garbage collector in ML, you're
> putting yourself in the position that you either have 2 GC in the program,
> or you adapt whatever version of ML you're running to use the new garbage
> collector you're writing...
I'll be remiss if I don't toot my own horn.
http://www.cs.princeton.edu/~danwang/Papers/tpsrvgc/
You can write a garbage collector for ML like languages using a first-order
ML like language that includes supports for regions. Thought it's not
explained as clearly as it should be in the paper. There are in fact two
GCs as you suggested, but the most primitive GC is very trivial it does not
have to scan the objects it is collecting for pointers. It's basically a
walk down a linked list which sets some mark bits.
Also the VLISP folk, built an entire runtime system for Scheme in Pre-Scheme
(which is basically ML with Scheme syntax) they do this so they can prove
correctness. Also, larger chunks of the SRC Modula-3 runtime system which
includes a garbage collector are written in Modula-3.
The Java Jalapeno JVM from IBM research has several different GCs written in
Java also. (http://www.research.ibm.com/jalapeno/publication.html#oopsla99_jvm)
So there are at least four GC's I know about that are written in relatively
high-level languages other than C. The VLISP collector and my work are
theoretical attempts aimed mainly at guaranteeing correctness/safety. They
are not designed to be used in realistic production systems. The Modula-3
GC has been in use for quite a while. The Jalapeno GC is quite impressive
too and seems to make the researchers at IBM who are building
high-performance server apps quite happy.
Anyway, it can be done in theory and has been done in practice.
Victor B. Putz
>for that but I wonder if OCaml (or another language with parametric
>polymorphism) would in any way be beneficial.
After several years of experience with C++ and games development, I admit to
being at a loss as to what C++ would in fact be *good* at compared to almost any
other language out there. Not to get into a language war, but unless tools
forced me, I would not use C++ for a MUD (or anything else).
You seem to be focusing on games, which frankly is a particularly nasty area and
generally requires a lot of state management (and lends itself to OOP). Of the
functional languages I've seen, OCaml is the best choice in terms of
speed/power. Eiffel would be an interesting OOP alternative (check out the
SmallEiffel compiler).
>Two would be a simple game 2D graphics 640x480 @ 256 colors, much like
>Gauntlet. (Run around, swing your sword, kill monsters, take the loot)
For 2-d graphics under OCaml, check out the beginnings of OCamlSDL
(ocamlsdl.sourceforge.net) which is a good start.
>However I would like to have advanced features like scriptable AI, possibly
>even having players script groups of units into coordinated battles vs other
>players. Again the question arises, is there anything in OCaml I'd find
>useful for that, or should I stick to C++.
Again: stay away from C++ if you can. It is evil. You will get significantly
better gains by coding in a higher-level language (OCaml, Eiffel, whatever) and
writing any necessary routines/wrappers in ANSI C.
As for writing and interpreting a scripting language under OCaml, others have
posted that it must be possible and easier under OCaml than other languages.
Given that it seems like the most frequent application of functional languages
is that of compilers for functional languages, I'm prepared to believe them
(heh). Of course, I have not done this myself, so I'm not sure how well it
works. It could be a lot of fun to have a lightweight scriptable language
(scheme comes to mind) running under an OCaml interpreter...
One disadvantage with OCaml right now is that it *seems* not to be particularly
portable: you have Windows and Linux and that's about it. Not important?
Depends on your application. I'm looking into commercial game development using
functional (or other) languages and consoles are becoming the dominant outlet...
right now SmallEiffel is winning over OCaml just because its compiler outputs
ANSI C (I was able to create a SmallEiffel runtime for the PalmOS relatively
easy by modifying the output C code and using a cross-compiler. I have no idea
how to go about that with OCaml!).
I'm incredibly interested in the application of OCaml to scriptable game
engines; I think it has a lot of potential. Unfortunately, I'm at something of
a loss as to how to go about it. If the OCaml dynamic loader supported
unloading of modules and execution of bytecode from optimized native code, you
could have a lot of fun writing plug-ins with OCaml itself, which would be
excellent... but I'm not sure we're there yet.
At least one noncommercial game has in fact been written with OCaml for MIT's
graphics course: check out the "Spaceman Spiff" entry at
http://graphics.stanford.edu/courses/cs248-videogame-competition/cs248-00/
Not bad considering it was a 3d OpenGL world using only 166k of source code. By
comparison, my C++ platform game (2d 8-bit graphics!) is currently up to 250k of
game code (.cpp and .h files) -- and that's *not* including the 643k of cpp
files and 398k of .h files for the supporting library (which admittedly does a
lot that Spiff doesn't do, like flexible menuing, customizable input device
paths, etc).
On the whole, I wish I'd used something besides C++. I have since basically
abandoned that project (which is too bad--it was looking pretty good toward the
end. But no one cares about 8-bit palettized graphics and 2-d platform games in
this day and age).
-->VPutz
Ji-Yong D. Chung
Victor B. Putz wrote in message <9lc0gn$im5$1...@cantaloupe.srv.cs.cmu.edu>...
>>One would be a MUD (Multi-User Dungeon). From what I hear C++ would be
good
>>for that but I wonder if OCaml (or another language with parametric
>>polymorphism) would in any way be beneficial.
>
>After several years of experience with C++ and games development, I admit
to
>being at a loss as to what C++ would in fact be *good* at compared to
almost any
>other language out there. Not to get into a language war, but unless tools
>forced me, I would not use C++ for a MUD (or anything else).
I am not interested in language wars, but I am
interested, if others don't mind, why you think so
(from the perspective of someone who has
used high level language such as Scheme/
ML.
If your reply is not fit for this newsgroup, I'd appreciate
it if you would still post it in another group. Of course,
I don't think posting it to comp.lang.C++
would be a good idea :-)
Daniel Andor
> One disadvantage with OCaml right now is that it *seems* not to be
> particularly
> portable: you have Windows and Linux and that's about it. Not important?
When you say it's not particulary portable, is that instrinsic to ocaml, or
simply that ports for other platforms aren't planned?
> Depends on your application. I'm looking into commercial game development
I'm interested in scientific applications, so alpha support would be
helpful. Also, are there any floating point performance comparisons between
languages?
Daniel.
Damien Doligez
>One disadvantage with OCaml right now is that it *seems* not to be
>particularly portable: you have Windows and Linux and that's about it.
That's not true. You also have many flavors of Unix, including
Mac OS X, and also some (limited) support for Mac OS 9.
--
Damien
Victor B. Putz
>>forced me, I would not use C++ for a MUD (or anything else).
> I am not interested in language wars, but I am
>interested, if others don't mind, why you think so
>(from the perspective of someone who has
>used high level language such as Scheme/
>ML.
Goodness... there are so many things. Where to start?
My basic feeling is that C++ tries to do a lot of things and doesn't do any of
them particularly well. There are so many tricks and traps to C++ that it's
difficult to be proficient without knowing a lot of idiomatic stuff. And there
are so many traps...
Is C++ better at systems-level bitslapping stuff? No better than C, certainly.
And C style and linkage being something of the "lingua franca" of systems
programming, why not use C instead of C++ for the really low-level routines?
Games programming in general *does* do a lot of bit-twiddling, but C can handle
that as well as C++, and most higher-level languages support calling C
functions.
Ah, say the knowledgeable ones. But C++ is "object-oriented", which is good for
large-scale program development. However, C++ has real problems with its OOP.
Ian Joyner wrote a great paper on this (and expanded it into a book) comparing
C++ to Java and Eiffel; C++ lost on all counts. If I was going to do an OO
design and implementation, I would use Eiffel for the main body and drop to
straight C for low-level implementation details (this is what I am doing with
PalmOS programming right now, and it is a great combination). However, neither
one handles stateless programming well, and neither has higher-order functions
(although Eiffel has something like them in the works... not perfect, but
something). Games lend themselves to OO designs, so a good implementation of OO
is a boon.
C++ does not inherently have good memory management--you have to do all
allocation/deallocation manually. It didn't take much time with
garbage-collected languages for me to see that GC is FAR superior for at least
90% of applications programming, and games in particular use a lot of
allocation/deallocation.
C++ does not have higher-order functions, which means that you spend a lot of
time rewriting pieces of code you should be able to combine. For example, in a
series of programs for the PSP, I wrote list classes which could calculate their
mean, standard deviation, etc. In each calculation, I had to manually iterate
over the lists of numbers, either with numerical indices or iterator objects.
When I tried rewriting a few of these algorithms using Haskell, OCaml, Emacs
lisp, and Scheme, I could get the same effect with fold-right or map, and just a
few lines of code. The difference is significant.
C++ does not lend itself to dynamic programming. While this can certainly be
done, it cannot be done as easily as, say, Scheme. There's a reason that Lisp
got a name for itself as a tool for AI development... in game terms, being able
to load up a game world and have each object own its own set of behavior
routines would be a huge benefit and allow you to add a great deal of
flexibility after the main executable has been released.
I guess after using C++ for several years and then discovering languages like
Eiffel, OCaml, and Scheme/Lisp (yes, an eclectic education, or lack of same), I
just see no reason to use C++ *except* for the industry support it has. And I
also admit that "industry support" can be pretty compelling.
> If your reply is not fit for this newsgroup, I'd appreciate
>it if you would still post it in another group. Of course,
>I don't think posting it to comp.lang.C++
>would be a good idea :-)
Heh... last time I posted something to comp.lang.c++ it was my one-person study
of how the SmallEiffel compiler beat gcc on a series of small programs (in terms
of lower error rates during development, faster compile times, smaller code
sizes, and faster execution times). Took a month to stop getting flames in my
mailbox.
[Daniel Andor writes:]
>When you say it's not particulary portable, is that instrinsic to ocaml, or
>simply that ports for other platforms aren't planned?
Not intrinsic to OCaml at all. In fact, the OCaml compiler *has* been ported to
other platforms (for example, there was a Caml light port in work for PalmOS at
one point).
The disadvantage is simply this: to write OCaml code which executes on another
platform, you have to implement either a bytecode interpreter or a native
compiler back-end, and that would probably be a lot of work. A compiler which
outputs ANSI C instead of native code probably generates less efficient code,
but you can then use a C compiler as the backend, which seems to be easier. I
haven't looked too closely at MLTon, which does at least some of this
(outputting ANSI C).
>I'm interested in scientific applications, so alpha support would be
>helpful. Also, are there any floating point performance comparisons between
>languages?
Sir, I do not know. You may be interested in Doug Bagley's computer language
shootout at http://www.bagley.org/~doug/shootout/ -- I know it has at least some
FP-intensive benchmarks.
-->VPutz
Victor B. Putz
>>particularly portable: you have Windows and Linux and that's about it.
>That's not true. You also have many flavors of Unix, including
>Mac OS X, and also some (limited) support for Mac OS 9.
I stand reasonably corrected; the MacOS downloads are quite visible from the
OCaml distribution page, and I should have intuited that the source tree
compiles on Unix if it compiles on Linux. My apologies.
(Original complaint still stands, though-- for commercial game development I'm
not sure it'd be easy to port to PS2, for example, or embedded platforms like
PalmOS).
-->VPutz
Ji-Yong D. Chung
Hi
>> I am not interested in language wars, but I am
>>interested, if others don't mind, why you think so
>>(from the perspective of someone who has
>>used high level language such as Scheme/
>>ML.
>
>Goodness... there are so many things. Where to start?
>
>My basic feeling is that C++ tries to do a lot of things and doesn't do any
of
>them particularly well. There are so many tricks and traps to C++ that
it's
>difficult to be proficient without knowing a lot of idiomatic stuff. And
there
>are so many traps...
I agree with you there on both points -- my
experience has been similar. Funny that I am
still writing my current programs in C++.
>Ah, say the knowledgeable ones. But C++ is "object-oriented", which is
good for
>large-scale program development. However, C++ has real problems with its
OOP.
>Ian Joyner wrote a great paper on this (and expanded it into a book)
comparing
>C++ to Java and Eiffel; C++ lost on all counts.
"Large scale" development -- this is what I don't know about.
I have heard from others that C++ facilitates building barriers
between different project groups (who are all working
on the same project). This allows groups to focus on interfaces, etc.
(you know the slogans).
Now, if I understand you right, you are saying that Java and Eiffel
outdo C++ on those accounts. I can see with respect to Java
(I don't know much about Eiffel). Java IS a better language
(I am not talking about the JVM's performance here).
> If I was going to do an OO
>design and implementation, I would use Eiffel for the main body and drop to
>straight C for low-level implementation details (this is what I am doing
with
>PalmOS programming right now, and it is a great combination). However,
neither
>one handles stateless programming well, and neither has higher-order
functions
>(although Eiffel has something like them in the works... not perfect, but
>something). Games lend themselves to OO designs, so a good implementation
of OO
>is a boon.
Just for curiosity, how would have (1) ML or (2) Scheme
served your purpose (instead of Eiffel)? Would Java have
been better?
>C++ does not have higher-order functions, [snip...]
>C++ does not lend itself to dynamic programming. [snip] ...
You are talking about the lack of support for different
techniques for abstraction and code reuse. I understand
what you mean here.
>I guess after using C++ for several years and then discovering languages
like
>Eiffel, OCaml, and Scheme/Lisp (yes, an eclectic education, or lack of
same), I
>just see no reason to use C++ *except* for the industry support it has.
And I
>also admit that "industry support" can be pretty compelling.
I view of C++ as C with just a few added features but not
as a true OO language. I think C++ is relatively crappy, but
if one already has learned it (by some misfortune), I do think it
is a bit preferable to C (despite slow compilation and
bloated binaries).
I also think if one does not know C and does not plan to learn
C, C++ is _NOT_ something you want to do. Finally, if one does
learn C++, it should be learned in terms of C -- otherwise,
you won't be able to escape various traps in C++.
Victor B. Putz
I can only speak relatively, because I have not been involved in seriously large
projects except those of my own design (my current "dead" project is up to just
under 1 meg of C++ source code), which isn't huge by most standards.
> Now, if I understand you right, you are saying that Java and Eiffel
>outdo C++ on those accounts. I can see with respect to Java
>(I don't know much about Eiffel). Java IS a better language
>(I am not talking about the JVM's performance here).
I think it behooves any OO person to at least look at Eiffel. Better yet, read
"Object-Oriented Software Construction" (second edition) by Bertrand Meyer,
which explains many of those design decisions (or seek out Ian Joyner's paper
comparing the three languages, available at http://www.elj.com/cppcv3/
Java clears up many problems with C++, true, but it still has problems...
> Just for curiosity, how would have (1) ML or (2) Scheme
>served your purpose (instead of Eiffel)?
Okay, The Big Confession: I'm not sure because I haven't tried them for serious
projects yet. Neither was really applicable to PalmOS programming (my current
project) because I either didn't have a good/fast implementation under PalmOS,
or I wasn't sure how to get a cross-compiler working. In addition, many
functional-style languages have serious memory requirements; since the PalmOS
has a dynamic stack of about 30k on old versions of the OS, I wasn't sure they
were the best choices.
If you mean in terms of general game programming (my other pastime), I can't
tell with ML because I'm not sure how well it lends itself to dynamic extension.
But extending a game via, say, Scheme would work tremendously well--in fact,
several commercial games have had in-game scripting languages based on
Scheme/Lisp. It's fairly simple, it can drive existing programs, and can be
used to abstract individual game object behaviour external to the game engine
(so individual objects could have their own behaviour routines, etc). And I
imagine ML could do as well. Since much of game programming has to do with
transformation of an in-game world datastructure onto the screen, the functional
approach can work well there.
In addition, for queries on objects, "stateless" queries (which calculate a
result without modifying state) are a boon, and easier to do and verify in
functional languages than imperative languages. I'm intrigued with OCaml
because of its object model, which allows you to select which fields in an
object are mutable and which are not...
What I'm not sure about is how well one can handle transformation of state (ie
the gameworld and all objects) through time. It's somewhat "against" the
functional mode of things. But I'm trying... (heh)
>Would Java have
>been better?
For PalmOS? Not so much, although there have been some good efforts in that
direction since I started. For games? Quite possibly, but the Java language
itself irritates me; might just be a personal thing (grin).
> I view of C++ as C with just a few added features but not
>as a true OO language. I think C++ is relatively crappy, but
>if one already has learned it (by some misfortune), I do think it
>is a bit preferable to C (despite slow compilation and
>bloated binaries).
I would probably not elect to write an entire application in straight C. But I
would be very likely to use a higher-level language and drop into C for
necessary system accesses/library usage/optimization when necessary.
-->VPutz
Norman Ramsey
Victor B. Putz <vp...@nyx.net.removeme> wrote:
>As for writing and interpreting a scripting language under OCaml, others have
>posted that it must be possible and easier under OCaml than other languages.
I have recently written an implementation of the scripting language
Lua for OCaml. Lua is used in the implementation of the popular
`Baldur's Gate' games---and for all I know, in other games as well.
I have not yet found time to make a separate release, but if you want
to play around, you can pick up the Quick C-- source distribution from
cminusminus.org and you'll find the Lua interpreter. It's about 3500
lines of Caml code for the full version 2.5 language and a significant
fraction of the libraries.
--
Norman Ramsey
http://www.eecs.harvard.edu/~nr