gxc -exe can delete source code

[lassik]

$ cat > hello.scm
(define (main) (display "Hello") (newline))
$ cat hello.scm
(define (main) (display "Hello") (newline))
$ gxc -exe hello.scm
*** ERROR IN gxc#compile-exe-stub-module -- Syntax Error
*** ERROR IN ?
--- Syntax Error at compile: module does not export symbol
... form:   hello
... detail: main
$ cat hello.scm
$

[belmarca]

I can reproduce on Gerbil v0.16-DEV-160-g680e1fa3 on Gambit v4.9.3 and Linux #1 SMP Debian 4.19.67-2 (2019-08-28) GNU/Linux.

[belmarca]

Looking at https://github.com/vyzo/gerbil/blob/master/src/gerbil/compiler/driver.ss, the compiler expects your code in a .ss file, and writes to a temporary .scm.

This will work:

hello.ss

(export main)
(define (main) (display "Hello") (newline))

The code shouldn't overwrite an existing file.

[belmarca]

@vyzo How do you want the driver to handle this? If the file or directory already exists, it should raise. But maybe to avoid confusion the generated extension could be .ss.scm instead of just .scm?

[lassik]

Thanks for looking into this @belmarca :) What is the rationale for using .scm files as tempfiles? .scm is a very common filename extension for Scheme source in general, so writing to any .scm file is liable to overwrite user code (unless it's an obvious tempfile name like .tmp.scm).

[lassik]

Do you mean this part in driver.ss:

  (let* ((output-bin (compile-exe-output-file ctx opts))
         (output-scm (string-append output-bin ".scm")))

Unix executables generally have no filename extension, so I guess outputting to an executable called hello would create hello.scm.

[belmarca]

Yes a quick fix would probably be to use .ss.scm instead of just .scm but no matter the extension, no file should be overwritten if it already exists.

As I said I will let @vyzo give his opinion since this touches a core part of gerbil. I don't feel comfortable sending a PR before he makes a suggestion.

[lassik]

I would recommend treating both .ss and .scm as user code extensions in general and treating them identically (as far as possible). .scm is very standard among R7RS programmers in particular, so it looks like user code in a directory listing. To people coming from other Schemes who don't know what it is, .ss.scm it looks like a source file that for some reason has both of the standard extensions for Scheme source code instead of having only one them. It doesn't look like a tempfile or an auto-generated file. Something along the lines of .gen.scm or .gen.ss would be more obvious.

[vyzo]

Yes, this is problematic. The compiler generates an .scm file for compilation with gsc, which may override the scheme source.
We can't name with a double extension because the executable will be wrongly named; perhaps a different extension will work too with gsc though.
Perhaps the correct behaviour is to error out if the target file exists.

[vyzo]

Actually we might use gsc's -o option to name the output file explicitly regardless of extension.

[lassik]

Would it work to create a subdirectory to store all the generated files?

[vyzo]

Doesn't sound like a great idea.

[vyzo]

I think we can simply use a different extension for the executable stubs -- we can try with .scmx (for scheme, expanded) and see whether gsc is happy.

[lassik]

A different extension is good enough.

Unix also has no trouble with multiple extensions like .tar.gz, to something like .expanded.scm would work fine. Windows can also handle those, but I'm not sure whether they look funny in the user interface (Windows Explorer).

[vyzo]

#330 fixes by using the .scmx extension for executable stub files.

[vyzo]

Sorry for the late turnaround, I finally got around fixing this.

[lassik]

Thank you!