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


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:


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


module Stack {
  class Node {
    type ItemType; // type of item

  record Stack {

  proc main() {
    var myStack = new Stack();
    var myNode = new Node(ItemType=int);


$ 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:


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!)


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

Reply via email to