[racket] #lang text ? #lang none ?

Four hours ago, John Clements wrote:
> 
> I think you're missing the "manifest destiny" I'm proposing; in
> particular, I'm thinking about push the #lang syntax outward into
> the world, so that people think, "hey; it makes sense that every
> text-like file should begin with a line stating what language it's
> written in."

I completely agee ... but that's hardly a new idea...  See Emacs "-*-"
lines, Email/HTTP headers, EXIF meta-data, description blocks in
archives, etc etc.  Each of these is potentially trying to pull the
same trick, and each of these have people that will agree and tell you
that you should obviously use *their* magic lines.  Then there's the
unix `file' command which specifically tries to guess something about
the file given all of these.


> You may argue that it'll never catch on, and you might be right. I
> don't mind tilting at windmills when it doesn't cost me too much,
> though.

Yes, I absolutely believe that it won't catch on, since there are so
many of them that failed in the past...

But more importantly, `#lang' is different from them: it has less
information for the languages that are actually in (=> our meta-data
is extremely small), and OTOH, it has more information in that it
specifies how the file behaves as code (executable script or library).
This is unlike most of these which specify only the kind of data and
not how it's used -- so to get the same kind of functionality you
inevitably give up the usage part and make it only a description of
the kind of content for the editor (much less useful than #lang in
general, since they'd all be no-ops when used as code).  And as a
description of contents, `#lang text' is far less descriptive than
even the very simple emacs -*- lines.


-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!