Re: [m-users.] Coding style
"Richard O'Keefe" <[email protected]> Sun, 25 Jan 2026 00:48:51 +1300
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <CABcYAdJwjy0dSWE6rfDHdeS78bPuuERS+Bgog4EJnb4-_tdLjg@mail.gmail.com> |
--===============8052484953490819909==
Content-Type: multipart/alternative; boundary="00000000000043744e064920dc80"
--00000000000043744e064920dc80
Content-Type: text/plain; charset="UTF-8"
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 <[email protected]> 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 [email protected]://lists.mercurylang.org/listinfo/users
>
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.mercurylang.org/listinfo/users
>
--00000000000043744e064920dc80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"></div><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace">Let's consider line-wrapping.</div><div=
class=3D"gmail_default" style=3D"font-family:monospace,monospace">There ar=
e at least four levels that wrapping could be done at.</div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace">1. Character level.=
=C2=A0 When you reach column N-1,</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">=C2=A0 =C2=A0whack in a \ and continue=
on the next line.</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace">2. Token level.=C2=A0 When the next token would not fit=
in the current line,</div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace">=C2=A0 =C2=A0add a line break.=C2=A0 Ideally, indent=
it.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace">3. Phrase level.=C2=A0 Pick some major phrase type(s) in the language=
and</div><div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace">=C2=A0 =C2=A0insert line breaks while trying to preserve phrases inta=
ct.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">4. Semantic level.=C2=A0 Add line breaks in a way that disguises the</=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=C2=A0 =C2=A0logical structure of the code as little as possible.</div><div=
class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">Sa=
dly, emacs works at level 1.=C2=A0 It doesn't even keep *tokens* intact=
,</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e">happily inserting line breaks not merely in comments and strings but</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">ev=
en in numbers and keywords.=C2=A0 For me, the result is that emacs line-</d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">w=
rapping is a major impediment to readability.=C2=A0 Backslashes in the</div=
><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">rig=
htmost column of the window are to me as the chirping of the</div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace">ceiling bird.=
</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace=
"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace">There have been language-BASED=C2=A0editors that enforced the rules=
of</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">the programming language as you typed and laid the code out by the</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">bo=
ok instead of the way you wanted it.=C2=A0 I used one and hated it,</div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">but it=
*did* respond rationally to both narrow and wide lines.<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace">We'=
ve had a number of discussions in the Erlang mailing list over the</div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace">years a=
long the lines of "what do I do when my functions get so big</div><div=
class=3D"gmail_default" style=3D"font-family:monospace,monospace">that the=
indentation pushes stuff too far to the right" where the</div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">consensus i=
s "don't do that", "don't be scared to write small f=
unctions",</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace">"rewrite for clarity", "don't be scared=
of vertical space", and such-like.</div><div class=3D"gmail_default" =
style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace">Demented elder anecdo=
te time:=C2=A0 during my PhD studies I met a programmer</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">who wrote in an Al=
golish AI programming this way:</div><div class=3D"gmail_default" style=3D"=
font-family:monospace,monospace">=C2=A0- he began each function on a new li=
ne</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospa=
ce">=C2=A0- he put a space between tokens only when forced to</div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace">=C2=A0 =C2=
=A0(this includes NEVER using any indentation)</div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace">=C2=A0- he pressed the retu=
rn key only when the next token would not</div><div class=3D"gmail_default"=
style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0fit on the current =
line or at the end of a function.</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">In Erlang terms, the result would have=
looked like</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace">handle_call(get_nodes,_From,Nodes)->{reply,Nodes,Nodes};<b=
r>handle_call(get_node,_From,[{Load,N}|Tail])->{reply,N,Tail++[{Load+1,N=
}]};<br>handle_call({attach,Node},_From,Nodes)->case lists:keymember(Nod=
e,2,Nodes)<br>of true->{reply,already_attached,Nodes};false->erlang:m=
onitor_node(Node,<br>true),spawn_link(Node,pool,statistic_collector,[]),{re=
ply,attached,Nodes++<br>[{999999,Node}]}end;<br>handle_call({spawn,Gl,M,F,A=
},_From,Nodes)->{reply,N,NewNodes}=3Dhandle_call(<br>get_node,_From,Node=
s),Pid=3Dspawn(N,pool,do_spawn,[Gl,M,F,A]),{reply,Pid,<br>NewNodes};<br>han=
dle_call(stop,_From,Nodes)->{stop,normal,stopped,Nodes}.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">He was the rea=
son we wrote a pretty-printer for that language.</div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">But now imagine this with=
very wide lines, or wrapped by Emacs.<br><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace"><br></div></div><br><div cl=
ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Sat, 24 Jan 2026 at 05:10, Zetian Lin <<a href=3D"mailto:zaaktin=
[email protected]">[email protected]</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><u></u>
=20
<div>
<p>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.)<br>
<br>
Cheers,</p>
<p>Z Lin</p>
<p><br>
</p>
<p><br>
</p>
<div>On 1/21/26 14:15, Ralph Becket wrote:<br>
</div>
<blockquote type=3D"cite">
=20
=20
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
Hi everybody,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
Happy New Year!</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
About twenty years back, when I left Mercury to start in
mainstream commercial programming, monitors were a lot
narrower.=C2=A0 There was a strong feeling then that 80 columns was
the Right and Proper Line Length.=C2=A0 Nowadays, of course, monito=
rs
are much more generous.=C2=A0 While I reject uncontrolled line
lengths, 80 columns seems painfully tight.=C2=A0 (I think the Linux
developers moved away from this some years ago).=C2=A0 That said,
when (back) in Rome, do as the Romans do.=C2=A0 So: what's the =
modern
community position on this?</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
Cheers,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:11pt=
;color:rgb(0,0,0)">
Ralph</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
users mailing list
<a href=3D"mailto:[email protected]" target=3D"_blank">users@list=
s.mercurylang.org</a>
<a href=3D"https://lists.mercurylang.org/listinfo/users" target=3D"_blank">=
https://lists.mercurylang.org/listinfo/users</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">users@list=
s.mercurylang.org</a><br>
<a href=3D"https://lists.mercurylang.org/listinfo/users" rel=3D"noreferrer"=
target=3D"_blank">https://lists.mercurylang.org/listinfo/users</a><br>
</blockquote></div></div>
--00000000000043744e064920dc80--
--===============8052484953490819909==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXNlcnMgbWFp
bGluZyBsaXN0CnVzZXJzQGxpc3RzLm1lcmN1cnlsYW5nLm9yZwpodHRwczovL2xpc3RzLm1lcmN1
cnlsYW5nLm9yZy9saXN0aW5mby91c2Vycwo=
--===============8052484953490819909==--