>> This is from the people who actually had to ask "does Windows actually
>> support letting multiple processes open the same disk file at once?"
>
> Heh. Did you tell them it's better at that then UNIX is?

My understanding is that Unix is *great* at letting multiple processes 
read the same file - it's *stopping* them doing this that's hard.

>> Question: Does that mean that one process can produce so much garbage
>> that
>> it forces endless GC cycles, slowing other unrelated processes down?
>> Or does
>> the VM partition memory on a per-process basis or something?
>
> Each actor (i.e., Erlang process) has its own heap, so you can generate
> a lot of garbage but it'll only make your own thread slow down.

Right, OK. So the worst you can do (presumably) is steal lots of CPU 
time. (?)

Come to mention it, what's Erlang's thread scheduler like? Does it just 
do round-robin for all threads ready to run, or can you assign thread 
priorities and stuff?

> That said, it's possible to generate specific kinds of garbage that go
> into shared heaps or interned string storage or etc, which will be mean
> to all the processes in the same VM. Hermes (which is somewhat similar
> to Erlang) was designed to let the interpreter avoid such. (Altho Erlang
> *could* avoid such problems with more work in the VM, Erlang wasn't
> specifically designed AFAIK with the concept of being safe to run
> "untrusted" code on a node, while that was pretty much Herme's main point.)

OK, fair enough.

>> What Erlang is doing is considering any two types to be "identical" if
>> they
>> have the same *structure*. That wouldn't do for Haskell; consider, for
>> example, how a PortID and a ThreadID are both 32-bit signed integers, but
>> are considered utterly different, incompatible types.
>
> Well, more like you have very few types, but they're dynamic types. You
> have list. You have tuple. You don't have list-of-X or tuple-of-three-Y's.
>
> I.e., just like in Haskell a list of 4 integers is the same type as a
> list of seven integers, in Erlang a list is a list, a tuple is a tuple.

Indeed. Erlang cares only about structure, not meaning. (Presumably the 
idiomatic way to distinguish between a ThreadID and a CustomerID would 
be to put an atom in front of it indicating it's "type".)

>> [Of course, TRWTF is that it's *signed*...]
>
> If they're IDs, it doesn't make sense to talk about math or ordering on
> them, so whether they're signed or not is irrelevant.

Presumably it just means that if you create more than 2^31 Haskell 
threads, the ThreadID counter will overflow and half the standard 
library will malfunction...

Soon you'll have FOUR THOUSAND AND NINETY SIX CHILDREN, and they'll all 
be PARALLEL, and Google will be like SLOOOOOW DOWN MAN! IT'S 
MUNCTIONAL!!!! >_<

>> You can upgrade the code, but unless you upgrade it all at once, both
>> versions need to speak the same wire protocol.
>
> Again, list of three integers vs list of seven integers.

There's more to a wire protocol than what types you exchange. (There's 
ordering, for example.)

>> I guess we sit back and see if they ever release anything...
>
> I mean, I'd be interested in seeing how you tell the compiler "I can
> take either v1 or v2" in a way that v1 and v2 are cleanly separated from
> the code. Most languages make a distinction of a channel specification
> where you provide the types for specific channels, but I don't know how
> Haskell would handle such a thing. Would it just be a convention that
> you put that stuff in a separate file?

I don't really know. In principle the information exists to let you do 
this stuff, but how you'd implement it I'm not sure.

GHC already generates "interface files" which are machine-readable files 
telling the compiler what's exported from each source module. Perhaps 
you could do some trick where you compare the old interface files to the 
new ones or something. (But this requires you to remember to not delete 
this files, which are usually considered "temporary", so probably some 
more specific mechanism is necessary.)

>> Yeah, I guess that works too.
>>
>> Presumably Erlang allows you to serialise cyclic data structures,
>> which is
>> notoriously hard for a pure functional language.
>
> I'm not sure how you'd get a cyclic data structure in Erlang, given that
> it's functional. It would imply something created earlier has to point
> to something created later in order to form a cycle.

Does Erlang not permit recursive definitions then?

   let list = [1, 2, 3] ++ list

That'll create a circular list for you in Haskell.

[Actually, it's not defined whether this is a recursive function, or a 
circular list. It's impossible to tell the difference from inside 
Haskell itself...]

>> Only works if foo/3 on node X is the same thing as foo/3 on node Y. ;-)
>
> Correct. That's why there's an MD5 of the code along with the identifier.

Yeah. And why Haskell is talking about doing something similar. 
Currently it just uses a name, but as you say, that breaks as soon as 
sender and receiver have different code.

>> Oh, right. So atoms are *globally* unique, not unique to each node?
>
> Well, they're ... atoms. Is 27.5 globally unique? Two atoms with the
> same textual representation are by definition the same atom.

Right, I see...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message