Import incorrect file does not produce a warning

Monkey Forums/Monkey Bug Reports/Import incorrect file does not produce a warning

Shagwana(Posted 2015) [#1]
A monkey program that imports a non existent file does not throw a warning/error.

eg..
Strict

Import mojo
Import this.file.dont.exist

Function Main:Int()
	Print "running"
	'Print test()    'This rightly flags an error!
	Return 0
End Function


Originally I discovered this because I was trying to call a function inside a file that I failed to import correctly. The result was the function was flagged as the problem, would have been better if the Import issue above was shown first!


ImmutableOctet(SKNG)(Posted 2015) [#2]
It does not throw an error because that is standard behavior. I agree with the sentiment that the warnings should be better, as you basically have to debug 'trans' to see what's missing. Other than that, you're saying that Monkey's compiler is doing its job. If the file doesn't exist, the module doesn't. The compiler just needs clearer warnings. I myself use the "optional module" behavior of Monkey all the time, as I have all of these, and I can't expect every single user to have every one. I have a repository that users can recursively clone for the primary modules, but that's still a lot to download. To this same effect, if someone just wanted my vector module, they could just grab that and 'util'. They wouldn't need the rest, because 'vector' only needs functionality described directly by 'util'. There's also a number of fixes for the standard "box" classes that I've added, and they generally need my 'boxutil' module. The big thing here is that 'boxutil' is optional. My 'retrostrings' module pretty much needs my 'stringutil' module (At least for the "extensions" to the command-set), and so on. The only thing 'trans' needs is better warnings, and maybe an "Optional" keyword for imports, but that's pushing it.

One of the major reasons I got Mark to change the preprocessor behavior, was for things to be done as they are imported. Sure, it's not perfect, but it gets the job done pretty well.

Here's an example of how I handle this, and generally speaking, it's what Mark does with some of his modules:

"main.monkey" (Build file):


"x.monkey":


As you can see, this also makes things configurable from the imported module's side. For example, you could have 'x' rely on external components, and thus, say it's unavailable if the native files aren't available. You could also make the external portion an optional thing, and use a target-check to see if it should be set to 'True'. But on top of that, you can add just one more check, and you can make it so the user can force native/external bindings to be off (Or technically, on). Here's my 'imageencoder' module, it does this.

The only issue I see with this module is with small encapsulated projects ("Local" imports), but that's why I think the compiler needs better warnings.


marksibly(Posted 2015) [#3]
> A monkey program that imports a non existent file does not throw a warning/error.

I think this really should cause an error!

Will it break some existing code...?


Samah(Posted 2015) [#4]
@marksibly: Will it break some existing code...?

If it does, then it's code that should have broken in the first place!


ImmutableOctet(SKNG)(Posted 2015) [#5]
@marksibly: Unless you add a keyword for declaring an import as optional, that would break a lot of my modules. I don't expect someone to clone all of my modules if they only want one or two. Likewise, changing this to an error would make it so there is literally no way to know if a module exists. This would also mean that some of my modules can't import optional extensions/back-ends automatically. My 'retrostrings' module does this. There isn't much of a reason to make it cause an error. A warning on the other hand, that's ideal. The compiler already does this currently, but the warnings aren't very descriptive. Do you not remember this thread? That bug has been fixed already, but this was one of the reasons it needed to be fixed. If you're going to change it, you'll need to give an alternative.

@Samah: What's your argument for this?

EDIT: I think I may have misinterpreted what you were saying, Samah.


Shagwana(Posted 2015) [#6]
I see ImmutableOctet predicament, yes a 'OptionalImport' keyword would be needed as this is functionality that can be very useful.


marksibly(Posted 2015) [#7]
I 'fixed' the import issue so that #vars set in an imported file could be used by an importing file. I didn't fully appreciate what you were up to!

I'm not opposed to having a mechanism that supports optional imports, although I think I'd prefer something like this (off the top of my head - it just seems more generally useful)...

#If ModuleExists( blah.etc )
#Print "blah.etc module is present"
Import blah. etc '#Import is starting to look nicer...
#Endif

I do think a 'plain' Import of a non-existant module should fail though.


ImmutableOctet(SKNG)(Posted 2015) [#8]
I'm completely for either a 'ModuleExists' "command" (With the preprocessor), or an "optional import" keyword. Both solutions would be easy to patch in to my own code (Preprocessor variables are already "abstracted" from this). I personally don't see much of an issue with "porting" my own code to a "ModuleExists" setup (Though honestly, having a keyword would reduce boilerplate code). I just don't want to have no option but to fork Monkey. As long as I can easily handle optional modules, I don't see a problem with changing it. If you do add a way to check if a module exists, it shouldn't be hard to make a "request" version of 'Import' that acts as a macro for doing it manually.

Just curious, but how was it not completely obvious what I was doing? I showed you a full example illustrating the compiler's behavior, and referred to this kind of setup. My example even used the same preprocessor structure.

So, how would "#Import" work, then? Would it basically be an automated check against "ModuleExists"? If so, that's basically what I'm looking for, and I think you should add it.


marksibly(Posted 2015) [#9]
> Just curious, but how was it not completely obvious what I was doing?

I vaguely remember you posting some sample code that had nothing to do with optional modules, although I may be wrong. Anyway, that's what I fixed.

But I also knew about the general issue of preprocessing occurring before imports for a while and had been considering doing something about it anyway.

The 2 are entirely separate issues IMO anyway.

> So, how would "#Import" work, then?

The same as plain Import - it just makes it explicit that #Import is now part of preprocessing. But I probably wont do anything here.