>
>> 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…
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.
>
>> 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?
>
You are not misunderstanding the proposal. I neglected to think through the use
cases you mentioned. I agree it’s not a good solution.
Matt Bauer
------------------------------------------------------------------------------
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
