Re: Limitations of standard C, formal interfaces, and other musings. Was: ms-level timings

[Rici Lake <lua@...>]

On 4-Aug-04, at 1:52 PM, Brian Hook wrote:

> Some areas are far too ambitious to roll into a standard
> distributions: graphical interfaces, a math library, a native threads
> library, high quality audio, file/directory handling, signal handling,
> etc.

All the same, thinking about what a directory interface would look like 
is a useful exercise.

For example, could directories simply be modeled as Lua tables? Or 
would it be too foreign for the table-set operation to throw an error?

I realise that we are probably not going to get to the level of 
defining a standard interface for the FreeBSD kqueue call or Mac OS X 
equivalent which you can use to receive notification when a new file 
has been added to a directory. But wouldn't it be useful to have a 
defined interface for common things like verifying whether a string 
represented a file or a directory; creating new files within 
directories; iterating over files within directories; and safely 
walking a directory path?

> That said, there are certain concepts that are common across a huge
> range of platforms that could easily be encapsulated in a single file
> and would likely benefit a lot of users.  The obvious ones are a ms
> accurate timer (when available), sleep, and maybe a handful of others.

The obvious *interface* for (more) accurate timers would be to allow 
os.time() to return a non-integer and insist that it be the number of 
seconds from some (undefined) starting time. The implementation details 
on some platforms, as Ben Sunshine-Hill rightly points out, might be 
more difficult.

Alex Sandro Queiroz e Silva asks about whether that was the goal of the 
LuaCheia project. I'm not part of the project so I cannot answer for 
them, but my understanding was that LuaCheia's goal is to provide an 
out-of-the-box Lua with a lot of features; that is, an implementation.

What I am suggesting here is some thinking about *interfaces*: what 
does a good API look like? And, furthermore, that rather than try to 
define a platform-independent monster (viz. various GUI libraries), 
just trying to focus on facilities which are very common across 
platforms so as to provide a common "style" for extensions.

R.