For those developers who care about this topic (task intent syntax) and
haven't weighed in, note that we're trying to decide ***next week*** for
the upcoming 1.10 release whether to:
1) stay with the status quo for another release (downside: puts off a
change that we currently perceive as inevitable; upside: reduces the
chances that we rush into a syntax that we end up disliking in a few
months);
2) adopt the keyword-based proposal
- using 'with' as the keyword?
- using some other keyword?
3) adopt some other (as yet unheard) proposal.
So let us (Kyle, Vass, and/or me at a minimum) if you have an opinion.
Speaking for myself, I'm not opposed to using a new keyword as suggested
here, and don't have any better suggestions at hand (either for a keyword
or for a different syntax). I'm feeling more inclined to make the switch
now than to put it off (though I do fear that I'll come up with a more
perfect keyword the day after the release).
The one change I'd make to the proposal is that I'm inclined to require
the parentheses after the 'with' (though stylistically, I'd put a space
before the parens to avoid making the 'with()' look like a function call).
This isn't for the sake of dodging a (nonexistent) syntactic ambiguity,
but rather to:
(a) improve readability (the forall case below looks a lot like a run-on
sentence, in particular -- and I anticipate other cases where there
are even longer lists of intents). I was originally thinking that
this could be done by convention, but it really couldn't b/c it's not
an expression being parenthesized;
(b) suggest more of a syntactic parallel with formal argument lists
(though the analogy is imperfect; in particular, there are no formal
types in intent lists and the symbol name effectively serves as both
formal and actual. But they still seem more similar than different)
(c) avoid requiring a different syntactic pattern for 'begin's with
intents vs. those without them.
To flesh out Kyle's list of examples, I'm adding a cobegin:
cobegin with ref a, in b { vs. cobegin with (ref a, in b) {
... ...
} }
And to show his examples with parens:
begin with (ref a, in b) ...
forall e in A with (ref a, in b) do
...
coforall i in 1..10 with
(inout baz)
{
...
}
-Brad
On Thu, 21 Aug 2014, Kyle Brady wrote:
Sorry for the delayed response, Vass and I had a very similar idea to
Christopher's.
begin with ref a, in b {
...
}
forall e in A with ref a, in b do
...
coforall i in 1..10 with
inout baz
{
...
}
I believe the parentheses around the list are not needed to be unambiguous,
as
long as we require any 'begin' that uses task intents to start with a 'do' or
block stmt.
//valid
begin with ref a do foo(a);
begin with ref a {
foo(a);
}
// invalid
begin with ref a foo(a);
-Kyle
From: Chris Doris <[email protected]>
Date: Tuesday, July 8, 2014 at 3:06 PM
To: Brad Chamberlain <[email protected]>
Cc: Chapel Sourceforge Developers List
<[email protected]>
Subject: Re: [Chapel-developers] suggestions for more general syntax for task
intent/ref clause?
Or a new keyword?
begin with(ref a, in b) { ... }
It's syntactically unambiguous. I chose "with" because in a very loose sense,
it's a bit like Python's "with" block, which is to do with tying the
behaviour of a variable to a code block. Also "with" is vague enough that it
could be re-appropriated for other similar tasks - such as what "with"
actually does in Python (it's a very useful feature, which should be in every
language!)
Christopher
On 8 July 2014 22:37, Brad Chamberlain <[email protected]> wrote:
Would a double paren work here?
begin (( ref c, in d )) { … }
Since it’s a paren, what could be passed into a task
intent would have to be limited. That may or may not
be an issue. I’m not familiar enough here to know. I
agree that the comparison operators make me think C++
right away too. Like you, I’m not in love with either
of these unfortunately.
I almost counterproposed this, but got stuck on the question as to
whether this would be a new 'double paren' token in the lexer (which
would be problematic because it would mean that other instances of
adjacent parenthesis -- like in nested tuples -- would become syntax
errors or require special handling in the parser) or whether it would
just be two consecutive paren tokens (which would suggest that there
could be whitespace between the parens, for better or worse).
-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
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
