I like the idea of a task intent clause taking a list of formal
arguments. I also think it should visually stand out from other
expressions. What about using ‘<' and ‘>’ to declare the task intent
formal arguments. Building off your illustration, it would look
something like:
begin < ref c, in d > { … }
I think with this syntax, you could also handle the blanket clause
without parsing issues like:
begin < in d, ref * > { … }
I'm having no strong opinions on this proposal, positive or negative (nor
any strong proposals of my own to put forth at this point). I think on
the plus side, it resembles a formal list while also being different
(which I think is good because I think it is different and that we want it
to be). On the minus side, I flinch a bit at the need to re-use the
comparison operators as a bracketing mechanism, though that may just be
lingering allergies to C++ template syntax... I'm sure we've lamented
over this many times over the years, but if only ASCII/keyboards supported
about five more flavors of bracketing...
That said, I really think the solution is to just make begin, for,
forall, coforall, if, do, while, etc take a block statement expression
instead of the more generic statement expression. Forcing the use of ‘{‘
and ‘}’ reduces a class of programming errors imho. If this was done,
you could just use ‘(‘ and ‘)’ for the task intent clause which would
look more natural I think.
I think it'd be somewhat of a shame to require 'begin { foo(); }' rather
than simply 'begin foo();' but if it fixed the problem, I'd consider it
further. Trouble is, I'm not seeing how it would solve the root problems.
E.g., requiring coforalls to use compound/block statements rather than
singleton statements doesn't seem to solve the ambiguity between 'in' as a
task intent vs. the keyword used to indicate 'forall i in 1..n' (and by
ambiguity, I mean "to the human reader" as much as "to a mechanical
parser" (or maybe even more than). Am I misunderstanding the proposal?
The one other negative reaction I have to this proposal is that I like the
potential of any new proposal for task intent syntax to help group
disparate argument intents into a single coherent list of some sort;
whereas continuing along the line established by the current syntax is
likely to result in a little cloud of intents scattered in after task
parallel keywords. That is, I think a proposal like:
begin <const in A, ref b, inout c> ...
is much nicer than:
begin const in(A) ref(b) inout(c) { ... }
or:
begin const in(A), ref(b), inout(c) { ... }
because of the fact that it has some grouping for the task intents rather
than a bunch of expressions that seem to be siblings to the 'begin' and
statement/expression defining the task.
-Brad
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
