Re: Question

[Bob Proulx]

Robert Elz wrote:
> Bob Proulx wrote:
> > However this difference in philosophy does not change the technology
> > that creating a compiler for an interpreted language is very hard.
> > Maybe impossible.
> 
> No.  Not impossible, not even all that difficult, just in this case,
> not all that beneficial either.   (There are lisp compilers around for
> example.)

Lisp is often used as the canonical example.  :-)

> It has been a long time since I looked inside bash, and I remember none
> of it, but I maintain another shell (currently anyway) and it most
> certainly contains a compiler - it just never emits the compiled code
> into any external form, it remains internal, without that it would be
> far too slow.   While bash is slow, it isn't that slow (ie: it is fast
> enough for its purpose) so I assume it does the same (or similar.)

Stephen Bourne himself thought about writing a shell compiler.

  
https://www.computerworld.com.au/article/279011/a-z_programming_languages_bourne_shell_sh/?pp=3
  "And the other thing I would like to have done is written a compiler
  for it.  I got halfway through writing a shell script compiler but
  shelved it because nobody was complaining about performance at the
  time."

> What is relevant though is that compilers for languages like these
> rarely generate machine code that is directly executed, because of the
> point made earlier that code can be generated on the fly (the canonical
> case is:
>       read var
>       eval "$var"
> ) the resulting binary must contain the complete compiler, so it can

Thank you for mentioning the canonical example above.  I almost
mentioned it.  But decided not to go there.

> handle cases like this - so the usual course of action is to compile into
> an intermediate form, then interpret that (rather than directly interpreting
> the untouched input format).   This also keeps the whole thing portable,
> so no variation (beyond writing portable code in the first place) is needed
> to make the whole system run on different architectures.

Of course that is a description of the JVM too.

However then it has all of the user interaction benefits of working
with a compiler and all of the performance benefits of using an
interpreter.  It is definitely a compromise tradeoff. :-(

> The reasons that no-one has bothered to do something more than what is now
> done for sh, is that the benefits just aren't there - not that it is
> impossible, or even very hard.   As was noted, with any normal shell script
> (there are exceptions) almost all the time is used by the utilities that
> the script runs, not by the script itself, so in many cases, taking the
> extra time to produce a compiled external form, then read it in again every
> time it is run would not usually lead to any net execution speed increase.

Agreed.  It just doesn't seem useful for the shell.

Note that 'go run golangprogram' is extremely fast, all things considered.
I'm impressed by it anyway.

> Now I believe that was not the objective here, which was just to make the
> code harder for others to read/modify/steal

In which case working with a language that has good support for
compilers from the start is probably a better strategy.

> - unfortunately that would not
> really work either.  Along with compilers come disassemblers (they are needed
> if for no other reason than to help debug the compiler - the shell I maintain
> has one built in - it is not usually included in the versions people use,
> but can be, just by recompiling it) and for these kinds of languages, they
> are usually very good (aside from white space, comments, and ordering of
> redirects relative to the rest of the words on the command line, the one I
> maintain produces essentially identical output to the script input - it might
> occasionally leave out redundant useless syntax that was in the original.)

Agreed.  Obscurity is not true security.  But it does keep the casual
observers out.

> Now to the philosophical ... I agree with the aims of free software, but
> I believe that should be interpreted correctly - that is, if software is
> free, it should impose no restrictions at all upon is recipients, which
> includes hidden "you should reciprocate and make your software free too"
> (which is beyond what GNU actually expects I believe, but many people
> seem to - which really means that those people are not really offering free
> software, they're just bartering, I'll give you mine, you give me yours ...
> that's just commerce.)

Libre Free Software under the GPL is not without cost.  The cost, said
way too simply, is to use and share alike.

Many people in the community have worked very hard to contribute to
the pool of free software.  People benefit from having this pool
available.  I don't think it is bad to ask people using this pool of
free software to make derivations from it also available in the pool.
It is somewhat like any shared thing.  Say using a shared kitchen.
You can use the shared kitchen but please leave it in a better state
than you found it.  But remember this only applies to derivations.  If
you build your own house then you can do anything you want in your own
kitchen.

> But any restrictions on the recipient mean that the software is not
> really free, and that includes nonsense like requiring users to
> redistribute the sources to anyone who wants it.  That's not
> freedom, that's an obligation (serfdom - you have to do my work for
> me.)

That is simply nonsense.

Bob