Feature request: include another file

[ZeroRin]

I'm currently writing some logics and noticed that I had to copy and paste a set of functions across different logic files. It's not so convenient and can be disastrous when I need to modify one of these functions (had to manually modify it in every file).

I wish we can have a sort of #include my_lib.mnd thing to make codes more reusable. as far as i'm concerned inserting the content of the target file into the position where #include happens should be good enough

[cardillan]

Yes, this would be very useful.

I'm currently planning a lot of changes to Mindcode (see #142), and supporting multiple source files in some form is one of the features I want to add. Unfortunately this will probably take considerable time to implement. I'll post a first draft of this functionality in #142 shortly; I'll be grateful for any comments or suggestions.

A workaround might be possible, though. Let's say that you have your library function in the file my_lib.mnd somewhere. If you're on Windows, you might create a batch file which would append the library functions to whatever source file you want to compile, something like this:

@echo off
type %1 > %~n1.tmp
echo. >> %~n1.tmp
type my_lib.mnd >> %~n1.tmp
java.exe --enable-preview -jar mindcode.jar cm %~n1.tmp %2 %3 %4 %5 %6 %7 %8 %9

(the %~n1 is the first argument on the command line minus the file extension). You'll need to provide correct (full) paths to java.exe, mindcode.jar and possibly my_lib.mnd. You might also add all the other parameters you always want to use when compiling (e.g. -c).

You'll save this into a batch file, say compile.bat, and to compile a file, you'll run compile.bat source.mnd. What the batch file does is this:

1. It copies your source code to a file with the same name and extension .tmp
2. It adds an empty line to the tmp file (just in case your original source code doesn't end with a newline)
3. It appends your library file to the tmp file.
4. It runs the created tmp file though the compiler.

Let me know if you need more help with this.

(The same can be done on Linux, probably even easier, but I'm not a Linux guy.)

[ZeroRin]

This workaround make sense. I managed to write a script that accept arbitrarily number of files and concat all of them before compiling. thanks for the tip.

[cardillan]

The latest release, 2.2.0, has a command-line argument -a for appending additional source files. It should be superior to the workaround, since many (unfortunately not all) compilation error messages include name of the file where the error occurs, line numbers in these messages aren't offset, and the debug output activated by -u source also shows the corresponding source file:

Final code before resolving virtual instructions:

    0:  set __sp 0                                                   a.mnd: allocate stack in cell1
    1:  set __fn0_n 27                                               a.mnd: print(fib(27));
    2:  callrec cell1 __label0 __label1 __fn0retval                  ...
        label __label1                                               ...
    5:  print __fn0retval                                            ...
    6:  end
        label __label0                                               lib.mnd: def fib(n)
    7:  jump __label3 greaterThanEq __fn0_n 2                        lib.mnd: if n < 2
    8:  set __fn0retval __fn0_n                                      lib.mnd: return n
    9:  return cell1                                                 ...
        label __label3                                               lib.mnd: if n < 2
   12:  push cell1 __fn0_n                                           lib.mnd: fib(n - 1) + fib(n - 2)

This currently works as a proof-of-concept of parsing the source files separately and joining the resulting parse trees for later compilation and will ultimately be replaced by modules (#149). I'll be grateful for any feedback.

[cardillan]

In 2.6.0 there's a new require keyword, which allows "including" another source file (or a system library). Attention needs to be paid to possible name clashes of function and variable identifiers, as Mindcode doesn't support separate namespaces yet, but nevertheless this should allow building custom libraries for Mindcode projects.

[cardillan]

Closing, as the current implementation allows including another file in the compilation. What needs to be solved separately is the problem of namespaces.