Is this paper publicly available somewhere? I think it would be interesting to read.<br><br>Best regards,<br>Kirill. <br><br><div><span class="gmail_quote">On 10/7/07, <b class="gmail_sendername">G Bulmer</b> <<a href="mailto:gbulmer@gmail.com">

gbulmer@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've been reading the paper "A language for specifying type contracts

<br>in Erlang and its interaction with success typing' that was presented<br>at the Erlang workshop. I think this is a good, useful and valuable<br>piece of work.<br><br>As far as I can see, there are only 2 pieces which are not covered by

<br>existing Erlang syntax:<br>1. a range of values, like (0..255), and (0..), and<br>2. "..." which seems to be interpreted as 0 or more.<br><br>IMHO, it would be a good idea to stay within Erlangs existing syntax,

<br>and avoid extensions.<br>Case one, could be dealt with using a sequence, seq(0,255) with a<br>reserved value for infinity, maybe inf(). I'd be happy inventing a<br>new function, it doesn't have to be seq().<br>

Case two appears to be the same as _. The example was [char(), ...] for non-empty string, which could also be written [char()|_]. I'm happy to use other alternatives like a 'magic' function, e.g. tail().

<br><br>What benefits do I think we'd get by staying within Erlang syntax?<br>1. There is little new to learn.<br>2. The parser for type contracts (type annotations) is already<br>written. This lowers the bar for others to reuse the type annotation

<br>information. I believe there is already a well defined representation<br>for parsed Erlang which may reduce the amount of work to reuse<br>annotations even more.<br>3. I believe there is already a well-defined mechanism for saving

<br>parsed Erlang in Beam files, so a tool needn't deal with Erlang<br>source at all.<br>4. Erlang syntax could be extended in the future, without having any<br>syntax 'stolen' by type annotations.<br><br>It was pointed out in the workshop that the syntax was proposed by

<br>Philip Wadler and Simon Peyton Jones. I accept these guys understand<br>more about types than I ever will. But, I don't think they are likely<br>to confuse surface syntax with underlying semantics. The underlying<br>

semantics seem to be clear. I am willing to believe I have missed<br>some subtlety, but otherwise staying within Erlangs existing syntax<br>seems to have the most benefits.<br><br>If there is a lot of work which has been expended on building

annotations with the original annotation syntax, then it would be worth building a tool to translate the ... and 1..n syntax. I assume it should be relatively straightforward to develop a pretty printer based on the existing type contract parser.

<br><br>So that is my main point, but I started to think, if the type<br>contract/annotation syntax is cast within the syntax of normal<br>Erlang, then we can consider using it within normal Erlang code. I<br>don't think it gives any more power than guards, but it would be a

pretty unification. So, we might consider taking a type annotation and using it directly, for example in patterns: receive X when [char()|tail()], pos_integer() -> fun(X) end. Or even: Pid ! [char()|tail()], pos_integer().

Also, assuming type-name functions yielded well defined values, storing type annotations in ETS/DETS should be straightforward. That might be a nice base for nifty tools which would like to check type annotations, maybe between versions of code.

<br><br>Summary: I think here are some genuine benefits for type contracts to<br>stay within Erlang syntax.<br>G Bulmer<br><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">

erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br>