Chapel Developers --
Continuing my rash of proposals this week...
For some time now, certain users and developers have grumbled about the
fact that there is no way to split a module's contents across multiple
source files.
As motivation, imagine that we want to create a GSL module that wraps the
GNU Scientific Libraries and that some subset of the 16 subject areas that
it covers are represented as sub-modules. It seems artificial/overly
constrained to require all that code to exist in a single file. Or,
imagine that a development group would like to carve a Chapel module
they're working on into several files, simply to split pieces of the code
base between different developers, or to follow the "one function per
file" organization that some teams seem to like to take. These seem like
reasonable requests to me and, conversely, saying that modules must be
defined entirely in single files feels to unnecessarily constrain code
organization for no good reason.
A few times in the past, I've taken a stab at breaking the current state
by adding an 'include' statement, but ran into challenges due to the
organization of our parser, the fixes for which were larger than I wanted
to take on at the time.
With Mike's recent efforts to refactor the parser into a "pure push"
parser to support an interactive Chapel environment, and our related
decision to commit ourselves to bison 2.5+, our guess is that adding
support for splitting a module across multiple source files becomes much
simpler.
To that end, I'd like to propose that we support a new statement in the
language:
include "<filename>";
which would have the effect of making the lexer switch to scanning
<filename> until it hits EOF, at which point it resumes with the next
statement in the original file. I believe the implementation strategy can
be thought of as maintaining a stack of lexer state variables. The net
effect can be viewed as being equivalent to cutting and pasting the
contents of <filename> into the current file in place of the include
statement.
This could be viewed as being similar to cpp's #include, but it's
different in that I'm proposing it be part of the language rather than a
pre-processor. One impact is that one cannot 'include' code at points
other than the statement level. I.e., it would be a syntax error to say:
var a =
include "<filename>";
In this sense, the proposal is probably more like LaTeX's \input statement
-- part of the language that only works at a certain level of the program
structure but nevertheless supports many common/useful cases without
requiring a preprocessor to be brought into the mix.
Comments? Concerns? Counterproposals?
(Note that in spite of the close-ness in timing and syntax, this idea is
reasonably different from the 'use'/dependences mail I sent out last
night, in that this one is about breaking Chapel code across multiple
files, and that was more about satisfying dependences for external
interfaces).
Thanks,
-Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
