I am afraid I share your wishful thinking, even if I regret so. The only way to get out of this dilemma is to go one or more levels higher. Meta-meta levels. And then come down, pragmatism at hand. What do we really need/want? Extensions to a (dead) although strong language? Obviously not. That doesn't mean occam, as the only pure embodiment of CSP I am aware off, doesn't have its merits. It taught us humility, the merits of sparseness, orthogonality, etc. But it is not a religion. What we need is a specification language that can be used to generate run-able binary code, verifiable. Taking into account the reality of what HW designers provide us (because HW and SW are still different worlds). Taking into account what really matters in the real world (cost and safety). There is a long way to go, but discussions help. Sorry if I annoyed some. Eric From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Rick Beton Hi all, I started the original discussion following Peter's 'Occam Obviously' presentation, but sadly the language discussion petered out, lapsing into a fascinating but many-year-long rehearsed discussions on priority. My original hope was to seek an answer to this question: if the answer is Occam (obviously or otherwise), what will it take to make Occam generally usable? In its present form it is not so. Then there's the question of aspiration versus practicalities. The first suggestion I made was for packages to be added to Occam-pi and I put it first deliberately. Not a new suggestion, this; in fact Occam3 had 'modules' way back in 19xx (choose your own xx). I don't really care for the details of the implementation, I'm much more concerned that Occam-pi/-tau should belong to a busy community, inspired by (a) clarity of thinking and (b) a need to make things happen. If this is wishful thinking, then alas Occam is not obviously going ever to be more than a teaching tool. So, what next? Rick |