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:firstname.lastname@example.org">
email@example.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(), ...]<br>for non-empty string, which could also be written [char()|_]. I'm<br>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
<br>annotations with the original annotation syntax, then it would be<br>worth building a tool to translate the ... and 1..n syntax. I assume<br>it should be relatively straightforward to develop a pretty printer<br>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
<br>pretty unification.<br><br>So, we might consider taking a type annotation and using it directly,<br>for example in patterns:<br>receive X when [char()|tail()], pos_integer() -> fun(X) end.<br>Or even:<br>Pid ! [char()|tail()], pos_integer().
<br><br>Also, assuming type-name functions yielded well defined values,<br>storing type annotations in ETS/DETS should be straightforward. That<br>might be a nice base for nifty tools which would like to check type<br>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:firstname.lastname@example.org">