Re: language design models, was Writing A Plain English Compiler

On Sat, 08 Nov 2014 10:48:09 -0600, Joshua Cranmer ?
<Pidgeot18@verizon.invalid> wrote:
>On 11/7/2014 3:23 PM, George Neuner wrote:




>I think actor models (which is basically CSP?) appear to be winning out,
>but, as you say, they're not completely sufficient. If I had to make a
>bet, it would be on an actor-based model with some support for
>cross-thread shared data collections. But I would be hesitant to wager
>very much even on that.


Yes, actors are a form of CSP. And I agree that CSP in whatever form
currently is the best option available. The major difficulty with it
is handling complex coordination patterns.


Special purpose coordination languages are better able to handle
complex communication patterns, but they rely on temporal decoupling -
i.e. they have no sense of real world time - and, so far, none has
proven to scalable beyond a few thousands of actors [which is not a
lot for a complex system].




>You've failed to mentioned transactional memory.


My MS degree is in database technology.


I can see potential for transactional memory, but currently HTM is
non-scalable, confined to shared-memory systems, and hard to use
effectively due to limitations on the size of managed memory, the
number of concurrent transactions supported and the less-than-friendly
isolation model that is implemented.


On chip HTM essentially works through an extension of the cache
coherence protocol to fail on X-access to a line owned by another core
rather than to arbitrate access to it. TM needs to track a great deal
of meta information - minimally the entire set of written lines on a
per transaction basis - which severely limits the size of memory that
can be managed. Existing HTM implementations provide only a handful
of kilobytes.


Implementations vary as to whether they also fail on read of a dirty
line owned by a concurrent transaction. Most don't and thus (in
database terms) provide only uncommitted-read isolation.
Uncommitted-read is the most basic isolation level and the most
difficult to work with ... essentially every TM hosted value has to be
considered (C) volatile.


STM layered on top of HTM can provide more programmer friendly
isolation and also can address the HTM size issues. But the STM layer
creates additional register and/or cache pressure on transactions that
can't tolerate the limitations of the underlying HTM [which in most
uses is likely to be most transactions.]


Pure STM can (at least theoretically) support clusters as well as
shared memory, but STM is slow even in shared memory: performance
similar to that of an in-memory DBMS, a bit faster because STM does
not also have to address data persistence.




Again, TM has value but is not a scalable solution.






>There are also things like Concurrent Collections which I'm
>hard-pressed to place, particular since I'm vague on the details
>(maybe dataflow?).


CC is just a thread safe collection.






>> Most natural languages are a hindrance to logic because they are
>> inherently ambiguous. There is some anecdotal evidence that Sumerian
>> might have been sufficiently unambiguous to program with, but the
>> issue is moot because no one today speaks it.
>
>There's an issue not strictly related to ambiguity that I realized
>when reading Gerry's examples. English (and presumably other natural
>languages, but I'm not enough of a linguist to say with any
>confidence) allows you to reliably refer to one, sometimes two, things
>without naming them. At the same time, it makes it cumbersome to name
>a temporary object.


Exactly. English in particular has slippery pronouns: the "royal"
"we" is singular; "you", "they" and "it" all may be singular or plural
depending on context.
[The plural use of "it" is rare in polite conversation, but is
relatively common in exasperation and vulgarity: e.g., "Screw it!" may
be a multiple reference.]




>I prefer Brainfuck as the go-to "unprogrammable" language. :-)


A neat simulation of a Turing tape machine. IIRC, there are several
compilers that target it as a bytecoded interpreter. Very small, but
still very powerful.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.