Programming components

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of
> erlang-list@REDACTED
> Sent: den 25 augusti 2005 09:44
> To: erlang-questions@REDACTED
> Subject: Re: Programming components
> 
> 
> 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.

Erlang has no syntax for defining types

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

This is a general statement about all typed languages.

Yes Erlang has integers etc. but there is no way to say that the factorial
function returns an integer 

	I'd like to say

	fac(int()) -> int().

	But this is NOT Erlang

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

I agree - but I wanted my examples to be simple - I have thought
a lot about these aspects of the problem.

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

YES - contract checking. The protocol spec IS a contract
to follow some agreed protocol - so we can check it dynamically - to do
so we need the spec.

The spec has two purposes:

	At design time - it tells the programmer what the protocol is
	At run time - it can be used to dynamically check that the client and server
	are correctly obeying the protocol


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

Yes.

Erlang has no strings - ie there is NOT a string data type.

"abc" is NOT a string but shorthand for [97,98,99]

Now suppose I see [97, 98, 99] on some I/O channel
what does this mean? is it to be interpreted as a list of three integers
or as a string? - nobody knows.

Most Erlang programmers choose to represent strings as "lists of integers" and
write "abc" in their programs when they wish to create a string.

I am suggesting they should use <<"abc">> (a binary)

This all has to do with making a simple type system that mays Erlang terms onto
XML data structures in an isomorphic manner.


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

In an all Erlang world they are still useful - since I want to *define* the
protocol between an Erlang client and an Erlang sever in such a way that it can
be strictly checked.

Erlang has a number of problems, both processes and protocols cannot be named.

This is fundamental - if we cannot name something we cannot talk about it (well we can
but this is difficult)

Processes do not have names, in the sense that modules have names.

We can talk about the module lists, or file and everybody knows what we mean.

But how to we talk about the process ? - it has no name - so we use a circularity
"the processes created when we evaluate the function ...."

There is no syntax for naming processes.

There no file Foo.pro containing

	-process(foo)
	-protocol(p)
	...

And there is not way of specify protocols - "read the code and figure out in which order
the messages are sent" is NOT a good reply :-)

 Cheers

/Joe


> Regards,
> 
> Dominic Williams
> http://www.dominicwilliams.net
> 
> ----
> 
>