Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^13: Slow evolution of Perl = Perl is a closed Word

by erroneousBollock (Curate)
on Sep 09, 2007 at 08:02 UTC ( [id://637893]=note: print w/replies, xml ) Need Help??


in reply to Re^12: Slow evolution of Perl = Perl is a closed Word
in thread Slow evolution of Perl = Perl is a closed Word

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://637893]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (6)
As of 2024-03-28 16:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found