bevan@cs.man.ac.uk (Stephen J Bevan) (04/05/91)
> What is portability? Portability doesn't just involve the compiler or > interpreter itself. It's a property of code written for it as well. If we are talking about the base language, then I'd agree with this. However, if you have a decent module system (like Python) you can put system specific features in separate modules. i.e if you are running under Amoeba, you can use the Amoeba module, if you are running on a Mac, you can use the Mac module. BTW I'm not saying the modules have to impement the same thing, rather they take advantage of the facilties of the machine. Where's the portability problem? Stephen J. Bevan bevan@cs.man.ac.uk
Paul_Abrahams@MTS.cc.Wayne.edu (04/10/91)
An example of a portable Icon function with a nonportable implementation is the file name generator I posted a while back. Given a file name with wildcards, its result sequence is the set of specific file names that match. The DOS implementation uses a specific system call, while the Unix implementation (I'd guess) would use a shell echo call with redirected output (since wildcard interpretation is generally done in the shell, not in the underlying system.) Note that DOS wildcards and Unix wildcards have somewhat different interpretations: DOS essentially ignores characters after `*', while Unix doesn't; and the DOS treatment of the file extension is quite different from that of Unix. Path name interpretation is another example of a portable function with a non-portable implementation, since DOS uses `\' but Unix uses `/' (and maybe the Mac uses something else again). But the notion of a path makes sense in any system that has tree-structured directories. (Does anyone know how this maps to the IBM OS/370 world?) Paul Abrahams Abrahams@mts.cc.wayne.edu