Hi Brian --
Sorry it's taken us awhile to get back to you -- busy week somehow.
In Java we have packages and classes, and all of the library is in a
package "edu.princeton.cs.algs4" using Java's reverse URL package naming.
Say I want to name my package 'Algs", so that my implementation of a
LinkedStack would be a record Algs.LinkedStack.T (T is for type, more on
that later). The only way I can see to do that now is to have a module Algs
which contains all of my algorithms in one file. Is there any way that I
can have that behavior (all modules accessible by Algs.Modname) and be able
to split my implementation across files, like in Java, or like Ada package
subunits?
...
I think an example of how to organize multifile/multimodule libraries in
Chapel would be enlightening. Packing everything into one file, as I see in
the examples in the mason registry, is not a solution I'm comfortable with.
At present, I'm afraid there's no direct way to do this -- Chapel doesn't
have a means of splitting modules across multiple files. We've (or at
least, I've) long envisioned adding some sort of '#include'-like directive
or statement to Chapel (though more as part of the language as in LaTeX
than by relying on a pre-processor) with the goal of being able to split a
module's contents across multiple files as one of the design goals.
Unfortunately, we haven't gotten there yet, though I don't believe it
would be a particularly challenging effort to add.
Over on issue #7847, we've found ourselves having a somewhat similar
discussion though it started from a different perspective. Specifically
in this comment:
https://github.com/chapel-lang/chapel/issues/7847#issuecomment-365953440
you'll see that Michael Ferguson has proposed using directories to at
least support some degree of having the directory serve as a parent module
and the files within it acting as sub-modules within that module (you'll
also see that I'm not a huge fan of this proposal, as I don't really like
program semantics to be determined by source location within a file
system).
If you want to chime in on either / both of these proposals, that'd be
feedback we'd value.
I also noticed that Chapel doesn't seem to permit types and their
parent module to have the same name. Originally I had tried to have a
module Stack with a (record) type Stack like
module Stack {
class Node {
type ItemType; // type of item
...
}
record Stack {
}
}
but the Chapel compiler rejects that.
I'm surprised to hear you say this because we do this all the time (and
are not convinced we want to, style-wise) and the compiler doesn't
complain. I expanded your sketch of code slightly and found that it
worked:
---
module Stack {
class Node {
type ItemType; // type of item
}
record Stack {
}
proc main() {
var myStack = new Stack();
var myNode = new Node(ItemType=int);
writeln(myStack);
writeln(myNode);
}
}
---
$ chpl testit.chpl
$ ./Stack
()
{}
---
So am guessing that you're doing something more that's either tripping up
a compiler bug or limitation, or otherwise hitting some other issue in the
language. If you have a more complete example demonstrating what you're
seeing, that'd be helpful.
PS: Chapel could also do with some naming and formatting conventions. I'm
trying to stick with Java-ish conventions (well, Java packages are
typically lower cased and I haven't done that yet...) and "One True Brace
Style" with non-optional braces (like Rust) and the Chapel code I read
varies greatly in style.
We get this request fairly often and I don't necessarily disagree with it,
but it hasn't gotten to the top of anyone's priority stack yet. See issue
7417, for example:
https://github.com/chapel-lang/chapel/issues/7417
That said, I'll add that I'm personally reluctant to suggest people change
approaches for certain things that I think are more religious than deeply
valuable like braces styles. There are definitely lots of issues that I
have a personal stance on; there are a lot fewer of them that I'd be
inclined to foist on a respected colleague who felt similarly strongly in
an opposite direction. So if I'm in charge of the style guide, it's
likely to be soft-ish in many respects (and if I'm not in charge of it,
it'd better conform to my preferences, goldarnit!)
-Brad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
Chapel-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/chapel-users
