Yes, to me that stuff seems to be obvious and distracting BS. <div><br></div><div>e.g. anything "internal" isn't exported by definition, right?<div><br></div><div>There *is* an issue between making a distinction between -export for API use and -export needed for use only within the app or library.</div><div><br></div><div>Anything else is not a weakness of erlang syntax IMHO. </div><div><br></div><div>/s<br></div><div><br>On Wednesday, September 12, 2012 2:56:31 AM UTC-5, Richard O'Keefe wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I was looking at some Erlang code today,
<br>and it had comments like
<br>
<br>        % Include files
<br>        % External exports
<br>        % Internal exports
<br>        % Macros
<br>        % Records
<br>        % External functions
<br>        % Internal functions
<br>
<br>only bulked up, and present even when the sections were empty.
<br>
<br>I take the definition of a "junk comment" to be
<br>"a comment that repeats something immediately obvious
<br> from the adjacent code".
<br>
<br>I can tell
<br>  an include because it starts with -include
<br>  an export  because it starts with -export
<br>  a macro    because it starts with -defined
<br>  a record   because it starts with -record
<br>  a function because it does not start with -
<br>so most of these are technically junk comments.
<br>
<br>In fact they remind most unpleasantly of COBOL (IDENTIFICATION
<br>DIVISION, DATA DIVISION, PROCEDURE DIVISION) and Classic Pascal's
<br>rigid (label; const; type; var; procedure; begin) ordering.
<br>
<br>In fact this ordering strikes me as pernicious in a very very
<br>similar way.  Suppose for example I have a sliding window module
<br>in which there is
<br>
<br>  %------------------------
<br>  % Purging
<br>  %------------------------
<br>
<br>  purge(Window) -> ...
<br>
<br>and this function uses a number of helper functions and macros
<br>that are not used in other parts of the file.  I want to put
<br>them *here*, close by the function(s) needing them, not to rip
<br>them away from their context just because some boilerplate comment
<br>says so.
<br>
<br>In fact I had been thinking about proposing a conventional use
<br>of an attribute:
<br>
<br>  -section(creating).
<br>  -section(adding).
<br>  -section(purging).
<br>  -section(testing).
<br>  -section(formatting).
<br>
<br>This is something that is already allowed by Erlang syntax, so there
<br>is no actual language change.  The proposal is to use _this_ attribute
<br>for _this_ purpose: *semantic* sectioning.
<br>
<br>Yes, the debt to the Smalltalk 4-pane browser and its "method
<br>categories" *is* pretty obvious, isn't it?
<br>
<br>The function of the -section attribute is to provide something a
<br>text editor can set automatic bookmarks from or at least let you
<br>search for, that _cannot_ be trivially determined from the source
<br>code.
<br>
<br>Have I missed an important benefit of the rigid syntactic ordering?
<br>
<br>While I'm at it, why don't other people sort their export lists into
<br>alphabetic order?
<br>
<br>function and its supporte
<br>
<br>______________________________<wbr>_________________
<br>erlang-questions mailing list
<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="bgU2Gu6Q7VMJ">erlang-q...@erlang.org</a>
<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br></blockquote></div></div>