Define an include-file

[reks99]

Hi,
as an enhancement I suggest the possibility to name (select) a file, which may be included in the generated code - for example a header file (with more includes) or a file for the import of required modules in python, perl,...
In Bash the file should be included with ". filename" after the shebang. Also in Python and Perl it can be included after the shebang.
This option might be set in the "export" option dialog.

What do you think about this.
Fine regards
Rolf

[codemanyak]

I have to admit that I haven't succeeded to get a clue what exactly you are proposing. Could you please elucidate your request with some examples?

[reks99]

Hi
my idea was, that in the export dialog you can select a filename and this filename should be included in the generated code.
For example: the filename is "prog.conf" then the generated bash code starts with:

#! /bin/bash

. prog.conf

Or in C-Code generation the filename might be "myincludes.h"
Then the generated c-code starts with the line

#include "myincludes.h"

Or in Python - the filename might be "mycode.py" which can have more imports.
The generated python code starts with

#! /usr/bin/python

import mycode

As far as I know, java also allows the include of libraries, which will be used in the code.

Hope that makes it more clear.
Fine regards
Rolf

[codemanyak]

Okay, thank you, this makes your intentions a little clearer.
But do you really think of it bringing reasonable benefit? I mean, this kind of include is not only language-dependent but also project-dependent, i.e. the set of modules / libraries / headers etc. to be included varies with every algorithm you write. Hence, it doesn't make much of a difference in user efforts whether to specify it in a (rather ephemeral!) export option or to insert it directly in the obtained export file. This is at least my impression. Well, some people may maintain their favourite one-size-fits-all standard header including all frequently used stuff.
For the set of "built-in" procedures and functions, I'm planning some more sophisticated support on export (including the appropriate import directives) anyway, as soon as the intended expression parser prototype is ready. (This will also bring several improvements for the BASH export in particular as deriving expression types is supposed to reduce guesswork.)
You see, I'm still not convinced that your proposed enhancement makes sense.

[reks99]

Hi,
of course this is not the perfect solution for everybody because nsd itself and the resulting export problems will never be a perfect gui-programming tool like a modern ide.
And of course nobody will be pushed to use such an option - but he can, if it fits (partialy) his work style.
And last, but not least, it seems for me an easy to implement feature.
Fine regards
Rolf

[codemanyak]

And last, but not least, it seems for me an easy to implement feature.

To insert a predefined line into the exported code is a trivial task, of course, but what about the configuration? Since the trinket to be included or imported would be different for every target language, we would need a control for every single export language (currently 12 if we neglect StrukTeX here). Moreover, these controls would have to be set up dynamically, according to the plugin character of the generator set...
That's why I'm in doubt about the balance beween benefit and efforts.

[codemanyak]

@reks99 Did you actually want literally to repeat yourself?

[codemanyak]

So, this is my draft now - the export options dialog would get a second tab where all the configurations for language-specific include / import / use directives may be placed as comma-separated enumerations:

The tooltips of the text fields would give some short explanation what it is meant to be.
The generators have different patterns how to form the language-specific directives from it. C and C++ would e.g. use an #include directive enclosing strings not delimited by angular braces in quotes, Java would form import ...; lines, Perl would put use ...; etc.
@reks99
I hope that meets your intentions (though I still doubt that many users will find this helpful).