Just looking through the CLC-INTERCAL documentation (often in the source code), and through the C-INTERCAL documentation I'm writing at the moment, and from my personal experience, I'm noticing a deficiency in INTERCAL. Many INTERCAL programs need various command-line switches for various features they need or use; these switches vary by compiler (not necessarily a bad thing), but they have to be typed each time and remembered either in a comment in the program or elsewhere (which is a bad thing). So I decided that it would be worthwhile making it possible to store this information along with the program. The method of doing this used by other programming languages is to put the information in a meaningful comment somewhere in the code, often after #! so UNIXy systems can automatically execute the program in question. Perl's method of doing this, in particular, is delightfully twisted, so INTERCAL has to come up with something weirder.
Anyway, the decision I'm tentatively making (and posting here to ask whether it's a good idea and whether I should do it, which in INTERCAL aren't necessarily correlated), is that as this information is metadata on the program, it may as well be metadata on the file in which it is stored. Specifically, the last-modified time. There is likely enough information storage there (even without messing with the date) to store all the command-line options that may be needed (including things like target language to compile to, debug options, etc., because this may be useful and I'll provide a way to override them). For language options in particular (C-INTERCAL, CLC-INTERCAL, INTERCAL-72, TriINTERCAL), using the extension makes sense and is what is done by more than one compiler at present, but there isn't enough room there for all the options, at least on DOS. So the plan is for the C-INTERCAL compiler, at least, to read options for a program from its extension and its last modified time. Both of these are easy to change on most modern operating systems.
Of course, this raises the question of backwards compatibility. The solution to that that I intend to adopt is to ignore the last-modified time unless the file has the read-only attribute set (DOS/Windows) or the writable by owner attribute cleared (POSIX operating systems); I suspect most other operating systems will have a similar setting. This has the added advantage of making it harder to change the last- modified time by mistake, and it should be reasonably easy to write a shell script that allows editing a file whilst preserving its read- only status and last-modified time.
Any thoughts? Is it worthwhile standardising the list of options across INTERCAL compilers (so that the same file will compile on multiple compilers without messing with options, as long as it's read- only), or should this simply be a C-INTERCAL thing or incompatible from one compiler to the next?
> Any thoughts? Is it worthwhile standardising the list of options > across INTERCAL compilers (so that the same file will compile on > multiple compilers without messing with options, as long as it's read- > only), or should this simply be a C-INTERCAL thing or incompatible > from one compiler to the next?
While the idea is interesting and suitably unusual, I can see problems when copying files, particularly copying across systems, and even worse when the date/time format is different (FAT for example stores the year, month, day, hour, minute and five bits of the second IIRC, while many filesystems store the number of seconds since some arbitrary date in the past). You would need to know what other operating systems, which you may never have heard of, do to the modification times of a file...
Perhaps what is required is a multiple way of specifying options, with different operating systems/filesystems supporting different models, and a simple program to convert from one to the other. If a programmer decides to use more than one at once, that's fine but if they are inconsistent with each other you get a compile error.
I was wondering if POSIX access control lists can be perverted to do something similar? Maybe using a mask which prevents write access to the file, and using the (now redundant) write bits in the various ACL entried to specify options.
On an unrelated note, the CLC-INTERCAL 1.-94.-2 is imminent (sometime this year), so if we can have a common INTERCAL option specification plan before too long, maybe I can implement it there.
I don't see compatibility between compilers as a bad thing: so many languages have incompatible compilers that it's incompatibility which should be banned from INTERCAL :-)
C
-- The address in the "From" header won't work. Email to "usenet" at "intercal" dot "dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages to go through the spam filter, and other conditions which I won't disclose.
Sorry for the double follow-up, but I was just thinking...
CLC-INTERCAL has a mechanism to encode all options in the suffix, which may only work for a filesystem with more than 3 characters for the suffix. However, perhaps this can be extended to encode some options in the file name, perhaps only when the file name is of a special format?
Maybe we need to have a special compiler option which reverses the name and the suffix while deciding which other options to enable. A suitable file will compile in any compilers provided that (1) the name isn't changed (the suffix can be changed if required) and (2) the one option "look at the name, not the suffix", is specified.
Of course, this may be just one of the many ways of specifying the options, as I mentioned in my previous reply.
I'd be interested to know if any other language does that.
C
-- The address in the "From" header won't work. Email to "usenet" at "intercal" dot "dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages to go through the spam filter, and other conditions which I won't disclose.
|
