Change current importing process

[Lartu]

Right now, when you import a .ldpl file into an LDPL project all the files get compiled one after another sequentially. This means that if I import file1, file2 and file3, variables in file 1 will be declared first, then its code will be compiled, then variables in file2 will be declared, etc. In the end this means that if in file1 I want to use a variable or a sup-procedure declared in file2 this will be impossible.

I think that probably the best way to fix this would be to make a big file copying all three DATA sections together and all PROCEDURE sections together and then compiling.

[Lartu]

This has been partially fixed, as now you can declare a sub-procedure after you call it.

I think that probably the best way to fix this would be to make a big file copying all three DATA sections together and all PROCEDURE sections together and then compiling.

However this hasn't been applied yet and I guess this is the way everything should be done (without, of course, removing or altering forward calling of sub-procedures).

[Lartu]

I was thinking about the importing process we had planned, @dvkt, maybe we could keep variables local to each file but export sub-procedures in a file to other files. So if I declare i in a file it won't step over other is declared within other sources, but I'll be able to access functions in other files. Maybe we could even add PRIVATE SUB-PROCEDURE and PRIVATE EXTERNAL SUB-PROCEDURE statements so that some sub-procedures stay private to the files they are declared in.

What do you think? This wouldn't be too hard to implement, actually.

[dgarroDC]

I think global variables are useful when you use a library to send it values (this wont be necessary if we implement parameters I guess) or get value. And if you want to use some i variable in your library code, it could be local to a sub-procedure if we implement #113.

I'm not sure if we need private sub-procedures, to avoid collisions you can use the <lib>.<subprocedure> notation.

Regarding the importing process, what about just passing one file to the compiler and use an IMPORT statement in your program if you want to import files? You could specify some relative path to a LDPL/C++ source file or even a library name and let it handle to a package manager in a future (we should call the packages briefcases btw (? ). The files you import would be compiled first so you could use its sub-procedures or global variables in your file, and the imported files wouldn't be able to use yours (and that's ok, it would be messy otherwise).

[Lartu]

I think global variables are useful when you use a library to send it values (this wont be necessary if we implement parameters I guess) or get value.

OH THAT IS TRUE HOW COULD I FORGET THAT

And if you want to use some i variable in your library code, it could be local to a sub-procedure if we implement #113.

This is true.

Regarding the importing process, what about just passing one file to the compiler and use an IMPORT statement in your program if you want to import files?

Yes, that is planned since LDPL 1.0 but was never implemented 😞

You could specify some relative path to a LDPL/C++ source file or even a library name and let it handle to a package manager in a future (we should call the packages briefcases btw (? )

I actually am working on a package manager for LDPL right now. Can't say when it (if ever) will be finished, but I was thinking on calling it LPM (LDPL Package Manager). I love the briefcases name hahaha.

The files you import would be compiled first so you could use its sub-procedures or global variables in your file, and the imported files wouldn't be able to use yours (and that's ok, it would be messy otherwise).

Hmmm that is nice, I like that!

My only problem with the current import process (aside from the fact that you cannot import something from the source file itself by calling something along the lines of IMPORT) is that if I declare the variable result in fileB.ldpl and then try to use it from fileA.ldpl (say, to call a sub-procedure with a parameter); if I compile the source like this (for some reason):
ldpl -i=fileA.ldpl fileB.ldpl
When LDPL is compiling fileA.ldpl it will try to access the not yet declared variable result and fail.

There are many ways to fix this. Maybe we could first compile all the DATA sections and then the PROCEDURE sections, maybe we could allow forward calling like I did with the SUB-PROCEDURES (if you call an undeclared sub-procedure its name is added to a stack in the state object; if LDPL has compiled every file and hasn't found a declaration for that SUB-PROCEDURE, it raises an error). This would fix the problem.

Also, now that I remember, another problem with importing would be that the file is parsed after all the included files are loaded. We should maybe parse the entire files before compiling and import all files noted in an IMPORT section or something (the order doesn't matter if we allow forward calling of sub-procedures and variables) and compile everything the way we do now.