Programming components

[erlang-list@REDACTED]

Hi,

> Erlang lacks a notion of types and a way of
> specifying components.

Regarding types, I'm trying to understand what you find
lacking in Erlang, and why you want it.

> Type systems always have three parts:
>
> 1) A set of primitive types
> 2) Glue for making complex types from primitive types
> 3) Aliases for defining new types

Doesn't Erlang have those? Primitive types, tuples and
lists, and records?

> Definition: A component is a black box with ports. If
> you send the port a well-typed message it will
> respond with a well-typed reply.
>
> Below I discuss two styles of specify the behavior of
> components.

It sounds as though you are discussing the
specification of servers, or protocols. "Components"
are more complex in that they must provide ways to
manage their lifecycle, to connect them to other
components etc.

> To *specify* the behavior of a black box I can write

[CSP style and RPC style examples clipped...]

I find your proposed notations quite appealing, as
notations go, but these days I rather favour using test
programs as a more useful form of specification.

Writing executable tests is both good for designing
good protocols, and produces a more useful result than
a spec. With a bit of care, test programs can even be
made to look as readable as a spec.

> 5) Introspection - yes :-)

Apart from development tools, or working around
deficient languages, I can't really think of any good
use for introspection. What do you have in mind?

> To obtain a beautiful mapping from abstract types to
> Erlang and XML I need to represent strings as
> <<"string">> and NOT "string"

I don't understand this. Could you elaborate?

Overall, I guess I'm having trouble seeing the
motivation for these proposals. Within an all-Erlang
world, they don't seem useful, and I suppose I am
skeptical about defining any kind of standard for
universal components.

Regards,

Dominic Williams
http://www.dominicwilliams.net

----