3 ms·

Doesn't the (necessarily loose) coupling of executables with source files create its own challenges? Or does it track the object file too, in which case we have

by ky3 7y ago

Doesn't the (necessarily loose) coupling of executables with source files create its own challenges? Or does it track the object file too, in which case we have 3 files, not 1, to manage simultaneously? The benefit of scripts is that each file is a self-contained single source of truth.

kazinator 7y ago
In the case of one .c file, there doesn't have to be an object file; you can go straight to executable "cc prog.c -o prog". Python implements a caching scheme for .pyc files; maybe it's not a scripting language ... If I were to venture an opinion on why C (in its usual implementations) is not a scripting language it would be: - no interactive prompt (REPL). - no reloading of code (other than clumsy, fragile, platform-specific shared lib mechanisms). - no execution of "top level forms": a program's entry point is a specific function (main on hosted implementations). When, e.g., Lisp code is compiled, the effect of loading the compiled file is still the same as of the source file: the top-level forms (now in a compiled form) are executed one by one. (What's a "script"? A file with instructions to be run one by one.) - no late binding; in fact, no program at all, unless all external references are satisfied. Scripting languages can run code that contains references to unknown global variables, or calls to unknown functions. These can be loaded late.
- TeMPOraL 7y ago
  > When, e.g., Lisp code is compiled, the effect of loading the compiled file is still the same as of the source file: the top-level forms (now in a compiled form) are executed one by one. (What's a "script"? A file with instructions to be run one by one.) Fun fact: the SBCL implementation of Common Lisp actually adds a shebang to its compiled, binary Lisp files, so you can compile your Lisp script and then execute it from the shell.
  - kazinator 7y ago
    My TXR Lisp adds a shebang to the compiled file, if the source file has one. $ cat > foo.tl #!/usr/bin/txr (pprinl "hello") $ txr -e '(compile-file "foo")' hello $ cat foo.tlo #!/usr/bin/txr (5 0 nil) ((2 3 #b'0200012400000004 02000010' #("hello") #(usr:pprinl))) If the source file doesn't have a hash bang line, the one isn't output. You'd think SBCL wouldn't need this sort of thing since it compiles to native code?
    - kazinator 7y ago
      I just improved this tonight. If the original program is unsuffixed, and so its hash bang line uses the --lisp option to say "treat this as Lisp source" that option is translated to --compiled, so that if the compiled file is also unsuffixed, it will be properly treated as compiled.

by ky3 7y ago

kazinator 7y ago

In the case of one .c file, there doesn't have to be an object file; you can go straight to executable "cc prog.c -o prog". Python implements a caching scheme for .pyc files; maybe it's not a scripting language ... If I were to venture an opinion on why C (in its usual implementations) is not a scripting language it would be: - no interactive prompt (REPL). - no reloading of code (other than clumsy, fragile, platform-specific shared lib mechanisms). - no execution of "top level forms": a program's entry point is a specific function (main on hosted implementations). When, e.g., Lisp code is compiled, the effect of loading the compiled file is still the same as of the source file: the top-level forms (now in a compiled form) are executed one by one. (What's a "script"? A file with instructions to be run one by one.) - no late binding; in fact, no program at all, unless all external references are satisfied. Scripting languages can run code that contains references to unknown global variables, or calls to unknown functions. These can be loaded late.

TeMPOraL 7y ago
> When, e.g., Lisp code is compiled, the effect of loading the compiled file is still the same as of the source file: the top-level forms (now in a compiled form) are executed one by one. (What's a "script"? A file with instructions to be run one by one.) Fun fact: the SBCL implementation of Common Lisp actually adds a shebang to its compiled, binary Lisp files, so you can compile your Lisp script and then execute it from the shell.
- kazinator 7y ago
  My TXR Lisp adds a shebang to the compiled file, if the source file has one. $ cat > foo.tl #!/usr/bin/txr (pprinl "hello") $ txr -e '(compile-file "foo")' hello $ cat foo.tlo #!/usr/bin/txr (5 0 nil) ((2 3 #b'0200012400000004 02000010' #("hello") #(usr:pprinl))) If the source file doesn't have a hash bang line, the one isn't output. You'd think SBCL wouldn't need this sort of thing since it compiles to native code?
  - kazinator 7y ago
    I just improved this tonight. If the original program is unsuffixed, and so its hash bang line uses the --lisp option to say "treat this as Lisp source" that option is translated to --compiled, so that if the compiled file is also unsuffixed, it will be properly treated as compiled.