Greetings,

I was examining Chapel out of curiosity to see how it compared to other
parallel languages I’ve used before.  I had a few questions about Chapel’s
semantics.

I’m asking these questions from the perspective of someone who would write
generic parallel libraries similar to Thrust or Threading Building Blocks.
The examples I've included below were designed as tests to reveal details
of Chapel's semantics.  They're meant to help identify ways to write robust
generic code that works predictably in all use cases.


1. Higher-order functions

I wrote a test to see if higher-order functions worked.  Compiling this
code gives me internal error CAL0056.  What should happen in this code?
Are higher-order functions supported?


proc times2(x) {
  return x * 2;
}

proc map(f, t) {
  return (f(t[0]), f(t[1]))
}

map(times2, (1, 1+1i))


2. Semantics of references and values

I had trouble understanding when Chapel uses value vs. reference
semantics.  For instance, in the following situation, resizing an array
exposes the semantic difference.  At the beginning of the code, A[5] is the
domain of B.  At the end, is it possible to restore the situation that A[5]
is the domain of B?


// Create array B whose size is given by A[5].
var myDom = {1..5};
var A : [myDom] myDom.type;
var B : [A[5]] int;

// B can be resized by assigning to A[5].
A[5] = {1..3};
writeln(B.domain);

// After resizing A, B can no longer be resized by assigning to A[5].
myDom = {1..4};
myDom = {1..5};
A[5] = {1..2};
writeln(B.domain);


What I infer from this is that
* Domains are mutable objects
* Domain variables hold references to domains
* Arrays of domains hold references to domains
* Assignment on domains (lhs = rhs;) does not modify the lhs reference, but
copies the value of the rhs object into the value of the lhs object

Is there a way to modify the reference held in a domain variable, instead
of modifying the domain that it references?

Incidentally, domain assignment leads to some oddness because domain
expressions are lvalues.  The statement ({0..1}) = {0..2}; compiles, while
(1) = 2; doesn’t compile.  Without the parentheses, both are syntax errors.


3. Subclassing

It looks like Chapel has subclassing with virtual methods.  I tried it out
with the code shown below, which tests how generics interact with
subclassing.  It gives internal error CHE0496.  What does that error mean?


class Base {
  proc foo(type T) : int;
}

class Derived1 {
  proc foo(type T) : int {
    var x : T;
  }
};

class Derived2 {
  proc foo(type T) : int {
    var x : T;
    var y : T;
  }
};

var x : Base;

if (stdin.read(bool)) {
  x = new Derived1();
}
else {
  x = new Derived2();
}

x.foo((int, int));


4. Dependent types

One nice feature of Chapel is that function parameters can be used in the
types of other parameters.  This makes it possible to impose constraints on
array domains, such as writing a function where all array parameters have
equal domains.  But why is it sometimes an error for a parameter to
reference an earlier parameter, while other times it’s an error for a
parameter to reference a later parameter?  Why does the error message say
“’reindex’ used before defined”?


// error: ‘reindex’ used before defined
proc bad_1(const sizes : [{0..1}] int, ref A : [sizes[0]] int) {}

// First parameter references second, this works
proc good1(ref A : [sizes[0]] int, const sizes : [{0..1}] int) {}

// Error: ‘D’ used before defined
proc bad_2(const n : D.idxType, D : domain(1,int,false)) {}

// Second parameter references first, this works but is the opposite order
from good1
proc good2(D : domain(1,int,false), const n : D.idxType) {}


5. Types

The first sentence of the chapter on types in the language specification
0.96 says, “Chapel is a statically typed language with a rich set of
types.”  This sentence is misleading because the type system described in
the language spec is not a static type system.  From what I’ve seen, I
think Chapel’s type annotations would be best understood as dynamically
checked assertions.

Chapel’s type system is not a static type system because types are
intermingled with evaluation in a way that prevents types from being
checked, once and for all, at compile time.  Verifying type-correctness at
compile time is the point of a static type system.  Chapel doesn’t do
that.  Moreover, types can have side effects and can depend on mutable
values, which pretty much precludes Chapel from doing that in the future.

What are Chapel’s types, really?


-Chris
------------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users

Reply via email to