Metadata and command-line options
ais523
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?
--
ais523
Claudio Calvelli
> 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.
Claudio Calvelli
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.