On 5/17/2011 8:22, Invisible wrote:
> I was under the impression that the registry is *only* for dynamic linking,
> and has nothing to do with static linking [which is what I'm talking about
> here].

Oh, yeah, I don't know how to use it for static linking.

> 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?

> 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.

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.)

> Well yeah, but if you're trying to use a mere textual "name" to decide what
> type something is, you need a version number or something to go with the
> name, to make it unique.

Sure.

> 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.

> [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.

> 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.

>>> as well. When you compile v2, the compiler checks what you changed, and
>>> warns you if you don't explicitly handle the v1 data (unless it's
>>> identical).
>>
>> That's fair. It would be interesting to see how that's specified.
>
> 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?

> 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.

>>> And yet, that would seem rather heavy compared to just sending a function
>>> name (or rather, a *unique* function identifier),
>>
>> Not all functions have names. For the functions that have names, I
>> believe you just send the fully-qualified name of the function.
>
> 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.

> 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.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message