Re:i t works

[Mark Carter <mcturra2000@...>]

Brian Hook wrote:

> > Let me put it like this: do you use /, \, :, . or <other> to
> > seperate path elements?

> Anyway, I think the point has been made =)


Good point. I never thought about the idiosyncracies. I've actually now 
read the recent thread concerning this matter.

But I would like to readdress the issue; please don't construe it as 
trolling. I'm trying to be constructive.

I'm taking my views from the angle that Lua, to be taken seriously, must 
have directory listing. The first thing I did with Lua was to read a 
file, and then print it out to stdout. The second thing I tried to do 
was list files in a directory, so that I could collate information for a 
web page. That's where I bumped into problems. It's going to be awefully 
difficult for Lua to gain in popularity as a scripting language if one 
is almost immediately forced to extend it.

It seems that the language implementors have 4 basic options:
1. Do nothing (the one that they're doing already)
2. Use branched code, such as LuaCheia
3. Provide some kind of library linking methodology
4. Stick some code in anyway

Option 1
--------

IMO, 1 is a bad choice. Programmers will definitely want to list 
directories.


Option 2
--------

I'd also suggest that 2 is also a bad option. Branching code creates 
maintenance headaches, and duplicates effort. Plus there is a problem of 
ongoing commitment. It is apparent from reading the thread that LuaCheia 
is already encountering this problem (no offence intended to LuaChiea 
developers, it's just a fact of life).

Option 3
--------

This probably would be a good option. I've programmed in Tcl on two 
occasions (so, not very often, then). One thing I noticed it had was an 
ability to link in DLLs.

That strikes me as being quite a good idea. Programmers would only have 
to write the functionality once, away from the core of the language, and 
then its done. The relevant libaray is shipped with the binaries, and 
everyone is happy.

Option 4
--------

My argument is that this isn't necessarily a bad option, despite 
cross-platform portability issues. Provide some incremental improvement, 
then hope that some day someone else will provide some other 
improvement, and so on, until the problem is solved.

For example, I cobbled together a directory-listing routine (like I said 
before, I nicked it from the internet). It uses the UNIXy way of doing 
things, and I am on a win32 machine. Now, providing the code compiles 
everywhere without barfing, at least Lua programmers have some kind of 
/chance/ of being able to list directories. The Borland and the VC++ 
guys might be disappointed, but it is conceivable that one of them will 
supply support for it in future.

Someone mentioned that this will tend to muddy the code, with lots of 
#idfef _WIN32 all over the place. In answer to their comment: yes, 
they're right, but I'd rather have a some preprocessing directives 
floating around and multiple implementations of the same code than for 
it to lack directory listings. In the end, it all boils down to making a 
design decision. And in my opinion, I think it's better to favour the 
inclusion of the functionality.

That leaves us with the little matter of:  do you use /, \, :, . or 
<other> to seperate path elements? My answer would be: whatever works 
for my platform. I have implemented os.dir(filename) as an extension for 
Lua. The way that FILENAME is specified is dependent on the 
implementation of the mingw libraries. UNIX programmers will have to use 
different delimiters. Ditto for the VAX people. But does this really 
matter? As a Windoze programmer, I don't really care what delimiters the 
UNIX guys use, and vice versa. All I care is that it works for my 
platform. The patch that I could provide uses the opendir() and 
readdir() functions. My patch ought to be usable by UNIX programmers 
straight away, regardless of whether they use /, \ or :.

Put it this way: I know for sure that you can list directories in Python 
without having to resort to extending the language; on UNIX and win32 
platforms. And I'm fairly confident in saying that Perl and Ruby provide 
that functionality, too. So, it definitely can be done!