Well, after reading that PDD (and linked groups posts) I feel a lot more comfortable about the direction of concurrency (in parrot).

In the past I'd tried to follow Dan's posts regarding the research being done in parrot concurrency (before the whole Leo/Dan explosion) and I hadn't really revisited the topic to check the progress being made.

What I liked in the PDD:

• first-class support for multiple thread paradigms?
• excellent depth in the GC-under-concurrency topic
• reality-based discussion of COW and VM/ints/threads
• copy constructs base on macros mapping to efficient per-OS code
• they're not throwing in too many language-specific assumptions
• continuation<=>VM mapping looks appropriate

To my limited experience, that all sounds well-reasoned. The perl6 Concurrency DRAFT spec seems quite thin on detail at this moment... is that not where this discussion should be focussed? To me it seems as though a wide variety of concurrency paradigms could be efficiently implemented based on the primitives and HLL concepts defined in the PDD.

Perhaps other monks have some ideas about what specifically could not be efficiently supported (or implemented without hazard) based on the HLL constructs in the PDD. Personally, I have two observations on the perl6 DRAFT spec:

1) I'm concerned that the language (and perhaps semantics) of the DRAFT spec are defined in terms of STM concepts.

I certainly don't discount STM as a good programming model (provided undo/redo hooks and some sort of module-boundry "contracts" for the sake of composability are provided); the concern I have is that language concurrency patterns (wrt: composability) are still in their infancy and I wonder whether one can efficiently model other concurrency paradigms on top of STM constructs.

I understand that in the Haskell community there is still major discussion about how competing concurrency paradigms compose with exceptions, other state-ish monads, and each other. While perl6 doesn't look like it has enough type-inference goodness (at this time) to make the kinds of guarantees necessary to utilise some of the more esoteric constructs, I still have some (probably unfounded) concern that couching the design in STM is a premature "optimisation".

2) Is perl6 going to be written off as unusable (by under-sold users of other languages) if it doesn't at least expose POSIX-like shared everything APIs?

I personally prefer a share/copy-nothing-by-default approach but can understand how shared-everything is very appealing to some folk. After all if parrot supports it, shouldn't perl6 at least expose it for completeness-sake?

-David

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.