[m-users.] Coding style

[Richard O'Keefe]

Let's consider line-wrapping.
There are at least four levels that wrapping could be done at.
1. Character level.  When you reach column N-1,
   whack in a \ and continue on the next line.
2. Token level.  When the next token would not fit in the current line,
   add a line break.  Ideally, indent it.
3. Phrase level.  Pick some major phrase type(s) in the language and
   insert line breaks while trying to preserve phrases intact.
4. Semantic level.  Add line breaks in a way that disguises the
   logical structure of the code as little as possible.

Sadly, emacs works at level 1.  It doesn't even keep *tokens* intact,
happily inserting line breaks not merely in comments and strings but
even in numbers and keywords.  For me, the result is that emacs line-
wrapping is a major impediment to readability.  Backslashes in the
rightmost column of the window are to me as the chirping of the
ceiling bird.

There have been language-BASED editors that enforced the rules of
the programming language as you typed and laid the code out by the
book instead of the way you wanted it.  I used one and hated it,
but it *did* respond rationally to both narrow and wide lines.

We've had a number of discussions in the Erlang mailing list over the
years along the lines of "what do I do when my functions get so big
that the indentation pushes stuff too far to the right" where the
consensus is "don't do that", "don't be scared to write small functions",
"rewrite for clarity", "don't be scared of vertical space", and such-like.


Demented elder anecdote time:  during my PhD studies I met a programmer
who wrote in an Algolish AI programming this way:
 - he began each function on a new line
 - he put a space between tokens only when forced to
   (this includes NEVER using any indentation)
 - he pressed the return key only when the next token would not
   fit on the current line or at the end of a function.
In Erlang terms, the result would have looked like
handle_call(get_nodes,_From,Nodes)->{reply,Nodes,Nodes};
handle_call(get_node,_From,[{Load,N}|Tail])->{reply,N,Tail++[{Load+1,N}]};
handle_call({attach,Node},_From,Nodes)->case lists:keymember(Node,2,Nodes)
of true->{reply,already_attached,Nodes};false->erlang:monitor_node(Node,
true),spawn_link(Node,pool,statistic_collector,[]),{reply,attached,Nodes++
[{999999,Node}]}end;
handle_call({spawn,Gl,M,F,A},_From,Nodes)->{reply,N,NewNodes}=handle_call(
get_node,_From,Nodes),Pid=spawn(N,pool,do_spawn,[Gl,M,F,A]),{reply,Pid,
NewNodes};
handle_call(stop,_From,Nodes)->{stop,normal,stopped,Nodes}.
He was the reason we wrote a pretty-printer for that language.
But now imagine this with very wide lines, or wrapped by Emacs.



On Sat, 24 Jan 2026 at 05:10, Zetian Lin <zaaktin.lam at outlook.com> wrote:

> I'm used to emacs w/ line wrapping turned on so extra-long lines probably
> feel less like a serious problem to me than other people... that said, I
> try to control the line width to under 100 columns in my code. (I do make
> exceptions for certain cases e.g. in purely templating works where it's
> clear that you're just appending strings.)
>
> Cheers,
>
> Z Lin
>
>
>
> On 1/21/26 14:15, Ralph Becket wrote:
>
> Hi everybody,
>
>
> Happy New Year!
>
> About twenty years back, when I left Mercury to start in mainstream
> commercial programming, monitors were a lot narrower.  There was a strong
> feeling then that 80 columns was the Right and Proper Line Length.
> Nowadays, of course, monitors are much more generous.  While I reject
> uncontrolled line lengths, 80 columns seems painfully tight.  (I think the
> Linux developers moved away from this some years ago).  That said, when
> (back) in Rome, do as the Romans do.  So: what's the modern community
> position on this?
>
> Cheers,
> Ralph
>
> _______________________________________________
> users mailing listusers at lists.mercurylang.orghttps://lists.mercurylang.org/listinfo/users
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20260125/83904d97/attachment-0001.html>