Programming components

erlang-list <>
Fri Aug 26 17:49:49 CEST 2005


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.

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

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

Cheers,

Dominic Williams
http://www.dominicwilliams.net

----




More information about the erlang-questions mailing list