* compile time rather than runtime portability
* lack of dynamic modifications of the runtime
not to be too contrary, but i'm not sure that these two things
are all that safe, in the security sense that i'd like for, say, a
kernel to be safe. perhaps i'm misunderstanding what they imply.
s.
Intel makes compilers for C, C++, and Fortran. As far as I can tell, they do
not make compilers for Lisp, Haskell, OCaml, or any other higher-level
languages. Intel knows more about how to get the most out of their own chips,
than just about anybody else. Intel compilers are a means to make
On 16/12/2007, terry mcintyre [EMAIL PROTECTED] wrote:
Intel makes compilers for C, C++, and Fortran. As far as I can tell, they do
not make compilers for Lisp, Haskell, OCaml, or any other higher-level
languages.
Intel also funds work (directly or indirectly) on the GCC suite, which
compiles
I think people that call java interpretted are somewhat misinformed. You
certianly can interpret it or any other language for that matter... but that
is not what is usually done. It is usually run through a JIT *compiler* so
that it is compiled. Interpretted is very different. I've written
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed gains. And as always, speed comparisons are only useful
in context. In terms of go programming if you are prototyping use
whatever the hell you want. If you are finishing
hahaha, good point... good point. Although I still will stick with C++, I
really ought to learn Lisp I think.
On Nov 22, 2007 2:43 AM, Raymond Wold [EMAIL PROTECTED] wrote:
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed
Nick Apperson [EMAIL PROTECTED] writes:
Java certainly supports both modes, but what I said is true. If you
are executing a loop repeatedly the actual code gets converted into
machine language that represents the actual code. It is not parsing
bytecodes anymore at this point.
It's a bit
On 21/11/2007, Stefan Nobis [EMAIL PROTECTED] wrote:
It's not an inherent feature of the
language that allows JIT.
That's not entirely true.
There are some languages (such as Perl) which have language features
which absolutely precludes JIT as we know it.
In Perl you can have a line of code
In theory, a perfect compiler given enough time would optimize all
languages to the same machine code if the program does the same thing.
actually, to be a bit nitpicky here, you can't do this. not even for
a single language.
s.
Stuart A. Yeates [EMAIL PROTECTED] writes:
There are some languages (such as Perl) which have language features
which absolutely precludes JIT as we know it.
Your example doesn't convince me: Your Perl example may be compiled
(but maybe the resulting code is a bit more complex than a direct
On Wed, Nov 21, 2007 at 09:11:25AM +, Stuart A. Yeates wrote:
In Perl you can have a line of code that looks like:
@result = (dothis $foo, $bar);
which could be either of:
@result = (dothis($foo), $bar);
@result = dothis($foo, $bar);
And the correct choice can vary each time the
On 15/11/2007, steve uurtamo [EMAIL PROTECTED] wrote:
the more i think about it, the more i love whatever language
i'm using for whatever project i'm working on. some projects
would be (or are) horrifying to try to implement in some languages
[the matlab-C example springs to mind], so, since
Hi,
On Nov 20, 2007 3:03 PM, Stuart A. Yeates [EMAIL PROTECTED] wrote:
The logical (but worrying) conclusion I draw from that paragraph is
that you would like to see a language with an intended application of
go...
Why would that be a worrying conclusion?
regards,
Vlad
My 2 cents about languages.
C is the universal assembly language. I don't think I've ever used a
computer family that didn't have a C compiler on it (after C was invented of
course). Often new languages, to get started, will just translate into C
code and then compile with the C compiler.
I'll try that with my Ruby GTP code. I'm assuming random moves until
no non-eye-filling moves are left and on a 9x9 board?
On Nov 20, 2007 9:58 AM, Chuck Paulson [EMAIL PROTECTED] wrote:
My 2 cents about languages.
C is the universal assembly language. I don't think I've ever used a
PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, November 20, 2007 6:46:35 AM
Subject: Re: [computer-go] Language [offtopic, aside]
Hi,
On Nov 20, 2007 3:03 PM, Stuart A. Yeates [EMAIL PROTECTED] wrote:
The logical (but worrying) conclusion I draw from that paragraph
Hi,
I think the reason for Ruby being so much slower is because it is an
interpreted language rather than a compiled language. So when you run
the program, a Ruby interpreter has to translate the instructions to
machine code as they are running, instead of a compiled language like
C where this
On 20/11/2007, Vlad Dumitrescu [EMAIL PROTECTED] wrote:
Hi,
On Nov 20, 2007 3:03 PM, Stuart A. Yeates [EMAIL PROTECTED] wrote:
The logical (but worrying) conclusion I draw from that paragraph is
that you would like to see a language with an intended application of
go...
Why would that
On Thu, Nov 15, 2007 at 04:41:19AM -0800, steve uurtamo wrote:
the more i think about it, the more i love whatever language
i'm using for whatever project i'm working on. some projects
would be (or are) horrifying to try to implement in some languages
[the matlab-C example springs to mind],
Java and C# are both compiled at some point if the same loop is running
repeatedly. Java is usually compiled just in time which is to say as each
function is first run. I'm not sure how C# is executed, but I think it gets
compiled before execution.
In theory, ruby and python could also be
Colin Kern [EMAIL PROTECTED] writes:
I think the reason for Ruby being so much slower is because it is an
interpreted language rather than a compiled language.
It's not the main problem (interpreted languages are slower than those
compiled to native code, but than even Java and C# are
On Nov 20, 2007 1:56 PM, Nick Apperson [EMAIL PROTECTED] wrote:
On Nov 20, 2007 12:48 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Colin Kern [EMAIL PROTECTED] writes:
I think the reason for Ruby being so much slower is because it is an
interpreted language rather than a compiled
On 20/11/2007, Colin Kern [EMAIL PROTECTED] wrote:
On Nov 20, 2007 1:56 PM, Nick Apperson [EMAIL PROTECTED] wrote:
On Nov 20, 2007 12:48 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Colin Kern [EMAIL PROTECTED] writes:
I think the reason for Ruby being so much slower is
(I just joined this list last week, this is my first post)
Hi Colin, welcome to the group.
I still find it easier and faster to code in Java (using Eclipse) than
with C++. The OP mentioned that Java is slow, but I have actually
read that in the recent years it has become comparably faster
There are possibilities like inline-perl, inline-ruby, critcl (inline
code for tcl) that are not too bad for mixing code.You can move back
and forth between C and a high level language fairly easily.
I've never tried using one of these (with inline stuff) for go.You
really want the core
Colin,
I would NOT recommend this site. It was last updated in '98. Many of
the optimizations listed were great for back then. They are terrible
for 2007 and will likely result in SLOWER execution, not faster.
For example, the claim is that a synchronized method call is 10 times
slower
Nick Apperson [EMAIL PROTECTED] writes:
Java and C# are both compiled at some point if the same loop is
At some point everything has to be translated to machine code. But
Java, C#, Ruby etc. are doing this at execution time -- that what most
people call a interpreter.
You are right, the
Just a few considerations about computer languages:
Event if it looks like there are many computer languages, Rob Pikes has said
:
C is the desert island language.
All the languages are bad, you have to choose the right balance of defects.
I have used a lot C, C++, Ada and Perl. I know about
Given all this support for Common Lisp, I figured i'd ask two questions:
1) are there any open-source computer Go efforts in lisp?
2) whatever happened to Peter Seibel, author of Practical Common Lisp?
A few years ago, Peter Seibel made a few posts to the computer-go list, and his
PCL book
On Nov 17, 2007 12:28 PM, terry mcintyre [EMAIL PROTECTED] wrote:
1) are there any open-source computer Go efforts in lisp?
I started with http://sourceforge.net/projects/cl-go a while ago, but
I didn't work on it recently and I don't have a clue what the other
guys did with the code when I
[EMAIL PROTECTED] (William Harold Newman) writes:
Still, though, sometimes useful things resist elegant implementation
in CL. For example:
* I doubt CL can be customized to support a thread library nearly
as gracefully as languages designed around threading from the
ground up.
All
as an aside, although not strictly useful for anything other than
what it was intended (what is?), matlab is a great
example of where loose typing can get out of
hand. just one or two extra characters here or
there, and all of a sudden the NxMxYxW matrix
represented by the letter g has undergone
Don Dailey wrote:
My Go program doesn't use any libraries except the standard C
libraries.
I agree at 99.9% !! The only exception in my case is SFMT.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
SFMT is 100% clean C software, easy to compile, easy to use and free.
A good
On Tue, Nov 13, 2007 at 11:57:30PM +0100, Benjamin Teuber wrote:
On Nov 13, 2007 10:18 PM, Nick Apperson [EMAIL PROTECTED] wrote:
With the next generation of C++ with
variadic templates I think C++ may overtake Lisp for metaprogramming, but I
don't know enough to really make that claim.
I don't have any problems with libraries, just ones that are
gratuitously introduced for no good reason. I'm the first one to use a
needed library.
Also, now that I think about it, I do use Mersenne Twister - I just
forgot about it because this was a late addition to my program. I will
look
Sent: Tuesday, November 13, 2007 10:34:26 PM
Subject: Re: [computer-go] Language
hahaha
one problem though... i can't easily determine the number of letters that are
inside the parenthesis...
maybe this is better:
paren type:open/parenspace type=normal/spaceletter type=normal
case=capitalX
.
Lars Nilsson
- Original Message
From: Nick Apperson [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, November 13, 2007 10:34:26 PM
Subject: Re: [computer-go] Language
hahaha
one problem though... i can't easily determine the number of letters
And it's not fast either. Free() has a reputation of being
slow, and that's not surprising if you look at the way it is
almost always implemented: scanning a list of addresses in
order to amalgamate the newly freed memory with adjacent free
areas.
this is a burden for the OS, not a defect in
whew. i need to switch out my ascii, then.
s.
- Original Message
From: Lars Nilsson [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, November 14, 2007 10:10:15 AM
Subject: Re: [computer-go] Language
On 11/14/07, steve uurtamo [EMAIL PROTECTED] wrote
On Nov 14, 2007 10:54 AM, steve uurtamo [EMAIL PROTECTED] wrote:
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad. thanks. :)
in that case, i'm impressed that i can do 2GB allocations.
On Nov 14, 2007 10:25 AM, steve uurtamo [EMAIL PROTECTED] wrote:
And it's not fast either. Free() has a reputation of being
slow, and that's not surprising if you look at the way it is
almost always implemented: scanning a list of addresses in
order to amalgamate the newly freed memory
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad. thanks. :)
in that case, i'm impressed that i can do 2GB allocations.
s.
: Re: [computer-go] Language
On Nov 14, 2007 10:54 AM, steve uurtamo [EMAIL PROTECTED] wrote:
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad. thanks. :)
in that case, i'm impressed
On Wed, Nov 14, 2007 at 11:04:41AM -0500, Álvaro Begué wrote:
On Nov 14, 2007 10:54 AM, steve uurtamo [EMAIL PROTECTED] wrote:
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad.
On Wed, 2007-11-14 at 07:25 -0800, steve uurtamo wrote:
And it's not fast either. Free() has a reputation of being
slow, and that's not surprising if you look at the way it is
almost always implemented: scanning a list of addresses in
order to amalgamate the newly freed memory with
On Wed, 14 Nov 2007, Don Dailey wrote:
Also, now that I think about it, I do use Mersenne Twister - I just
forgot about it because this was a late addition to my program. I will
look at the SIMD version - just using the non-SIMD version was a big
speedup over the standard library rand()
On Wed, 14 Nov 2007, Hellwig Geisse wrote:
The type of software I had in mind was an interactive system,
running for days (or even months) without restarting, together
with the possibility of creating function closures. I find it
hard to imagine how you can do that without a garbage collector.
I don't think of it as a library either, and technically it's not.I
do compile those few lines of code and link them in separately.
- Don
Christoph Birk wrote:
On Wed, 14 Nov 2007, Don Dailey wrote:
Also, now that I think about it, I do use Mersenne Twister - I just
forgot about it
On Wed, 2007-11-14 at 12:30 -0800, Christoph Birk wrote:
I write (astronomical) instrument control software in C that
runs for days (upto weeks). I call malloc() when I need memory
and free() when the particular sub-task is done ... no problem.
Then you are a lucky guy... ;-)
With closures
On Wed, 14 Nov 2007, Hellwig Geisse wrote:
On Wed, 2007-11-14 at 12:30 -0800, Christoph Birk wrote:
I write (astronomical) instrument control software in C that
runs for days (upto weeks). I call malloc() when I need memory
and free() when the particular sub-task is done ... no problem.
Then
On Wed, Nov 14, 2007 at 10:40:15AM -0500, Álvaro Begué wrote:
Anyway, go programmers should probably not be using a whole lot of dynamic
memory allocation, and certainly not enough to make the performance of
free() matter at all.
Doesn't that depend strongly on how a program works? For
On Nov 14, 2007 4:58 PM, William Harold Newman [EMAIL PROTECTED]
wrote:
On Wed, Nov 14, 2007 at 10:40:15AM -0500, Álvaro Begué wrote:
Anyway, go programmers should probably not be using a whole lot of
dynamic
memory allocation, and certainly not enough to make the performance of
free()
perhaps this is an obvious statement... The best language depends on the
way in which your program works. Having used C++ extensively, my program
designs naturally fit easily into that language. I'm sure a lisp programmer
would think of better solutions that would only work in lisp. As far as
On Wed, Nov 14, 2007 at 04:44:25PM -0600, Nick Apperson wrote:
perhaps this is an obvious statement... The best language depends on the
way in which your program works. Having used C++ extensively, my program
designs naturally fit easily into that language. I'm sure a lisp programmer
would
I definately agree with the spirit of what you are saying, and probably I am
just missing something, but I'm not sure that the examples you gave are
truly restricted in C++. You can import the setjmp header from C (or any
number of other similar such libraries) and have crazy gotos. Every major
In message
[EMAIL PROTECTED], Nick
Apperson [EMAIL PROTECTED] writes
WARNING: This digresses into a rant by the end... You've been warned.
If you like to have your garbage collected for you then use one of the
management strategies present in C++. If you like delayed freeing,
overload new or
Nick Apperson wrote:
If
you can't avoid memory leaks, fine, don't use C++ or C, but don't blame the
language. You could use garbage collection if you need it; don't make us
all stoop to your level of competency and don't try and claim that your
language is just as fast when it isn't.
There
Nick Apperson wrote:
WARNING: This digresses into a rant by the end... You've been warned.
But I'll be damned if Java takes over the world because there are
programmers that don't know when they need to use garbage collection.
If you can't avoid memory leaks, fine, don't use C++ or C, but
are recommending and choosing important to you? What are you
defending? What are you trying to achieve?
Jim
- Original Message
From: Nick Apperson [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, November 13, 2007 12:07:10 AM
Subject: Re: [computer-go
On Nov 13, 2007 10:36 AM, Ian Osgood [EMAIL PROTECTED] wrote:
I like Forth. I got excited about UCT around the time of the Computer
Olympiad and wrote a bitmap-based 9x9 program. What is the general
impression on bitmap vs. mailbox board representations for Monte
Carlo readouts?
I never
On Mon, Nov 12, 2007 at 04:41:35PM -0500, Chris Fant wrote:
I would like some language recommendations. Requirements:
Runs in Linux
Has garbage collection
Fast
Well supported
Can interface with MPI (can make C calls)
Yes, wouldn't want a language question to start a war.:-|
On Nov 13, 2007 11:10 AM, William Harold Newman
[EMAIL PROTECTED] wrote:
On Mon, Nov 12, 2007 at 04:41:35PM -0500, Chris Fant wrote:
I would like some language recommendations. Requirements:
Among the languages I know something about (which excludes D and C#,
for example)...
technically
On Tue, Nov 13, 2007 at 10:46:23AM -0500, Jason House wrote:
I never went down the road of bitmap based go because I had not clever way
to efficiently track captures. How did you get around this hurdle?
When I was thinking of this - long time ago - I defined a 'shake' operation
that expands a
On Nov 13, 2007, at 7:46 AM, Jason House wrote:
On Nov 13, 2007 10:36 AM, Ian Osgood [EMAIL PROTECTED] wrote:
I like Forth. I got excited about UCT around the time of the Computer
Olympiad and wrote a bitmap-based 9x9 program. What is the general
impression on bitmap vs. mailbox board
On Nov 13, 2007 11:23 AM, Heikki Levanto [EMAIL PROTECTED] wrote:
There are pathological cases where this has to loop many times, flood
filling
the one liberty to a long chain of stones, but those should be rare.
This was my big turn-off. I would expect the average case in mid-game to
On Nov 13, 2007 5:10 PM, William Harold Newman
[EMAIL PROTECTED] wrote:
Also Prolog may be in a higher obscurity class than the others: unlike
even the most obscure languages listed above, I don't know any serious
applications which are maintained in Prolog today.
I think at least one route
Willaim Harold Newman: I actually already addressed this concern earlier
when I said If you don't directly use the heap in C++ ( i.e. you use the
smart pointer class) you don't have to worry about garbage collection
(except if you make a circular list).
As far as the other stuff you said, I'd
On Tue, Nov 13, 2007 at 11:35:43AM -0500, Jason House wrote:
On Nov 13, 2007 11:23 AM, Heikki Levanto [EMAIL PROTECTED] wrote:
There are pathological cases where this has to loop many times, flood
filling the one liberty to a long chain of stones, but those should be
rare.
This was my
On Nov 13, 2007 5:35 PM, Jason House [EMAIL PROTECTED] wrote:
On Nov 13, 2007 11:23 AM, Heikki Levanto [EMAIL PROTECTED] wrote:
There are pathological cases where this has to loop many times, flood
filling
the one liberty to a long chain of stones, but those should be rare.
This was my
No need to get turned off on that. In most cases you don't need to
shake that much. Remember you only need to get the new stone and its
direct opponent neighbours connected to a liberty. There's plenty of
tricks for early termination. Last time I tested it I got ~75k uniform
random playouts
On Nov 13, 2007, at 9:17 AM, Heikki Levanto wrote:
Now that I know of MC and related techniques, it might pay off
anyway to see
if a bitmap machine could play reasonably fast simulations. I can
see two
problems remaining: A quick test to sort out all eyelike points, to
get a
bitmap of
On Nov 13, 2007 11:31 AM, Ian Osgood [EMAIL PROTECTED] wrote:
On Nov 13, 2007, at 7:46 AM, Jason House wrote:
On Nov 13, 2007 10:36 AM, Ian Osgood [EMAIL PROTECTED] wrote:
I like Forth. I got excited about UCT around the time of the Computer
Olympiad and wrote a bitmap-based 9x9
On Nov 13, 2007 6:40 PM, Chris Fant [EMAIL PROTECTED] wrote:
No need to get turned off on that. In most cases you don't need to
shake that much. Remember you only need to get the new stone and its
direct opponent neighbours connected to a liberty. There's plenty of
tricks for early
I was only half kidding about forth - it is a language I haven't really
explored and at some point I want to learn it, and give it a good enough
chance that I can form a well educated opinion of the language.
It's my understanding that the good optimizing compilers for forth are
commercial.
How does the speed of the Haskell version compare to the C and Java
version? The Haskell web site now brags about how fast Haskell is.
I have become jaded about claims - you will find almost every language
site talks about how fast their language is.
- Don
John Tromp wrote:
On Nov 13,
On Nov 13, 2007, at 11:11 AM, Don Dailey wrote:
Ian Osgood wrote:
On Nov 12, 2007, at 3:59 PM, Don Dailey wrote:
How about forth? A lot of the high level languages we are talking
about essentially get converted to forth (or I should say a
forth type
language.)
- Don
I like Forth.
On Nov 13, 2007 2:15 PM, Don Dailey [EMAIL PROTECTED] wrote:
How does the speed of the Haskell version compare to the C and Java
version? The Haskell web site now brags about how fast Haskell is.
Not too well:-(
Fhourstones in Haskell runs more than 10 times slower than the C version...
Chris Fant [EMAIL PROTECTED] writes:
I would like some language recommendations.
So I would suggest Common Lisp: The programmable programming
language. I think it's the single most flexible language -- you get
everything, from imperative over object-oriented to functional and
declarative
I used Lisp a little bit in college and I enjoyed it. And you are not
the first person to mention that it is a good fit for Go. Thanks for
everyone's comments and thanks for not being hostile to each other on
this touchy subject. Turns out we CAN all just get along.
On Nov 13, 2007 2:59 PM,
I'd also say that Lisp seems like a great choice. I'm happy to see that C++
has been adding support for all the metaprogramming because that is what is
going to really matter in the future I think and it is why Lisp is such a
great language.
On Nov 13, 2007 2:13 PM, Chris Fant [EMAIL PROTECTED]
Nick Apperson [EMAIL PROTECTED] writes:
Reference counting and copy on write.
Do you know that there's much more to garbage collection than
reference counting and that reference counting has some major
drawbacks? There are even hard real time capable garbage collectors
out there.
But I'll be
On Nov 13, 2007 3:36 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
You miss the point: Using languages with GC is not about programmers
who can't avoid memory leaks. It's not about ability, it's about
productivity. If the only reason you don't use assembler is that with
C your code is easier to
On Nov 13, 2007 3:22 PM, Nick Apperson [EMAIL PROTECTED] wrote:
I'd also say that Lisp seems like a great choice. I'm happy to see that
C++ has been adding support for all the metaprogramming because that is what
is going to really matter in the future I think and it is why Lisp is such a
I already mentioned that reference counting is not enough for GC... That I
know. I personally don't user reference counting very often. The most
common case being a case where a resource doesn't itself point to anything.
That way I know it won't form a loop. But usually, I just don't use it at
Nick Apperson [EMAIL PROTECTED] writes:
And I don't htink I missed the point about productivity. I've heard
that argument time and again. That is fine. I personally find that
with the STL in C++ and with the ability to write my own templates,
I can write algorithms in fewer lines of code
Yeah,
I've only dabbled in Lisp, but it seems like a great language to me. It
is on my list of languages to learn. I couldn't agree with you more about
Java and C# being about prohibition. With the next generation of C++ with
variadic templates I think C++ may overtake Lisp for
2007/11/13, Hellwig Geisse [EMAIL PROTECTED]:
On Mon, 2007-11-12 at 20:17 -0800, steve uurtamo wrote:
C
garbage collection: free().
Well, that's not garbage collection.
Ok, Java don't have garbage collection: don't close open files, sockets
etc. only frees memory (maybe never) but nobody
I must be a dinosaur - at least a minimalist - but I don't understand
the big deal about library support that has been mentioned a lot here.
My Go program doesn't use any libraries except the standard C
libraries.Since it's written in C, I have access to hundreds of
libraries for C, but
On Nov 13, 2007 5:01 PM, Don Dailey [EMAIL PROTECTED] wrote:
I must be a dinosaur - at least a minimalist - but I don't understand
the big deal about library support that has been mentioned a lot here.
My Go program doesn't use any libraries except the standard C
libraries.Since it's
On Nov 13, 2007 10:18 PM, Nick Apperson [EMAIL PROTECTED] wrote:
With the next generation of C++ with
variadic templates I think C++ may overtake Lisp for metaprogramming, but I
don't know enough to really make that claim.
I don't know about variadic templates, but in general it is almost
On Tue, 13 Nov 2007, Don Dailey wrote:
I must be a dinosaur - at least a minimalist - but I don't understand
the big deal about library support that has been mentioned a lot here.
:-)
My Go program doesn't use any libraries except the standard C
libraries.Since it's written in C, I
Common lisp? Does it have xml libraries?
- Don
Stefan Nobis wrote:
Chris Fant [EMAIL PROTECTED] writes:
I would like some language recommendations.
So I would suggest Common Lisp: The programmable programming
language. I think it's the single most flexible language -- you get
On Nov 14, 2007 12:18 AM, Don Dailey [EMAIL PROTECTED] wrote:
Common lisp? Does it have xml libraries?
- Don
http://www.google.de/search?q=common+lisp+xml
___
computer-go mailing list
computer-go@computer-go.org
Good, I wouldn't want it without XML libraries.
Is there any versions that use XML for writing code?I want to be
able to use xml tags instead of parenthesis:
paren /paren
Then it will much more readable - which is one of the strengths of xml.
- Don
Benjamin Teuber wrote:
On Nov 14,
Sounds like you want to write a Go program in XSLT!
Ian
On Nov 13, 2007, at 3:51 PM, Don Dailey wrote:
Good, I wouldn't want it without XML libraries.
Is there any versions that use XML for writing code?I want to be
able to use xml tags instead of parenthesis:
paren /paren
Then it
hahaha
one problem though... i can't easily determine the number of letters that
are inside the parenthesis...
maybe this is better:
paren type:open/parenspace type=normal/spaceletter
type=normal case=capitalX/letterletter type=normal
case=capitalM/letterletter type=normal
Don Dailey [EMAIL PROTECTED] writes:
I must be a dinosaur - at least a minimalist - but I don't
understand the big deal about library support that has been
mentioned a lot here.
For Go library support isn't very important -- just one argument more
in favor of more exotic languages, that make
I would like some language recommendations. Requirements:
Runs in Linux
Has garbage collection
Fast
Well supported
Can interface with MPI (can make C calls)
Hope this doesn't start a war.
___
computer-go mailing list
On 11/12/07, Chris Fant [EMAIL PROTECTED] wrote:
I would like some language recommendations. Requirements:
Runs in Linux
Has garbage collection
Fast
Well supported
Can interface with MPI (can make C calls)
OCaml. Check on all counts.
Lars Nilsson
Are you a troll?
I'd recomend staying away from proprietary languages personally... for
obvious reasons. I don't think there is any language that doesn't sacrifice
some speed for garbage collection. But, speed is a relative thing. If you
don't directly use the heap in C++ (i.e. you use the
1 - 100 of 153 matches
Mail list logo
