This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Optional Arguments (was Re: CVS script)



> But in any case, they were defining a programming language,
> not an extension to shell scripts.  It is not clear to me why
> the Bourne shell comment syntax really should be an issue for
> a programming language that has a very differnt syntax, and that
> uses shell's comment character for other pruposes.

#! is not just a comment syntax for the bourne shell but when
it is the first two bytes of a file it represents _at_kernel_level_
that this file is a script. It is a really low level unixy thing
and totally entrenched. It effects system() and execv() and all
sorts of stuff.

> Of course, you don't want to start /bin/sh either.  Fine:
> 
> 	#/usr/bin/guile --script
> 	(define ...)

The problem with this (aside from the missing !) is that it is nice
to be able to (load "joe") from inside guile and also $joe from the
shell. Unless the (load) knows about scripts this isn't possible.

> Finally, my recommendation:
> Treat "#!" followed by (optional spaces then) "/" as a comment
> start, in a way compatible with Guile and scsh.  "#!" followed by a
> letter is one of the special tokens.  "#!" followed by anything else
> is an error.  Voila, problem solved, in a clean way that does not
> require any magic, that is compatible with most existing uses, and
> that is copatible with the DSSSL ISO standard.

Surely the thing to do is treat the first two bytes of the file specially.
That is what unix does, that is where the #! is important and anyone
who is writing DSSSL and starts their file with #! (without intending it
to be a script) is going to be considered such a clot by the unix community
that it is a GOOD thing if such a file has errors. Anyone using #! or #!/
as a comment in the MIDDLE of a scheme program is going to attract similar
attention from the scheme community.

> > How hard would it be to write a perl program to transform everyone's
> > DSSL programs to the new syntax?  Seems like changing that in the
> > DSSL implementations themselves would involve little more than a
> > search and replace anyhow.
> 
> That is not going happen.  Just accept it.  No-one is going to
> be interested in doing that to solve a non-existant problem.

Anyone who writes for unix is ignoring a lot of peer pressure from
the Microsoft community anyhow. The purpose of following the ISO is
to stay as broadly compatible as possible, not because the ISO are
any particular authority (their standards are not even `free' by the
definition associated with `free software'). Never the less, causing
essentially good code to break without good reason is just bloody minded.

	- Tel