Thoughts on the recent ICFP contest

[Ted Dennison <dennison@telepath.com>]

I was reading over the results of this year's ICFP programming contest 
(http://icfpcontest.cse.ogi.edu/ ) last week.

For those allergic to following links, this year's project was to build 
a simple virtual robot that moves crates around and interacts with other 
robots in a way that maximizes its own score. Entrants had the recent 
long weekend (long in the US anyway) to complete their entries, at which 
time they'd compete against each other's entries to see how they score. 
This is *very* similar to an AI class project I did as an undergrad (in 
Lisp), so I'm somewhat familiar with the issues involved with doing this.

One thing I started wondering is what libraries would have been needed 
to have been available for someone to complete this project 
competitively in Ada. After reading over the web pages of some of the 
contestants (http://icfpcontest.cse.ogi.edu/links.html ) and a bit of 
thought, I came up with the following things that would have helped an 
Ada implementation get into the lightning round (submitted <24 hours 
after the requirements were posted):

   (1) An inference engine.
   (2) High-level socket bindings.
   (3) A generic implementation of Dijkstra's Algorithm

(1) would be useful for the actual robot decision-making process.
We already have it in a preliminary form, with my CLIPS bindings 
(http://www.telepath.com/~dennison/Ted/AdaClips/AdaClips.html )

(3) (http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/dijkstra.html ) 
would have saved someone lots of time here, but is probably not 
something that would be general-use enough to find laying around in a 
reusable package library somewhere. I could be wrong though...

That leaves me with (2), which is both generally useful, and not 
available right now (at least not outside of Claw). I'm thinking the 
best way to do this in the context of Ada would be to implement it as a 
stream, with the various sockopt function codes implemented as 
primitives on it.  I'm curious if anyone else thinks something like this 
ought to be available.

Another thought I had was that for a general-purpose socket stream to be 
really useful in many applications, you'd also need some way to tell it 
to transmit an entire buffer at once, rather than one component at a 
time (although you might want that in a lot of situations too). The best 
idea I came up with is a new type that users can convert their objects 
to (via some kind of pointer magic-perhaps), which has its 'Write and 
'Read implemented to write the whole defined length of the buffer at 
once. This would be quite useful with *any* stream too, not just with 
socket streams. Since this is a speed optimization, copying the buffer 
would be missing the point. Therefore, it would probably be implemented 
as a simple addres and length (or pointer if the type is generic).

Anyway, I'm curious what other Ada folks think about all this.