New Naming about hopac HOT 8 CLOSED

Thanks for the suggestions. Let me see.

Renaming Ch -> Channel might be a good thing as Channel isn't that long of a name and can perhaps be pronounced more easily while reading code.

Alt -> Alternative starts to get a bit long for my personal taste—due to the use in several submodules, like IVar.Alt and Promise.Alt, and suffices like Promise.queueAsAlt. The Occam language, for example, also uses the abbreviation alt for a related concept, so in some sense the abbreviation is established. Alt can already be pronounced easily without having to mentally extend the name. So, I'm reluctant to renaming Alt to Alternative.

Hopac has nothing named Actor.

Cont is very much an internal concept and I don't see value in renaming that. The only reason it is exposed at all is that F# + .Net makes it impossible to create really low overhead fully abstract types, and I really don't want to impose significant overhead by fully hiding everything (believe me, I've tried many variations and done extensive benchmarking and analysis of the machine code generated by the .Net runtime). If client code is directly using Cont objects they are looking for problems.

I've been thinking about doing a one last pass over the interface of the library before pushing it to version 1.0.0. I'm mainly interested in seeing whether more extensive use of F#'s computation expressions could make Hopac programs look more like they were written in a genuine concurrent programming language. I think I'll make an experimental attempt at such a revised Hopac interface and also try to incorporate some of these naming suggestions to see which ones seem reasonable.

Again, thanks for the suggestions!

from hopac.

Main thing is it should be reasonable. I am new to the library. Also I have missed a few items also.

if something is not to be used in the client side please be explicit in the documentation and also perhaps add an attribute for additional precautions. Thanks again for considering this.

from hopac.

Also please do the same for the sister projects also.

from hopac.

Thanks for the suggestion—that is exactly how the documentation has already been written. There is exactly one document that mentions Cont and that is Notes on the Internal Implementation of Hopac. The Hopac Library Reference does not document any internal primitives. Actor is only mentioned in the document that compares Hopac to actor models and shows how you can achieve similar things with Hopac straightforwardly.

I assume you are not previously familiar with Concurrent ML? I seriously and highly recommend starting with John Reppy's book Concurrent Programming in ML. It is an excellent book and I can't recommend it highly enough. After that you can read Programming in Hopac and the reference manual to understand how Hopac differs from Concurrent ML.

from hopac.

Thanks for the pointers. Will do this.

from hopac.

Any other books you would recommend?

from hopac.

For understanding the main programming model of Hopac, John Reppy's book is what one needs.

Other book recommendations would depend on what you primarily want to achieve. For example, if you want to write programs that scale to multiple cores, then you need to understand how to structure basic parallel algorithms and a book like Structured Parallel Programming might be illustrative (though I personally found it could have used a bit of editing).

For more concurrent, asynchronous and distributed oriented programming you might want to read about how people structure Erlang programs (e.g. there is a book by Cesarini et al and another book by Armstrong et al). After one understands how to overall structure programs with lightweight threads (answer: as independent end-to-end processes), one can implement those patterns using the model offered by Hopac / Concurrent ML.

from hopac.

When you get used to it current naming is not that bad.

from hopac.