Request : imports allowed anywhere

EDIT: This can be considered solved. Or rather, change that to a request for a documentation update.

Is there a good reason why imports have to be done at the very beginning of the program?
I mean it's not like BlitzMax compiler is done in one pass or anything.
I can reference in my code functions or types declared later on, but I can't add an import at the point where I actually need it???
Quite frankly this is getting on my nerves.

This is all the more annoying that building modules has been regarded as something for "advanced" programmers (even if there's not much to it), in that it doesn't come out of the box (requires to install MINGW on windows).
Those that want to code out of the box and not bother with building modules just use includes instead.
But these includes *cannot* do the import they require, or else the compiler complains that an import must be done at the start of the program. You'll then have to let the main program do the import for you (oh god, that's modular programming...) or make it a module just to satisfy the compiler.
And let's be clear, even "advanced" programmers are not always willing to make a module out of a twenty lines long code snippet, seriously.

So the question is:
is there any rationale behind this?
Given that even a stupid preprocessor could do the trick (moving all the imports at the very beginning), I doubt it, but I may be biased.

Can we remotely hope a change in this behaviour?

As a bonus question : am I alone worrying about this?

Thanks.

Yep, so you can see faster which ones are used.

NOt the same question, but similar
http://www.blitzmax.com/Community/posts.php?topic=59760#666272

That's not a good reason. This kind of things are best to be left to the discretion of the programmer.
By the same reasoning we should only be able to declare local variables at the start of a function. But that's not the case. That's the very same issue, I don't see why a different rationale should apply.

In the early days, a lot of programming languages mandated to have local variables all declared at the start of a function. And a lot of people thought it was better that way, more "organized". Until finally most people realized the benefits of locality: a local variable, used locally (doh) should be declared as close as possible to its use. Hence the change regarding this rule from C to C++.

And my question is more about a good "technical" reason.

Where does "import" imply "module" ?

I have no problems importing .bmx files in a program that are not modules.

minGW is only required because WINDOWS doesn't have gcc compiling "out of the box".
If you want to look at it that way, both Mac and Linux require you have a development environment installed too - for *any* compiling.

It would have been better had Include not been available at all - but I see how BRL used it so that Blitz3D coders etc wouldn't have to learn something "new"... ;-)

You should also have a word with Sun, while you are at it, and tell them that Java should allow imports anywhere in the code too. Damn those Sun people - they think they know everything... tsk.. pah...

If you insist on using Includes, which seems lazy to me (although others seem to swear by it), then you need to live by the consequences.
Why anyone would want to Include all the .bmx files and recompile all 15,000 lines of their app everytime they change a character in one of the files, is beyond me.
It seems silly that rather by using Import, one can cut compile times down to almost nothing, don't you think?

But then, if your .bmx files are only 20 lines of code, using Include shouldn't take too long to compile....

You can please some of the people some of the time....

;-)

Because the compiler needs to know the entire interface topography before it can parse the source code?

I know. ;)
If you read the thread I linked to you will see I gave the same arguments as you 10mths ago, and it was promised that some change to import/include would be looked into.

What I wanted, was either a way for Superstrict to be ignored in includes, or imports to be placed Anywhere.

OK, then I'm lazy. That's fine to me. Lazy bones make good programmers. They're better at factorization.

You missed the point I'm afraid. I want to be able to include files that do imports (whatever it imports). I just can't.

But hey, I don't care if anyone finds it usefull ot not, I just don't get the point of explicitely forbidding it.

If you say why should I be able to do it, I'd like to say: why not? And in front of that I see good reasons to *allow* it. I'm not saying it will change the face of programming in BlitzMAx, it will just make my life easier from time to time.

Except I can actually import at the start of every java file...
And it wouldn't make sense to import inside a class, right? ebcause every pice of code in java is inside a class, which isn't the case at all in BlitzMax. So maybe I'd need a better phrasing: I want to be able to put an import everywhere at the global scope.
In addition, making a module requires to have it in the mod directory. That's annoying enough that I don't want to do it for little code snippets. That's my main concern personnaly. If I could have modules in my own project's folder then that would be all fine.

And you missed one thing again: the "20 lines" part. I make modules when it makes sence, but for little code snippets I'd rather not. Is it SO much beyond you?

Nope. How the hell can I call a function defined later on then?

Apparently..
I just don't understand what the obsession with making modules and using Imports is all about.
If you want to Import some code, it doesn't need to be in a module.
afile.bmx

SuperStrict

Import "mystuff.bmx"

mystuff.bmx

SuperStrict

' ... some stuff

Modules are only useful if you want to package up some library or such... otherwise you can get by fine with simply Importing a .bmx when you need it.

Possibly or there's a lot of confusion.
What is the actual problem/question you're asking?
If you import a module/file it might contain 20 functions which you use in 20 different places. Where would you want to put the import statement in that case?

The import statement needs to be at the very start of the program. If I include a file which does an import, obviously there's a syntax error in the present state of the compiler.
The problem is with "mystuff.bmx" here. You need an example, so here it is:

'Main program
Import bla.bla
Import bla.bla2
Include "mystuff.bmx"

'Mystuff.bmx
Import some.module.mystuff.really.needs
Function MyFunction()
End Function
...

OK, right now this can't work because "Import some.module.mystuff.really.needs" doesn't end up at the start of the program when the code gets expanded in the include statement.

If I want i to work, solution 1 is:

'Main program
Import bla.bla
Import bla.bla2
Import some.module.mystuff.really.needs
Include "blabla.bmx"
Include "mystuff.bmx"

'Mystuff.bmx
Function MyFunction()
End Function
...

That is, move the import in the main program. Ugly.

Solution 2 is:

'Main program
Import bla.bla
Import bla.bla2
Import some.module.mystuff.really.needs
Import "me.mystuff"
Include "blabla.bmx"

'Mystuff.bmx
Module me.mysuff
Function MyFunction()
End Function
...

That is, make it a *module*.
It solves the problem because then both files are compiled separately, with in both cases no more import statement that appears in the "wrong" place.


Of course here a simpler solution is to simply move the include up, like this:

'Main program
Import bla.bla
Import bla.bla2
Import some.module.mystuff.really.needs
Include "mystuff.bmx"
Include "blabla.bmx"

'Mystuff.bmx
Module me.mystuff
Function MyFunction()
End Function
...

But obviously that won't work for more than 1 single include file.

But why can't you use :

'Main program
Import bla.bla
Import bla.bla2
Import "mystuff.bmx"   ' Import instead of Include

'Mystuff.bmx
Import some.module.mystuff.really.needs
Function MyFunction()
End Function

is what I don't understand... because that will compile without issue as far as I can see.

I guess I don't see what the fascination is with using "Include"...

Just post it as bug and Mark will response.

...

Actually Brucey, you're right. Totally right. I didn't really got the

Import "mystuff.bmx"

part until just now.
That's right, I only just realized you can do that and it will really work just like a module import.
As the fact of not being able to keep my source files in my own directory was my inly personal concern (I'm not concerned by the out of the box thing), it perfectly solves my problem. And actually it solves the out of the box thing too.
So, sorry for the fuss.
For what it's worth, I had done a test to check if the Import "bla.bmx" made any change, and it failed. Obviously I must have done something really stupid. And the uncommon idea of "importing a source file" didn't help to realize that.

I just wished the docs were anywhere close to explicit about this. It would have required a single line in the docs to save me from the trouble.

And I don't even know if the code will actually be recompiled everythime. I'll have to test for curiosity sake (though I don't care).

There has never been any fascination. Give me the ability to remove the syntax error on the import statement AND to keep my files in my own folder and I'm happy. That's precisely what I got, so everything's fine.

Using Import, only the files that you change will be recompiled. Everything else will only be linked into the app, saving you lots of time if there is a large amount of code in separate .bmx's.


Glad you solved your problem.

:-)

Unfortunately, it seems that it IS actually recompiled everytime.
Apparently when importing raw .bmx files, each one is recompiled everytime I compile the top file, even with no code modification. That was more or less what I expected (or feared).
Too bad, but I can easily live with it. Though the net compile time seems to be worse now, which seems quite logical actually : the total amount of source code to compile is the same but with the uncompressible processing (process creation, initialization etc) being multiplied several times and additional linking required.

Maybe I have some weird setup problem that prevents the normal behaviour to work correctly. Please let me know if you can confirm that the imported raw .bmx files are not recompiled everytime. Thanks.

Not if you have quick build turned on.

And if it did, when you use BLIde you loadin the import once, tell it to be built, and then it wont be rebuilt if quick build is on

Import is basically a compiler directive to link object files in to the main file. That's why it works with either BMX files, modules, C, whatever. It just adds a file to the link step. You're lucky you don't have to specify them in a command line configuration like in VC++.

Ahem, I know what an import is. But you actually import compiled code, not source files. That's what seemed disturbing about the idea of "importing a .bmx file". Though I now like the way it's done in BlitzMax.
But thank you. And yes, I am indeed glad not to have to specify it on a command line.

@H&K: Thanks, I knew it was probably a stupid thing. It was bound to happen, until recently I had not done any real coding in BlitzMax since the day I bought it.