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 * > { … }
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.
Matt Bauer
On Jul 3, 2014, at 5:53 PM, Vassily Litvinov <[email protected]> wrote:
> I am soliciting suggestions for generalizing the current syntax for task
> intent clauses.
>
> * What is a task intent clause?
>
> It allows the user to list the variables to be treated specially w.r.t.
> task intents. E.g. if 'i' is defined outside a 'begin' and used inside
> it, then 'ref i' indicates that 'i' is to be passed by reference into
> the begin task function. Otherwise 'i' is passed by blank intent.
>
> var i = 5;
> begin i = 6; // illegal - 'i' is constant within the begin
> begin ref(i) i = 6; // legal; updates the original 'i'
>
> See Section 24.7 "Task Intents" in the Chapel Spec.
>
> * Why generalizing?
>
> Currently only 'ref' can be specified in a task intent clause. We would
> like to support other intents, for example 'in'.
>
> * What are the issues?
> Or, why can't we generalize the current syntax in a straightforward way?
>
>
> - Allowing 'in' for the coforall loop, the way we currently allow
> 'ref', makes it ambiguous at least syntactically, perhaps also visually,
> e.g.:
>
> coforall a in (b) { ... }
>
> Is 'a' the index variable and 'b' a no-paren iterator (a call to
> which is wrapped in parens)? Or is 'a' a no-paren iterator and 'in(b)' a
> task intent clause?
>
>
> - We are about to introduce ref variables, declared using 'ref'
> instead of 'var'. This is syntactically ambiguous with the current task
> intent clause:
>
> begin ref(i,j) ...
>
> The parser can't tell whether ref(i,j) are a task intent clause or a
> declaration of two reference variables.
>
>
> - It would be nice to have a task intent clause remind a list of
> formal arguments. However, the simple solution is also syntactically
> ambiguous:
>
> begin ( a.b; )
> begin ( ref c, in d ) { ... }
>
> The parser can't tell whether the left paren starts a parenthesized
> expression or a argument-list-like task intent clause. This is perhaps a
> consequence of building the parser with bison.
>
>
> Suggestions?
>
> P.S.1. Kyle B. and I have worked out a proposal. I'd like to let others
> take a shot at it before circulating ours.
>
> P.S.2. We are working on applying task intents to 'forall' statements.
> The task intent clauses in foralls will be available using the same
> syntax as coforalls.
>
> Vass
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
