Fri Aug 26 17:49:49 CEST 2005
>> 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
> 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
... 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...
More information about the erlang-questions