Extending Erlang

[James Hague]

> It's all documented in the normal places.  We could always use more
> tutorials of course but these things are as well documented 
> as everything
> else.  And there are tutorials:
> 
> 	http://www.erlang.org/doc/r9b/doc/tutorial/part_frame.html
> 	http://www.erlang.org/doc/r9b/erts-5.2/doc/html/part_frame.html

The ErlDrvEntry structure has picked up three new entries since that
documentation was written :)  I'm assuming that they're irrelevant in most
cases, as those three fields, plus the preceding two fields, are left
unintialized by esdl and no one has complained.

I think the interoperability tutorial does a great job of explaining things,
as long as you're writing a vanilla driver.  It would be good to have a
concrete example that involves port_control() and directly creating Erlang
terms.

Surely it would be better to ditch the shole ErlDrvEntry struct and just use
exported functions?

>As has been said previously in this thread it's
>supposed to be hard.  :)

Don't you think that's a bad answer though?  What if it turned out that the
uninitialized fields in the esdl driver *were* bad, and could crash the
emulator under certain circumstances?  What if the only reason they're
uninitialized is because DanG didn't know about them?  Isn't that a bad
situation?  If exported functions were used instead, then then the
dependency on the size of a struct goes away.

James