 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/17/2011 1:07, Invisible wrote:
>> Unless you register it, I expect.
>
> Well, no, what I'm saying is that if you call a function that's defined in
> (say) windows.h, the linker somehow "finds" it.
Right. It's probably in the C runtime.
> But if you wrote some C
> source code of your own, you have to tell the linker to link in the object
> code or it complains it can't find it.
Right. Unless you register it. Then the linker looks up the code in the
registry and links it against the file that the registry says the code is
in. That's what the registry is for, and why it's called a registry.
You may need to make it a COM DLL first to register it; I don't remember the
exact details any more.
> (The answer is probably something like "GHC automatically includes the Win32
> files at link time".)
That's my guess.
> If I do a "foreign import", the Haskell compiler generates a Haskell
> function which calls the corresponding C function. Which is fine if you're
> statically linking the C code into your binary. But you don't link the
> Windows kernel into your application, do you? It does some weird magic with
> processor rings and code gates to enter kernel mode to run the code.
In every system I've ever used, the "weird magic" is in a linker file that
always gets loaded. For example, msvcrt.dll (Microsoft visual C run time)
for Windows, glib for GCC under Linux, etc.
> I'm no expert, but as I say, I was under the impression that the usual way
> to access a DLL is to link in a small C stub which defines the code
> necessary to dynamically find and execute the exported functions from the DLL.
Or branch to a jump table that the loader fills in with addresses from the
DLL when it loads the DLL, which it loads based on the headers of the program.
Most systems do almost all of this automatically specifically because C
doesn't have any standard syntax for doing this. I suspect if
dynamically-loaded code was the norm in C from the beginning, much less
would be automated by the OS's loader.
> Personally, I thought "DLL hell" went away about 10 years ago...
Yes, pretty much.
> Right. So all you're saying is that OS processes are heavier than Erlang
> processes.
Well, much heavier than Linux or Windows processes. By many, many orders of
magnitude. There are OSes where processes are very light, like Singularity,
Mach, AmigaOS, etc. Generally what you hear referred to as a "microkernel"
is a kernel where processes are so lightweight that you can afford to put
each device driver and file system in its own process.
> One thing Erlang can do (and Haskell can't, easily) is that because Erlang
> is a VM, you can have several unrelated Erlang applications running on the
> same VM.
Yes. Indeed, the whole point of the VM is to be a virtual machine, so the
idea of an "application" is a user-level construct, not something built into
the language. (In much the same way that a "login" is a user-level
construct in UNIX/Linux, whereas in most other OSes, it's an OS-level
construct.)
> Yes, the entire program is statically typed, but this one tiny part where
> you have to do a simple runtime type check automatically COMPLETELY DESTROYS
> EVERY SINGLE ADVANTAGE OF STATIC TYPING!
I didn't say that. I said it loses a lot of the benefits, where "benefits"
are "guarantees" in my mind.
Now, in this particular case, it probably is doing enough work in the
connected set of processes that converting from dynamic to static typing is
worthwhile. In the discussions we were having before, I was talking about
things like web pages, that almost never do any significant processing on
their own at the server, so statically typing a web page where you're
translating dynamically typed SQL results into HTML doesn't really help to
have static typing. I.e., when it's not one tiny part but rather a majority
of the program, it's worse.
> Basically you need to manually make sure you send a version number at the
> start of your message exchange, or something like that, and make sure that
> all servers and clients you write can handle all versions of the protocol.
Or you just check the types and do the right thing with them. Of course,
knowing what the right thing is can be difficult. E.g., if you have been
working with 2D longitude/latitude, and the new version needs altitude also,
you could have all the places that take a 2-element tuple start also working
with a 3-element tuple and asking how many elements it has, then start
generating 3-element tuples. The number of elements in the tuple can serve
as your version number.
> Or design the protocol so that it never needs to change. (Which is not
> infeasible if you can send code as part of the protocol I suppose...)
Well, they handle it by letting you upgrade the code.
> Not really. When you compile v1, you assume that the other side will be v1
> 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.
> The Haskell implementation has a potential advantage in that you can specify
> precisely how to serialise stuff if you want to.
You just do that in code with Erlang. I.e., you write your own serializer,
or you send a message to a local agent that then sends the message to the
remote agent that has only what you want.
> 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. (And since function
names are atoms, the actual text of the function name is cached after the
first time, so you don't have to send more than "the 37'th function I've
sent you" next time.)
If you send a lambda, I believe it sends the bytecode. There may be caching
involved there too, but I don't remember.
I was too awed by the landmines in the data format to remember the other
details.
> Come to think of it, I'm still figuring out how it manages to send atoms...
It sends them as text, the first time.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
More erlang fanning:
The protocol between the deamons:
http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html
The protocol between the individual actors:
http://www.erlang.org/doc/apps/erts/erl_ext_dist.html
You want to look at 8.21 and 8.22. It seems the code doesn't ship, since
logically the function can't really be constructed at runtime. Instead, it's
a reference into the BEAM file (where a BEAM is like a java jar).
Because of course "external term format" is exactly what anyone would google
for to find that. I'm also rather amused that altho Erlang has wonderfully
powerful expressions for parsing byte streams, they used ASCII art with
ambiguous textual descriptions to describe the format of the stuff on the
wire instead of giving you the Erlang expression that would parse it
unambiguously.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> But if you wrote some C
>> source code of your own, you have to tell the linker to link in the
>> object
>> code or it complains it can't find it.
>
> Right. Unless you register it. Then the linker looks up the code in the
> registry and links it against the file that the registry says the code
> is in. That's what the registry is for, and why it's called a registry.
>
> You may need to make it a COM DLL first to register it; I don't remember
> the exact details any more.
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].
> In every system I've ever used, the "weird magic" is in a linker file
> that always gets loaded. For example, msvcrt.dll (Microsoft visual C run
> time) for Windows, glib for GCC under Linux, etc.
Right. That's probably it...
> Most systems do almost all of this automatically specifically because C
> doesn't have any standard syntax for doing this. I suspect if
> dynamically-loaded code was the norm in C from the beginning, much less
> would be automated by the OS's loader.
On the other hand, the main advantage of C is that almost nothing is
built-in, which means that everything can be changed... ;-)
>> Personally, I thought "DLL hell" went away about 10 years ago...
>
> Yes, pretty much.
This is from the people who actually had to ask "does Windows actually
support letting multiple processes open the same disk file at once?"
>> One thing Erlang can do (and Haskell can't, easily) is that because
>> Erlang
>> is a VM, you can have several unrelated Erlang applications running on
>> the
>> same VM.
>
> Yes. Indeed, the whole point of the VM is to be a virtual machine, so
> the idea of an "application" is a user-level construct, not something
> built into the language.
Fair enough.
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?
>> Yes, the entire program is statically typed, but this one tiny part where
>> you have to do a simple runtime type check automatically COMPLETELY
>> DESTROYS EVERY SINGLE ADVANTAGE OF STATIC TYPING!
>
> I didn't say that. I said it loses a lot of the benefits, where
> "benefits" are "guarantees" in my mind.
>
> Now, in this particular case, it probably is doing enough work in the
> connected set of processes that converting from dynamic to static typing
> is worthwhile. In the discussions we were having before, I was talking
> about things like web pages, that almost never do any significant
> processing on their own at the server, so statically typing a web page
> where you're translating dynamically typed SQL results into HTML doesn't
> really help to have static typing. I.e., when it's not one tiny part but
> rather a majority of the program, it's worse.
>
>> Basically you need to manually make sure you send a version number at the
>> start of your message exchange, or something like that, and make sure
>> that
>> all servers and clients you write can handle all versions of the
>> protocol.
>
> Or you just check the types and do the right thing with them.
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.
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.
[Of course, TRWTF is that it's *signed*...]
>> Or design the protocol so that it never needs to change. (Which is not
>> infeasible if you can send code as part of the protocol I suppose...)
>
> Well, they handle it by letting you upgrade the code.
You can upgrade the code, but unless you upgrade it all at once, both
versions need to speak the same wire protocol.
>> Not really. When you compile v1, you assume that the other side will
>> be v1
>> 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...
>> The Haskell implementation has a potential advantage in that you can
>> specify
>> precisely how to serialise stuff if you want to.
>
> You just do that in code with Erlang. I.e., you write your own
> serializer, or you send a message to a local agent that then sends the
> message to the remote agent that has only what you want.
Yeah, I guess that works too.
Presumably Erlang allows you to serialise cyclic data structures, which
is notoriously hard for a pure functional language.
>> 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. ;-)
> If you send a lambda, I believe it sends the bytecode. There may be
> caching involved there too, but I don't remember.
>
> I was too awed by the landmines in the data format to remember the other
> details.
I'll have to check it out sometime...
>> Come to think of it, I'm still figuring out how it manages to send
>> atoms...
>
> It sends them as text, the first time.
Oh, right. So atoms are *globally* unique, not unique to each node?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/05/2011 16:19, Darren New wrote:
> More erlang fanning:
>
> The protocol between the deamons:
>
> http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html
>
> The protocol between the individual actors:
>
> http://www.erlang.org/doc/apps/erts/erl_ext_dist.html
Ouch. The pain...
> You want to look at 8.21 and 8.22. It seems the code doesn't ship, since
> logically the function can't really be constructed at runtime. Instead,
> it's a reference into the BEAM file (where a BEAM is like a java jar).
Erlang sends an index into the BEAM file, the eventual Haskell
implementation is going to send linker labels (i.e., indexes into the
executable image).
I notice also that Erlang sends "Uniq", which is "the hash value of the
parse for the fun". In other words, it sounds like it's a cryptographic
hash function of the syntax tree for the function's source code. Which
is pretty much what the Haskell people are talking about for version
control.
> Because of course "external term format" is exactly what anyone would
> google for to find that.
Oh, but of course!
> I'm also rather amused that altho Erlang has
> wonderfully powerful expressions for parsing byte streams, they used
> ASCII art with ambiguous textual descriptions to describe the format of
> the stuff on the wire instead of giving you the Erlang expression that
> would parse it unambiguously.
Myself, I was amused by
"The description here is far from complete and will therefore be further
refined in upcoming releases. The protocols both from Erlang nodes
towards EPMD (Erlang Port Mapper Daemon) and between Erlang nodes,
however, are stable since many years. "
So the description is "far from complete"? That's really helpful. Oh,
but the protocols "are stable since many years". So I'm guessing English
isn't your first language then? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/17/2011 8:32, Invisible wrote:
> Erlang sends an index into the BEAM file, the eventual Haskell
> implementation is going to send linker labels (i.e., indexes into the
> executable image).
Well, note that there's two versions, from different releases of the VM.
> I notice also that Erlang sends "Uniq", which is "the hash value of the
> parse for the fun". In other words, it sounds like it's a cryptographic hash
> function of the syntax tree for the function's source code. Which is pretty
> much what the Haskell people are talking about for version control.
I believe that's correct. And the old version sent the MD5 of the range of
bytes that implement the function, or something. (It's actually the AST,
which is available also as part of the macro expansion phase of compilation.)
> So the description is "far from complete"? That's really helpful.
Yet typical for open source, where proponents often claim that the code *is*
the documentation.
> Oh, but
> the protocols "are stable since many years". So I'm guessing English isn't
> your first language then? :-P
Uh, no. Ericcson.com, corporate headquarters Stockholm, Sweden.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I notice also that Erlang sends "Uniq", which is "the hash value of the
>> parse for the fun". In other words, it sounds like it's a
>> cryptographic hash
>> function of the syntax tree for the function's source code. Which is
>> pretty
>> much what the Haskell people are talking about for version control.
>
> I believe that's correct. And the old version sent the MD5 of the range
> of bytes that implement the function, or something. (It's actually the
> AST, which is available also as part of the macro expansion phase of
> compilation.)
The trouble is, if the compiler optimisations change, the BEAM code
might change, even if what the function actually does is unaffected.
That [I would hope] is why it hashes the AST, not the compiled code.
OTOH, depending on how it works, there may be more than one AST which is
trivially equivilent.
OTFH, I believe Rice's theorum states that function equity is
undecidable. We're not really trying to prove which functions are equal;
we're trying to prove which ones are *not* equal...
>> So the description is "far from complete"? That's really helpful.
>
> Yet typical for open source, where proponents often claim that the code
> *is* the documentation.
The source code *is* the documentation = EPIC FAILURE.
The usual response I see from OSS is "you should be greatful we bothered
to write any documentation at all!"
>> Oh, but
>> the protocols "are stable since many years". So I'm guessing English
>> isn't
>> your first language then? :-P
>
> Uh, no. Ericcson.com, corporate headquarters Stockholm, Sweden.
LOLRUS.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/17/2011 12:12, Orchid XP v8 wrote:
> My understanding is that Unix is *great* at letting multiple processes read
> the same file - it's *stopping* them doing this that's hard.
Well, there is that, yes.
> Right, OK. So the worst you can do (presumably) is steal lots of CPU time. (?)
Well, you can break the stuff that's shared, like the large binary store or
the atom intern stuff.
> 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?
I don't think there's any priority stuff that I remember.
> 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".)
Pretty much, yes.
> 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...
It might not even mean that, if nobody does any comparisons or math with them.
>>> 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.)
Well, yes, if you have two versions of Erlang that don't speak the same
protocol as the other, they won't connect.
> 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.)
That was the kind of thing I was asking about, yes.
> Does Erlang not permit recursive definitions then?
Not of data. If "list" is already defined, you can't assign to "list" again.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/17/2011 12:16, Orchid XP v8 wrote:
> The trouble is, if the compiler optimisations change, the BEAM code might
> change, even if what the function actually does is unaffected. That [I would
> hope] is why it hashes the AST, not the compiled code.
Right. I expect that's why they changed the definition of what goes over the
whire.
> OTOH, depending on how it works, there may be more than one AST which is
> trivially equivilent.
That wouldn't really matter. There's one place the function is defined in
the code. If there's a *different* function that does the same thing, then
it's still a different function.
All they're doing is ensuring the function they have is the same one you
have. They don't have to prove they're different, only that they're identical.
> We're not really trying to prove which functions are equal; we're trying to
> prove which ones are *not* equal...
Right.
> The usual response I see from OSS is "you should be greatful we bothered to
> write any documentation at all!"
I've even seen "yes, we know the documentation is all wrong and misleading,
but we didn't bother to put a note on it saying that" (Apache), as well as
"please, sir, may I write the documentation for you?" "No." (Blender)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
