Programming components

[Joe Armstrong (AL/EAB)]

Dominic wrote:

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of
> erlang-list@REDACTED
> Sent: den 26 augusti 2005 17:50
> To: erlang-questions@REDACTED
> Subject: RE: Programming components
> 
> 
> Hi Joe,
> 
> >> 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
> 
> I know, but I'm trying to understand why this is a
> problem. Erlang has no syntax for classes or
> inheritance, either, but last time I heard you thought
> they sucked ;-)
> 
> > 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
> 
> But that's what I like about Erlang. You get the fun
> out of functional, without the type-obsessive part.

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.
> 
> Ah, I see. It seems to me that /types/ is an
> insufficient ambition for contracts. Wouldn't it be
> more interesting to have Eiffel-like contracts for
> components? I haven't thought about this before, but it
> occurs to me right now that Erlang pattern matching
> would provide a very rich way to express preconditions,
> postconditions and invariants on a component. It would
> be even better than Eiffel!
> 
> > Processes do not have names, in the sense that
> > modules have names.
> 
> Now that's an interesting idea. In practice, it seems
> to me most people tend to have a module for a given
> process, so it's not a great shortcoming. But something
> like your suggested:
> 
> > There no file Foo.pro containing
> >
> > 	-process(foo)
> > 	-protocol(p)
> > 	...
> 
> ... would make the design more clear.

YES

> 
> > 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 :-)
> 
> OK, now I see what you mean. I just don't want the
> solution to be base on strict typing...
> 
YES - now you're getting it.

Specifying protocols will make the design clearer.





I want a strictly checkable language-neutral type system to apply at the
boundaries to components. This MUST be a dynamic checker.

	If the spec says

	{"fac", int(1..1000}} => {"result", int()} within 2578 ms

This means that a component MUST compute factorials of integers less than
1000 within 2578 milliseconds.

Suppose you now want to compute factorial 123

Do this:

	Content-Type: text/myXML
	Content-length: NNNN
	<tuple>
	 <str>fac</str>
	 <int>123</int>
	</type>

	When you parse this you MUST get {<<"fac">>, 123}

or this

	Content-Type: text/erlBin
	Content-Length: NNNN
	- a binary -

	When you to binary_to_term on this you MUST get	{<<"fac">>, 123}
	
This can be checked against the spec

Then the system Must reply
	
	Content-length: NNNNN
	Content-Type: text/myXML
	<tuple>
	  <str>result</str>
	   <int>138764893423514 ... whatever</int>
	</tuple>

Or

	Content-lengh: NNNN
	Conent-Type: text/erlBin
	[[ term_to_binary  {<<"result">>, 13827651274 (whatever :-) } ]]

Within 2578 ms

All this must be dynamically checked.

Why?

	1) Proofs might be wrong
	2) Proofs involving timeing are impossible in multi-tasking systems

I want to capture functional and NON-functional behaviour at the interface

	A => B     within Time
	******            ****
	Functional        Non-functional

Type system might give me a handle on the function but but they do not address
the non-function bit

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

/Joe